Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #83, НОЯБРЬ 2005 г.

Секреты покорения эльфов

Крис Касперски ака мыщъх

Хакер, номер #083, стр. 083-106-4


Давай для разминки просто поменяем первые две команды местами: xor ebp,ebp/pop esi на pop esi/xor ebp,ebp. Подведем курсор к первой машинной команде (она расположена по адресу 80482C2h) и нажмем <Ctrl-A> (Assemble), вводим pop esi. Редактор предложит несколько вариантов ассемблирования на наш выбор: 5Eh и 8Fh C6h. Выбираем 5Eh, как самый короткий (8Fh C6h просто не влезет в отведенное место), затем точно так ассемблируем команду xor ebp,ebp.

Измененные байты редактор выделят красным цветом, что наглядно и очень красиво, но при нажатии на <F2> (save) они вновь зеленеют, подтверждая, что все исправления успешно сохранены. Полей контрольной суммы в ELF-заголовке нет, и потому заботиться о ее пересчете не нужно. Линух контрольную сумму файла не считает! А не считает он ее потому, что проектировался головой. Это же не Windows! Такое впечатление, что PE-файл проектировала толпа народу, с трудом взаимодействующая между собой. Суди сам: и Линух, и Windows поддерживают механизм отложенной загрузки по требованию. Страницы образа проецируются в память тогда и только тогда, когда к ним происходит обращение, в результате чего немедленно после запуска файл готов к работе, а все недостающие страницы дозагружаются уже потом (или не загружаются вообще, например, часть программы, ответственная за печать, вообще не будет загружена, если ни разу не был выбран пункт print). Процесс загрузки как бы «размазывается» во времени, не нервируя никакими песочными часами, которые так любит демонстрировать Windows. Но! Ведь при подсчете контрольной суммы происходит неизбежное обращение ко всем страницам, и все они загружаются в память, даже если не нужны. Получается, что у нас есть два механизма - один оптимизирует загрузку, другой ее «пессимизирует», съедая весь выигрыш. Где логика?!

А вот разработчики Линуха переложили подсчет контрольной суммы на устройства ввода/вывода, которые ее действительно считают. Конечно, это не страхует от искажений. В частности, жесткие диски контролируют только физические дефекты, но не обращают внимания на логические искажения (вирусы). Тем не менее, особого смысла в контрольной сумме, хранящейся непосредственно в самой файле, все равно нет. Если вирус может модифицировать файл, он модифицирует и контрольную сумму. По науке, контрольные суммы нужно хранить в отдельном «защищенном хранилище», и их подсчетом должна заниматься файловая система или антивирусные ревизоры. Ни того, ни другого в мире Линуха не наблюдается. Хотя они как бы есть, но ни у кого реально не установлены.

Единственную проблему представляют протекторы и упаковщики исполняемых файлов, контролирующие собственную целостность. С каждым годом их становится все больше и больше. UPX, протектор от shiv'ы... В них на первых порах лучше не внедряться!

Но мы отвлеклись. Выходим из hex-редактора, нажав <F10>, и запускаем пропатченный файл. Он запускается, подтверждая свою работоспособность. Значит, модификация прошла успешно!

Назад на стр. 083-106-3  Содержание  Вперед на стр. 083-106-5