QMD - работа с запакованными/зашифрованными прошивками Swift 3G.

f2065 · 22 января, 2012

У новых Swift-3G (S5610 C3520 B7722 и т.п.) прошивки запакованы. Однако, оказалось что Samsung ничего нового не придумал, и там всё тот же уже известный алгоритм Quram с минимальными отличиями. У этих телефонов нет NOR+NAND памяти, а только медленная NAND. Прошивка в телефоне так и хранится запакованной, а при включении быстро разархивируется в ОЗУ и работает там (распаковку производит функция в .bootloader).

Теперь вот (при помощи alex999_ и vvyura) есть утилита для распаковки таких запакованных прошивок.

Про формат прошивки замечу что сектора QMDC - это те которые распаковываются, а вот QMDU - это сектора которые очевидно не сжаты и копируются как есть (хотя в распаковщие как-то используется DSP-сопроцессор для них) и пока про них более ничего не понятно. Некоторые сектора не сжаты - видимо те что плохо сжимались - и они передаются на выход целиком.

Пока обратно запаковать распакованную прошивку нечем. А залить в мобилу незапакованную прошивку видимо нельзя - в частности потому что места не хватит.

Однако, раз прошивка работает в ОЗУ - можно например модифицировать .bootloader чтобы он после распаковки прошивки накладывал на неё в ОЗУ необходимые патчи. Ну как на Qualcomm это реализовано…

ER_FLASH_CB_MAIN - это обычно основной файл прошивки.

ER_FLASH_CB_PAGE, ER_FLASH_CB_ROOT, ER_FLASH_NCB_DSP, ER_RAM_CB - пока не понятно. Ясно только что все эти файлы кроме PAGE - содержат прямой массив QMDC/Unknown/QMDU-секторов, а вот PAGE - имеет в начале таблицу расположения секторов и сектора в таблице перечислены не по порядку. Предположительно в PAGE вынесены редкоиспользуемые функции вшитые в прошивку - типа всяких инет-клиентов - они распаковываются по мере надобности.

Версия от 2012.01.30 04:04 -QMDC_Util_201201300404.rar

