Na ile da się zdezasemblować program?

Na ile da się dys-asembler-ować program , czy można jakoś zamienić kod na język wyższego poziomu np. na c ? Np. exe jakiejś gry jak mafia .

Podstawowa sprawa - dezasembler dezasembluje do deadlistingu w... asemblerze. Do jedynego-słusznego-disasma (Interactive Disassembler) istnieje plugin dekompilatora - HexRays - potrafiący ze sporą pomocą użytkownika generować kod w prawie-ANSI C. http://hex-rays.com/decompiler.shtml - do poczytania i obejrzenia. Korzystając ze specyficznych dla kompilatora informacji RTTI itd. można niby jeszcze trochę to podkręcić, ale to tyle, na dzień dzisiejszy wiele więcej z kodu natywnego się nie wyciągnie.

Aha, jeszcze jedno, nie próbuj zaglądać do 'Order Hex-Rays Decompiler Europe'.

Może najpierw dowiedz się co decyduje o poziomie aplikacji... Podczas kompilacji kod schodzi przez wszystkie poziomy aż do najniższego, więc powstają miliony możliwości jeśli chodzi o ponowne podniesienie aplikacji wyżej. Skąd możesz wiedzieć co jest w kremie który został perfidnie i mocno zmiksowany? Smakuje dobrze, ale żeby odkryć co w nim jest trzeba przeprowadzić szczegółowe badania...

@deus
No tak... Tylko wynik podnoszenia tego kodu kilkukrotnie zmielonego będzie zupełnie inny niż wejściowy. Duża część na pewno będzie wymagała poprawek ludzką ręką, zakładając że chcemy zrozumieć kod.

HexRays nie robi praktycznie nic wartościowego sam z siebie. Użytkownik ma od cholery roboty żeby ponazywać zmienne, oznaczyć tablice, rozmiary/wtf, podobierać typy - dopiero wtedy HR może pokazać swoje możliwości. Tutaj jest całkiem fajny przykład tego, co ten plugin potrafi zrobić jeżeli się go odpowiednio poprowadzi - http://www.hexblog.com/decompilation/files/lighty_fraudload.zip.

Czyli da się zrozumieć dowolny kod trzeba tylko trochę posiedzieć nad tym. Oczywiście nazwy będą inne niż początkowo ale to nie jest jakiś większy problem raczej.

Nazw nie będzie wcale, o ile nie są zawarte w RTTI lub rozpoznane poprzez biblioteki sygnatur - wszystko nazywasz ręcznie, wedle własnego uznania. Co do 'nie jest to jakiś większy problem' to się 'raczej' mylisz, tylko na pierwszy rzut oka wygląda prosto. Stary przykład bardzo popularnej i prostej funkcji, z 'dekompilacją' (HexRays 1.1), po znajomości:

http://pastebin.4programmers.net/760 - asm // edit - poprawiłem link bo poprzedni kod nie zawierał chunków
http://pastebin.4programmers.net/758 - 'C'

...a teraz powiedz mi co to za funkcja, najlepiej od razu.

StudentX napisał(a)

Na ile da się dys-asembler-ować program
Dezasemblować chyba.

czy można jakoś zamienić kod na język wyższego poziomu np. na c ?
W zasadzie tylko ręcznie z asemblera. Inaczej to wygląda w przypadku kodu zarządzalnego, np. programów w Javie czy C#. Tam, jeśli twórcy nie zastosowali obfuskacji (zaciemniania) kodu, można odtworzyć prawie dokładnie kod źródłowy /ale oczywiście bez komentarzy ;-)/

Np. exe jakiejś gry jak mafia.
Co innego mały pliczek mający kilobajt pojemności, a co innego wielomegabajtowa aplikacja. Ogarnięcie wielkiej ilości kodu asemblerowego jest niemożliwe. W skompilowany kod zagląda się tylko w konkretnym celu, np. złamania jakichś zabezpieczeń. A i wtedy większość czasu zajmuje szukanie i izolowanie odpowiedzialnej za to funkcji.

Azarien napisał(a)

Co innego mały pliczek mający kilobajt pojemności, a co innego wielomegabajtowa aplikacja. Ogarnięcie wielkiej ilości kodu asemblerowego jest niemożliwe. W skompilowany kod zagląda się tylko w konkretnym celu, np. złamania jakichś zabezpieczeń. A i wtedy większość czasu zajmuje szukanie i izolowanie odpowiedzialnej za to funkcji.

No nie wiem, pracowałem przy tworzeniu 'nieoficjalnych' rozszerzeń do jednego programu, trzeba było rozłożyć całą mechanikę GUI (własne klasy MFC pisane jako zamiennik kontrolek systemowych) żeby coś swojego dodać, jak to było 1kB kodu maszynowego to mam swoje zdjęcie w avatarze (Keeeraaaj, doonkeeey?). Wszystko jest możliwe, wymaga tylko nieco czasu - definiujesz struktury, enumy i ich używasz, nazywasz kolejne funkcje... Co więcej, robiłem to bez możliwości debugowania kodu w ogóle, połapanie się w tym zajęło pewnie ze dwa tygodnie, ale nie było niewykonalne.

