/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.
Прошу любить и жаловать, Ваш Добро пожаловать в наш Чат в Telegram
ErikPshat, ну дак ты пишешь жидко, среди твоего рассуждения истину искать что иголку в стоге сена.
Для начала нужно устроить мега-компрессию. 7-zip юзает стандартную zlib библиотеку. Я нашел объявление функции сжатия:
ZEXTERN int ZEXPORT deflateInit2 OF((z_streamp strm,
int level,
int method,
int windowBits,
int memLevel,
int strategy));
method
The method parameter is the compression method. It must be Z_DEFLATED in this version of the library.
windowBits
The windowBits parameter is the base two logarithm of the window size (the size of the history buffer). It should be in the range 8..15 for this version of the library. Larger values of this parameter result in better compression at the expense of memory usage. The default value is 15 if deflateInit is used instead
windowBits can also be –8..–15 for raw deflate. In this case, -windowBits determines the window size. deflate() will then generate raw deflate data with no zlib header or trailer, and will not compute an adler32 check value.
windowBits can also be greater than 15 for optional gzip encoding. Add 16 to windowBits to write a simple gzip header and trailer around the compressed data instead of a zlib wrapper. The gzip header will have no file name, no extra data, no comment, no modification time (set to zero), no header crc, and the operating system will be set to 255 (unknown). If a gzip stream is being written, strm->adler is a crc32 instead of an adler32.
memLevel
The memLevel parameter specifies how much memory should be allocated for the internal compression state. memLevel=1 uses minimum memory but is slow and reduces compression ratio; memLevel=9 uses maximum memory for optimal speed. The default value is 8. See zconf.h for total memory usage as a function of windowBits and memLevel.
strategy
The strategy parameter is used to tune the compression algorithm. Use the value Z_DEFAULT_STRATEGY for normal data, Z_FILTERED for data produced by a filter (or predictor), Z_HUFFMAN_ONLY to force Huffman encoding only (no string match), or Z_RLE to limit match distances to one (run-length encoding). Filtered data consists mostly of small values with a somewhat random distribution. In this case, the compression algorithm is tuned to compress them better. The effect of Z_FILTERED is to force more Huffman coding and less string matching; it is somewhat intermediate between Z_DEFAULT_STRATEGY and Z_HUFFMAN_ONLY. Z_RLE is designed to be almost as fast as Z_HUFFMAN_ONLY, but give better compression for PNG image data. The strategy parameter only affects the compression ratio but not the correctness of the compressed output even if it is not set appropriately. Z_FIXED prevents the use of dynamic Huffman codes, allowing for a simpler decoder for special applications.
у нас стоит
deflateInit2(&strm,
9, // максимальный насколько я понимаю
Z_DEFLATED, // метод DEFLATED он в этой либе такой всегда
15+16,
8, // это размер памяти который будет выделен на внутрение операции (в уровнях, 8 по дефолту)
Z_DEFAULT_STRATEGY // алгоритм сжатия
);
Скажи мне какие параметры должны быть для максимального сжатия? Вроде они такие как и должны быть.
frostegater, да, я уже 100500 раз перечитыл исходники, изучил метод компрессии zlib
К сожалению тут всё выставлено на максимум и алгоритм deflateInit2 самый расширенный, поэтому не знаю даже куда копать.
Можно ещё memLevel=9 выставить, он у меня так и проставлено, но это на большее сжатие вроде не влияет.
Единственно тут не хватает сжатия по словарю, как в 7-Zip:
Changes in 1.2.5.2 (17 Dec 2011)
- Allow deflateSetDictionary, inflateSetDictionary at any time (in raw)
- Add deflateResetKeep and fix inflateResetKeep to retain dictionary
- Fix gzwrite.c to accommodate reduced memory zlib compilation
Кстати, выше я скомпилировал zlib-1.2.8 для Win32, а оказывается нужно было под Unix, но у меня так выползает непонятная ошибка. Поэтому выкладываю zlib-1.2.7
Может как-то подключить либу 7z?
Прошу любить и жаловать, Ваш Добро пожаловать в наш Чат в Telegram