Какая зарплата у тн вирусных аналитиков

А чего тут подсказывать? Гребанный write прямо в девайс. Что шокирует? То-то.
и любой опен джи эл и еще с ним заканчиваются системным вызовом wirte и вся недолга.
История создания win32 api известна и себя не оправдала.
Синопсис этой печальной саги таков:
Умники из micro$oft решили а давайте создадим отдельно системные апи и надстройку win32/
С точки зрения потенциала тогда это выглядело вроде бы здраво, да вот незадача история показала иначе.
Системные апи, сказали умники из микрософта, мы будем менять, кол-во аргументов, названия функций.
А win32 пущай юзают программеры. Таким образом интерфейс будет одинаков а мы типа, если чего
системные вызовы будем менять. В результате идея с треском провалилась после того как
в вин32 появились такие перлы CreateFileW, CreateFile, CreateFileA. И встает вопрос какого хрена
вы тут понавыдумывали, когда в линух люди все продумали заранее. Там есть ф-ция open которая все это делает
и создает файл и открывает. его. Такова печальная история винды.

 

neutronion_old_school,
CreateFile() тоже какбе и создает файл и открывает его.

 

А ты пореверсь немного и поймешь, что это не так. В результате, системные апи не так уж сильно видоизменились в винде.
И вот тебе доказательство шизофрении виндовозов.
https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365430(v=vs.85).aspx
Это зачем?
Вопрос, тогда нахрена это было надо.

 

Вот черт. А я всегда и создавал и открывал файлы только этой функцией. Хорошо, что ты подсказал, что это делается не так

 

Прогноз по ос таков, уже озвучивал, но не слушали.
Ядро везде! будет линукс и у виндовс, эппла, андроидов, суперкомпьютеров и искусственного интеллекта.
Но десктопы допускаю будут разные и возможно пропиетарный набор программ. (которые все равно у всех будут примерно
одинаковые). Это упростит жизнь всем. Системщикам, прикладникам, ядерщикам, разрабам железа. Все будет унифицированно
и приведет к взывному развитию. Мы это уже наблюдали в мобильном мире. Дальше будет только больше.
Миллион ядер, которые все равно делают примерно одно и то же не нужны с точки зрения здравого смысла.
Не надо ускорять энтропию. Нам и так осталось мало, всего-то пару миллиардов лет, если повезет.

 

тут дело принципа. Проблема в том что в виндовс куда не сунься везде такой бардак. Нагородили, чтобы стричь овец.

 

Чего? Какой apt-get? Нет у меня никакого apt-get. У меня zypper стоит, и вполне себе нормально функционирует. А вокруг у него есть оболочка YaST, которая работает либо на Qt, либо на ncurses. Что первое, что второе - это юзермодные библиотеки. Уж разработчики Unix-систем мыслили здраво и правильно отказались от того, что система должна внутри себя ещё и графон тащить, который, кстати, ещё далеко не факт что будет производителен, юзабелен и соответствовать всем современным требованиям.

 

SadKo,

#98

Я раньше думал что вы вполне адекватны, но вы пишите какую то не логичную и не соответствующую реальности чушь.

Вы видите в этом всём лишь обёртку, которую оцениваете весом - количеством системных вызовов.

Про руткиты с pae опцией я не помню, видимо вы что то не так поняли, впрочем не важно.

Программирование как вы говорите просто и логично везде и под любую систему, реальную или виртуальную. Изучить те самые системные вызовы/интерфейсы/синтаксис на уровне взял-вызвал, для реализации обычного апп больше и не требуется.

Если же углубиться в тех детали реализации, то всё становится понятным. И понятно почему адреса функций именованы(нт) - эта ось ушла далеко от доса(не просто так), принципы которого остались в никсах, до сих пор какие то прерывания.. Это тоже впрочем не важно, есть соответствующий раздел хоть и мёртвый, не нужно оживлять тут мамонта.

 

TermoSINteZ,

> И уж современным требованиям Windows графика соответствует куда больше, чем в никсах.

Всё верно. Все перспективные разработки, всё железо под нт.

Они видимо забыли путь развития этой ос, раз завернулись на сисколах. Гуй был изначально полностью ядерным. Но так как чем больше кода в ядре, тем больше бага - была принята схема по переносу возможной части гуя в менее привилегированный режим. Таким образом сейчас половина гуя работает в юзер мод, ошибки в котором никак не влияют на работу ядра. Таким образом не нужно лишнее межкольцевое переключение - это профайл. А так как шлюз лишний раз не используется, то адреса именовали и создали систему импортов.

А никсы же так и остались отсталым следствие развития доса.

 

