Господа, возможно ли теоретически, написать архиватор в несколько десятков байт? Суть в том, что написан шел-код, допустим на 500 байт, еще на 50 дешифровщик этого кода. В итоге получается 550 байт. Реально ли написать мини-распаковщик, размер которого + размер запакованного кода < размер исходного кода?? Вопрос чисто теоретический.. Повторяющихся фрагментов почти нет..
зависит от энтропии. у аплиб около 180 байт вроде распаковщик, а жмет довольно неплохо. +жать лучше нешифрованный код обычно
имхо это бред жмется все что угодно вопрос только с каким коэффициентом ну применить такую теорию сжатия - для всех dword'ов посмотреть статистику - очень не плохо если они все кучкуются вокруг у нескольких значений с радиусом в байт, а дальше кодируешь каждое значение - ставишь "опорный кадр" и дальше идут байты добавки
RtlDecompressBuffer() является стабом для RtlDecompressBufferLZNT1(). Уложился в 50 байт(базу и лимит кодовой секции найдёт сторонний код): Code (Text): GET_RtlDecompressBufferLZNT1 proc C ; Esi: База секции кода нтдлл. ; Edi: Предел секции кода. ; cld mov edx,esi Check: mov eax,dword ptr [edx] cmp eax,esi jb Next cmp eax,edi jnb Next mov ecx,dword ptr [edx + 2*4] cmp ecx,esi jb Next cmp ecx,edi jnb Next cmp dword ptr [edx + 3*4],ecx jne Next ; STATUS_UNSUPPORTED_COMPRESSION = 0xC000025F cmp dword ptr [ecx],00025FB8H ; 0xXX00025F jne Next cmp byte ptr [eax + 5],51H je Exit Next: inc edx cmp edx,edi jb Check xor eax,eax Exit: ret GET_RtlDecompressBufferLZNT1 endp Хотя у LZ малая степень сжатия.
ну я бы так не говорил,особенно учитывая соотношение скоростей компрессия/декомпрессия,и обьем юзаемой памяти( как и при компрессии так и при декомпрессии ) остальные,более "крутые" алгосы,жрут дофига памяти,и очень медленны )) п.с. хотя для специализированных данных( например ASCII текста ),можно найти и алгосы получше.
Наверное для 500 байт вместо LZ достаточно построить код хаффмана чтоли, те присвоить более частым байтам или ниблам более короткие последовательности бит. Наверное код построения частотного дерева можно уместить в несколько десятков байт. Сначала нужно построить дерево и посмотреть наскоро оно жментся а потом подумать об оптимальном распаковщике
Вернее так, можно сначала комфортно запаковать на Си с использованием даблов для хранения вероятностей, а потом убедивщись что сжатие стоит свеч написаать мааленький префиксный расспаковщих на Асме с готовой таблицей-деревом.
небольшой оффтоп =))) случайные данные равно как и архивированные можно сильно запаковать если записать их на оптический носитель каждый пит которого поддерживает четыре, восемь, или больше градаций яркости =))) однако внешне это будет выглядеть как повышение емкости самого носителя по сравнению со стандартной болванкой такого де размера. Но мы то знаем что там просто идет многократное ужатие всей информации.
Всем спасибо за ответы. RtlCompressBuffer жмет слишком плохо, мой код она только на 4 байта увеличила, в то время как другая либо на 20 байт ужала. Для теста сжал первые 65535 байт kernel32.dll: RtlCompressBuffer их сжал их до 43к, а вот Zlib до 32к.. Винрар еще чуть посильнее. Это конечно удобно что таскать либу не надо, но жмет хренова 0_о Вопрос решен другим способом. А именно хранение части кода в другом месте и юзание его загрузочника.
persicum Процессор цифровой, соответственно память юзает битовую, а не аналоговую, так что бит битом останется. test555 Она обычно удовлетворительно ужимает модуля, в частности секции данных. Разумеется что всяко качественный пикод пожат ею будет очень плохо.
есть теория - в ДНК записана инфа в исчислении по модулю 20 - очень крутое "сжатие" в одной из книжек про Луну автор посчитал, что код ДНК надо равернуть в картинку предположительно 2ххх на 8хх пикселей. код уже известен - нужно написать прогу, желательно на масме, котрая будет делать перебор различных параметров развёртки и показывать картинку ушану, который будет этим заниматься и тогда - можно эту ДНК хакнуть и получить доступ к знаниям сверцивилизации, которая создала жызнь на Земле. вот
