они просто видимо выпендриваются перед пиратами - типа смотрите какая у нас игра классная и большая...хотя вероятно это для диска надо..может с этим "мусором" игры быстрее с них грузятся ,ведь скорость чтения там порядка 2мбайт\с))

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

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

Если, к примеру файл EBOOT.BIN имел определённый размер, то после декриптовки он приобретает другой размер.
И когда мы его засовываем обратно в образ, то из-за того, что размер изменился, все последующие файлы сдвигаются при сохранении. Отсюда все смещения сдвигаются и диск становиться не читаемым, т.к. в таком диске разрабы установили привязку по LBA, а не по названию.

Адресация LBA - аббревиатура этого вида дисковой адресации отражает сущность используемых в ней дисковых адресов: Logical Block Address, то есть «адрес логического блока» или «логический адрес блока».

Так вот, в данном случае один блок здесь рассчитывается из расчёта 2048 байт на блок. Один блок состоит из 4 секторов по 512 байт.
Один блок здесь - это минимальная единица исчисления и всё подчиняется этому правилу в UMD пространстве.

Это я расписал просто литературным языком, чтобы более-менее было понятно простому народу, поэтому просьба не цитировать со всякими опровержениями и сообщениями об ошибках.

Теперь перейдём из теории к практике...
Число в FileList - что оно означает?

Это число означает закреплённую позицию LBA для каждого файла, присутствующего в образе (точной копии байт-в-байт физического UMD-диска).

Если мы видим на экране монитора файл, имеющий конкретное название, например EBOOT.BIN, то это не значит, что этот файл прямо так же и записывается с этим названием.
Все названия папок и файлов записываются отдельно в определённое место на диске, а оттуда, по этим названиям идёт ссылка на сам файл по позиции LBA.

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

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

Это число LBA так же можно увидеть в UMDGen, который умеет высчитывать и показывать эти позиции (на примере "Gran Turismo"):

LBA показывает количество блоков. В данном случае, один блок равен 2048 байт. Отсюда, если нам необходимо вычислить расположение файла PSP_GAME/SYSDIR/EBOOT.BIN в образе (на диске), то нужно произвести математическое действие:
LBA 32-ой блок (как видно на 2-ом рисунке) умножить на 2048 = 65536.
Что мы видим на самом деле в хексе:

То есть эта цифра как раз указывает на количество блоков от начала образа (физического диска).
Поэтому FileList выполняет функцию закрепления всех начальных позиций файлов на свои исходные места, как они были до изменения размера одного из них (EBOOT.BIN при декриптовке в данном случае).

ErikPshat, мне долго никто не отвечал, что если честно, я сам уже разобрался. Но всё равно спасибо за развёрнутый ответ, пригодится многим, думаю.

Я объясню, откуда вопрос вообще возник. Всё дело в том, что если в ~PSP файл ELF хранится в gzip, то после распаковки его размер должен стать больше. Соответственно, размер нового EBOOT.BIN может стать больше размер старого/"закриптованного" EBOOT.BIN. Соответственно, при запаковке обратно в iso и использовании LBA-позиций из файла, хвост нового EBOOT.BIN может пересечься в "дисковом" пространстве с началом следующего по списку файла.

Учитывая, что сейчас всем рекомендуется использовать экспортированный список файлов со смещениями, это могло бы... могло бы. Кстати, на примере Disgaea2 я посмотрел, этого не происходит - во-первых, там достаточно (5 полных с хвостиком блоков) нулей, плюс, размер декриптованного ELF-а меньше(!) размера исходного запакованного.

hasherfrog добавил 08-10-2009 в 12:09
>> Но разрабы иногда хитрят
Это они ещё не хитрят. Я думаю, что самым простым следующим их шагом будет чтение первых байтов EBOOT.BIN и проверка что это не чистый ELF, а ~PSP :-P

Не совсем так. В Gzip упаковывались файлы прошивки PRX (~PSP) совсем давно в формат RLZ. Но так как PSP по сей день умеет работать с этим архивом, то разработчики Homebrew как раз этим форматом пользуются. А так же в этот формат упаковывал свои кастомные файлы и Dark_Alex, как и все последующие последователи.

Но официальные файлы Sony сейчас похоже не пакует, а просто переконверчивает их другим способом - KL3E, KL4E. По сути это не компрессия, а просто перекодировка в другой формат с шифровкой.

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

Размер файла в ~PSP проставляется так же на старых позициях в 4-ёх байтах:
0x28 - размер декриптованного файла ELF
0x2C - размер зашифрованного файла ~PSP
0хB0 - размер декриптованного файла EBOOT.BIN в играх, дополнительно к 0x28