Из файла читается 320h байтый заголовок закодированной информации. Если успешно считано выполняется функция decode_nbf_header, функция в цикле побайтно передает указатель на байт буфера в функцию расшифровки alg_decode_nbf_header, она сохраняет результат по этому же указателю. При вызове функции alg_decode_nbf_header [ecx+14h] меняется. Нужно написать кодер и декодер заголовка, а алгоритм расшифровки мне непонятен. Подскажите пожалуйста, что за алгоритм используется или как его исследовать. Листинг из IDA5 .text:00408A77 call _strcpy .text:00408A7C pop ecx .text:00408A7D mov eax, [edi] .text:00408A7F pop ecx .text:00408A80 push esi .text:00408A81 lea ecx, [ebp+var_208] .text:00408A87 push [ebp+lpHeaderBuffer] .text:00408A8A push ecx .text:00408A8B mov ecx, edi .text:00408A8D call dword ptr [eax] ; decode_nbf_header .text:00406777 decode_nbf_header proc near ; DATA XREF: .rdata:off_41D6E4o .text:00406777 .text:00406777 arg_0 = dword ptr 8 .text:00406777 arg_4 = dword ptr 0Ch .text:00406777 arg_8 = dword ptr 10h .text:00406777 .text:00406777 push ebp .text:00406778 mov ebp, esp .text:0040677A push ebx .text:0040677B push esi .text:0040677C mov esi, [ebp+arg_4] .text:0040677F push edi .text:00406780 push [ebp+arg_0] .text:00406783 mov edi, ecx .text:00406785 mov eax, [edi] .text:00406787 call dword ptr [eax+8] .text:0040678A mov ebx, [ebp+arg_8] .text:0040678D test ebx, ebx .text:0040678F jle short loc_4067AB .text:00406791 .text:00406791 loc_406791: ; CODE XREF: decode_nbf_header+32j .text:00406791 movzx eax, byte ptr [esi] .text:00406794 lea ecx, [ebp+arg_4] .text:00406797 mov [ebp+arg_4], eax .text:0040679A mov eax, [edi] .text:0040679C push ecx .text:0040679D mov ecx, edi .text:0040679F call dword ptr [eax+10h] ; alg_decode_nbf_header .text:004067A2 mov al, byte ptr [ebp+arg_4] .text:004067A5 mov [esi], al .text:004067A7 inc esi .text:004067A8 dec ebx .text:004067A9 jnz short loc_406791 .text:004067AB .text:004067AB loc_4067AB: ; CODE XREF: decode_nbf_header+18j .text:004067AB pop edi .text:004067AC pop esi .text:004067AD pop ebx .text:004067AE pop ebp .text:004067AF retn 0Ch .text:004067AF decode_nbf_header endp .text:004066F7 alg_decode_nbf_header proc near ; DATA XREF: .rdata:0041D6F4o .text:004066F7 .text:004066F7 var_4 = dword ptr -4 .text:004066F7 arg_0 = dword ptr 8 .text:004066F7 .text:004066F7 push ebp .text:004066F8 mov ebp, esp .text:004066FA push ecx .text:004066FB mov edx, [ecx+14h] .text:004066FE push ebx .text:004066FF push esi .text:00406700 mov esi, [ecx+10h] .text:00406703 push edi .text:00406704 push 1 .text:00406706 pop ebx ; ebx=1 .text:00406707 xor edi, edi ; edi=0 .text:00406709 and esi, ebx ; esi=1 .text:0040670B and edx, ebx ; ebx=1 .text:0040670D mov [ebp+var_4], 8 ; var_4=8 .text:00406714 .text:00406714 loc_406714: ; CODE XREF: alg_decode_nbf_header+72j .text:00406714 mov eax, [ecx+0Ch] ; eax=4b45524e .text:00406717 test al, bl ; al==bl .text:00406719 jz short loc_40673C ; al!=bl .text:0040671B shr eax, 1 .text:0040671D mov [ecx+0Ch], eax .text:00406720 mov eax, [ecx+10h] .text:00406723 test al, bl .text:00406725 jz short loc_406730 .text:00406727 shr eax, 1 .text:00406729 mov [ecx+10h], eax .text:0040672C mov esi, ebx .text:0040672E jmp short loc_40675E .text:00406730 ; --------------------------------------------------------------------------- .text:00406730 .text:00406730 loc_406730: ; CODE XREF: alg_decode_nbf_header+2Ej .text:00406730 shr eax, 1 .text:00406732 xor eax, [ecx+28h] .text:00406735 xor esi, esi .text:00406737 mov [ecx+10h], eax .text:0040673A jmp short loc_40675E .text:0040673C ; --------------------------------------------------------------------------- .text:0040673C .text:0040673C loc_40673C: ; CODE XREF: alg_decode_nbf_header+22j .text:0040673C shr eax, 1 ; div 2 .text:0040673E xor eax, [ecx+24h] ; [ecx+24h]=7ffffff .text:00406741 mov [ecx+0Ch], eax .text:00406744 mov eax, [ecx+14h] .text:00406747 test al, bl .text:00406749 jz short loc_406754 .text:0040674B shr eax, 1 .text:0040674D mov [ecx+14h], eax .text:00406750 mov edx, ebx .text:00406752 jmp short loc_40675E .text:00406754 ; --------------------------------------------------------------------------- .text:00406754 .text:00406754 loc_406754: ; CODE XREF: alg_decode_nbf_header+52j .text:00406754 shr eax, 1 .text:00406756 xor eax, [ecx+2Ch] .text:00406759 xor edx, edx .text:0040675B mov [ecx+14h], eax .text:0040675E .text:0040675E loc_40675E: ; CODE XREF: alg_decode_nbf_header+37j .text:0040675E ; alg_decode_nbf_header+43j ... .text:0040675E mov eax, edx .text:00406760 add edi, edi .text:00406762 xor eax, esi .text:00406764 or edi, eax .text:00406766 dec [ebp+var_4] .text:00406769 jnz short loc_406714 ; eax=4b45524e .text:0040676B mov eax, [ebp+arg_0] .text:0040676E xor [eax], edi .text:00406770 pop edi .text:00406771 pop esi .text:00406772 pop ebx .text:00406773 leave .text:00406774 retn 4 .text:00406774 alg_decode_nbf_header endp
Сначала переведите все эти процедуры на язык высокого уровня (например, C). Гораздо проще будет анализировать...
Da i tak vsio vidno. Tri funkcii vozvedeniya v kvadrat v GF(2^n). Odna dlia n = 31 s polynomom 0xFFFFFFFF v [ecx+24h], drugiye dve ne vidni kakogo razmera i s kakimi polynomami. Eti polynomi hraniatsa v [ecx+24h], [ecx+28h] i [ecx+2Ch] (tolko v nih biti zadom naperiod, no eto ne vazhno). Rezultati vseh trioh po odnomu bitu skladivayutsa vmeste i danniye tak shifruyutsa po odnomu byte. Vnutrenneye sostoyaniye etogo stream cipher nahoditsa v [ecx+0Ch], [ecx+10h] i [ecx+14h]. Kakiye tam v [ecx+28h] i v [ecx+2Ch] znacheniya? Eto pohozhe na algorithm zapatentovanniy Fujitsu (US Patent 6636549), no tot po-krepche. Ruptor
Kstati, ya proveril etot cipher - u nego OCHEN korotkiye periodi v paru soten bytes. Zatikayetsa ochen bistro. I eto yesli vse tri GF(2^n) dlia raznih n (naprimer 29, 31 i 32). Yesli vse n=31, to zatikayetsa yeschio bistreye i gorazdo huzhe, i dazhe na stream cipher ne pohozhe (slishkom uzh prosto lomayetsa). K tomu zhe 0xFFFFFFFF polynom sovsem ne primitivniy... Chto eto za zver takoi??? Otkuda ti yego vikopal? Ruptor
Kstati, yesli tebe prosto implementation nado, to eto delo mozhno znachitelno uskorit po triom 8->32 s-box tablitsam i sdvigaya vse tri registra srazu po 8 bit. A voobsche v C eto vigliadit primerno tak: Код (Text): #define gfmul1(x,y,p) ((y)&1?((y)>>=1,(x)^=(p)):((y)>>=1,(x))) #define nbf_next_bit ((((a)=gfmul1(a,a,0xFFFFFFFF))^((b)=gfmul1(b,b,?))^((c)=gfmul1(c,c,?)))&1) i tak v cycle vse biti XOR po 1 bitu. Ruptor
Это заголовок nbf файла HP. Если по шагово прогнать, (привожу первые 16 байта из 320h) вход: 3A862B77D22D59320B2A422E48C3BFFC ... выход:48504E424600000091010000D52E1C26 ... decode_nbf_header proc near ; DATA XREF: .rdata:off_41D6E4o .text:00406777 .text:00406777 arg_0 - принимает значение 4e52454bh используется в alg_decode_nbf_header только 4Bh, которое меняется после декодирования очередного байта .text:00406777 arg_4 - указатель на буфер .text:00406777 arg_8 - размер буфера .text:004066F7 alg_decode_nbf_header proc near ; DATA XREF: .rdata:0041D6F4o .text:004066F7 .text:004066F7 var_4 - это в 8 .text:004066F7 arg_0 - байт который нужно декодировать и передается аргумент arg_0 из decode_nbf_header который меняется после декодирования очередного байта, и участвует в следующей операции декодирования. (если я правильно понял) Ruptor, можно по подробнее (пока не соображу( ). Щас трассировку погоняю, внимательнее значения посомотрю. Посмотрю утилиту XDA Flash ROM вдруг совпадет, формат. Вроде HTC для всех PDA разрабатывает ). Спасибо!
Znachit source tebe poluchayetsa takoi: Код (Text): static unsigned long a = 0x4B45524E, b = ?, c = ?; #define gfmul1(x,y,p) ((y)&1?((y)>>=1,(x)^=(p)):((y)>>=1,(x))) #define nbf_next_bit() ((((a)=gfmul1(a,a,0xFFFFFFFF))^((b)=gfmul1(b,b,0x3FFFFFFF))^((c)=gfmul1(c,c,0x0FFFFFFF)))&1) // ... for (i = 0; i < bytes; i++) for (j = 0; j < 8; j++) buffer[i] ^= nbf_next_bit() << j; Generitsa po 1 bitu vizivaya nbf_next_bit(), oni skladivayutsa v bytes i potom eti bytes vse XOR na danniye. Kakiye tam iznachalniye b i c? bez nih eto ne vosproizvesti. Oni hraniatsa v [ecx+10h] i [ecx+14h]. U etogo generatora period 31*29*27=24273. Tak chto mozhesh prosto sgenerirovat i sohranit potok poka on ne zaciklitsa na pervih 64 bitah gde x == x[i-24273] sdvinutoye na 3 bita. Posle etogo on budet ciklit po 24273 bita do kontsa sveta. XOR prosto etot potok na danniye i vsio. Budet gorazdo prosche i bistreye chem sam etot algorithm. Ruptor
Ребят, а не поможете разобраться с iPAQPCSDK.dll ? там есть две функции, которые подсчитывают Checksum(32bit) одну CalculateFileCRC() разобрал и нашел что и куда она пишет.. а втот CalculateHeaderCRC() так и не понял что откуда и как считает. прошивка для hp iPAQ rx1950 она состоит из 2х частей. чексум второй части и размер пишется в конце первой 4 байта CRC, 4 байта Size и (66 66 00 00) а вот вначале файла (если сравнить разные ромы) есть 8 байт неодинаковых. 9 байт везде одинаковый.. предполагаю, что там тоже 2 по 4, но вот как оно получено - не понимаю. заранее спасибо за любой намёк.. асм я не особо понимаю.. поэтому и не могу разобраться, а вот если мне на сях объяснить, ну или как говорили на любом языке высокого уровня - то я пойму.. сам файлик можно взять тут.. оставлю его в темпах.. http://catman.spb.ru/tmp/iPAQPCSDK.dll (84 kb) Заголовок1 - http://catman.spb.ru/tmp/header1.nbf (2 kb) Заголовок2 - http://catman.spb.ru/tmp/header2.nbf (2 kb) Если разберете обе функции - я буду вообще счастлив =) и не забуду вас в подписи об авторах Fix
На самом деле разбираться, как вычисляется сумма не нужно. Достаточно найти место, где происходит проверка контрольной суммы заголовка и тела NBF файла, и изменить нужные байты. Адреса найти не сложно IDA в помощ. Для прошивальщика 1950 (если не ошибаюсь версия 3.0.3) достаточно исправить iPAQPCSDK.dll в двух местах, в новом прошивальщике 3.4.0 уже нужно править hpRUU.exe.
В том и дело, что не найти это самое место, откуда он читает злосчастные 4 байта =) Одну функцию нашел. 4 байта CRC и 4 байта размер второй части РОМа.. CRC действительно просто.. обычное суммирование.. Checksum(32bit) править DLL и EXE - уловки, а т.к. щемся через карточку (SD) - программа прошивки на КПК проверяет обе CRC.. вот CRC заголовка ну никак не могу найти =(
не спорю, что можно было бы отследить момент чтение через дебагер, но проблема в том, что аппарат не у меня и я не могу сэмитировать эту ситуацию. это тоже осложняет мои поиски =(
CatMan скорее всего, это все уже давно раскопано - ищи на специализированных форумах. вот тут например чувак чего-то пишет про контрольные суммы и как считать для nbf: http://www.pocketpcmag.com/forum/topic.asp?TOPIC_ID=22704 и т.д. и т.п.
CatMan А вот готовая прога на перле, которая с этими nbf работает и суммы всякие для них вычисляет: http://www.nah6.com/~itsme/cvs-xdadevtools/romtools/splitrom.pl
nbf nbf'у рознь.. у них структура разная и они есть для КПК и для труб.. мне надо именно от rx1950. я достаточно перерыл всего и нашел структуру многих NBF, но к сожалению не попалась мне структурка от rx1950 =(
CatMan сколько есть различных прошивок от этой модели с различными CRC? выложи все что есть куда-нибудь - я посмотрю, есть там линейная зависимость
яж в первом посте дал линки на DLL и два абсолютно правильных заголовка.. т.е. это заголовки с NBF от производителя, которые проходят проверку. по оффсету A4E идут 4 байта чексум второй части далее сразуже 4 байта размер второй части потом в первом варианте 55 55 00 00 во втором варианте 66 66 00 00 не знаю что это - да ине может быть чексум заголовка.. тело заголовка состоит из инфы о прошивке.. язык, версия, тип кпк.. а вот первые 8 байт - непонятны.. безусловно значимые, но не разобраться что это. девятый байт везде одинаков и имеет значение 0x04 у меня для разбора есть только эти два заголовка и ДЛЛ которая их проверяет. ни КПК ни шнура нет. т.е. я не могу сэмитировать процесс прошивки и дебагером словить момент проверки CRC.. что смог - разобрал.. более никак не найти =( возможно чексум заголовка вообще во второй части рома.. т.е. заголовог imgfs части рома, а не заголовок самого рома.. не могу сказать.. оригинальный правильный ром http://catman.spb.ru/tmp/CEOS_original.rar оригинальный бут лоадер (тажа структура рома) http://catman.spb.ru/tmp/CEBL.nbf
