Хочу изменить дефолты, которые прописывает рап и посмотреть, что из этого выйдет. Если я все правильно понял, он должен сам себя разлочить.



А мне всегда казалось, что именно 128....

Отвечу сам себе.
RAPx HASH : E9EFF4BFAA5393217CA6B17755FC3E14
Это первые 16 байт хеша SHA1 одного из RSA ключей. МТ-бокс обзывает этот ключ ROOT_KEY. Вот только нафиг понадобилось его хешировать, не пойму. Если это защита от подмены ключа, то как-то она слабовата... А больше никакого разумного объяснения придумать не могу.

Это просто как-бы определитель, а какую подпись должен иметь лоадер или любое другое подписанное образование. Т.е. если он "жигули", то мы используем мотор от жигулей, а не от тойоты. Что такое мотор, какие функции он выполняет и какой он имеет шаблон крепления в названии ничего не сказано. Вообще эта штука называется Manufacturer Public Key Identifier.

MD5 именно 128 бит.

Подобная технология применяется при формировании строгих имен сборок в Microsoft .NET и называется "маркер открытого ключа" ("Public key token"). Предназначена фактически для упрощения идентификации и сравнения RSA ключей. То есть, скажем, есть у нас большой список RSA ключей и нужно как можно быстрее определить, входит ли наш ключ в этот список. В этом случае можно хранить не сами ключи, а их маркеры и их же сравнивать.

Осталась одна проблема, которую я пока решить не могу. Есть RSA-подпись, которой подписано MCU. Есть 3 ключа, одним из которых подписано MCU. Каким конкретно, определить не могу, да и хрен с ним, не трудно и перебрать. И есть какая-то функция, которой подписанные данные сворачиваются в 128 байт. Вот эту функцию я пока разгадать не могу. А без нее там делать нечего.
Я вижу 2 варианта:
1. Разработчики обкурились какой-то дряни и давай выдумывать какие-то самопальные хеш-алгоритмы.
2. Вся безопасность этой системы основана на том, что никто не знает вышеупомянутой функции. Ибо пока я не вижу, что могло бы мне помешать подменить ключи.
Вся работа встала, пока не будет найдена эта хеш-функция, если ее вообще когда-нибудь удастся найти...

Вы в курсе, что RSA несимметричный алгоритм??? Какие ключи Вы собрались перебирать???

а он наверно собрался приват експоненту подбирать брутфорсом
http://theory.stanford.edu/~dabo/papers/RSA-survey.pdf
http://www.rsa.com/rsalabs/node.asp?id=2092
http://www.rsa.com/rsalabs/node.asp?id=2093
голые факты в деньгах!

Тут есть одна принципиальная вещь. Хеш-алгоритмы (рассматриваем как подкласс крипто-алгоритмов), или другие крипто-алгоритмы они могут и не изобретать. А вот перемешивание данных относительно самих себя- это им никто не запрещает делать. Этого даже лицензировать не надо. Сколько я наблюдал защит от телефонов, - все они основаны на использовании "чистого" алгоритма + перемешивание и перетосовка входных и/или выходных данных. Зачастую даже обходятся без "чистого".
"ох и не легкая эта работа - из болота тащить бегемота..."
Вообще, если не "зацикливаться" на nokia и внимательно посмотреть на примере других "производителей", то цифра 80h приобретёт чуть ли не эпическое значение для подписей. Посмотри подпись SE-шных баб - сертификаты по 0x80 байт. ОДМ алкатели и моторолы - 0x80 байт. и т.д. Кроме того есть примеры среди этого техасовского выводка, где boot расположен не в core, а "эмулирован" в прошивке. Вот где можно "подсмотреть" и приоткрыть тайну 0х80-ти байт. :-)

Но проблема не в идентификации алгосов. Рано или позно упрёшься в изюм (знаете, как говорят - "изюминки ей не хватает"). И вот какие-то 40 или 56 бит изюма так переsрут тебе весь твой труд, что станет грустно и обидно за бесцельно прожитые солнечные дни :-)

Всего в прошивке найдено 9 открытых RSA-ключей. 6 из них не имеют отношения к подписи MCU. Стало быть, остается 3. Вот их я и собрался перебирать.

