O EXE-packerach raz jeszcze – sprostowanie i ciekawostki

dodał 24 września 2018 o 18:25 w kategorii HowTo  z tagami:
O EXE-packerach raz jeszcze – sprostowanie i ciekawostki

W poprzednim artykule opisałem główne zasady działania programów znanych jako EXE-packery. Jednakże w jednym z akapitów popełniłem pewien duży błąd, nie wspominając o bardzo ważnej rzeczy związanej ze starymi komputerami.

Niniejszy artykuł jest sprostowaniem części mogącej wprowadzić naszych czytelników w błąd oraz małym uzupełnieniem w formie ciekawostek.

Press Play On Tape

W komentarzach padły zarzuty, iż tryb Turbo nie ma nic wspólnego z kompresją kodu. Wspomniałem o nim, ponieważ najbardziej rozbudowaną ideą zapisu kodu, aby wczytywał się z taśmy jak najszybciej, było skompresowanie go, zapisując go dopiero po kompresji w trybie Turbo. Zapomniałem o dodaniu najbardziej istotnej informacji, że tryb ten przede wszystkim powodował zmianę formatu modulacji zapisu bitów na taśmie, aby były one zapisywane gęściej oraz odtwarzane dzięki temu z większą prędkością przesyłu.

Dlaczego wspomniałem o trybie Turbo w kontekście kompresji kodu? Tytuły, które zawierały własny program wczytujący resztę w trybie Turbo, były zwykle kompresowane. Wczytywanie programu odbywało się więc w taki oto sposób:

  1. Ładowany jest program Turbo.
  2. Program Turbo wczytuje (skompresowany) kod, korzystając ze swojego „szybszego” formatu zapisu danych.
  3. Następuje dekompresja wczytanego kodu lub jego części po odczytaniu całej zawartości z taśmy.
  4. Główny kod jest uruchamiany (następuje skok do jego początku).

Tutaj chciałbym również zaznaczyć, iż po przeprowadzeniu poszukiwań, w różnych źródłach natrafiłem na informacje, iż nie wszystkie programy ładujące dekompresowały kod po jego wczytaniu i program mógł być zapisany w trybie Turbo, ale nie był skompresowany. Zdarzały się także sytuacje, gdy sam program był skompresowany, ale nie był zapisany w trybie Turbo. Bywało z tym różnie w zależności od producenta programu lub gry.

Teraz dodatkowo jeszcze wytłumaczę pewną kwestię techniczną – pewnie wiele osób się nad tym zastanawiało: dlaczego czasami przy uruchamianiu gierki na naszym komodorku przed ekranem tytułowym widzieliśmy zmieniające się szybko przez kilka sekund w charakterystyczny sposób znaki lub glitche graficzne?

Źródło: https://commons.wikimedia.org/wiki/File:Turboload_commodore_64.gif

Commodore 64 (jak sama nazwa wskazuje) miał 64 KB pamięci operacyjnej, z czego część była zarezerwowana dla wewnętrznych układów (procesora graficznego, układu dźwiękowego i pozostałych). Rozpakowujący się właśnie program nie może nadpisać jeszcze nierozpakowanej części ani samego kodu dekompresującego tym już rozpakowanym. Sprytnie wykorzystano te zarezerwowane części pamięci (dla procesora są one widziane tak jak każda inna część operacyjna), gdyż często służyły one jako bufor lub nawet sam kod dekompresujący był wykonywany właśnie z nich. Układ graficzny i dźwiękowy interpretowały zawartość tego „własnego” obszaru pamięci jako zawartość wyświetlanego obrazu, a w drugim układzie jako wartości odtwarzanego dźwięku – stąd też bardzo często przed samym ekranem tytułowym widzieliśmy przez chwilę migające znaki i glitche lub słyszeliśmy trzaski i szumy.

Ciekawostka: za czasów komputerów 8-bitowych oraz 16-bitowych jeszcze przed erą PC występował specyficzny podział dla nazewnictwa kompresorów kodu: packery wykorzystywały proste algorytmy takie jak np. RLE (zapisywanie powtarzających się sekwencji znaków w skróconej formie), natomiast crunchery to programy wykorzystujące bardziej zaawansowane algorytmy porównywalne z późniejszymi EXE-packerami dla PC (paradoksalnie pierwotne określenie takich narzędzi przyjęło się bardziej), zwykle z rodziny LZ (stąd wzięła się również nazwa LZEXE – jednego z pierwszych popularnych EXE-packerów dla systemów DOS). Określenia packer i cruncher, w zależności od użytego rodzaju kompresji, przeszły również do świata komputerów Amiga.

