Prawie każdy programista języków niskiego i średniego poziomu spotyka się z pojęciem kompresji kodu wykonywalnego, czyli użyciem programów popularnie nazywanych EXE-packerami. W niniejszym artykule dowiecie się, dlaczego powstały, jak działają oraz dlaczego są popularne do dziś.
Nie dotykaj, bo się nie wgra…
Pierwsze techniki kompresji kodu powstawały już w czasach komputerów, które do zapisu oraz odczytu programów korzystały z magnetofonów i kaset – mowa tutaj przede wszystkim o najpopularniejszych wówczas komputerach Commodore 64 oraz ZX Spectrum. Aby wczytać program do pamięci, należało odtworzyć taśmę od początku do końca. Standardowy zapis nie był optymalny pod względem czasowym (ładowanie mogło trwać nawet do 15 minut), programiści wpadli więc na pomysł, by skompresować zapisany na taśmie kod, a następnie dekompresować go bezpośrednio do pamięci w trakcie ładowania. W takim przypadku najpierw – za pomocą standardowej metody – ładowany był tzw. „program Turbo” , który przejmował całą obsługę magnetofonu, odczytując skompresowaną zawartość z dalszej części taśmy i dekompresując ją do pamięci. W ten sposób ładowanie programu skracało się np. z 15 minut do około 3-5, w zależności od rozmiaru oryginalnego kodu. Po odczytaniu całej zawartości następowało uruchomienie.
Technika ta była najczęściej nazywana „Turbo Tape” lub „Fast Loader”, a programy pozwalające zapisywać, odczytywać i kopiować programy zapisane takimi metodami nazywały się ich różnymi wariacjami. Po pewnym czasie większość programów same w sobie zawierały już wspomniany program ładujący, wyświetlając np. w trakcie ładowania logo producenta, a programy ładujące gry bardzo często odtwarzały w trakcie ładowania ich ścieżkę dźwiękową.
Czas na pliki
Po rozpowszechnieniu się komputerów klasy PC użytkownicy i twórcy oprogramowania zaczęli zmagać się z problemami rozmiarów aplikacji i gier. Twarde dyski miały dość małą pojemność i były na początku bardzo drogie, a przy coraz bardziej rozbudowanych produkcjach zwykle jedna dyskietka (o pojemności najpierw 360 KB, ostatecznie 1,44 MB) mogła nie być w stanie pomieścić danego tytułu wraz ze wszystkimi towarzyszącymi plikami lub dodatkowymi programami. Postanowiono więc skorzystać z metody kompresji kodu wykonywalnego – powstały programy umożliwiające skompresowanie pliku .COM lub .EXE, nadal pozostawiając go uruchamialnym bez konieczności ręcznej dekompresji przed załadowaniem. Co prawda, istniały wówczas już programy takie jak PKZIP czy ARJ, jednak służyły one do kompresji całych plików i katalogów bez możliwości korzystania z nich bez konieczności ręcznego rozpakowania.
Należy tutaj wspomnieć o archiwach SFX – są to pliki wykonywalne .EXE, których zadaniem jest rozpakowanie dołączonego do ich kodu archiwum (najczęściej ZIP, 7z lub CAB) bez konieczności posiadania odpowiedniego programu dekompresującego. Obecnie najczęściej spotykaną formą takich archiwów są instalatory aplikacji, które oprócz rozpakowania plików do odpowiednich folderów przeprowadzają również konfigurację systemu, tworzą odpowiednie skróty itd. – z EXE-packerami nie mają one jednak nic wspólnego. Każdy popularny dziś archiwizator posiada możliwość utworzenia archiwum w takiej formie.
W ten oto sposób coraz bardziej rozbudowane programy mogły zmniejszyć swoją objętość na dysku (zwykle główny program w formie pliku .EXE był największym plikiem). Podobnie jak wyżej opisana metoda w przypadku taśm, plik .EXE po kompresji składał się z dwóch części: małego programu rozpakowującego kod aplikacji do pamięci (zwykle kilkaset bajtów) i samego skompresowanego kodu. Jednym z najpopularniejszych EXE-packerów, jakie powstały za czasów systemów z rodziny DOS, był rozpowszechniony jako freeware program LZEXE autorstwa Fabrice’a Bellarda (ciekawostka: jest on również autorem takich projektów jak ffmpeg oraz QEMU).
Po sukcesie LZEXE dość szybko zaczęły pojawiać się kolejne tego typu programy wykorzystujące bardziej efektywne algorytmy kompresji, a także komercyjne EXE-packery, takie jak PKLITE autorstwa firmy tworzącej znanego już wówczas PKZIP-a czy wywodzący się z naszego rodzimego podwórka WWPACK (niestety nie zdobył on dużej popularności).
Fragment pliku .EXE skompresowanego za pomocą PKLITE z widoczną charakterystyczną sygnaturą
Jako ciekawostkę można tutaj dodać informację, że za pomocą programu PKLITE w wersji 1.15 skompresowano dość sporą część narzędzi systemu MS-DOS w wersjach 6.x (np. FORMAT.COM) i niektóre programy systemów Windows 95, 98 i Me działające w graficznym trybie DOS (np. SCANDISK.EXE).
Twórcy komercyjnych rozwiązań dodawali od siebie dodatkowe funkcje do użycia w swojej aplikacji, np. autor programu mógł sprawdzać w trakcie jego działania, czy kod nie został rozpakowany ręcznie i przywrócony do pierwotnej formy. Dla prawie każdego popularnego EXE-packera zwykle powstawał program typu EXE-unpacker (przywracający oryginalny plik .EXE) albo taka funkcja była dostępna w samym kompresorze. Zaraz, zaraz…
Pozytywne efekty uboczne
Ach, no tak – rozkwit programów typu shareware! Kompresowanie kodu aplikacji nie tylko zmniejszało rozmiary plików wykonywalnych, ale także w pewien sposób zabezpieczało je przed modyfikacjami (np. w celu usunięcia ograniczeń wersji testowej, by funkcja przyjmująca kod rejestracyjny akceptowała dowolny jako prawidłowy). Modyfikacja skompresowanego kodu bez jego wcześniejszej dekompresji nie jest bowiem możliwa. Twórcy komercyjnych EXE-packerów oferowali nabywcom pełnych wersji możliwość dodania dodatkowych zabezpieczeń w celu uniemożliwienia ręcznego rozpakowania lub podejrzenia kodu, wspomniane już wcześniej funkcje do sprawdzenia, czy program nadal jest spakowany, a także dodatkowe funkcje sprawdzające integralność kodu w trakcie wykonywania skompresowanej aplikacji (ich brak uniemożliwiał prawidłowe funkcjonowanie programu). Oczywiście pewne grupy użytkowników poradziły sobie z tymi „dodatkami” – wymagało to jednak o wiele więcej pracy niż przywrócenie pierwotnej wersji pliku .EXE i modyfikacja „czystego” kodu. Jest to jednak temat na kolejny artykuł.
Nadchodzi rewolucja: UPX
Rok 1998 przyniósł pewną rewolucję w temacie EXE-packerów – do tej pory nie istniał jeszcze żaden EXE-packer, który potrafiłby kompresować nie tylko kod 16-bitowych plików .EXE uruchamianych w systemie DOS, ale również 32-bitowe aplikacje Win32. Zaczęły pojawiać się pierwsze tego typu narzędzia, obsługujące 32-bitowy kod, a najpopularniejsze z nich to wydany na licencji Open Source UPX oraz wydane komercyjnie programy ASPack i PECompact.
Ekran opisu programu UPX
Ponieważ budowa 32-bitowych plików EXE jest o wiele bardziej skomplikowana (oprócz samego kodu mogą one w sobie zawierać także inne zasoby, np. tablice tekstów, obrazki, ikony, kursory), bardzo często zdarzało się, że kod po kompresji po prostu nie uruchamiał się bądź działał błędnie, gdy chciał skorzystać z zasobów zamieszczonych w pliku z własnym kodem. Dlaczego więc te trzy narzędzia stały się najpopularniejsze? Ich twórcy największy nacisk położyli na kompatybilność ze wszystkimi wersjami systemów operacyjnych, dostępnymi kompilatorami oraz możliwymi danymi umieszczonymi oprócz kodu. Oprócz zwykłych plików .EXE obsługiwały również inne korzystające z tego samego formatu, jak np. DLL czy OCX (kontrolki ActiveX).
Twórcy UPX-a poszli jednak o krok dalej. Pozostałe narzędzia skupiały się tylko na kodzie Win32 (opcjonalnie obsługując .DLL), a dzięki temu, że sam projekt był udostępniany na licencji open source, obsługa większej liczby formatów plików została szybko rozbudowana przez społeczność. W początkowych wersjach UPX obsługiwał jedynie 16-bitowe pliki .EXE, .SYS i .COM działające w systemach DOS oraz 32-bitowe .EXE i .DLL. Obecnie kompresuje również pliki binarne uruchamiane pod systemami Linux, macOS, Windows CE, a nawet dwóch architekturach retro – Sony PlayStation (PS1) oraz Atari ST. Istnieje także możliwość użycia kompresji LZMA zamiast domyślnej, opracowanej przez autorów (aczkolwiek takie pliki będą uruchamiać się o wiele wolniej ze względu na skomplikowany algorytm), stosowanej w popularnym programie archiwizującym 7-Zip (udostępnianym również na licencji open source).
UPX jest obecnie najpopularniejszym EXE-packerem na całym świecie.
EXE-packery nadal są wykorzystywane
Pomimo upływu lat oraz ogromnego postępu w zwiększaniu pojemności dysków EXE-packery nie przestały być używane, a sam UPX jest bardzo często dołączany do różnego rodzaju kompilatorów, nawet tych komercyjnych. Dlaczego nadal korzystamy z EXE-packerów?
- Użycie EXE-packera zabezpiecza kod aplikacji przed łatwym podejrzeniem go lub wprowadzeniem modyfikacji.
- W przypadku dużych plików .EXE załadowanie skompresowanej wersji i jej rozpakowanie w pamięci może być szybsze niż załadowanie oryginalnego pliku bezpośrednio z dysku (a tym bardziej, gdy plik jest pobieramy z sieci lub uruchamiamy z powolnego nośnika danych).
- Pliki .EXE bardzo często są wyraźnie mniejsze niż ich oryginalne wersje spakowane tradycyjnymi archiwizatorami (np. ZIP) – algorytmy EXE-packerów opracowane są specjalnie do kompresji kodu i są bardziej efektywne niż uniwersalne algorytmy kompresji (ma to znaczenie np. przy dystrybucji oprogramowania – przygotowanie jak najmniejszego pakietu instalacyjnego).
- Niektóre bardzo zaawansowane obecnie komercyjne EXE-packery pozwalają na połączenie pliku .EXE oraz dodatkowych wymaganych przez niego plików .DLL (lub innych wykorzystywanych przez aplikację) do pojedynczego pliku .EXE, eliminując w ten sposób możliwe błędy powstałe w wyniku posiadania przez użytkownika niekompatybilnych bibliotek czy konieczności dystrybuowania dodatkowych plików.
Minusem użycia EXE-packerów jest minimalne opóźnienie względem uruchomienia głównego kodu programu od jego załadowania do pamięci – musi on zostać najpierw rozpakowany, zanim zostanie wykonany. Tutaj autorzy najpopularniejszych narzędzi starali się w taki sposób dostosowywać użyte algorytmy, by były one jak najszybsze przy dekompresji. W praktyce nawet na bardzo starych komputerach nie odczujemy tego opóźnienia. Twórcy programu UPX określili w 2000 roku, iż pliki skompresowane za pomocą ich narzędzia rozpakowują około 13 MB kodu w ciągu sekundy na starym procesorze Pentium 133 – dziś jest więc to ze względu na o wiele większą moc współczesnych komputerów nie do zauważenia.
Jeżeli macie ochotę pobawić się starymi EXE-packerami, możecie znaleźć całkiem ciekawą ich kolekcję na stronie ExeTools.com. Natraficie tam również na inne narzędzia do „zabawy” z plikami wykonywalnymi (strona ta niestety nie jest aktualizowana od 2002 roku).
Co dalej?
Sama idea kompresowania kodu wykonywalnego znalazła swoje dalsze zastosowanie w językach skryptowych oraz interpretowanych. Powstały kompresory kodu źródłowego takich języków jak chociażby PHP, Python czy JavaScript. Można także znaleźć w sieci kompresory kodu HTML i CSS. Temat ten nie ograniczył się więc tylko do plików .EXE i kodu maszynowego wykonywanego bezpośrednio przez procesor. Cały czas ponadto powstawały (i powstają nadal) także swego rodzaju wewnętrzne rywalizacje między autorami EXE-packerów: który z kompresorów będzie bardziej zoptymalizowany pod względem rozmiaru pliku wynikowego, rozmiaru kodu dekompresującego czy szybkości działania danego algorytmu kompresji. Polecam zaawansowanym programistom samodzielnie przetestować działanie takich narzędzi wobec własnych plików .EXE (a jeśli chodzi o platformę .NET – omówimy to w następnym artykule z tej serii).
Komentarze
Oj. Mało wiecie o tym, co się działo na 8 bitowcach :) Turbo, to jedno, a kompresja plików wykonywalnych, to drugie. Programy na dyskietkach (i taśmach) praktycznie zawsze były przechowywane w formie skompresowanej. Uruchomienie takiego programu (np. gry) uruchamiało procedurę do dekompresji, która na końcu wykonywała skok do komórki pamięci, pod którą był wynikowy kod wykonywalny. To się działo już w latach osiemdziesiątych. Kompresja mogła trwać całą noc :) Ale warto było.
Wiemy, tylko to za dużo do opisywania by artykuł nie stał się całą książką ;) oczywiście chodzi o np. słynny komunikat „Decrunching…” :)
Szanowny Panie, jak wiesz to popraw te bzdury. Masz od 12 minuty lopatologicznie youtu.be / _9SM9lG47Ew
przeciez napisał o tym na początku arta…
Nie. Na początku arta jest info o innej metodzie zapisu i odczytu. Nie ma to nic wspólnego z kompresją.
W C64 przyśpieszenie ładowania z kasety polegało na modyfikacji systemu zapisu i odczytu kodu, w tym np. pominięcie danych naprawczych. I do tego służyły programy typu „turbo rom”, itp. a nie do dekompresji. Podobnie przyspieszenie odczytu z dyskietki które dawał np kardridż finale III polegało na zmianie transmisji danych pomiędzy stacją a komputerem, a nie kompresją. Czyli faktycznie cały kod z dyskietki/kasety był ładowany skompresowany, przy czym kompresja nie miała wpływu na rodzaj transmisji.
Możliwe że niektóre programy stosowały dekompresję w locie podczas ładowania, ale jeżeli już to raczej pojedyncze przypadki.
Nie istnieje pojęcia „dancyh naprawczych” w kontekście zapisu na magnetofon i dysk dla popularnych komputerów 8-bit. Kolejna brednia.
Czy każdy kompresor zostawia swój charakterystyczny tag? W jaki sposób (poza rozszerzeniem pliku i ewidentnym tagiem) stwierdzić, że coś jest skompresowane określonym kompresorem?
Większość kompresorów ma charakterystyczne cechy pod względem budowy pliku wynikowego, niektóre z nich natomiast nie pozostawiają żadnych charakterystycznych cech i jedyną możliwością określenia czy plik jest spakowany danym packerem jest sprawdzenie pierwszych bajtów kodu od entrypointa – każdy packer ma inny kod.
O FSG nie wspomnieliście, kolejny polski wynalazek. W 98% używany do pakowania malwaru.
Ach tak, FSG od xtreeme – cii, to będzie w kolejnej części tej serii!
@Sopel, czy ten art i następne będą również na >>> niebezpiecznik.pl?
Nie, ale pojawi się tam za to niedługo coś innego, czego nie będzie tutaj :)
Hej Sopel,
O czym jeszcze napiszesz?
Art. ciekawy…
Dzięki!
Przejrzymy jeszcze inne zabezpieczenia kodów aplikacji, a później gier :)
Mają jeszcze jeden minus: nieznacznie marnują pamięć operacyjną. Każda instancja programu musi bowiem dostać swoje własne strony pamięci.
Wiele razy na różnych forach wypowiadałem się, że windowsowa kompresja dysku wbrew pozorom może w wielu przypadkach przyspieszyć uruchamianie programów niż pozostawienie ich na dysku w postaci nieskompresowanej. Jak widać w artykule jest tego potwierdzenie. Niestety trudno niektórym patrzącym przez pryzmat czasów windows 95 wytłumaczyć, że szybciej jest wczytać skompresowany plik i na szybkim bo takie są obecnie procesory rozpakować w pamięci niż czytać wiele danych pliku nieskompresowanego szczególnie na dyskach mechanicznych.
Systemy Turbo w C64 i Atari nie polegały na kompresji danych. Polegały na zmianie modulacji i czasem na dodaniu kawałka elektroniki (Atari). Procesor 6502 nie miał czasu na dodatkową obsługę dekompresji, był w całości zajęty demodulowaniem sygnału w przypadku Turbo. Jedyny znany mi sposób „kompresji” przy wczytywaniu danych polegał na detekcji bloków z 0 batami i nie nagrywaniu ich przez wykorzystanie funkcjonalności chunków danych w Atari. Nie nadawał się do Turbo z uwagi na obciązenie obliczeniowe cpu a i kompresja zazwyczaj nic nie dawała, w wiekszości przypadków tylko zwiększała czas ładowana z powodu przerostu metadanych sterujących.
Wszystkie 8-bit komputery z lat 80-tych nie kompresowały nic na taśmie w czasie rzeczywistym. Nie było na to czasu w cpu. Były natomiast systemu Turbo zmieniające modulacje i sposoby zapisu bajtów na magnetofon, działały bo twórcy oryginalnych rozwiązań nie przykładali się za bardzo do roboty i w przypadku Atari osiągano absurdalne przyspieszenia (Blizzard, Turbo2000).
Ja rozumiem że trzeba od czegoś zaczynać pisanie ale żeby od bredni?
W Spectrumach też była inna modulacja – było słychać wyraźnie wyższy dźwięk, a wręcz przeważnie szum. Takich, które się czytały i rozpakowywały w pamięci, było mało, bo i po co. Za to sztuczka jak ominąć limit pamięci: wczytać kod rozpakowujący do pamięci ekranu.
W Spectrumach była inna modulacja tak samo jak inna była w każdym 8-bit komputerze. Nie było standardów. Atari miało domyslnie chyba najgorszą pod względem prędkości ale jednocześnie całkeim odporną na rozciąganie taśmy (w PRL bywały kasety które po kilku uzyciach z 60 minut robiły się 90 minut). Zx ładował szybko i z byle czego, tam nie było nawet potrzeby do turbo. C64 był gdzies po srodku ale zaleta była taka że musiał być przerabiany makgentofon, jak w Atari, turbo było czysto softwareowe. Niektóre co bardziej egoztyczne maszyny nie doczekaly sie w ogóle turbo.
Samych systemów Turbo do Atari było z naście. Każdy inny, choć wszystkie (?) opieraly się o tą samą zasadę, kodowania szerokością impulsu.
Zero kompresji, chyba że temporalnej :).
*NIE* musiał być przerabiany magnetofon w C64
O właśnie. I o tym pisałem na górze w komentarzu. To nie była kompresja. Kompresja (a w zasadzie dekompresja) była również, ale nie w czasie ładowania. Następowała po uruchomieniu załadowanego już pliku wykonywalnego.
Kompresja to jedno.
Turbo to drugie.
Oba mozna stosować w dowolnych kombinacjach. Ale moc procesorów 8-bit nie była wystarczająca na obsługe jednoczesną, zawsze to było szeregowo, najpierw wczytywano, potem robiono dekompresje. A już na pewno nie można Turbo nazywać metodą kompresji, to zmiana modulacji w przypadku magnetofonu.
Pomijam, że kompresja gier to domena demosceny i crackerów. Normalne wydania gier nie bawiły się w takie mierne oszczędności (pojedyncze procenty dla duzych gier z uwagi na to że większość packerów była kiepska bo musiała być szybka, bywało że to tylko wariacja żalosnego RLE, lepsze pakery pojawiły się bardzo późno) natomiast crackerom było to potrzebne to wstawiania intra/trainera które inaczej zazwyczaj się nie mieściło.
Turbo istniało też dla stacji dysków i też nie miało nic wspólnego z pakowaniem a jedynie ze zmianą sposobu komunikacji z kontrolerem stacji. Ani jeden bit nie był zmieniany.
Autor do wymiany. Albo niech skasuje to intro. Jeszcze ktoś przeczyta.
@Sebo, STOP zostaw Sopla, on nie jest temu winny, po prostu nie doczytal z Internetu.
@Sopel, glowa do gory nastepny art bedzie lepszy ;)
„Panu tu pieprzy od rzeczy, panie Arturze, ale skoro juz żesmy wydrukowali …” – autentyczny cytat recenzenta z pewnego wydawnictwa technicznego z lat 80 ;)
Nie przesadzaj. Błędy merytoryczne w publikacjach wytyka się od setek lat. Tutaj mieliśmy po drodze, mam nadzieję, kilka miejsc gdzie ktoś na to powinien zwrócić uwagę a nie zwrocił. Czy to aby nie świadczy o tym że autor nie powinien więcej pisać byle czego bez sprawdzenia a redacja nie powinna zatrudnić ludzi którzy mają śladowe wykształcenie informatyczne i nie chodzą do gimnazjum? Uczym się na błędach, ale tego nie da się robić jesli ktoś błedu nie pokaże palcem. No więc pokazuje. Z nadzieją że to podniesie poziom merytoryczny. Ale nie jest to jakaś specjalnie wielka nadzieja.
@Sebo, dobrze prawisz jak ktos pisze glupie glupoty nalezy to wskazac, majac nadzieje ze zmieni sie podejscie autora do weryfikacji wiedzy przed publikacja. Czego mi brakuje…? Odnosnikow do wiarygodnych zrodel…
Szkoda ze nie jest to wymog do umieszczania artykulow w Internecie.
@Sopel, czekamy na wdrozenie dzialan korygujacych…
Takie mamy pokolenie facebookowe że wiarygodnośc artykułu ocenia się po jego fajności a nie cytacjach i poziomie recenzji. Co robić, kiedyś aby napisać artykuł do technicznej gazety trzeba było się postarać. Teraz pisać każdy może a desperackim pędzie do zapełnienia czymkolwiek strony … no …
@Sebo To się nazywa (brak) wykształcenia technicznego – konkretnie inżyniera :)
Brak wykszłatecnia technicznego jeszcze nie eliminuje człowieka z procesu pisania bądź recenzji tekstów technicznych, np. w informatyce jest wielu samouków. Dopiero wrodzony tuamnizm (czyli „jestem humanistą bo nie rozumiem matematyki”) powinien elimiować. Zakładam że Autor nie przypuszczał e pisanie tekstów technicznych to taki cieżki kawałek chleba. Na wszystko trzeba mieć dowód, cytacje, odnośnik. Na szczęscie od wieków i mam nadzieje że po wieki.
Strona https://www.exetools.com/ faktycznie nie jest aktualizowana od lat. Jednak forum https://forum.exetools.com/ działa cały czas i tam są najnowsze narzędzia do „zabawy”. Godnym uwagi jest również forum https://forum.tuts4you.com/
Jest jeszcze jeden problem związany z pakowaniem exe – niektórzy (mniej przykładający się) twórcy antywirusów traktują z góry pliki skompresowane niektórymi algorytmami jako podejrzane
Będzie o tym w dodatku do tego artykułu :)
Co wy tam palicie? Żaden system turbo dla Atari czy C64 nie używał kompresji.
Ja? Radomskie. Ale jak Pan Major chce, to Franz ma Camele :p
A co do Twoje komentarza, już o tym wspomniano 10x. Po co powtarzać?
@Falmic he he :D
Mnie natomiast interesuje jedna rzecz – jak w ogóle exe-packery działają? Bo o ile pamiętam, UPX bardzo ładnie pakował zarówno pliki pod Windowsem jak i pod Linuksem, na poziomie 40-60%. Co jest zatem – w prostych słowach – „śmieciem” w exekach którego można się pozbyć?
@Art W plikach formatu EXE nie ma w zasadzie śmieci. Zainteresuj się budową pliku EXE to sam zobaczysz, że po pierwsze ma on ściśle określoną strukturę logiczną.. składającą się z przestrzeni które np. są dopełniane zerami. Pod pewnymi adresami w pliku (offsetami) muszą znajdować się informacje gdzie i co się znajduje. I tak dalej i tak dalej. Plik EXE to jest w zasadzie plik o zadanej strukturze w której wpisany jest kod maszynowy + dane. Część da się mocno skompresować, a część bardzo słabo lub w ogóle. A jeszcze inne fragmenty można po prostu generować z automatu.
„Śmieciem” jak to nazwałeś jest entropia kodu i innych danych w pliku wykonywalnym, która zwyczajnie jest niska. Exepacker używa algorytmów kompresji do zwiększenia poziomu entropii, jednocześnie zmniejszając rozmiar pliku. Generalnie w plikach exe nie ma niepotrzebnych danych, ale można stosować pewne optymalizacje do zmniejszenia jego rozmiaru przed kompresją, jak np. przycinanie sekcji, usuwanie informacji debug, relokacji, nadmiarowych ikon itp. Są to rzeczy bardziej zaawansowane, które mogą powodować pewne niestabilności w specyficznych sytuacjach.
Fabrice Bellard to niezly kozak, warto napisac o nim jakis artykul. Moze powstanie nowy cykl, biograficzny?
Cześć,
Mam jeszcze jedno pytanie a o złożonych systemach też będzie np.:
Google itp.?
Dzięki
„(ładowanie mogło trwać nawet do 15 minut)”
Mogło trwać tyle ile było taśmy nawiniętej… czyli 1-1.5h o ile mnie pamięć nie myli
Widzę, że pojawiło się dużo komentarzy na temat Turbo w C64. Przyznaję się bez bicia, że uprościłem ten opis do jednego akapitu i może on być przez to mylący dla niektórych w pewien sposób – miałem na myśli skompresowany kod, który był następnie zapisywany metodą Turbo – dopiszę w najbliższym czasie rozwinięcie tego tematu by sprostować niejasności.
Nie uprościłeś. Napisaleś bzdurę. Pakowanie danych i Turbo to dwie rzeczy niezależne od siebie. Nie brnij. Ciągle jeszcze żyją osoby ktore doskonale wiedza jak to dzialało. Poczekaj choć aż wykitują.
Cześć,
Mam jeszcze jedno pytanie a o złożonych systemach też będzie np.:
Google itp.?
Dzięki!
PS polecisz jakieś dobre książki o hackingu?
Turbo niczego nie kompresowało. Turbo modyfikowało format zapisu na taśmie, tak ze miał on większą gęstość i wczytywał się do komputera z większą szybkością. Zamiast – załóżmy – 300 bps, wczytywało się 1200 albo 2400 bps :).
Nie ma to nic wspólnego z kompresją kodu.
Hej, dlaczego mój komentarz się nie pojawia? Po raz kolejny mam taki problem, kiedyś wcześniej miałem go na Niebezpieczniku…
Komentarze są moderowane i mogą pojawiać się z opóźnieniem, bo redaktorzy uprawnieni do ich zatwierdzania nie spędzają całego swego czasu przy komputerach (choć może by i chcieli)
W następnym odcinku wstęp do SoftIce’a. W międzyczasie prosimy o zapoznanie się z +HCU.
bedziemy crackowac crackmesy mNICHa :D
Zaczniemy od czegoś prostszego, np. od WinRARa :P
Albo napiszemy vxd-ka do emulacji niektórych dongli na LPT. Tudzież wygenerujemy licencję FlexLM czając się na ichnią implementację strcmp.
„mowa tutaj przede wszystkim o najpopularniejszych wówczas komputerach Commodore 64 oraz ZX Spectrum”. Gdzie tak było? W Polsce najpopularniejsze było Atari.
ZX był bardzo popularny na wyspach, c64 choćby za naszą zachodnią granicą, zaś za wschodnią były dziesiatki klonów ZX. Różnie z tym było, być może jednak jakiś udział na rynku mial Pewex który Atari miał w ofercie jak pamietam. Na pocieszenie autora mozna powiedzieć że c64 faktycznie C64 wyprodukowano naście milionów i nikt go w produkcji nie pobił. I już nie pobije bo ostatnie komputery o stabilnej architekturze znikneły wraz z Amigą.
@Sopel
Mimo „małych” błędów świetny artykuł.
A może by tak pójść o krok dalej.. i wstawiać przykładowe kody ASM doklejania własnych procedur do już istniejących plików typu .COM czy EXE?
pozdrawia
fan ATARI
Dudek Andrzej – „Jak pisać wirusy”
To już staroć ale jest ciągle w konteksie artykułu sensowna.
Jak napisał @Sebo – jest to sensowna pozycja, którą bardzo dobrze znam :) o dziwo przeczytałem ją dopiero po moich „próbach i błędach” :D mimo wszystko dopisywanie własnego kodu, czy nawet przykłady w takich artykułach mogą być nużące dla niektórych czytelników. W następnych będę miał dla was niespodzianki za to :)
Dudek Andrzej – „Jak pisać wirusy”
@Sebo, Książka Andrzeja Dudka to była jedna z moich pierwszych książek związanych z komputerem. Oj bardzo się przysłużyła w mojej edukacji.
Można go nie lubić, ale chyba zapomniałeś o polskim królu exe-pakerów i exe-protektorów – Bartoszu Wójciku od PELocka, to najbardziej znany protektor z Polski (innego chyba nawet nie ma) https://www.pelock.com sam próbowałem go kiedyś łamać, ale trudna sprawa, po tygodniu mi się odechciało ;-)
Kiedyś próbowałem zrobić prostego EXE-Packera w win32asm, działał na 3 plikach na krzyż, to jest góra roboty i Mont Everest testowania.
To co wyprodukował bart – ciężko przebić nawet w skali światowej. Są to lata pracy i dekady doświadczenia. Wcale mnie nie dziwi, że nie mamy nikogo innego kto na tym polu reprezentuje Polskę, ponieważ ten temat jest niezwykle trudny, polecam samemu spróbować żeby zrozumieć.