Комментарии 96
Это не просто реверс инженеринг, это уже следующий уровень, даже не могу адекватно название придумать.
Аплодирую стоя.
p.s. помню фантастические сериалы типа звёздные врата, где учёные за дни и считанные годы разбирались с железом и софтом чужой цивилизации..
Полагаю вы занимаетесь именно этим только взаправду.
p.p.s. не думаю, что прошивку того же квантового процессора будет так просто разобрать, да просто нейронная сеть поставит исследователя в тупик
По длине бинарника можно прикинуть, что за зверь. Прошивка для 8битки вряд ли будет больше 64Кб. Ну и исключить известные архитектуры, типа 8080, Z80, dsPIC.
А еще, позвонить заказчику и попросить сфоткать начинку подробнее.
или в даташитах на известные MCU поискать наиболее часто встречающиеся в бинарнике опкоды?
в авторах вроде указаны люди с к.ф.-м.н. итп учеными степенями, но с системным подходом похоже проблемы…
Мир тесен…
Да, действительно очень и очень тесен.:) Тем более логично, что встречи итшников происходят на сайте хабра:)
PS До сих пор рассказываю всем историю как я чуть не сдал Чернову А.В программу на нобелевскую премию на практикуме:) Но не сдал все же.
Я встречал (дорабатывал) такой изврат, как виртуальная ассемблерная машина на ассемблерной же прошивке для PIC16.
Для реально существующих процессоров намного проще проверять по карте памяти (порты ввода/вывода, регистры периферии и т.п.)
Но от вас же просили компилируемый исходник, т.е. где-то существует тулчейн под вполне конкретный проц? А для этого тулчейна существуют вполне конкретные заголовочные файлы, ибо писать (uint16_t)0x4000080A=01 вместо GPIOA->ODR=1<<CS в конечном исходнике было бы несколько странно…
Плюс, например, комбинация режимов периферии (таймеров) и DMA, обвязанных ещё и схемотехнически, без знания периферии камня, схемы и осциллограмм в готовом устройстве — превращается просто в набор бессмысленных присвоений и адресов. Которые, на самом деле, являются обработчиками прерываний от DMA, скажем.
Ну то есть, видно, что труд вами проделан большой, но за абстракциями и недоговорённостями смысл потерялся.
Пардон, (uint16_t)a=b вместо
GPIOA->ODR=1<<CS;
Ему требовался алгоритм управления в виде компилируемой С-программы...
И как вы собирались без тулчейна выдать ему компилируемую C-программу? =))
То, как мы в итоге разбирались с физикой, в рамках данного цикла статей мы опустим...
Если с физикой разбирались, то скорее всего у вас доступ устройству был, поэтому сделать оценку контроллера можно было.
Когда в руках живая плата — это прозванивается за 10 минут. Но в случае если есть только бинарник — было бы интересно как тут быть?
Уверен, они сделали гораздо больше количество параллельных допущений, большинство из которых не сработало. О том, которое сработало написали пост.
Как понимаете, это не про везение.
ps: ваш пример вообще не понял — ну перемешаны на плате линии данных для удобства разводки, что с того ?
Я просто не вижу чем в данном конкретном случае частотный анализ, чем то лучше банального «угадывания» по набору априорных сведений об архитектурах — кроме того что он подразумевает писанину кода.
Вы не упомянули о случае косвенной адресации, когда адрес перехода хранится в ячейке памяти. Возможно, это не очень распространено в прошивках, но очень часто встречается в бинарном коде — такие вещи, как высокоуровневые классы — это всегда таблица переходов для их методов, например.
Другой вопрос, что команд перехода может быть сильно больше одной (когда размер адресуемой памяти превышает размер регистра, фантазия проектировщика системы команд начинает бить ключом — может появиться пяток разных способов адресации в одном чипе).
Насколько часто компилятор проявляет энтузиазм, создавая подпрограммы там, где их не было в высокоуровневом коде?
AFAIK, никогда. Зато часто делает наоборот — инлайнит подпрограммы, так что в бинарнике уже нету RET/CALL.
Я бы искал операции вроде ADD и MOV как самые часто встречаемые в вообще любой программе
Им соответствуют сотни кодировок в зависимости от операндов, так что частотный поиск уже не поможет.
На так давно помогал с прототипом защиты от подобного анализа для "мягких" процессоров.
Идейно защита достаточно проста — вставляется несколько скремблеров, в частности в шину данных и в декодер инструкций, конечно с зависимостью от адреса и ключа прошивки. Технически же сложности из-за необходимости экономить cells и latency, ну и возня с toolchain. Но получается очень неплохо, можно даже специально оставлять статистические bias/skew, которые при попытке их использовать уводят в совершенно неверном направлении ;)
Возможно, эта прошивка была не украдена, а сбита ПВО.
1280 ГК РФ:
Лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения воспроизвести и преобразовать объектный код в исходный текст (декомпилировать программу для ЭВМ) или поручить иным лицам осуществить эти действия, если они необходимы для достижения способности к взаимодействию независимо разработанной этим лицом программы для ЭВМ с другими программами, которые могут взаимодействовать с декомпилируемой программой
В 200х+y году фирма, которая это делала прекратила своё существование, ну и для вишенки на торте со всех складов и из продажи исчез применённый заказной микроконтроллер…
В 200x+y+z году надо было выпустить новую партию…
По любому законодательству в этом случае можно обреверситься что прошивкой, что схемой устройства, чтобы выпустить новую партию.
У вас же редкая ситуация — прошивка на руках в легко читаемом формате, но неизвестно от какого процессора. :-).
Все история выдумана, совпадения с реальностью случайны.
Важно, что у подпрограммы одна точка входа, то есть все подпрограммы, вызывающие данную, переходят на один и тот же адрес точки входа.
Не всегда, бывает и немного кода до подпрограммы, на которую тоже прыгают. Эдакая подпрограмма с двумя входами. Не удивлюсь, если бывает и больше.
Тайна прошивок