Fast, Small, Good

Jeden z naszych czytelników zapytał, dlaczego nie wspomniałem o pewnym wynalazku z naszego rodzimego podwórka, tym razem jednak znanym na świecie – chodzi o EXE-packera o nazwie FSG, który obsługuje on pliki .EXE w formacie Win32 PE.

FSG jest produkcją grupy crackerskiej xtreeme, działającej w Polsce na początku lat dwutysięcznych – większość popularnych programów antywirusowych z góry traktuje pliki nim skompresowane jako podejrzane, ponieważ jest on często wykorzystywany do kompresowania malware’u.

Ta produkcja w porównaniu do „wewnętrznych” EXE-packerów różnych innych grup crackerskich i demoscenowych została wydana na świat, a summa summarum jakość tego EXE-packera była całkiem niezła jak na standardy w tamtych czasach.

Fragment pliku .NFO z opisem dołączony do instalatora FSG 1.33

Co takiego wyróżnia FSG wśród innych EXE-packerów, że zalicza się on do kategorii „wynalazków”?

  • Jest to produkcja pochodząca ze sceny crackerskiej.
  • Napisany został w czystym kodzie assembly.
  • Kod dekompresora w ostatniej wersji to tylko 158 bajtów – 197 bajtów w starszej wersji kompatybilnej z Windows 10.
  • Podobny stopień kompresji jak najpopularniejszy UPX.
  • Poczucie humoru twórców.

FSG wydawany „podziemnymi” ścieżkami nigdy nie był użyty przez jakiekolwiek oprogramowanie komercyjne lub nawet bezpłatne. Stał się jednak bardzo popularny wśród grup crackerskich, demoscenowych oraz wśród producentów oprogramowania malware (do dziś jeszcze można znaleźć świeże produkcje nim spakowane).

Instalator FSG 1.33 (wygląda bardzo podobnie
jak ówczesne instalatory tzw. „ripów” gier)

Jeśli macie ochotę sprawdzić, czy wasz program antywirusowy także traktuje FSG jako coś niebezpiecznego lub posłuchać muzyki chiptune i zobaczyć crackscenowe animacje (twórcy FSG stworzyli dla niego klimatyczny instalator i cracktro), to FSG w wersjach 2.0 (uwaga: pliki spakowane za pomocą tej wersji nie działają w Windows 10, podobnie jak sam instalator i EXE-packer) oraz 1.33 możecie znaleźć tutaj. A muzykę z instalatora znajdziecie na YouTube.

O czym jeszcze mogliście nie wiedzieć

Na koniec jeszcze pięć innych ciekawostek związanych z EXE-packerami.

  • Pliki .EXE zawierające 64-bitowy kod dla systemu Windows mają taki sam format jak te 32-bitowe – bardzo szybko wszystkie EXE-packery obsługujące kod 32-bitowy dostały obsługę kodu 64-bitowego, gdy systemy 64-bitowe weszły do powszechnego użytku, gdyż wymagało to jedynie zmiany kodu samego dekompresora.
  • Od około 1997 roku „standardowe” 64 KB lub 128 KB w układzie przechowującym oprogramowanie BIOS w komputerach PC przestało wystarczać pod względem pojemnościowym – domyślacie się już na pewno, po jakie metody sięgnięto. Tutaj ciekawa sprawa, jaką odkryłem: Award użył algorytmu kompresji, a nawet formatu pliku wynikowego identycznego jak archiwizator LHA, tworząc nietypowe archiwum SFX rozpakowujące się do określonych adresów pamięci zamiast na dysk jako obraz BIOS do zaprogramowania w układzie płyty głównej.
  • Słynny niegdyś program antywirusowy MkS_Vir w wersji dla DOS był spakowany autorskim EXE-packerem, który powstał tylko i wyłącznie dla niego (oglądaliście dema pokazowe efektów działania opisanych w encyklopedii wirusów? Są to oryginalne fragmenty kodów z nich wydobyte).
  • W Windows Me plik IO.SYS był skompresowany EXE-packerem, dla którego nie znaleziono żadnego działającego podobnie przy dekompresji – prawdopodobnie tak jak ciekawostka powyżej powstał on tylko na potrzeby tego pliku (zawiera on główne moduły trybu MS-DOS w Windows Me).
  • UPX w najstarszych swoich wersjach posiadał easter egga polegającego na tym, że nie mógł rozpakować swojego własnego pliku wykonywalnego, wyświetlając komunikat błędu „cannot unpack UPX ;-)”.