Myślisz, że jak się robi statyczne unpackery do protectorów? Raz, że zwykle trzeba sobie z obfuskacją poradzić to jeszcze trzeba to dokładnie przeanalizować i napisać na bazie tego własny kod, najlepiej czyniąc niezależnym od konkretnej wersji. Też sporo zabawy i babrania się w wielu kilobajtach niezbyt czytelnego asm, ew. z pomocą HexRaysa (tutaj naprawdę może się przydać).

Nie przesadzaj też, że szukanie tyle czasu zajmuje. Nie pamiętam kiedy ostatni raz miałem taki przypadek, że więcej szukałem niż analizowałem właściwą mechanikę. Jak wiesz czego się spodziewać to są dziesiątki sposobów na znalezienie. Jedyne co naprawdę może spowolnić to obfuskacja/wirtualizacja.

// poprawiłem temat bo aż oczy bolały...

deus:
memmove?

Np. exe jakiejś gry jak mafia

Taniej będzie napisać silnik od nowa (tzn wynająć kogoś do napisania kodu).

// tak w sumie to popsułeś zabawę, można przyjąć, że to memmove - deus

W takim razie mam inne pytanie , jak najlepiej zabezpieczyć program zdezasemblowaniem ?

Obfuskując, wirtualizując niektóre partie kodu... streszczając - inwestując w protektor.

Tylko po co ktoś miałby dezasemblować? Łatwiej ukraść kod niż ten zdekompilowany doprowadzić do stanu uzywalności. A jeśli ktoś chciałby zlamać zabezpieczenia to z protektorami i tak sobie poradzi w rozsądnym czasie.

Jak chcesz mieć 100% pewność że nikt ci nie zreversuje kodu, to go nikomu nie dawaj, tylko odpal uslugę w chmurze, która będzie dokonywać odpowiednich obliczeń.

donki7 napisał(a)

Łatwiej ukraść kod niż ten zdekompilowany doprowadzić do stanu uzywalności.

Wiesz, to co dałem to tylko efekt wciśnięcia F5, bez obróbki, nadawania typów itd. Poza tym to cholernie mocno optymalizowana implementacja memove, po prostu nazywasz funkcję _memmove i zostawiasz, przecież nie będziesz przeklejał fragmentów biblioteki standardowej...

Tak się składa, że bardzo często się algorytmy szyfrowania, kompresji, obsługę wirtualnych systemów plików robi przynajmniej częściowo na bazie deadlistingów. Tzn. jeżeli mówimy o ingerencji w dane danego programu, protokołu komunikacji...

Tak swoją drogą to czemu w mem<cóśtam> nie jest używane DMA (tzn oddzielny scalak) dla dużych bloków?

Mógłbyś rozwinąć?

Wikipedia napisał(a)

DMA ma za zadanie odciążyć procesor główny od samego przesyłania danych z miejsca na miejsce (np. z urządzenia wejściowego do pamięci), procesor może w tym czasie zająć się „produktywnym” działaniem, wykonując kod programu pobrany uprzednio z pamięci RAM do pamięci cache operujący na danych w tejże pamięci zgromadzonych. Specjalizowane układy wspomagające DMA (np. te spotykane w PC) potrafią też kopiować obszary pamięci dużo szybciej niż uczyniłby to programowo procesor główny.

Natomiast w żadnym kodzie funkcji kopiujących nie znalazłem odwołania do takich specjalizowanych układów, a niby coś takiego w PC jest.

Cholera, jak ja dawno się mechaniką DMA nie interesowałem... będzie z 7 lat. Coś mi się kojarzy, że RAM <-> RAM jest średnio wykonalne bo nigdy z pomysłem wykorzystania w tym celu się nie spotkałem. Poza tym nie przesadzajmy, raczej nie kopiuje się setek megabajtów RAM <-> RAM, zaś odpalenie operacji DMA ma swój koszt.

ale DMA to chyba transmisja pomiędzy hd/cdrom <-> RAM z pominięciem procesora. Znając życie, technologia już dawno pewnie przestarzała :)

kod programu może się nie opłacać doprowadzać do stanu użyteczności , ale np. jakieś algorytmy już raczej tak. Np ja bym chciał zobaczyć jak wygląda kod rozpoznający capatha.

Nie capatha tylko captcha. Ty moze lepiej przejrzyj kod odpowiadajacy za sprawdzanie pisowni np w wordzie albo firefoxie ;p
Poszukaj to znajdziesz....

areksum napisał(a)

ale DMA to chyba transmisja pomiędzy hd/cdrom <-> RAM z pominięciem procesora.

Ogólnie transmisja RAM-urządzenie z pominięciem procesora.

Znając życie, technologia już dawno pewnie przestarzała :)

Nie.