Как пожать, упаковать и зашифровать исполняемый ELF-файл для PSP - Страница 2

Dedok179 · 25.05.2020, 20:52

Сообщение от ErikPshat

Ну хорошо, что у вас всё быстро делается без лишних вопросов

В Hex Workshop закройте все лишние окна справа слева внизу, они пока не нужны.

Короче, откройте в хекс-редакторе kirk.16, он занимает ровно 272 байта (0x110)
Выберите в меню File -> Export -> С Source (*.c, *.cpp).
У вас сохранится файл kirk.c

Теперь откройте его в Notepad++ и так же откройте в исходниках файл main.c - вы должны увидеть сходство кирка с исходным кодом в этом месте:

unsigned char kirkHeader[272] = {
    0x8B, 0x5D, 0xC0, 0x96, 0x38, 0x77, 0x54, 0x6D, 0x2E, 0x40, 0x07, 0x42, 0x8D, 0x5A, 0xAE, 0xEF, 
    0x11, 0x34, 0x0F, 0x5D, 0xF8, 0x57, 0x7A, 0x7A, 0x06, 0xDA, 0xE2, 0xB1, 0x4F, 0x5A, 0x3D, 0x84, 
    0x99, 0xC4, 0xF4, 0x95, 0x61, 0xDF, 0x88, 0xBA, 0xB3, 0x60, 0x09, 0x90, 0x5A, 0x94, 0xD8, 0x58, 
    0xC5, 0x3A, 0x33, 0x3E, 0xD7, 0x30, 0x20, 0xED, 0xCC, 0xA8, 0x7B, 0x90, 0x46, 0x9B, 0x0C, 0xFC, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x48, 0x06, 0x2F, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x7E, 0x50, 0x53, 0x50, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x4D, 0x6F, 0x64, 0x65, 0x6C, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x48, 0x06, 0x2F, 0x00, 0xA0, 0x07, 0x2F, 0x00, 
    0x24, 0x01, 0x00, 0x00, 0x44, 0xDD, 0x1E, 0x00, 0x5C, 0x46, 0x2D, 0x00, 0x40, 0x00, 0x40, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xCA, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x4C, 0xCA, 0x20, 0x00, 0x84, 0x2A, 0x2E, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x06, 0x06, 0x09, 0x00, 0x00, 0x00, 
};

Вот эта строка указывает на количество байт: unsigned char kirkHeader[272] = - по этому количеству вы должны ориентироваться, чтобы не спутать блоки и там и там.
Из kirk.c выделяете движением мышки слева весь цифровой код сверху вниз, не затрагивая скобки { и };, копируете, затем выделяете в исходнике main.c такой же код и заменяете.
Теперь открываете оригинальный шифрованный не декриптованный EBOOT.BIN (~PSP). Выделяете с самомго начала заголовок, размером 336 байт (0x150).
И делаете всё тоже самое File -> Export -> С Source (*.c, *.cpp).
У вас сохранится файл EBOOT.c
Теперь откройте его в Notepad++ и так же откройте в исходниках файл main.c - вы должны увидеть сходство в EBOOT.c размером 336 байт с исходным кодом в этом месте: unsigned char rawData[336] =
Точно так же копируете, вставляете, сохраняете main.c и компилируете новый PrxEncrypter.
Ну вот и всё, у вас есть энкриптер именно для этого вашего файла.
Берёте ваш кастомный файл, который надо упаковать как оригинал, кидаете рядом с программой или прямо на программу, либо в консоли натравливаете команду
```
PrxEncrypter.exe EBOOT.BIN
```
На выходе вы должны получить файл DATA.ENC - это и есть ваш пожатый и подписанный EBOOT.BIN, переименовываете его потом и пакуете в ISO.
У него будет тот же заголовок как у оригинала, точно такой же размер, как и записано в хедере и он будет работать на любой OFW, как и оригинал.

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

Думаю, с PS3 меня будут ожидать примерно такие же проблемы если не больше

Dedok179 · 25.05.2020, 21:38

К сожалению файл размером больше первоначального он отказывается принимать

Yoti · 25.05.2020, 22:23

Сообщение от Dedok179

Думаю, с PS3 меня будут ожидать примерно такие же проблемы если не больше

Слово "PlayStation" правильно написать ты уже не осилил.

ErikPshat · 26.05.2020, 04:51

Yoti, да ладно, не придирайся, парень дедок вполне смышлённый, просто имеются немного пробелов

Сообщение от Dedok179

К сожалению файл размером больше первоначального он отказывается принимать

Ну так правильно. В кирке и в заголовке проставлены размеры шифрованного файла и так же декриптованного ELF, тело шифруется исходя из размера оригинала и размера пожатого, записанного в хедере, который изменять никак нельзя, иначе хэши блоков не совпадут. Размеры записаны в позициях 0x28 и 0x2C по 4 байта в Little Endian.
Так что размер ELF не может превышать оригинал, но может быть меньше, просто концовка забивается нулями до нужного размера.
Либо можно упаковать и подписать увеличенный кастомный файл - кирком и хедером другого официального файла большего размера.

Сообщение от Dedok179

Такой вопрос, могу ли я немного модифицировать ваш исходник для некоторой автоматизации процесса?

Да без проблем, модифицируйте как вам угодно

Yoti · 26.05.2020, 08:12

ErikPshat,
я не в первый раз вижу этот ник и аватар, если что.

Dedok179 · 26.05.2020, 09:20

