Сообщение от frostegater
/upd
Очень интересно. Хедеры подбираются по 0x70 оффсету в Kirk хедере. В нем хранится размер закриптованого DATA.PSP.
Этот оффсет с выравниванием и поправками (хз зачем, но получается верно) сравнивается с размером считанного elf и подбирается подходящий хедер.
|
Ну так я об чём писал
здесь и
здесь и ещё одну строчку
здесь.
Я уже по нескольку раз здесь переписал диссертацию, а вы по ходу её не читали
Сообщение от frostegater
интересная вещь, последние 4 байта декриптованого стаффа не нули.. что же они значат?
|
Они не всегда 4 байта. Это зависит от размера архива. При архивировании архив забивается нулями по размеру 0x70 в кирке и в конец добавляются какие-то байты, я встречал до 8-ми байт. Скорее всего контрольные суммы блоков.
И потом, после подписывания ты наверное проверяешь и декриптуешь. Но декриптер тебе выдаёт уже разархивированный файл, поэтому сам архив ты не видишь, как он выглядет внутри и сколько места занимает. Я уже писал
вот здесь (Ликбез №2), что лучше в исходниках
PrxDecrypter (не путать с Энкриптером) пофиксить расжатие
1F8B и он не будет разархивировать, а только декриптовать. Тогда ты сможешь подсмотреть, как сжимает Энкриптер в архив, сколько места занимает, на сколько добиватся нулями и что дописывает в конце. Конец архива GZ найдёшь по размеру декриптованного файла. - Поэтому я и говорю, что Astonishia Энкриптер не в состоянии ужать до исходника.
Сообщение от frostegater
Я вот не пойму почему размер ELF меряется с размером криптованого файла?!
|
Я думаю, что он сначала ищет по
psp_header, затем проверяет по
kirk-header, если кирк не подходит, то он снова отправляется в поиск по
psp-header. То есть зацикленный круг, пока не сойдётся. Я тоже сначала полумал, с какой стати он из обработки кирка начинает искать в psp-header.