Шутниг А кто мешает сгенерить другую пару ключей и подменить открытый ключ вместе с подписью? Должна быть какая-то защита от подмены ключа, но я ее там в упор не вижу.

Может и так. Но мне непонятен один факт. Просто так никто ничего делать не будет. Если защита сделана правильно, нет никакой нужды перемешивать данные или другими способами затруднять идентификацию алгоритмов. Почему бы просто не взять SHA1(тем более что он там уже использовался) и зашифровать RSA? По правилам криптографии секретными должны быть только ключи, но не алгоритмы. Если безопасность хоть немного зависит от того, знает взломщик алгоритм или нет - плохая защита.
Там точно есть какая-то уязвимость, будем искать...

Наверное подпись MCU зашифрована RSA алгоритмом, так как RSA не хеш-функция, а алгоритм шифрования - блок на вход-такой же блок на выход.
То есть RAP для определения целостности данных, поступает следующим образом: вычисляет подпись MCU(кстати какого она размера ?), дешифрирует подпись(та что идет с MCU) открытым ключом(для дешифровки подписи), и сравнивает, если сравнение прошло успешно, то проверяет хеш подписи(для завершения авторизации MCU).
Можно сразу сделать вывод что закрытый ключ(каким шифруется подпись MCU) не хранится даже в RAP.
И есть пара вопросов Sniper-ру:
1.Одинаковы ли ключи в разных моделях ББ5( ну или в разных версиях RAP).
2. Отличаются ли ключи в разных прошивках одной модели ?
3. Если я прав,и подпись MCU зашифрована RSA алгоритмом, каков алгоритм вычисления подписи(или контрольной суммы) MCU ?
4. Если верен п.3 и известен алгоритм вычисления подписи, не пробовал ли ты самопально написать программу по RSA дешифровке подписи что бы точно определить нужный ключ ?
И просьба: Если можешь выложи в нех отдельно части с подписью, хеш, и тремя ключами.

1. В 6630, 6680, 6681, N70 одинаковые. В N91(тот же RAP) другие. Они разные даже в N91 4Gb и N91 8Gb. То есть от версии RAP ключи не зависят.
2. Пока отличий не нашел. Но это не значит, что их не может быть.
3. Если бы я это знал, задача уже была бы решена.

Попробую объяснить все поточнее.
X - подписанная часть прошивки. Теоретически может быть любой длины.
F(X) - неизвестная пока хеш-функция или нечто подобное. Сворачивает Х в нечто длиной не больше 128 байт.
Y - подпись длиной 128 байт.
E, N - открытый ключ RSA-1024. Есть 3 возможных варианта E и N.
Если выполняется равенство F(X)=Y**E mod N, подпись верна.

При расшифровке Y любым из 3-х ключей получается 128 байт. Поэтому имеем 3 варианта.
1. F(X) имеет длину 128 байт. (наиболее вероятно)
2. F(X) имеет меньшую длину, но перед проверкой дополняется еще какими-то данными до 128 байт.
3. В проверке участвует не весь результат расшифровки Y, а какая-то его часть.

предположим что F(x) банальный sha1 6 раз. 8 оставшихся байт просто типа битового образа предыдущих 120 байт. и что это даёт? знание хэшфункции не даёт ничего. я могу тебе сказать все алго что юзаются в дкт4(ну почти все) и ничего не изменится

Хочу ответить tevel-у: Если F(х) известная функция, то проходит атака sniper-а - меняем дефолтные значения в мцу, вычисляем простую функцию F(x) от мцу (банальный sha1 6 раз), подменяем Е и N своими значениями(вычисляем свои пары P,Q и E,N), вычисляем Y=F(x)**P mod Q (P и Q - известны) который тоже подменяем - и все МЦУ подписано, и наверное RAP сам себя разлочит ;-).

Предлагаю sniper-у, вычислить свои пары P,Q и E,N такой же длины. Поочередно менять в 3-х неизвестных ключах Е,N и соответственно перевычислять Y и посмотреть какой ключ отвечает за подпись МЦУ.
Это если ключи не входят в зону защищеную подписью.

P.S. Естественно это все возможно только в учебном варианте RSA(без перестановок данных), если используются перестановки данных до шифрования и после дешифровки - то такой метод не пройдет и все ключи окажутся не работоспособными, после их замены.