Да я вполне адекватен, однако о венде могу говорить только по остаткам знаний восьмилетней (а то и более) давности.
Сейчас Linux only, и ваши наезды на архитектуру Linux-дистрибутивов также мне кажутся полной чушью.
Мой опыт программирования мне подсказывает, что чем проще интерфейсы, тем они стабильнее и юзабельнее.
Если же интерфейс предоставляет по 10 функций, которыми можно сделать примерно одинаковые вещи, значит, что-то не так с этм интерфейсом.

Но, опять же, не буду распыляться, а то опять начнётся холивар Win vs Linux vs Mac. Каждый хвалит свой инструмент (читать хлеб) и ругает чужой. Это нормально.

 

Ну хорошо, с графикой все так же как и в виндовс. Хотя писать туда тоже можно но Для скорости вывода графики нужен прямой доступ к железу из юзермода.
Тут и у винды и у линуха принципиально подходы одинаковы. И это несколько большая часть, чем просто ядро конечно. В силу опять повторюсь необходимости быстрого вывода графики на экран. Но в конечном счете все сводиться к тому, что пишется что-то в память, неважно будь она системной или графической карты. Очевидно, что для вывода графики, графической карте нужна информация в разных ипостясях. Будет ли она сама считать синусы и косинусы углов и других графических прибамбасов, либо это будет делать юзеровская библиотека. ioctl - это скорее настройка дров, а не обмен данными графическими.
Графика - особый случай. У нас речь идет о сис колах в которых линух использует их как есть, а винда юзает посредника(кривого) в виде win32/64/ Когда-то какйо-то умный человек сказал: "Не плоди сущностей больше чем это необходимо."
по графике: https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/

 

я бы не стал так безоговорочно пиарить винду. Сони Плейстейшен на unixax построено. И это только начало. Как линух отжал в мобилах в спутниках и марсианских роверах, так отожмет усех и в графике. Дай время и все встанет на свои места.

 

Тендеция показывает, у линуха будущее не в следствии того, что он лучше всех, а в том, что его архитектура и лицензия не оставляет другим в будущем шансов. Читал что эппл поддерживает сисколы и команды юниксовские. Не могу сказать точно не лез в эппл. Но если это так, то это обозначает только один большой факт: эппл уже морально и технически готова перейти на ядро линукса.

 

TermoSINteZ,
Я тебя понимаю, ты специалист вроде в написании дров по графич. картам. Но не нужно быть семи пяди во лбу, чтобы понимать, что графическая карта требует:
1) настройки ioctl
2) писать либо прямо в карту, либо используя ось.
3) графические манипуляции с данными. Либо это делает карта(что естественно быстрее, опять не надо быть Эйнштейном, чтобы это понимать.)
либо это делает юзермодовская библиотека.
И резюмируя. Как реверсеру, ему все равно кто как там работает, ему нужно знать только одну простую вещь:
Любое устройство получает или принимает данные. in и out. Это все что нужно понимать. И вот в этом месте
где пишется и читается данные. В этой точке мы встаем и аналим, кто же подставил кролика Роджера?

 

TermoSINteZ, Ок. Раз ты специалист в этой области, я -нет.
Тогда ответь на пару простых вопросов, сначала по винде.
1) Кто создает графику скажем сцены?
2) Как эта графика передается на исполнение карте?
поскольку ты написал, что у винды свой дров для взаимодействия с дровами проприетарных граф. карт, то все сводится к deviceIoControl и WriteFile? или я что-то упустил?
создается IRP пакет с данными и посылается. Так в граф. картах или они придумали какой-нибудь еще более изощренный механизм, который все равно сводится к чтению записи данных в память.
Вот и все.

 

TermoSINteZ,
Спасибо, дружище. Но все же я настаиваю там есть WriteFile и он вызывается постоянно, мне даже реверсить этого не надо.
А как же иначе посылаются данные из юзермода в кернел по-твоему? Да, возможно все что ты описал и верно, но это
очень сложная точка зрения программиста. А точка зрения хакера такова, так у них происходит команда writefile
Если отбросить все хрень.
mov esi, [esp+10h+arg_0]
mov edx, ecx
lea edi, [eax+edi*2]
shr ecx,2
rep movsd
(живой пример, как вариант, естесственно с нужными привелегиями, которые у ядра -божественные)
Хакер это тот кто использует систему не как написано в документации, а так как ему хочется. Т.е. идет к сути.
Суть всех этих манипуляция заключается, что данные нужно переправить в память либо устройства либо оперативки.
То, что ты описал это сложная структура данных, но от этого данными они не перестают быть. Вот в чем дело.
Поэтому я все же настаиваю, что все сводится к WriteFile. Скоро доберусь до одного проекта, там есть директХ
вот и покажу на примере.