Сообщение от ErikPshat

да ладно, не придирайся, парень дедок вполне смышлённый, просто имеются немного пробелов

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

Сообщение от ErikPshat

Так что размер ELF не может превышать оригинал, но может быть меньше

Ну, это немного не состыковывается с конечной целью. Видимо все таки без пересборки образа тут не обойдется. Всегда старался обойти этот процесс ибо на PS1/2 он не только геморный, но и есть шанс нарушить некоторые данные при неверно составленной карте образа.

Dedok179 · 26.05.2020, 12:10

Сообщение от ErikPshat

Ну так правильно. В кирке и в заголовке проставлены размеры шифрованного файла и так же декриптованного ELF, тело шифруется исходя из размера оригинала и размера пожатого, записанного в хедере, который изменять никак нельзя, иначе хэши блоков не совпадут. Размеры записаны в позициях 0x28 и 0x2C по 4 байта в Little Endian.
Так что размер ELF не может превышать оригинал, но может быть меньше, просто концовка забивается нулями до нужного размера.
Либо можно упаковать и подписать увеличенный кастомный файл - кирком и хедером другого официального файла большего размера.

Т.е эту "хитрожопость" не обойти так полагаю? В предыдущих работах была вполне уместная такая схема: оригинальный файл+загрузчик и другие данные(больше оригинального)->упаковка->получаем файл меньше оригинального что удобно для простой замены в образе

ErikPshat · 26.05.2020, 12:46

Сообщение от Dedok179

В предыдущих работах была вполне уместная такая схема: оригинальный файл+загрузчик

А что вы такого делаете с ELF, что он превышает размер оригинала? Вы же понимаете, что нельзя сдвигать скомпилированный код, это чревато нарушением линковки и смещения позиций программного кода.
И про какой загрузчик вы тут говорите? Оригинальный файл ELF - он же и есть загрузчик, т.е. исполняемая программа, а если у неё есть ресурсы, то они все отдельно находятся. Так что тут не надо никакие загрузчики к ELF приклеивать.

Dedok179 · 26.05.2020, 13:28

Сообщение от ErikPshat

А что вы такого делаете с ELF, что он превышает размер оригинала? Вы же понимаете, что нельзя сдвигать скомпилированный код, это чревато нарушением линковки и смещения позиций программного кода.
И про какой загрузчик вы тут говорите? Оригинальный файл ELF - он же и есть загрузчик, т.е. исполняемая программа, а если у неё есть ресурсы, то они все отдельно находятся. Так что тут не надо никакие загрузчики к ELF приклеивать.

Я не к ниму (оригиналу), а сам исполняемый файл(оригинал) в загрузчик размещаю. В итоге получается размер: сам код загрузчика+рутина+оригинальный файл. Приложил схему как это работает. Еще понятнее не знаю уж как объяснит это дело(такой я, в учителя не возьмут).

Yoti · 26.05.2020, 13:52

ErikPshat,
GTA Cheat Device помнишь? Вот он делает такую же хрень, только вместо плагина на карте памяти, как у всех белых людей, он его хочет вшить в образ. Да ещё так, чтобы LBA не поехали, на которые 99% игр пофиг. Максимализм перфекционизма, видимо. Вот только я вижу лишь одно решение - кастомный пакер-анпакер в самописный загрузчик добавлять. Либо самопал на место оригинала, а все зависимости в конец закинуть. Или вместо boot.bin, если влезет.

**BlackDaemon** · 26.05.2020, 14:12

Формально есть свободная LBA в SYSDIR под обновление прошивки, которую можно в теории использовать под другие нужды

Yoti · 26.05.2020, 14:37

BlackDaemon,
ну, кстати, тоже верно, там даже с запасом место будет. Просто смысла в этих извращениях немного - на диск образ не запишешь всё равно. Также можно оригинальную исполняшку декриптнуть и как boot.bin положить, а свой код на место eboot.bin засунуть. Тут смотря какого размера исполняшка сама, иногда там мелкий лодырь для модуля лежит.

ErikPshat · 26.05.2020, 15:22

Вот же извращенцы мля

В общем немного упростил сборку, залил во вложение на всякий, пускай хранится здесь.
Сделал Example, просто запустить 1 MAKE.BAT и закидывать папку "SIGNED GAME" на консоль в ms0:/PSP/GAME/ кто не в курсе.
Потом наводите курсор на игру и можете слушать часами модную современную музыку без остановки.
Название композиции не скажу

секрет. И что за игра не скажу, сами смотрите...

P.S. из main.c убрал #include <zlib.h>, ибо прога давно не использует архиватор zlib, а вместо него 7-Zip. Из Makefile убрал LDFLAGS=-lz, пускай без него собирается.

Dedok179 · 26.05.2020, 16:29

Сообщение от Yoti

ну, кстати, тоже верно, там даже с запасом место будет. Просто смысла в этих извращениях немного - на диск образ не запишешь всё равно. Также можно оригинальную исполняшку декриптнуть и как boot.bin положить, а свой код на место eboot.bin засунуть. Тут смотря какого размера исполняшка сама, иногда там мелкий лодырь для модуля лежит.

Как-то даже не подумывал об этом. Может это будет один из выходов, спасибо.

**riku.kh3** · 26.05.2020, 17:38

В конец самого образа-то религия не позволяет данные добавлять? Как там что-то может сместиться и поехать, если поправить только указатель на файл в файловой таблице и дописать его содержимое в конец ISO. :/

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