Как дизассемблировать bin файл
Обновлено: 07.07.2024
Версия 3 процессоры семейств 12, 16, 17.
Версия 4 - изменен редактор процессоров, добавлена 18 серия. Полностью переписано ядро работы и добавлены новые возможности. Проект был заморожен, т.к. выполнил свои функции по дизассемблированию, осталась отладочная версия без сохранения. Можно самостоятельно редактировать процессоры и мнемонику команд. Интеллектуальное распознавание регистров и их битовых значений, максимально корректная работа со страницами и банками.
Инструкции
Дизассемблер для Microchip PIC контроллеров.
Инструкция по работе:
2.Загрузить .hex файл при помощи стандартного диалога.
4.Выбрать соответствующий процессор.
5.После первого прохода появиться запрос на создание заголовочного файла для имен регистров и bits.При отказе файл не создается.
6.После второго прохода,
Если получаемый файл большей длины, чем может позволить NOTEPAD, то запустится диалог запроса имени файла для сохранения в текущем каталоге. Иначе получаем возможность редактирования встроенным редактором с сохранением по стандартному диалогу. Основное отличие от предыдущих версий - возможность редактирования команд и установки и редактирование новых процессоров.
Инструкция по установке нового типа процессора:
1. Запустить диалог Setting -> Processors.
2.Выбрать или создать новую Family.
3. Создать новый процессор ( Processor -> New -> Editor -> OK).
4. Ввести разрядность ( Processor -> ComboBox(12,14,16)).
Address -> Programm - длина данных программ
Address -> EEPROM адрес загрузки в HEX файле
6.Поставить флажки на соответствующий BANK SFR(. в текущей версии не всегда о тслеживается правильно удаление флажков).
7.Выбрать количество SFR в каждом банке(SFR - специльные функциональные регистры).
8.Отредактировать или ввести соответствующие наименования регистров и bits, после каждого бита нажимать кнопку "Enter". ! Регистры на банки не отображаются, каждый банк вводить отдельно.
9.Нажать кнопку "OK" - данные сохраняться в файле Family.dis
Диалоговым окном Setting -> Instruction можно изменять мнемонику команд.
Данные по процессорам однозначно определяются файлом family.dis, по коммандам instr.dis, д ля ввода новых процессоров достаточно заменить только первый файл.
P.S. Страничные Label`s и названия SFR будут правильно определяться только при стандартных способах переключения страниц и банков данных.
1.добавлена сериализация для загрузки .hex файлов по умолчанию.
2.исправлена ошибка расширения файлов при сохранении.
3.исправлены ошибки подсчета текущей даты.
4.изменен код регистрации.
5.объеденены инструкции call и goto для 14,16-разрядных процессоров.
6.для 16-разрядных процессоров определена инструкция lcall.
7.исправлен выбор банка при выборе процессора.
1.при сериализации сразу выполняем дизассемблирование.
2.включена обработка расширения .bin файлов.
1.При открывании файла он добавляется в Recent File list(ускоренное открытие).
2.Теперь при открывании файла обновляется содержимое окна.
1.Добавлен новый тип 18сХХХ серия. Возможны пока ещё ошибки, но для того и существует отладка.
2.Полностью переделан формат ввода и хранения инструкций и процессоров. (family1.dis,instr1.dis)
3.Теперь отдельный .inc файл не создается.
4.Теперь можно копировать уже набитые процессоры.
5.При вводе названий регистров и бит, если установлены метки, то значения копируются автоматически в установленные банки.
Дизассемблер для Microchip Pic контроллеров сборный ( отладочная версия без сохранения).
Дизассемблеры и декомпиляторы исполняемых файлов
В комментариях к статьям меня часто спрашивают где взять тот или иной инструмент, используемый в исследовании. По возможности я всегда указываю ссылки, но теперь настало время самых мощных инструментов, а именно дизассемблеров и декомпиляторов исполняемых файлов. Сразу уточню терминологию. Дизассемблирование - преобразование программы из двоичного кода к ее ассемблерному представлению. Декомпиляция - процесс воссоздания исходного кода программы.
Скриншот программы dnSpy
Скриншот программы IDA Pro Advanced
IDA Pro (сокращение от Interactive DisAssembler) - один из моих основных инструментов для реверс-инжиниринга и разбора файлов. Это интерактивный дизассемблер и отладчик с поддержкой множества форматов исполняемых файлов для большого числа процессоров и операционных систем. Чтобы перечислить все его возможности потребуется целая книга. Но даже тут возможности IDA не заканчиваются. Плагин Hex-Rays для IDA Pro позволяет декомплировать ассемблерный листинг в более-менее человекопонятный псевдокод, по синтаксису похожий на C. В некоторых случаях это значительно облегчает работу. Просто так приобрести IDA Pro частным лицам практически невозможно, и дело не только в непомерной цене, а в том, что автор придерживается абсолютно неадекватной политики в плане продаж. К счастью, несколько последних версий этого замечательного дизассемблера, несмотря на все трудности, были успешно слиты в свободный доступ. Это IDA Pro Advanced 6.8, последняя доступная версия, которая работает с 32-битными системами, а также IDA Pro Advanced 7.0 и IDA Pro Advanced 7.2 для 64-битных систем. Если по каким-то причинам вы не можете использовать варез, то на офсайте есть бесплатные демо-версии с урезанным функционалом.
Скриншот программы Interactive Delphi Reconstructor
IDR (Interactive Delphi Reconstructor) - бесплатный декомпилятор исполняемых файлов и динамических библиотек. В отличие от IDA Pro, этот декомпилятор создан специально для разбора файлов, написанных на языке Delphi. Сейчас проект прекратил развитие, если какие изменения и вносятся, то исключительно косметические. Исходники для доработки открыты. Лично я пользуюсь стабильным комплектом Interactive Delphi Reconstructor 2.6.0.1.
Скриншот программы VB Decompiler Pro
Еще один специализированный декомпилятор - VB Decompiler Pro. Он работает с программами (EXE, DLL, OCX), написанными на Visual Basic. В случае, если приложение собрано в p-code, декомпилятор может разобрать его практически до исходного кода. Но даже если приложение скомпилировано в native code, в этом случае VB Decompiler анализирует и восстанавливает довольно много инструкций, чтобы насколько это возможно приблизить ассемблерный код к исходному. Это сильно упростит задачу анализа алгоритмов исследуемой программы. Честные граждане могут воспользоваться бесплатной Lite-версией с офсайта, для любителей полных версий софта есть релиз VB Decompiler Pro 10.0. Антивирусы могут ругаться на активатор, но тут вы уже сами решайте что делать.
Конечно, это далеко не полный список инструментов для дизассемблирования и декомпиляции, который есть в свободном доступе. Например, та же набирающая популярность Ghidra от АНБ может составить конкуренцию IDA Pro с Hex-Rays. Но я в этой статье перечислил лишь те программы, которыми пользуюсь сам и которые упоминаются в статьях на этом сайте.
Начинающие реверсеры, еще не познавшие все прелести чистого ассемблера, постоянно спрашивают на хакерских форумах, где бы им раздобыть
декомпилятор для Си или Паскаля. Декомпиляторов-то много, но вот результат. без дизассемблера все равно ну никак не обойтись. И вот, наконец, свершилось!
Ильфак (автор легендарного дизассемблера IDA Pro) выпустил декомпилятор нового поколения
HexRays, делающий то, что другим не под силу. Мир вздрогнул от восторга (реклама вообще обещала чудо), порождая сейсмические волны впечатлений: от оргазма до полного отвращения. Истина же, как водится, где-то посередине, и стоит обозначить эту середину, рассмотрев слабые и сильные стороны
декомпилятора, а также
области его применения.
Почему у Ильфака получилось то, что упорно не желало получаться у других? Начнем с того, что
HexRay представляет собой всего лишь плагин к IDA Pro — интерактивному дизассемблеру более чем с десятилетней историей, первая версия которой увидела свет 6 мая 1991 года. Спустя некоторое время к работе над ней подключился удивительный человек, гениальный программист и необычайно креативный кодер Юрий Харон. Вместе с Ильфаком (не без помощи других талантливых парней, конечно) они начали работать в том направлении, куда еще никто не вкладывал деньги. До этого дизассемблеры писались исключительно на пионерском энтузиазме параллельно с изучением ассемблера и довольно быстро забрасывались. Ильфак и
Юрий Харон решили рискнуть. В итоге IDA Pro стал не только основным, но и, пожалуй, единственным продуктом фирмы
DataRescue (мелкие утилиты и прочие ответвления не в счет). Стоит ли удивляться, что парням удалось решить практически все фундаментальные проблемы дизассемблирования, над которыми просто не хотели работать остальные разработчики, зная, что быстрой отдачи не будет и проект потребует десятилетий упорного труда. Самое время выяснить, что же это за проблемы такие, откуда они берутся и как решаются.
Фундаментальные проблемы декомпиляции
Компиляция — процесс однонаправленный и необратимый, в ходе которого теряется огромное количество лишней информации, совершенно ненужной процессору. Это не шутка! Исходный текст, написанный на языке высокого уровня, чрезвычайно избыточен, что с одной стороны упрощает его понимание, а с другой — страхует программиста от ошибок. Взять хотя бы информацию о типах. На низком уровне процессор оперирует базовыми типами: байт, слово, двойное слово. Строки превращаются в последовательности байтов, и, чтобы догадаться, что это строка, приходится прибегать к эвристическим алгоритмам.
Структуры и классы также «расщепляются» в ходе компиляции, и, за исключением некоторых виртуальных функций, все остальные члены класса теряют свою кастовую принадлежность, становясь глобальными процедурами. Восстановить иерархию классов в общем случае невозможно, а в принципе не сильно и нужно.
Никто из здравомыслящих людей не требует от декомпилятора получения даже приближенной копии исходного кода, но мы вправе рассчитывать на удобочитаемость листинга, а также на то, что повторная компиляция не развалит программу, а создаст вполне работоспособный модуль — тогда мы сможем вносить любые изменения в
декомпилированный текст, развивая его в нужном нам направлении. В противном случае такому
декомпилятору место на свалке, и фиксить баги декомпиляции ничуть не проще, чем переписывать подопытную программу с нуля.
Декомпиляции препятствует ряд серьезных проблем, важнейшие из которых перечислены ниже.
Что в имени твоем
Комментарии, имена функций и переменных в процессе компиляции теряются безвозвратно (исключение составляют динамические типы, имена которых в двоичном модуле хранятся как есть, а потому и тормозят, словно динозавры). Ну, комментариев в большинстве исходных текстов и так негусто, так что их отсутствие еще можно пережить, но вот без имен переменных и функций логика работы даже простейших программ становится совершенно непонятной.
К счастью, современные программы наполовину (а то и более) состоят из библиотечных и API-функций, которые распознаются классическим сигнатурным поиском. Главное — собрать обширную базу библиотек всех популярных (и непопулярных) компиляторов с учетом многообразия их версий.
IDA Pro уже давно поддерживает технологию FLIRT (Fast Library Identification and Recognition Technology), не только распознающую библиотечные функции, но также восстанавливающую их прототипы вместе с прототипами API-функций, которые, кстати говоря, могут импортироваться не только по имени, но еще и по ординалу, то есть по номеру. Чтобы превратить бессловесный номер в имя, понятное человеку, опять-таки требуется база.
Почему реконструкция прототипов так важна для декомпилятора? А потому, что она позволяет восстанавливать типы передаваемых функциями переменных, назначая им хоть и обезличенные, но все же осмысленные имена в стиле: hWnd, hModule, X, Y, nWidth, nHeight, hCursor, hMenu, hDlg. Согласись, это намного лучше, чем dword_1008030, dword_1008269, dword_1006933, что характерно для подавляющего большинства остальных
декомпиляторов.
Даже если часть переменных распознана, то это уже упрощает анализ программы и реконструкцию оставшихся переменных.
Константа или смещения
В силу архитектурных особенностей x86-процессоров константы и смещения (они же в терминах языков высокого уровня указатели) синтаксически абсолютно неразличимы, и
декомпилятору (равно как и дизассемблеру) приходится задействовать мощные эвристические алгоритмы, чтобы не попасть впросак.
А какая между этими двумя сущностями разница? Очень большая! Вот, например, в регистр EAX загружается число 106996h. Если это указатель на ячейку памяти или массив данных, то дизассемблер должен воткнуть по этому адресу метку (label) и написать MOV EAX, _offset_ lab_106996 (естественно, имя метки дано условно, и совпадение с ее численным значением абсолютно случайно — при повторной компиляции она может оказаться расположенной по совершенно другому адресу). А вот если 106996h — это константа, выражающая, например, среднюю плотность тушканчиков на один квадратный метр лесополосы или количество полигонов на морде монстра, то ставить offset ни в коем случае нельзя, поскольку это введет нас в
заблуждение при анализе, а еще, как уже говорилось, при повторной компиляции смещение может уплыть, превращая число 106996h черт знает во что. Программа либо будет работать неправильно, либо сразу рухнет (особенно, если путаница между константами и смещениями происходит не единожды, а совершается на протяжении всего листинга).
Так как же все-таки определить, кто есть кто? На первый взгляд, все достаточно просто. Если данная сущность используется как указатель (то есть через нее происходит обращение к памяти по заданному адресу: mov eax, 106996h/mov ebx,[eax]), тут и
дизассемблеру ясно, что это смещение. Но стоит лишь немного усложнить пример, скажем, передать 106996h какой-нибудь функции или начать производить с ней сложные манипуляции, то дизассемблеру потребуется высадиться на полную реконструкцию всей цепочки преобразований. Но даже тогда его решение может оказаться неверным, поскольку в языке Си индексы (то есть константы) и указатели (то есть смещения) полностью взаимозаменяемы и конструкция buf[69] не
только равносильна 69[buf], но и транслируется в идентичный машинный код, при реконструкции которого возникает очевидная проблема.
У нас есть два числа A и B, сумма которых представляет указатель (то есть существует возможность определить, что это указатель, да и то если попыхтеть), но вот что из них индекс? Увы. Формальная математика не дает ответа на этот вопрос, и дизассемблеру приходится полагаться лишь на свою интуицию да эвристику. Указатели в win32, как правило, велики, поскольку минимальный базовый адрес загрузки файла равен 100000h. Индексы же, как правило (опять! как правило!), малы и много меньше указателей, однако если у нас имеется массив, расположенный по адресу 200000h и состоящий из 3 145 728 (300000h) элементов (а почему бы, собственно, и нет?!), то тут индексы старших элементов становятся больше
базового указателя на массив, что вводит дизассемблер в заблуждение.
Код или данные
Вот так проблема! Наверное, даже самый тупой дизассемблер разберется, что ему подсунули: код или данные, тем более что в PE-файлах (основной формат исполняемых файлов под Windows) они разнесены по разным секциям. Ну, это в теории они разнесены, а на практике компиляторы очень любят пихать данные в секцию кода (особенно этим славиться продукция фирмы Borland).
С другой стороны, практически все компиляторы (особенно на Си++) сплошь и рядом используют вызовы функций типа CALL EBX. Чтобы понять, куда ведет такой вызов, необходимо установить значение регистра EBX, что требует наличия более или менее полного эмулятора процессора, отслеживающего всю историю содержимого EBX с момента его инициализации и до непосредственного вызова.
Но непосредственные вызовы - ерунда. Вот косвенные - это да! Реконструкция CALL dword ptr DS:[EBX] требует не только эмуляции процессора (то есть набора машинных команд), но и эмуляции памяти! Естественно, это на порядок усложняет дизассемблерный движок, зато нераспознанные массивы данных мгновенно превращаются в функции и, что самое главное, дизассемблер показывает, кто именно и откуда их вызывает!
Наличие эмулятора процессора и памяти позволяет также отслеживать положение регистра ESP, используемого для адресации локальных переменных и аргументов, передаваемых функциям. Если же эмулятора нет (а в IDA он есть), дизассемблер способен распознавать лишь простейшие формы адресации/передачи аргументов. Механизм, ответственный за распознание и отслеживание аргументов, носит красивое название PIT, но эта аббревиатура отнюдь не расшифровывается как «Пивоваренный [завод] Ивана Таранова», а происходит от
Parameter Identification and Tracking — идентификация и отслеживание параметров, то есть аргументов. Тех, что бывают у функций. А еще бывают функции без аргументов, но это уже другая история.
Реконструкция потока управления
Языки высокого уровня оперируют такими конструкциями, как циклы, операторы выбора, ветвления и т.д., что делает программу простой и наглядной. Собственно говоря, именно отсюда и пошло структурное программирование. А ведь когда-то, давным-давно, в Бейсике (и других языках того времени), кроме примитивного GOTO, ничего не было и программа, насчитывающая больше сотни строк, превращалась в сплошные «спагетти», лишенные всякой логики, внутренней организации и следов цивилизации.
Начиная с пятой версии в IDA Pro появился механизм графов, позволяющий автоматически реконструировать циклы, ветвления и прочие «кирпичи» языков высокого уровня. Впрочем, польза от графов была небольшой, и в реальности они только замедляли анализ, поскольку подобрать адекватный механизм визуализации и навигации Ильфаку так и не удалось… Но ведь не пропадать же труду?!
У истоков HexRays
К пятой версии IDA Pro имела в своем арсенале все необходимое для автоматической декомпиляции, причем не просто декомпиляции, а очень
качественной декомпиляции, декомпиляции принципиально нового уровня, до которого не дотягивает ни один другой существующих
декомпилятор.
Вот так и родилась идея дописать к IDA еще небольшую (на самом деле очень большую) порцию кода, переводящую китайскую ассемблерную грамоту в доступный и понятный листинг на языке Си. Закипела напряженная работа, по ходу которой выявлялись все новые и новые подводные камни, обход которых требовал времени, усилий и мозговой активности. А всякая (или практически всякая) работа упирается в деньги, тем более что у Ильфака фирма!
Включать декомпилятор в дистрибутив IDA Pro Ильфак не стал. Тому было несколько причин. Первая и главная — основной массе текущих пользователей IDA декомпилятор не сильно нужен, если они им и будут пользоваться, то лишь из чистого любопытства, запустят пару раз, плюнут и вернутся к привычному стилю жизни - анализу дизассемблерного листинга. Второе — зарабатывать на жизнь (Ильфаку) и содержать фирму как-то же надо?!
Все это привело к тому, что декомпилятор, получивший название (HexRays), был выпущен отдельным продуктом, но - внимание на экран - требующим
обязательного присутствия IDA, поскольку HexRays — всего лишь плагин. Таким образом, реверсеру, желающему упростить свою жизнь за счет автоматической декомпиляции, необходимо прибрести как саму IDA, так и
HexRays. Причем приобретать этот комплект будет совсем другая пользовательская аудитория, совсем не та, что приобретала ИДУ и почитала ее как самый лучший интерактивный дизассемблер. Интерактивный — значит, тесно взаимодействующий с пользователем (в смысле с хакером). В противовес ей, пакетные дизассемблеры стремятся к максимальной автоматизации
реверсинга, лишая пользователя возможности вмешиваться в процесс и отдавать указания.
HexRays в отличии от IDA Pro интерактивностью не обладает: она у него атрофирована еще в зародыше. Нет даже опций настройки! А там где нет интерактивности, нет и хакеров. И тут мы плавно переходим к ответу на вопрос кому нужен
HexRays.
Боевое крещение
Итак, Hex-Rays у нас на руках. Устанавливаем его туда же, где располагаются все остальные
плагины для IDA Pro, и приступаем к тестированию. В качестве объекта тестирования используется стандартный блокнот (в данном случае из комплекта поставки W2KSP0), на котором обкатываются все вирусы, все упаковщики исполняемых файлов (вместе с распаковщиками), все протекторы. словом, декомпилятор не станет исключением. А что? Блокнот - достаточно простая программа, обуславливающая тот минимум функционала, ниже которого декомпилятор из мощного программного комплекса превращается в дорогостоящую, но абсолютно бесполезную игрушку.
Загрузив notepad.exe в IDA Pro и ответив на ряд несложных вопросов мастера автоанализа, даем дизассемблеру некоторое время поработать и, когда он перейдет в режим ожидания, заходим в меню «File -> Produce File -> Create C file» или нажимаем горячие клавиши <Ctrl-F5>.
Сначала на экране появляется логотип HexRays с предложением провериться на обновления и после нажатия на OK
HexRays думает некоторое время, а когда он закончит заниматься магической деятельностью, на диске образуется файл notepad.c.
Может, мы не тот компилятор выбрали для тестирования? Вообще-то, по идее, декомпилятор должен выдавать листинг на ANSI C, поддерживаемый любым ANSI-совместимым C-компилятором, но… все мы хорошо знаем любовь Ильфака к продукции фирмы Borland. На нем написана сама IDA, на нем же вышло первое SDK… Хорошо, берем последнюю версию
Borland C++ (благо она бесплатна) и что же?! Вновь простыня ошибок и ругательств, приводящих к преждевременному прерыванию компиляции. Оказывается,
чтобы откомпилировать декомпилированный файл, над ним еще предстоит основательно поработать. Вот тебе и раз…
А вот тебе и два! Декомпилятор выдал чистый *.c-файл, проигнорировав тот факт, что notepad.exe содержит еще и секцию ресурсов, но даже если при загрузке блокнота в IDA форсировать обработку ресурсов, мы все равно ничего не получим. Ну не умеет
HexRays с ними работать и все-тут! Возможно, когда-нибудь он этому и научиться, но сейчас - нет.
Другими словами, HexRays не позволяет компилировать декомпилированные программы без дополнительной ручной работы и реально пригоден лишь для анализа. Возникает резонный вопрос: и насколько же он упрощает анализ? Чтобы не быть голословным, приведу два фрагмента кода:
if ( RegOpenKeyExA(
HKEY_CLASSES_ROOT,
"CLSID\\\\InprocServer32",
0,
0x20019u,
&hKey) )
result = 0;
>
else
cbData = 260;
if ( !RegQueryValueExA(hKey, ValueName, 0, 0, lpData, &cbData) ) v1 = 1;
RegCloseKey(hKey);
result = v1;
>
return result;
Просто? Красиво? Понятно? Элегантно? Еще как! А вот как выглядел тот же самый код в чистом дизассемблере:
.text:0100318F push ebp
.text:01003190 mov ebp, esp
.text:01003192 push ecx
.text:01003193 push ecx
.text:01003194 lea eax, [ebp+hKey]
.text:01003197 push esi
.text:01003198 xor esi, esi
.text:0100319A push eax ; phkResult
.text:0100319B push 20019h ; samDesired
.text:010031A0 push esi ; ulOptions
.text:010031A1 push offset SubKey ; lpSubKey
.text:010031A6 push 80000000h ; hKey
.text:010031AB call ds:RegOpenKeyExA
.text:010031B1 test eax, eax
.text:010031B3 jnz short loc_10031E7
.text:010031B5 lea eax, [ebp+cbData]
.text:010031B8 mov [ebp+cbData], 104h
.text:010031BF push eax ; lpcbData
.text:010031C0 push [ebp+lpData] ; lpData
.text:010031C3 push esi ; lpType
.text:010031C4 push esi ; lpReserved
.text:010031C5 push offset ValueName ; lpValueName
.text:010031CA push [ebp+hKey] ; hKey
.text:010031CD call ds:RegQueryValueExA
.text:010031D3 test eax, eax
.text:010031D5 jnz short loc_10031DA
.text:010031D7 push 1
.text:010031D9 pop esi
.text:010031DA
.text:010031DA loc_10031DA: ; CODE XREF: sub_100318F+46?j
.text:010031DA push [ebp+hKey] ; hKey
.text:010031DD call ds:RegCloseKey
.text:010031E3 mov eax, esi
.text:010031E5 jmp short loc_10031E9
.text:010031E7
.text:010031E7 loc_10031E7: ; CODE XREF: sub_100318F+24?j
.text:010031E7 xor eax, eax
.text:010031E9
.text:010031E9 loc_10031E9: ; CODE XREF: sub_100318F+56?j
.text:010031E9 pop esi
.text:010031EA leave
.text:010031EB retn 4
Согласись, что сравнение отнюдь не в пользу дизассемблера, но не спеши радоваться. Рассмотрим еще один пример:
Что делает этот код? Совершенно непонятно. То есть не то чтобы совсем непонятно, но смысл как-то ускользает. Тут требуется проанализировать, что это за переменные такие, кто еще (помимо этой функции) их модифицирует и зачем? В дизассемблере листинг выглядит схожим образом, но мощная система навигации по коду вкупе с перекрестными ссылками и подсветкой одноименных переменных/функций сокращает время анализа на несколько порядков, причем ни в одном текстовом редакторе, ни в одной среде программирования подобной системы навигации по коду нет!
А это вид в дизассемблере:
.text:01002306 loc_1002306: ; CODE XREF: sub_1002239+C4?j
.text:01002306 mov eax, dword_1008028
.text:0100230B push ebx
.text:0100230C push edi
.text:0100230D mov dword_1008BCC, eax
.text:01002312 push dword_10087D0
.text:01002318 call sub_10059A3
.text:0100231D test eax, eax
.text:0100231F jz short loc_1002328
Наш вердикт
HexRays – это, безусловно, большой шаг вперед и неплохое подспорье для начинающих, но… он не стоит тех денег, которые за него просят, к тому же (это касается начинающих), однажды потратив время на изучение ассемблера, мы обретаем возможность реверсировать что угодно и в чем угодно (на худой конец с помощью утилиты DUMPBIN.EXE, входящей в состав SDK), а обольщенные возможностями автоматической декомпиляции, мы становимся заложниками
HeyRays со всеми вытекающими отсюда последствиями.
Полную версию статьи
читай в февральском номере Хакера! Демонстрационную версию IDA ты найдешь на нашем диске. К сожалению, мы не можем выложить HexRays по правовым соображениям. На нашем диске будет видеоролик, демонстрирующий возможности HexRays.
Вот его скромный набор. Более подробную информацию можно найти в даташите на него.
Данный контроллер является собратом по линейке Intel 8049, только лишенный внутренней памяти.
Еще раз повторюсь, контроллер очень старый, однако, как мне казалось его более современные братья, которые имеют аналогичный, но более широкий набор переферии типа Intel 80c31 и другие контроллеры семейства 80с51 строятся на одной архитектуре и я даже сначала обрадовался, когда с помощью Ida pro произвел дизассемблирование и получил это:
Моему взору предстали знакомые команды и программа любезно отобразила стрелочками переходы по адресам от различных векторов прерывания. Однако радость была недолгой.
Дабы удостовериться, что дизассемблирование произведено верно, я решил повторить процедуру для другого контроллера того же семейства 8031, несильно отличающегося от 8051. Проводил это в среде разработки Phyton Code Master и получил те же самые команды. Среда чудесным образом отображала мне распределение памяти, адреса регистров
И я решил попробовать "пройтись" по программе с помощью симулятора. И буквально на второй же команде меня напрягло следующее: После выполнения второй инструкции осуществлялся переход по метке в самый конец памяти на операцию NOP, то есть минуя всю основную программу. Что-то пошло не так. Начал разбираться и обратил внимание на то, какая команда в этот момент выполнялась, начал искать ее в даташите на свой контроллер и не нашел. Это означало только одно — архитектура контроллеров разная и тот дизассемблированный файл не годится для его исполнения контроллером 8031(51), несмотря на всю их схожесть. Пришлось начать сначала, однако, все гораздо страшнее, чем я предполагал. Почти целый вечер я потратил на то, чтобы найти дизассемблер для контроллера 8039 и после первых минут поиска стало понятно, что о привычном дизассемблировании в среде разработки или той же самой IDA Pro можно забыть. Наконец, я наткнулся на сайт, где скачал дизассемблер для этого контроллера под Windows, Linux. У меня на ПК установлен Windows 7 и из под него дизассемблер не запустился, даже через эмулятор DOS-BOX и в режиме совместимости. Из под Linux — получилось, однако дальнейший процесс опишу для Win. На помощь пришло приложение Virtual PC с помощью которого друг помог сэмулировать старую-добрую XP из под которой, опять же, через консоль запустилось приложение. Выглядело это так:
после чего я получил программу работы котроллера №1 в ЭБУ в более-менее адаптированном для чтения ассемблерном виде, записанную в файл с расширением .txt.
Нужно отметить, что процесс ассемблирования производится аналогичным образом — из файла с программой в текстовом формате создается прошивка, которая потом с помощью программатора записывается в микросхему ПЗУ. Вот такая вот жесть :-)
Учитывая, что мне еще предстоит долго работать с этим контроллером и программами для него от разных моделей, пожалуй, попробую добавить в Ida Pro данный тип микроконтроллера, но это уже совсем другая история. Продолжение следует. Не переключайтесь :-)
Данный пост призван помочь настроить рабочую среду для выполнения операций по изменению прошивок ЭБУ. Задачу изменения некоторого участка кода в прошивке можно разделить на три типа:
- Изменение значений некоторых данных без изменения из количества, то есть без изменения размера прошивки, например, когда одни калибровки меняются на другие.
- Небольшие изменения кода, когда ненужные операции просто заменяются на пустые (nop) по количеству, необходимому для сохранения размера прошивки.
- Существенные изменения кода, когда без дизассемблирования и последующей сборки прошивки уже не обойтись.
Первые две задачи обычно легко решаются с помощью шестнадцатеричного редактора, в котором одни данные, по заранее известным адресам, заменяются на другие. В случае изменения кода следует помнить о сохранении смещений после редактирования, то есть размер первоначального кода должен соответствовать размеру измененного. Для достижения данного результата необходимо пустые места дополнять операциями nop, которые сами по себе ничего не выполняют, но место в прошивке занимают. Размеры команд можно посмотреть в датащитах на процессор.
Рассмотрим последний - самый сложный вариант изменения исходного текста прошивки. Процесс дизассемблирования описывать не буду, так как это отдельная большая тема, небольшие заметки можно посмотреть здесь i205dm53 reverse engineering. Введение. Будем отталкиваться от того, что дизассемблированный листинг прошивки у нас получен в IDA, теперь необходимо получить соответствующий asm файл. Для начала настроим необходимый нам диалект языка ассемблера, наиболее подходящий к нашему компилятору (о нем чуть позже). В IDA идем Options\General\Analysis в поле Target assembler выбираем 8051 Cross-Assembler by MetaLink Corporation Далее создаем asm файл используя следующий пункт меню: Здесь следует отметить, что все функции в IDA должны быть развернуты, то есть не должно быть следующих областей, так как при экспорте данные функции не попадут в листинг (для разворачивания достаточно встать на функции и нажать "+" на цифровой клавиатуре): Все, дизассемблированный листинг получили. Половина дела сделана. Далее выбираем любой текстовый редактор, в котором мы будем правит код - это может быть любой редактор, я использую SciTE. Для того чтобы полученный листинг без ошибок скомпилировался необходимо добавить самой первой строкой следующую директиву компилятора: $NOMOD51. Далее изменяем код и компилируем полученный листинг. В качестве компилятора я использую бесплатный ASEM-51. Для компиляции в командном интерпретаторе cmd, набираем команду: asemw.exe source.asm, где source.asm - листинг прошивки. На выходе получает файл source.hex, для получения бинарного файла прошивки необходимо воспользоваться утилитой hexbinw.exe из состава компилятора. Вызов данной утилиты выглядит следующим образом: hexbinw.exe source.asm.
Читайте также: