Первые четыре байта определяют размер блока данных в катором собственно всё и находится.
В качестве примера далее будет рассматриваться: Demo_Survival.lfr
Первые четыре байта: 000054B6h это 21686. Действительно размер этого файла без этих 4 байтов составляет 21686 байт.
Дальше этот блок данных расшифровывается не по сложному алгоритму (то ли сложение то ли вычитание щас не препомню). В расшифровке участвует массив данных по адресу: 0040B750

Далее идёт такое количество операций с расшифрованными данными что у меня опух мозг. Да и вообще что то тут не так... и действительно в процессе трассировки мне встречались вот такие строки:
need dictionary
incorrect data check
incorrect header check
invalid window size
unknown compression method

Уж больно это на архивацию похоже. Просмотрев все строки в исполняемом файле я нашёл вот что:
deflate 1.1.4 Copyright 1995-2002 Jean-loup Gailly

Мля это алгоритм архивации такой. deflate - сжатие а inflate - расжатие. Теперь понятно почему файлы записи так мало весят.

Следующии этап исследования включает в себя:
1) Через отладчик посмотреть на разархивированные данные, можно немного посмотреть какая с ними работа ведётся.
2) Реализовать алгоритм deflate а лучше тупо найти исходники ибо в изобретании велосипеда нет ни чего хорошего.
Попутно можно и алгоритм заархивирования (inflate) реализовать ибо после патча автора, HP Lost, имейла нужно же обратно заархивировать! ухаха... ))

Добавлено (2008-09-16, 11:07 Am)
---------------------------------------------
Походу они zlib 1.1.4 заюзали для сжатия.

Добавлено (2008-09-16, 12:00 Pm)
---------------------------------------------
Качнул я zlib.dll версии 1.1.4 и чуть не кончил ))) Столько всего похоже и на основе пожощих функций понял где uncompress функция, ей 4 параметра передаётся.