| Сейчас на форуме: Dart Raiden, bedop66938, morgot (+6 невидимых) |
 |
eXeL@B —› Электроника —› Пробую расшифровать firmware |
| Посл.ответ | Сообщение |
|
|
Создано: 26 августа 2011 17:43 · Поправил: Fallout · Личное сообщение · #1 Ковыряю сейчас один девайсик на АРМ процессоре. Чип защищен от считывания. Судя по прошивки она зашифрована блочным ( блок - 64 бита ) алгоритмом.... похоже на TEA. Точно знаю некоторые места прошивки в незашифрованном виде.... Пример: часть до шифра: Code:
после шифра: Code:
Как видно из этих кусков, то что шифруется блоками по 64бита... ибо результат зашифровки первых 64 бит такой же как и вторых.... вот еще пример с нулями: исходный кусочек: Code:
после шифра: Code:
как видно абсолютно таже картина..... может быть у кого то есть опыт с этим алгоритмом ( или может тут, что то другое может быть ? ) еще заметил одну вещь.... если сравнить два шифрованных файла прошивки ,в них есть идентичные блоки.... причем иногда размером более 500 байт... хотя основная часть прошивки даже в её начале ( где предполагается, что данные одинаковые ) разные.... поэтому странно толь используется один и тот же ключ ( наверное должно быть так ибо я должен иметь возможность обновить прошивку с любой версии ) Толи данные преобразовываются перед шифровкой например XORом используя номер версии прошивки... ( 4 байта в конце прошивки - её версия ) толи еще что.... п.с: так же заметил ,что практически не сжимается шифрованный файл архиватором.....  |
|
|
Создано: 26 августа 2011 18:10 · Личное сообщение · #2 Не для тегры фирмварь случайно ? Так там AES 128 bit - http://androidroot.mobi/technical/tf-secure-boot-key/ |
|
|
Создано: 26 августа 2011 20:03 · Личное сообщение · #3 Написано же, блок - 8 байт, а не 16. ----- старый пень |
|
|
Создано: 27 августа 2011 09:02 · Личное сообщение · #4 Не имея данных про железяку - вариант только перебор или счастливый случай ;) |
|
|
Создано: 27 августа 2011 11:35 · Личное сообщение · #5 Rus Нет, не для него.... а какие данные помогут кроме того, что это ARM процессор ( производитель NXP серия LPC17xx ) ? Я про то, что это не телефон ,а просто девайсик который управляет внешними устройствами через USB порт компьютера... доступ соответственно имеется только к бутлодеру.... если понять алгоритм то можно сделать инжект своего кода и сдампить таким образом через тот же интерфейсный порт всю прошивку.... но вот это и есть самое сложное 
|
|
|
Создано: 27 августа 2011 13:30 · Личное сообщение · #6 Fallout Основных вариантов два: либо дешифрует прога в персоналке, которая общается с загрузчиком и тогда надо колоть ее, либо сам бутлоадер - тогда надо колоть его. В угадайку здесь играют редко и еще реже из этого что-то получается. |
|
|
Создано: 27 августа 2011 16:29 · Поправил: Fallout · Личное сообщение · #7 tundra37 Извиняюсь если не полностью изложил информацию.... я конечно же полностью разобрал ПО для обновления firmware... включая протокол обмена и тд. Расшифровкой прошивки занимается сам бутлодер... ПО ( обмен идет в текстовом режиме, окончание строки - символ перевод каретки '\r' ) лишь говорит бутлодеру по какому адресу записать блок , далее берет этот блок из прошивки и кодирует его в UUE ( аля Base64 ... разбиваются данные по 6 бит, и добавляется 32 к полученному значению ) ибо весь обмен идет в текстовой форме... |
|
|
Создано: 27 августа 2011 17:41 · Личное сообщение · #8 А бутлоадера нет никакой версии? ----- Yann Tiersen best and do not fuck |
|
|
Создано: 27 августа 2011 18:05 · Поправил: Fallout · Личное сообщение · #9 К сожалению нет.. бутлодер внутри чипа... нашел еще одну интересную вещь на других прошивках... Зная что это прошивка под арм и то, что по адресу 0 в ней начало таблицы прерываний с известным содержимым ( проверял собирая под этот чип тестовый код, шифрованая часть подтверждает это ) что должно шифроваться двумя одинаковыми группами по 8 байт... а так же ,что по адресу 0x40 от начала должны быть нули... что подтвержается шифрованием их одинаковыми 8 байтными блоками тоже.... я очень удивился когда увидел что все мои предыдущие догадки совпадают и там ( чипы одинаковые в разных девайсах ) но только в этом случае все было сдвинуто от начала прошивки на 8 байт... и первые 8 байт это я думаю ничто иное как ключ для расшифровки... ... так как в разных версиях прошивки содержимое по разному пошифровано... и таким образом - это означает что ключи расшифровки лежат не в бутлодере.... ибо я могу на старую прошивку прошить самую новую без обновления до предыдущих версий.... ... в итоге я думаю что в первом случае ключ находится в самом бутлодере ... а во вторых случаях в самой прошивки... если решить второй случай тогда это поможет узнать алгоритм шифрования и решить случай номер 1.... прикладываю файлы прошивок если кому интересно firmware_v1, 2, 3 - шифрованые прошивки ( первые 8 байт - скорее всего ключ для расшифровки, таким образом это вроде не TEA ....или это часть ключа от TEA а вторая всегда одинаковая или это вообще RC5 ) , firmware_wo_crypt - прошивка от одного из девайсов без шифрования... но для такого же камня... просто для примера ... последнии 4 байта - версия прошивки...  0127_27.08.2011_EXELAB.rU.tgz - analyze.zip
|
|
|
Создано: 27 августа 2011 18:30 · Личное сообщение · #10 Даже если мы будем знать что это точно TEA, то не факт что ключ в начале тоже не пошифрован, а брут 8 байтового ключа ой как продолжительный по времени процесс. ----- Yann Tiersen best and do not fuck |
|
|
Создано: 27 августа 2011 18:34 · Поправил: Fallout · Личное сообщение · #11 PE_KillЭто да... вот как раз потому, что почти зашел в тупик... решил поискать свежих идей... что странно ,что если сравнивать между собой прошивки скажем 2 и 3 то там будут большие куски с одинаковыми байтами более 900 байт подряд одинаковых... так же во всех прошивках вначале одна и таже последовательность байт с адрес 0x20 - "1B 67 00 C4 AB 11 7D 67" которая встречается не один раз.... странно оно все таки... |
|
|
Создано: 27 августа 2011 22:41 · Личное сообщение · #12 Первые 8 байт могут быть salt или random довесок к внутреннему ключу. Как вариант - попытаться найти дыру в самом бутлодыре или в уже работающей в чипе проге (если прога скажем какие-то команды с внешнего мира принимает - передавать ей неверный параметр, затереть стек переполнением и т.д. пока не свалится) и потом через таким образом разработанный exploit сдампить код бутлодыря через COM или какой другой канал. Опять же - чип так и не назван - есть ARM чипы в которых атака на залоченный flash может быть произведена через JTAG. При самом худшем раскладе - идти в соседнюю ветку где мужики с мелкоскопами и иглами фьюзы снимают. |
|
|
Создано: 28 августа 2011 01:10 · Личное сообщение · #13 RusДа это может быть что угодно в том то и дело.... чип я уже говорил из серии LPC17xx... если конкретно то LPC1754 различий просто почти нет.... всего есть 3 CRP уровня защиты... в данном варианте CRP2 то бишь доступ по JTAG отключен ,есть только доступ к ISP ( процессор может загружать внутренний ( прошитый производителем ) бутлодер ) ,но в CRP2 если загрузить внутренний бутлодер процессора то возможно только ограниченное количество команд ,а именно стереть полностью чип и записать новый код.... стереть определенный сектор или изменить определенный сектор нельзя.... можно стереть только весь чип... так что я думаю толку мало будет ... данная затея не коммерческая, а просто дать всем возможность сделать данный девайсик .... будем капать.... |
|
|
Создано: 28 августа 2011 08:58 · Личное сообщение · #14 Это как раз вариант, который можно попытаться сломать через JTAG. Защита там сделана весьма прозаично - ею как таковой занимается bootloader и сам flash аппаратно не защищен от считывания, как это сделано у других производителей - при старте проца бутлодырь тупо (т.е. в своем коде) считывает из флеша байт флагов защиты и если что - блокирует JTAG. Кроме того, что были официальные дырки в некоторых версиях самого бутлодыря, такой подход к защите означает, что если получить управление через JTAG раньше чем bootloader начнет выполнять свои инструкции - то можно потом делать с чипом все что угодно, в том числе и считать флеш. При старте CPU его бутлодырь тактируется внутренним клоком с частотой в несколько мегагерц, но внешний jtag порт ограничений по частоте не имеет, т.е. можно успеть задвинуть инструкцию отладчика STOP, пока бутлодырь еще не успел заблокировать JTAG. В инете были статьи на эту тему, вот для lpc2 нагуглил : http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/crp-security.html |
|
|
Создано: 28 августа 2011 11:15 · Поправил: Fallout · Личное сообщение · #15 RusДа, там так и есть при старте бутлодер считывает флаг защиты из определенного адреса флеши... по поводу официальных дырок, то они были в старых версиях бутлодера... как раз основаные на переполнении буфера... в данном случае версия внутреннего бутлодера 4.1 ... в которой на сколько мне известно все пофиксено.... а вот по поводу JTAG это интересно.... но судя по диаграмме из документа: http://ics.nxp.com/support/documents/microcontrollers/pdf/user.manual.lpc17xx.pdf 32.4 Boot process flowchart Вначале идет проверка CRP ,а потом включение JTAG порта ... получается изначально он отключен... плюс если скажем знать что данная прошивка полностью обновляет чип ... тогда можно пропатчить нужное место у самой прошивки (если надеется, что все таки шифр блочный, то остальные данные будут нормальные... пострадает только 8 байт... и может даже все остальное будет нормально работать ).... лишь бы при расшифровки там не получился правильный CRP код... таким образом можно обойти защиту тоже.... в данном случае CRP должен находится по адресу 0x000002FC. там должен быть соотвенно патерн соотвествующий CRP2 0x87654321 ( CRP1 - 0x12345678, CRP3 - 0x43218765 ) |
|
|
Создано: 28 августа 2011 12:16 · Личное сообщение · #16 JTAG изначально (после reset) всегда включен в этом чипе. CRP (он же флаг защиты) читается самим бутлодером - а для этого он должен выполнять свои инструкции - т.е. надо успеть вклиниться жтагом до этого момента. Насчет переписать его поверх - это мысль, легче перебрать 1 байт чем ломать весь шифр. Если длина передается в протоколе и 1 является валидной длиной - то тереть этот байт до посинения, если минимум 8 байт, то неплохо бы знать что за данные хранятся рядом с CRP или после него, ну и нужно помнить - если это флеш, а не EEPROM, то стирается и обновляется вся страница/сектор. Вариант через JTAG более интересный, так как он универсален для всех бутлодырей в этих чипах и самое главное - неинвазивный - оригинальная прошивка в случае чего всегда остается в целости и сохранности. Я забросил эти чипы еще когда их делал филипс, а то можно было бы провести лабораторную работу по теме jtag ;) |
|
|
Создано: 28 августа 2011 12:49 · Личное сообщение · #17 Судя по диаграмме ,то JTAG включается только после проверки CRP... это и логично... может раньше было так, что JTAG по умолчанию работал ? ( статья по обходу защиты которая была выложена раньше... я думаю уже устарела ибо 5 лет спустя все таки ) ибо как то уж очень очевидный тогда способ обхода... по поводу перезаписать я думаю поправить саму прошивку и залить потом в устройство ибо загрузчик не позволяет стереть выбранный сектор... а возможно стереть только весь чип ( видимо разработчики решили повторить логику ограничений CRP2 или они пользуются ISP функциями внутри своего загрузчика ).. рискованое оно дело... если особенно загрузка потом не произойдет ,а это вероятность этого пока что 90% ) но если получится и даже я затру 4 байта рядом ( блок то 8 байт ) то потом считав прошивку уже в нормальном виде можно посмотреть алгоритм расшифровки... расшифровать оригенальную прошивку и перепрошить девайс ) |
|
|
Создано: 29 августа 2011 09:43 · Личное сообщение · #18 Хм... не прокатило.... видимо ошибся в смещении ( забыл про то, что вначале эта константа может идти... надо было затереть вообще весь сектор ) .... ну что поделать бывает... теперь будем в статике дальше анализировать... девайсик убился 
|
|
|
Создано: 29 августа 2011 10:05 · Личное сообщение · #19 jtag включен всегда после reset, ихний isp в boot rom первыми инструкциями его выключает. а кстати в ram там писать и exec тоже запрещены при crp security enabled ? |
|
|
Создано: 29 августа 2011 10:35 · Поправил: Fallout · Личное сообщение · #20 при CRP2 нельзя )... можно только стереть весь чип.... про JTAG ... учитывая что это старая фишка... ну неужели так все просто должно быть.... хм.. ладно будем капать .. прикладываю еще два файла на посмотреть... одинаковая версия прошивки ...под девайсы на одном и том же камне.... с одной и той же периферией... то бишь различаются они чуть чуть... то бишь в начале прошивки я думаю вообще не должны..... если их бинарно сравнить ,то увидим множество совпадений.... 8 байтный патерн с адреса 0x20 должны быть нули .... как и с адреса 0xD0 эти места одинаковые в двух прошивках.... да и вообще там одинаковых мест полно.... но все же таблица векторов прерываний разная.... причем видно что шифрованые блоки одинаковые... но в каждой они свои... тоже странно.... п.с: по поводу JTAG ... чип стер весь что бы проверить не изменялся ли внутренний ISP код... код оказался не изменен.... думаю залочу его сам уже и попробую метод с JTAGом если получится... 0034_29.08.2011_EXELAB.rU.tgz - 1.2.0_analyze.zip
|
|
|
Создано: 29 августа 2011 17:09 · Личное сообщение · #21 Ничего удивительного что таблица векторов у версий прошивок разная - если писать на C то так обычно и бывает. То что есть повторяющиеся блоки говорит о том что нету seed/salt - т.е. фиксированный симметричный ключ. Те байты с начала - это может быть серийный номер девайса, default установки, etc. ISP код не меняется, так как он в ROM - его кстати можно спокойно дизассемблировать (или найти в сети исходник) и посмотреть что он выполняет в первую очередь. Для JTAG нужен хитрый программатор - стандартный USB не подойдет - он должен по фронту reset (а лучше с заданным +/- смещением) защелкивать буфер заданных команд. Также можно упомянуть, что по официальной спецификации, JTAG система должна быть асинхронной по отношению к девайсам - это дает доп. выигрыш по скорости - начинают задвигают инструкцию STOP _до_ сигнала reset - и последний бит, который и вызывает ее исполнение, можно задвигать одновременно или чуть позже сброса. Правда можно отметить, что некоторые производители ради упрощения схемотехники (борьба с гонками) забивают на спецификации. |
|
|
Создано: 29 августа 2011 17:42 · Поправил: Fallout · Личное сообщение · #22 По поводу серийного номера устройства, то прошивка одна на все устройства... серийный номер прошивается в USB2COM переходник ( на основе FT245 ) через который устройство общается с компом... и он никак не участвует в шифровании... нужен лишь просто что бы различать устройства пользователю... по поводу алгоритма шифрования стало вроде известно, что используется RTEA алгоритм (*оочень высока вероятность, ну оно и видно было что блочный с размером блока 64 бита ) ( вот иногда не надо людям просить на форумах о том какую защиту им применить в их коммерческом железе... а гугл как известно иногда помогает найти по нику разработчика с офиц форума продукта ) ..... будем капать дальше спасибо за интересную информацию |
|
|
Создано: 29 августа 2011 17:47 · Личное сообщение · #23 То что это вариация чая это и так видно, только вот проблему брута ключа не отменяет. ----- Yann Tiersen best and do not fuck |
|
|
Создано: 29 августа 2011 18:01 · Поправил: Fallout · Личное сообщение · #24 PE_KillНу да перспектива брутить 128 бит ключ как то не очень радужная ... надеясь на то, что алгоритм был без изменений и тд ... так что остается только попробовать с JTAG ( хотя мало вероятно ) ну и на ошибку авторов... что тоже мало вероятно.... хотя встречал такое.... |
|
|
Создано: 06 сентября 2011 09:02 · Личное сообщение · #25 Fallout расскажи что за девайс то хоть был (понимаю что не принципиально в данном случае, просто интерересно) |
|
eXeL@B —› Электроника —› Пробую расшифровать firmware |
Для печати