мля... может я чего то не понимаю. коллизия полная у ша1 это 2 в 80 степени. да, для криптографии это маленькое значение но никак не для мцу небольшого относительно размера.

tevel-у: Попрубую почетче объяснить - там где пишут софт вычисляется подпись мцу F(x) (неизветная хеш функция), которая затем с помошью RSA алгоритма и секретного ключа(P и Q) зашифровуется Y=F(x)**P mod Q и затем помещается в файл мцу, как и открытый ключ E и N. после вычисления RAP F(x), он по Y вычисляет F(x) и этим проверяет целостность данных в мцу. Функция sha1 имеет известный алгоритм вычисления и можно вычислить ее от модифицированого мцу. Если F(x) представим что известна, то изменив мцу, вычислив от него F(x)(свою), и создав совершенно другую пару ключей секретный(P и Q) для шифровки F(x) и открытый(E и N) для дешифровки F(x), можно зашифровав хеш F(x)(от измененного мцу) своим ключом (P и Q) Y=F(x)**P mod Q, и подменив Y-зашифрованную подпись и открытый ключ E,N - получаем проход процедуры проверки целосности данных мцу RAP-ом. Далее меняем в старой версии прошивки дефолтные значения сим-локов на разлоченный вариант + подменяем зашифрованную подпись Y и открытый ключ для ее дешифровки E и N на свои значения. Вносим изменения в 308 блок по Деджану и прошиваем измененным мцу. Вот дальше интересна реакция RAP который будет востанавливать 308 по дефолту. Как видно никакого брутфорса и поиска коллизий не нужно в этом варианте. Интересно мнение инженеров по этому вопросу, вроде все логично и можно проверить, конечно если не жалко потерять аппарат.

sniper-у: Если не трудно, посмотри изпользуется ли перестановка данных после дешифровки(возведения в степень по модулю) зашифрованной подписи. Это интересно тем что если перестановка не используется и открытый ключ не входит в подписанную зону, то все можно проверить уже сейчас. F(х) вычислить по Y, перешифровать это же F(x) уже в свой Y1 и подменить каждый из 3-й пар ключей на свой и посмотреть на каком ключе тел. будет нормально работать. А если ты посмотрел алгоритм то наверное можешь посмотреть и перестановки данных после шифрования для повышения стойкости к брутфорсу.
Хотелось бы получить ответ на 2-а вопроса, раз ты зашел так далеко:
1. Входят ли открытые ключи которые ты собрался менять в зону мцу защищенную подписью ?
2. Если ть ли перестановки данных(байтов) после возведения в степень по модулю ?
3. выложи тут ключи в нех-е хочется посмотреть на их вид.

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

аааа.... понял.. 2 Alex999/ Дык открытые ключи не лежат в мцу, они в бутроме. и изменить их никак нельзя

Вот sniper писал что в прошивке они лежат, ну тогда даже не знаю ;-(.
Может и в прошивке и в бутроме ? или скорей всего в бут роме их хеш sha ?(первые его 16 байт) то что МТ называет ROOT_key. Тогда надо искать коллизии среди сгенереных ключей. Ждем ответа snipera.

Это не есть факт. tevel, ты сам видел ключи в бутроме или это тебе кто-то сказал?
Почему-то не вижу здесь, как выложить файл, поэтому выкладываю на вебфайле. http://webfile.ru/1375884
Если ключи в бутроме, то что это?


1. Входят, но в другую зону. Всего в прошивке несколько защищенных зон. Данные, которые надо поменять, в одной зоне, ключи в другой.
2. Х\З.
3. Жми ссылку. Там 4 ключа, первый не используется для подписи интересующей нас зоны. Это тот самый ROOT_KEY, о котором я писал выше. Хотя возможно используется для подписи чего-то еще, например той же зоны с ключами.

P.S. Да, хеш ключа ROOT_KEY(вернее часть хеша) хранится в бутроме и мне это не очень нравится. Но с этим потом будем разбираться, не все сразу.

потому что если ключи не в бутроме то получается бред-раз.
2- я знаю как организована защита в дкт4, и не думаю что в бб5 будет менее параноидально.
3- в 2020 проце именно в бутроме