отличия от предыдущих: добавлена поддержка ZLib (теперь распаковываются файлы с partition_compression_algorithm 0 (ZLib) и 2 (QMDC), улучшен алгоритм поиска сжатых блоков, многочисленные мелкие оптимизации и багфиксы.

Версия от 2012.03.22 22:04 -QMDC_Util_201203222204.rar

отличия от предыдущих: добавлена распакова PAGE-файлов, для quram проверена работает точно, для zlib вероятно неправильная (у меня мобилы с zlib нет - сравнить RAM-дампы не могу).

Версия от 2012.04.16 15:51 -QMDC_Util_201204161551.rar

мелкие отличия от предыдущих: подписано поле +C в заголовке, чекбокс-переключалка регистра букв контрольной суммы.

Изменено 16 апреля, 2012 пользователем f2065

vvyura · 22 января, 2012

А залить в мобилу незапакованную прошивку видимо нельзя - в частности потому что места не хватит.

Судя по этим строкам из B7722XEXEKD3.ppt

partition_name="MAIN"
partition_path="B7722XE.cla\ER_FLASH_CB"
partition_offset=0x100000
partition_size=0x01500000

должно хватить.

Только распаковщик удаляет из файла заголовок, его наверно надо оставлять.

У незапакованых сегментов он же есть.

Пока обратно запаковать распакованную прошивку нечем.

Наткнулся вчера на патент US8059016.

Не этот ли алгоритм?

f2065 · 22 января, 2012

Судя по этим строкам из B7722XEXEKD3.ppt
partition_name="MAIN"
partition_path="B7722XE.cla\ER_FLASH_CB"
partition_offset=0x100000
partition_size=0x01500000
должно хватить.

Не всё так просто… Половина реально рабочего кода вынесена в PAGE.

partition_name="PAGED"

partition_path="B7722XE.cla\ER_PAGE_FLASH_CB"

partition_size=0x1400000

А оно распаковывается в размер 0x1EBD950…

Ну и ещё напомню что B7722 на Swift не очень то похож - не понятно что там за патчи делать.

А вот у C3520 например уже местом так не разбрасываются: в ptt размер MAIN-партиции 0xC00000, а распаковывается оно в 0x119ED1C.

Но в принципе если глобально понять логику всей прошивки - то можно и незапакованное залить… Там же NAND всё равно огромная. Принести в жертву часть пользовательской памяти…

Только распаковщик удаляет из файла заголовок, его наверно надо оставлять.

Ну поля заголовка более-менее понятны, и все существующие поля - показаны в QMDC_Util.

У незапакованных файлов: block size = 0, и packed data = unpacked data.

А удаляет распаковщик не только заголовок но и сектора QMDU, которые очевидно важны но не понятно зачем в их обработке вызывается типа LDCLT p13,C14,[R0] и всё. У B7722 кстати они вообще встроены в QMDC-архив и видны только после распаковки. Причём их обработка влияет на флаги и дальнейшую распаковку (там в непонятных ситуациях выводится предупреждение checkpoint). А у меня нет реального B7722 чтобы запуская в нём понять правильно ли у меня воспроизведена эта логика… Выходной файл может иметь вкрапления посторонних данных (надо абсолютную адресацию в нём проверить на соответствие по смыслу, в начале и в конце CLA, но пока ещё не думал над этим). Прошивка C3520 распаковывается корректно полностью, проверено с реальной мобилой.

f2065 · 28 января, 2012

Некоторые новости постепенно накопившиеся:

Алгоритмов компрессии бывает несколько. В заголовке файла по +0x20 - значение из partition_compression_algorithm из .ptt

Представленный распаковщик пока умеет только тип 2 распаковывать - Quram QMDC.

Однако например у C5130 или S5550 прошивки сжаты с типом 0 (очевидно, где-то и тип 1 есть - итого как минимум 3 типа компрессии). У них в начале секторов сигнатура 0x78,0xDA и далее ничего не понятно пока…

Некоторые QMDC-прошивки (например у B7722) при распаковке распаковщик обращается к DSP, и самые последние 4 байта берёт из него… Вероятно это какая-то контрольная сумма или типа того. В случае создания патчей этот вопрос очевидно надо тоже решать…

Распаковать PAGE-файл пока не могу. Понятно что его реальная карта расположения секторов где-то в MAIN.

Нужно достать ELF-файлы на какие-либо прошивки у которых есть PAGE-файл… Без такой мобилы и без ELF - я врядли смогу сделать распаковку PAGE. Кстати уже ясно что в PAGE и много MCC-кода вынесено, т.е. для написания патчей исследовать содержимое PAGE может понадобится.

Нужна помощь по двух вопросам:

- в какой прошивке ктонибудь видел в .ptt-файле значение partition_compression_algorithm=0x1

- нужна любая прошивка имеющая PAGE (partition_name="PAGED" или "PAGE") с ELF-файлом, локализация без разницы (среди русских очевидно нет, уже надо искать среди нерусских), partition_compression_algorithm=0x2 (но в перспективе может быть и не важно). В саппорте боксов и т.п. надо обратить внимание где соседняя версия прошивки вдруг на 30-50% больше по размеру - вероятно там будет ELF (расширение у файла может отсутствовать или быть .X).

Снег · 28 января, 2012

0x78,0xDA - это начало ZLIB

f2065 · 28 января, 2012

Вобщем распаковка через zlib1.dll получилась… В следующей версии QMDC_Util будет распаковка прошивок с partition_compression_algorithm=0.

vvyura · 29 января, 2012

В следующей версии QMDC_Util будет распаковка прошивок с partition_compression_algorithm=0.

Я так понимаю, для этого алгоритма можно сделать и упаковку?

Тогда можно попытаться распаковав раздел с алгоритмом 2, упаковать в 0 и подсунуть телефону...

f2065 · 29 января, 2012

Я так понимаю, для этого алгоритма можно сделать и упаковку?

Видимо да, я пробовал - ZLib примерно такое же создаёт. Надо только внимательно документацию ZLib прочитать и чтобы он тоже выдавал посекторную компрессию.

Но не целесообразно это - это у древних телефонов, и сейчас уже никто патчи для них делать не будет…

Тогда можно попытаться распаковав раздел с алгоритмом 2, упаковать в 0 и подсунуть телефону...

Так сходу - не получится. Я смотрел, у этих новых мобил лоадер проверяет версии компресии, и для 0 и 1 есть отдельные переходы где просто возвращается код ошибки и выход, а распаковщик только для типа 2 у них. Так что новая мобила не сможет распаковать старую версию. А вытащить распаковщик из старых лоадеров (где только 0) и встроить его в новые - не так просто, старый распаковщик имеет существенно более сложный код чем Quram, плюс использует команды которые BinEdit не понимает (например 312E322E MRCCS p14,1,R2,C2,C1,1).

Но в теории наверно более реально сделать для новых мобил лоадер с поддержкой ZLib чем написать упаковщик Quram…

vvyura · 20 марта, 2012

Распаковать PAGE-файл пока не могу. Понятно что его реальная карта расположения секторов где-то в MAIN.

Карта как раз в начале PAGE-файла и лежит...

На примере С3520:

00002000:  66070000 E4070000 00A01700 F8040000
00002010:  00683200 EC070000 00900100 58040000

Первое слово в таблице (0х766) - похоже количество блоков, распаковщик его и определяет (или он их считает по всему файлу?). С этим пока вопрос, но для начала не важно...

Далее пара слов на блок - размер и смещение от начала. Чтобы получить физический адрес, надо прибавить размер заголовка (0х2000).

Получаем адрес первого блока: 0x17C000, распаковываем:

00000000:	0020	MOV	R0, #0x0
00000002:	7047	BX	LR
00000004:	10B5	PUSH	{R4,LR}
00000006:	0400	LSL	R4, R0, #0
00000008:	232C	CMP	R4, #0x23
0000000A:	0DD9	BLS	loc_00000028
0000000C:	FF22	MOV	R2, #0xFF
0000000E:	4232	ADD	R2, #0x42
00000010:	FF20	MOV	R0, #0xFF
00000012:	E530	ADD	R0, #0xE5
00000014:	09A1	ADR	R1, =0x3C
00000016:	24F274EC	BLX	off_00224900
0000001A:	2200	LSL	R2, R4, #0
0000001C:	6420	MOV	R0, #0x64
0000001E:	0BA1	ADR	R1, =0x4C
00000020:	24F272EC	BLX	off_00224908
00000024:	0020	MOV	R0, #0x0
00000026:	10BD	POP	{R4,PC}
	loc_00000028:	
00000028:	092C	CMP	R4, #0x9
0000002A:	03D8	BHI	loc_00000034
0000002C:	3034	ADD	R4, #0x30
0000002E:	2006	LSL	R0, R4, #24
00000030:	000E	LSR	R0, R0, #24
00000032:	10BD	POP	{R4,PC}
	loc_00000034:	
00000034:	3734	ADD	R4, #0x37
00000036:	2006	LSL	R0, R4, #24
00000038:	000E	LSR	R0, R0, #24
0000003A:	10BD	POP	{R4,PC}
0000003C:	66616365	DCB	"facebook7util.c"
0000004C:	66616365	DCB	"facebook7_NumberToBase36 : Error, vp_LowerString[%d]"

А вот так начинается MAIN-партиция у С3322:

		facebook2_OrbitRegisterWithSMS:
90140800:	0020	MOV	R0, #0x0
90140802:	7047	BX	LR

	facebook7_NumberToBase36Digit:
90140804:	10B5	PUSH	{R4,LR}
90140806:	0400	LSL	R4, R0, #0
90140808:	232C	CMP	R4, #0x23
9014080A:	0DD9	BLS	loc_90140828
9014080C:	FF22	MOV	R2, #0xFF
9014080E:	4232	ADD	R2, #0x42
90140810:	FF20	MOV	R0, #0xFF
90140812:	E530	ADD	R0, #0xE5
90140814:	09A1	ADR	R1, =0x9014083C
90140816:	C4F3B4E9	BLX	_osys_01InputTraceInfo+1
9014081A:	2200	LSL	R2, R4, #0
9014081C:	8520	MOV	R0, #0x85
9014081E:	0BA1	ADR	R1, =0x9014084C
90140820:	C4F3B2E9	BLX	_osys_10DefaultTrace+1
90140824:	0020	MOV	R0, #0x0
90140826:	10BD	POP	{R4,PC}
	loc_90140828:	
90140828:	092C	CMP	R4, #0x9
9014082A:	03D8	BHI	loc_90140834
9014082C:	3034	ADD	R4, #0x30
9014082E:	2006	LSL	R0, R4, #24
90140830:	000E	LSR	R0, R0, #24
90140832:	10BD	POP	{R4,PC}
	loc_90140834:	
90140834:	3734	ADD	R4, #0x37
90140836:	2006	LSL	R0, R4, #24
90140838:	000E	LSR	R0, R0, #24
9014083A:	10BD	POP	{R4,PC}
9014083C:	66616365	DCB	"facebook7util.c"
9014084C:	66616365	DCB	"facebook7_NumberToBase36 : Error, vp_LowerString[%d]"

Далее идет блок по адресу 0x328800. На стыке блоков (0xA0E - 0xA10) все красиво:

00000A08:	2018	ADD	R0, R4, R0
00000A0A:	5118	ADD	R1, R2, R1
00000A0C:	8842	CMP	R0, R1
00000A0E:	4DD8	BHI	loc_00000AAC
00000A10:	00F0EEF8	BL	off_00000BF0
00000A14:	0028	CMP	R0, #0x0
00000A16:	49D1	BNE	loc_00000AAC
00000A18:	5348	LDR	R0, =0xCA204C52

Вот аналогичный код С3322:

9014746C:	1219	ADD	R2, R2, R4
9014746E:	0818	ADD	R0, R1, R0
90147470:	8242	CMP	R2, R0
90147472:	4DD8	BHI	loc_901475BE
90147474:	00F000F9	BL	Magic4_Client_Stored
90147478:	0028	CMP	R0, #0x0
9014747A:	49D1	BNE	loc_901475BE
9014747C:	5C48	LDR	R0, =g_bIsVectorFontCursorInit

Еще непонятный момент - бывает ссылка на какой-либо блок идет два раза подряд. Но если выкинуть из цепочки дубль - вроде склеивается правильно.

f2065 · 20 марта, 2012

Карта как раз в начале PAGE-файла и лежит...

Я не смог по ней распаковать.

Там понятно только где лежат сектора… Это в итоге конечно полезно - поскольку некоторые сектора не пакованы и не имеют сигнатуры.

Но вот последовательность секторов я не смог выявить…

Или может там адрес куда распаковывать, но тоже вроде не понятно…

Надо разобрать что значат все ячейки в таблице, там же на каждый сектор их несколько (причём ещё ведь в заголовке сектора есть некая инфа).

Самсунг кстати любит делать вложенные таблицы. У B5722 к примеру иконки главного меню это тоже таблицы в несколько уровней, и со случайным соответстием координат 1…30. Одна лежит в CSC, две других лежат в прошивке… Потому очень может быть что для PAGE тоже есть вторая таблица в MAIN.

Еще непонятный момент - бывает ссылка на какой-либо блок идет два раза подряд. Но если выкинуть из цепочки дубль - вроде склеивается правильно.

А ещё бывает что сектора идут не последовательно…

Далее пара слов на блок - размер и смещение от начала.

Там на блок по 4 слова… 2 из которые не понятны. Я вначале тоже думал что всего по два слова, но всё-же там по 4. Иначе местами встречаются адреса за пределами памяти и прочие глюки.

vvyura · 21 марта, 2012

Но вот последовательность секторов я не смог выявить…

Таблица и есть последовательность.

Берем сектор по смещению из первой записи, распаковываем. Берем из второй, распаковываем сразу за первым. И т.д.

Надо разобрать что значат все ячейки в таблице, там же на каждый сектор их несколько (причём ещё ведь в заголовке сектора есть некая инфа).

Размер и смещение, ничего больше я там не вижу...

А в заголовке сектора врядли будет что-то, влияющее на его положение в памяти.

А ещё бывает что сектора идут не последовательно…

Непоследовательно идут сектора в PAGE-файле или ссылки на них в таблице?

Там на блок по 4 слова…

Пока все говорит за то, что 2. Распаковал сектор по 3-ей ссылке - он замечательно приклеился к первым двум.

Иначе местами встречаются адреса за пределами памяти

У С3520 опять же, минимальное смещение в таблице 0х8000, максимальное - 0х453000. Это соответствует действительности - физический адрес первого сектора - 0xA000, последнего - 0x455000.

RusEm · 21 марта, 2012

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

Точно также в свое время поступили с броадкомами

f2065 · 21 марта, 2012

а что мешает немного подредактировать бутлоадер и снять дамп с оперативки

Отсутствие такой мобилы… Дамп B7722 кстати мне присылали, но одного его мало (плюс я не понимаю архитектуру B7722 - это затрудняет поиски места где вызывается переключение страниц). Только стало понятно что логика распаковки не простая, понять её по таблице в начале PAGE не получилось…

Да кстати, проблема то с PAGE, а не с MAIN.

PAGE распаковывается частями по мере надобности. Ну например туда вынесен твиттер-клиент…

Сразу после загрузки мобилы то там пусто.

Изменено 21 марта, 2012 пользователем f2065

f2065 · 21 марта, 2012

И всё-же результат не получается…

B7722XEJG6_Master\B7722XE.cla\ER_PAGE_FLASH_CB

Таблица:

00000800 E9 1E 00 00 EC 07 00 00 00 D0 04 00 10 03 00 00

00000810 F0 A4 F5 00 E8 07 00 00 00 C8 32 00 A0 04 00 00

00000820 00 D0 FE 00 E8 07 00 00 00 D0 32 00 98 02 00 00

00000830 68 CD EC 00 84 07 00 00 00 08 C8 00 84 07 00 00

00000840 00 08 C8 00 E8 07 00 00 00 D8 32 00 E0 02 00 00

00000850 20 AD F1 00 E8 07 00 00 00 E0 32 00 C8 01 00 00

0001F680 00 00 E5 00 0C 07 00 00 00 20 CF 00 0C 07 00 00

0001F690 00 20 CF 00 FF FF FF FF FF FF FF FF FF FF FF FF

Вот некоторые высказывают версию что в таблице вобщем идут строки по два слова: первое это размер сектора данных вместе с 'QMDC', а второе - это адрес расположения сектора.

1F694-804=1EE90. Смотрим на первое значение в таблице. Вопрос. Почему оно наводит на мысли что в таблице строки по 4 слова, а не по 2 ?

Ещё не понятно почему все сектора идут через одни - один большой, второй мелкий…

Но далее всё ещё более запутано.

Первая строка таблицы - указывание на такой сектор - ну всё нормально, такое я знаю как распаковать…

0004D000 51 4D 44 43 F0 07 00 00 70 0F 00 00 10 01 00 00 QMDC ...p.......

0004D010 90 03 00 00 0B D6 54 52 92 BA E5 FD 78 B7 4D 5E .... TR x M^

Вторая строка таблицы - ещё какие-то дополнительные 4 байта в начале перед QMDC-сигнатурой. И чего с этим делать то ?

00F5A4F0 A8 76 D4 76 51 4D 44 43 0C 03 00 00 00 10 00 00 v vQMDC........

00F5A500 8C 00 00 00 10 01 00 00 0B C7 EF 97 3F B9 6F B7 ........ ? o

Кстати сравниваем слово после QMDC и в таблице, очевидно что эти 4 байта не входят в размеры.

Находим и сравниваем размеры вышестоящго QMDC-сектора, и оказывается что эти 4 байта в его размеры входят.

Распаковщик QMDC я знаю, он не умеет искать сигнатуры сам, он берёт данные вообще с через 8байт от начала QMDC.

Смотреть куда указывает адрес из таблицы и потом там несколько байт сканировать на предмет начала QMDC ? Сомнительный алгоритм…

Вобщем я всё более убеждаюсь что распаковать по этой таблице нельзя (хотя местами да, последовательности секторов и совпадают с дампом). Это вероятно какой-то артефакт… Ну вот у B5722 например есть дополнительная таблица иконок меню, которая во-первых битая, а во-вторых ведёт к набору иконок которые не используются (я неделю наверно пытался её понять).

зы. у C3520XEKJ5\C3520XE.cla\ER_FLASH_CB_PAGE1 тоже полно QMDC-секторов которые в таблице не видны.

При полном скане сигнатур - выдираю около 7.5мб как и указано в общем заголовке файла, а по таблице нахожу только 4.5мб

Изменено 21 марта, 2012 пользователем f2065

vvyura · 22 марта, 2012

f2065,видимо ты упустил это:

Чтобы получить физический адрес, надо прибавить размер заголовка (0х2000).

0х2000 - для С3520, для В7722 0х800

Т.е. в твоем примере цепочка будет такая: 0x04D800 0xF5ACF0

Распаковал вручную эти два сектора - они совпали с дампом ОЗУ.

1F694-804=1EE90. Смотрим на первое значение в таблице. Вопрос. Почему оно наводит на мысли что в таблице строки по 4 слова, а не по 2 ?

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

Этим можно объяснить и повтор секторов в таблице: сектору не нашлась пара, и в качестве пары указали его же. Почему для пары не писали 00, FF или еще чего - не знаю, "умом корею не понять". Очевидно, что дважды его распаковывать не надо.

Вобщем я всё более убеждаюсь что распаковать по этой таблице нельзя

Не, всунуть левую таблицу в самое начало файла - это уже слишком. :idea:

upd: Похоже, я понял предназначение группы.

При объединении первых двух секторов получилось ровно 4 Кб.

Распаковал сектор "без пары" - те же 4 Кб.

Т.е. одна запись в таблице - 4 Кб распакованных данных.

Тогда (пример из предыдущего поста) размер распакованных данных - 0x1EE9000, в заголовке видим 0x1EE8E90. Очевидно, последняя группа получилась меньше.

Стоп... Дамп имеет такой-же размер. PAGE распаковывается полностью?

Изменено 22 марта, 2012 пользователем vvyura

f2065 · 22 марта, 2012

Не, всунуть левую таблицу в самое начало файла - это уже слишком.

Ну а как быть с тем фактом что местами таблица указывает не на начало сектора ?

Причём в памяти сектора идут не последовательно, т.е. адрес второго сектора нельзя получить просто в конце первого. Надо смотреть таблицу, а там адрес бывает кривой… захватывающий часть другого сектора а не просто потерянные данные.

Дамп имеет такой-же размер. PAGE распаковывается полностью?

На 7722 памяти много, возможно… Но у других вроде он не полностью распаковывается.

vvyura · 22 марта, 2012

Ну а как быть с тем фактом что местами таблица указывает не на начало сектора ?

Пример в студию.

Надо смотреть таблицу, а там адрес бывает кривой… захватывающий часть другого сектора а не просто потерянные данные.

Ничего не понял...

Опять же, хотелось бы пример.

f2065 · 22 марта, 2012

Пример в студию.

Ну так я выше написал, пример - вторая ячейка таблицы в B7722XEJG6_Master\B7722XE.cla\ER_PAGE_FLASH_CB указывает на неверный адрес… И таких примеров там далеко не один.

vvyura · 22 марта, 2012

Ну так я выше написал, пример - вторая ячейка таблицы в B7722XEJG6_Master\B7722XE.cla\ER_PAGE_FLASH_CB

Ты серьезно, или прикалываешься?

На этот пост я отвечал - адрес без учета заголовка PAGE-файла.

Т.е. считываем 0xF5A4F0, прибавляем размер заголовка (для 7722 он 0x800) и получаем адрес сектора в файле 0xF5ACF0.

Я распаковал первые два сектора - они совпали с дампом.

f2065 · 22 марта, 2012

Получилось…

Читаем ячейку, если размер и адрес совпадает с предыдущей - то пропуск.

Если ячейка указывает на сектор QMDC - то распаковываем его

Если ячейка указывает на сектор QMDU - то просто его копирует пропустив 8 байт (сигнатура и размер данных)

Если ячейка указывает на сектор без известной сигнатуры - то просто копируем его целиком.

И так повторяем по кол-ву указанному в первой ячейке умноженному на 2.

QMDC - 0x35A1 (13729) блоков

несжатых без сигнатуры - 7

QMDU (несжатые) - 0x114 (276)

и ещё 0x716 (1814) двойных ссылок в таблице, которые я отбрасывал.

Нерациональный какой-то у них принцип.

Вобщем алгоритм малопонятный, но как ни странно дампы совпадают.

Но это с Q-компрессией… А вот с ZLib - не уверен что всё правильно. C5130SXEIK1\C5130SXE.cla\ER_PAGE_FLASH_CB

Ну во-первых там кол-во секторов соответствует указанному в первой ячейке реально (без умножения).

Все сектора с 0x78 - zlib распаковывает… Их 0x14DA (5338) и все распаковывает (хотя 1байтная сигнатура не очень надёжная ведь).

Однако там есть ещё 4 сектора без 0x78 вначале.

На них ZLib ругается Z_DATA_ERROR…

0000B800 92 DC DC 01 52 10 6C A3 EA CC 68 A8 3F 16 20 6B

0000B810 59 94 CC E2 F0 B0 0B 8C A5 EA 43 19 F0 AE EC C7

0000C800 53 A4 5F 91 83 21 3E 4B EA 96 D8 FF 00 7A 19 64

0000C810 92 EB 8F A6 10 8C 18 B7 92 92 47 11 BF 89 04 FE

0000D800 9A AC 9D FA CC F5 C4 A5 78 65 4B 11 1E 22 D5 34

0000D810 84 57 92 F0 0A FC 8A 25 08 47 69 F8 F7 A4 47 D8

0000E800 EB F9 9B 5C 65 9D FC D7 2D 0D A4 5E DC 7E A4 D9

0000E810 6A 4E F5 8C EF B8 1B 00 28 AA 29 B0 D7 9D EB 57

Сектора не сжимаются архиваторами, вероятно они сжатые.

Но сигнатуры нет.

И кстати это 4 сектора лежат в самом начале файла (перед ними таблица).

Ссылка в таблице на них примерно в середине таблицы.

000095F0 28 A9 BE 00 8B 09 00 00 74 DE 63 00 00 0F 00 00

00009600 00 20 03 00 00 10 00 00 00 B0 00 00 00 10 00 00

00009610 00 C0 00 00 00 10 00 00 00 D0 00 00 00 10 00 00

00009620 00 E0 00 00 1F 07 00 00 FF D7 4F 00 AA 06 00 00

Судя по фиксированным размерами - видимо их надо копировать как несжатые…

Копировать их как непакованные, или вообще пропускать, в любом случае расхождения в размерах с общим заголовком файла… А дампов его ОЗУ его нет чтобы сравнить

vvyura · 22 марта, 2012

Вобщем алгоритм малопонятный, но как ни странно дампы совпадают.

Алгоритм как раз простой:

Видимо, смысл PAGE - не распаковать его сразу весь, а подгружать данные по мере необходимости. И надо по адресу в ОЗУ быстро находить упакованные сектора с нужными данными. Для этого размер распакованных данных на один блок ровно 0x1000 байт. Тогда, чтобы заполнить адреса 0x3000-0x4000 сразу читаем четвертую запись в таблице.

Размер одного сектора QMDC из каких-то соображений ограничен, и 4 кб в него не всегда удается запихнуть. Поэтому одна запись содержит два блока.

При упаковке берем 4 кб, сжимаем.

- если все влезло в один блок, то второй уже не нужен. Это помечаем дублированием ссылки (чем плохой вариант?).

- если не влезло совсем чуть-чуть, байтов 30, то выгоднее не сжимать их, а записать незапакованными - тогда вторым создаем QMDU блок.

- если не удалось упаковать и в два блока - записываем "как есть" (в неупакованных блоках у С3520 в основном IFEG-графика, которая уже упакована).

Как-то так.

Ну во-первых там кол-во секторов соответствует указанному в первой ячейке реально (без умножения).

У ZLib ограничения на размер сектора нет, поэтому не надо делать пары.

(хотя 1байтная сигнатура не очень надёжная ведь).

Кстати, признаком "неупакованности" можно считать размер блока - 0х1000.

в любом случае расхождения в размерах с общим заголовком файла

А при распаковке одного блока ровно 4 кб получается? Может, что-то лишнее пишется, или недописывается...

f2065 · 22 марта, 2012

- если не влезло совсем чуть-чуть, байтов 30, то выгоднее не сжимать их, а записать незапакованными - тогда вторым создаем QMDU блок.

Непонятно почему есть как непакованные блоки QMDU, так и просто непакованные блоки.

Экспортирую соответственно оба варианта - дамп полностью совпал… Но зачем так придумали - не понятно.

У ZLib ограничения на размер сектора нет, поэтому не надо делать пары.
Кстати, признаком "неупакованности" можно считать размер блока - 0х1000.
А при распаковке одного блока ровно 4 кб получается? Может, что-то лишнее пишется, или недописывается...

Я понял в чем причина… В заголовке файла поле unpacked data - указывает реальный размер данных, который на 2-3кб меньше размера распакованного файла. Но в распакованном файле после этого значения как раз данные обрываются и далее 2-3кб FFFFFFFF… А размер файла кратный 4кб, у обоих вариантов компрессии

Вобщем похоже всё распаковывается правильно. Потом только надо будет для ZLib алгоритм поиска улучшить, искать несжатые сектора сравнивая размер (видимо не с фиксированным 0x1000, а с константой из заголовка файла).…

Хм, а в quram-прошивках где попадаются несжатые сектора без QMDU-сигнатуры - у них размер 0x800… при том что в заголовке файла указан размер сектора 0x1000 и QMDC-сектора распаковываются в 4кб…

Вобщем надо больше прошивок изучить… Детектить сектора по размеру тоже может привести к ошибкам…

vvyura · 23 марта, 2012

Непонятно почему есть как непакованные блоки QMDU, так и просто непакованные блоки.

Тут все понятно:

QMDU - небольшой "остаток" от 4 кб, непоместившийся в блок QMDC;

просто непакованный блок - 4 кб данных, которые нельзя упаковать в два блока QMDC.

Это для PAGE-файла. Для других файлов критерии наверно другие.

Еще вопрос - по какому принципу формируется порядок блоков в PAGE-файле, зачем они так перемешаны.

Прослеживается закономерность, что они идут от большего к меньшему, но много исключений.

RusEm · 23 марта, 2012

скорее всегно такой порядок вызван особенностью нанда

И кстати как патчить то лучше?? патчить в ОЗУ после распаковки?? или все же перепаковывать будем?

vvyura · 23 марта, 2012

И кстати как патчить то лучше?? патчить в ОЗУ после распаковки?? или все же перепаковывать будем?

А есть возможность упаковывать в Quram?

Вход

QMD - работа с запакованными/зашифрованными прошивками Swift 3G.

Рекомендуемые сообщения

Ссылка на комментарий

Поделиться на другие сайты

Топ авторов темы

Популярные дни

Топ авторов темы

Популярные дни

Популярные посты

f2065

f2065

Снег

Изображения в теме

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Создать аккаунт

Войти