Hogyan írják a töréseket?

Visszafordítják a programot. Assemblybe elég egyszerű, de pl. az IDA Pro nevű programmal C szerű kódot is elő tudnak állítani.

Utána pl ha van egy üzenet, hogy nem található a licensz, vagy hasonló, akkor ez a szöveg talán megtalálható a visszafordított kódban. Ennek van egy címe... ezt meg lehet keresni, hogy honnan hivatkoznak rá. Aztán amelyik "függvény" ezt megívja, vagy ami azt hívja stb taralmaz egy elágazást egy feltétel alapján. Ami azt mondja meg, hogy regisztálva van-e a cucc. És itt csak át kell írni, hogy pont ellenkező esetben ugorjon. (pl jz => jnz) (Vagy mindig vagy csak simán ne ugorjon)

Így előáll a megcrackelt program.. ezt persze tesztelik. Utána már gyerekjáték egy kis programocskát írni, ami az adott bájtot módosítja.

Én nem vagyok cracker, de pár natív alkalmazát sikerült már így feltörnöm. Persze azért próbálkoznak védekezni ez ellen is... de hát az csak annyit jelent, hogy bonyolultabb megtalálni, hogy hol is kell átírni valamit :)

Ha esteleg nem natív kódról van szó, hanem pl egy .NET-es vagy Javas alkalmazásról, akkor mégkönynebb dolga van a crackernek. Még akkor is jóval könnyebb, ha obfuszkálva van az alkalmazás.

Nagyon leegyszerűsítve és sablonosan: valaki ír egy szoftvert/programot egy vagy több magasszintű nyelven (pl: Java. C++, Python stb...) - ugye a számítógép nem érti ezeket a nyelveket, ahhoz hogy futni tudjon rajta egy program átalakítja bináris kóddá (0 és 1-sek szekvenciális sorozata) és ezt a bináris kódot képes futtatni. Azonban ez a bináris kód visszafejthető assembly kódra ami körülbelül egy átmenet a gépi kód és a magas szintű programozási nyelven írt kód között (pl: regiszterek értékei hogyan módosulnak, milyen memóriacímeket használ a program stb...). Bizonyos szoftverek segítségével és kellő szakértelemmel az assembly forráskódja megváltoztatható egy programnak így gyakorlatilag az eredeti működéstől eltérő lesz a program működése, de a funkcionalitása megmarad (pl: úgy módosítasz egy programot, hogy a belépés ellenőrzésénél mindig IGAZ legyen a feltétel kiértékelése, és ekkor bármilyen kulccsal be tudsz lépni vagy egyszerűen kikommentezed ezt a részt az assembly kódban és nem fogja kérni például a nevet és a kulcsot).

Ilyen módon offline programokat lehet patchelni, online ellenőrzésnél amikor egy távoli szerver végzi el a hitelesítést akkor pedig általában a hálózati kommunikáció során kiküldött csomagoknak a visszafejtésével és kiértékelésével lehet elérni a célt.

Szoftvereket szándékosan nem írtam, nehogy sértsem az oldal házirendjét, viszont ha érdekel bővebben a téma akkor "Reverse Engineering"-nek nézz utána, egyébként a vírusok/kártékony szoftverek működését is ilyen módon szokták visszafejteni laborkörnyezetben.

Úgy, hogy a bináris futtatható kód (EXE, DLL, stb) is k#rvanagy türelemmel lépésenként megértehtő, visszkövethető hogy működik. (pl. IDA, Immunity, OllyDbg). Hol van (akár több helyen) a licensz vizsgálat, hol történik egy elágazás. Majd a bináris kódban ezt átírják, és hopp... volt elágazás, nincs elágazás.

Kicsit bonyolultabb ha anitdebug kód, vagy spéci PE packer van. De azokra is vannak "gyógymódok". (PE unpackerek, dumpok, debug scriptek. stb).

Van ahol hasonló módszerrel megfejtik, hogy a licensz kulcs ellenörzés hogyan történik. És hopp egy licensz generáló már is készíthető.

De vannak elterjedt "dobozos" licensz protektorok (tipikusan gardverkulcsok ilyenek) amit a védendő alkalamzásba építenek (pl Sentnel, HASP). Ezeknél a törés gyakran egyszerűbb, mert már eleve ismert a metódus.

Nem kell ehhez forráskód. De pl. a védelem (obsfucator) nélküli IL kód, .NET-be majdnem forrásód minőségűvé fordítható vissza (pl. dnSpy).

Remélem a kíváncsiságod kielégítettem :D :D

Nem teljesen úgy, ahogy eddigiek leírták.

A programokat elindítják, majd trace-elik, és figyelik, hogy milyen folyamatok zajlanak le. Adott folyamatnál töréspontokat helyeznek el, bizonyos címen elhelyezett változók értékeit felülírják, vagy egyszerűen félre jumpolnak, tehát kikerülik az ellenőrzési folyamatot.

#5: Azért indítástól kezdve a licensz ellenőrzésig nem tudod végig tracelni.. Előtte azért meg kell találni hogy kb hol van.

Másrészt "változók" nem nagyon vannak... csak regiszterek.

Szerintem te még ilyet nem csináltál.

"Másrészt "változók" nem nagyon vannak... csak regiszterek."

Regiszterek a processzorban vannak. A program meg a memóriában foglal helyet. Változók nélkül nem létezik számítógépi program.

"Szerintem te még ilyet nem csináltál."

Te sajnos nem vagy arra képes, hogy ezt rólam, vagy bárki másról megállapítsd. Nagyon zöld vagy.

#5: Szerintem pedig pl. a 4-es kb ezt pont írta le.

Egyébként a trace (ami általában az API-k/rendszerhívások automatikus "leköveteését" jelenti) nem mindig elégséges. Pl egy licenszkulcs ellenörzésnél nem sokra mész, ha látod hogy mondjuk egy nem létező licenszfájlból olvasna be valamit, de ha utána ezzel kapcsolatban nincs már API hívás akkor akkor annyi. Következő lépésként úgy is meg kell KÉZZEL és AGGYAL vizsgálni egy debuggerrel/disassemblerrel hogy a licensz fájl beolvasás után az ott lévő adatokkal mi a szenttsz@rt csinál, mi alapján dönt hogy demo vagy full működés.

#6: Ez filozófia kérdése :) A forráskódban még változónak hívjuk, a lefordított kódban pedig ezek a változók az optimalizáció függvényében vagy CPU regiszerek ahogy írtad, vagy hoszabb-rövidebb időre lefoglalt memória tartományok, vagy még annyi sem (ha mondjuk az optimalizáció rájötthogy tök felesleges). De mondjuk főleg a memóriában lefogalt "változóknál" csak filozofikus megközelítés hogy memória regisztereknek (pl öszetett struktúráknál/típusoknál a "regiszter" szó kicsit hülyén is hangzik) vagy továbbra is "változóknak" nevezzük. De szerintem ne a szemntaikába menjünk bele, a kérdező nem erre volt kiváncsi.

" trace (ami általában az API-k/rendszerhívások automatikus "leköveteését" jelenti) nem mindig elégséges. Pl egy licenszkulcs ellenörzésnél nem sokra mész,"

Jaj vazzeg.

Programok crackelésének sok fogása, metódusa van. elsősorban a programban alkalmazott védelem az, ami meghatározza a kikerülés lehetőségeit.

Ha mondjuk van egy kulcs bekérés a progi elején, akkor meg fog jelenni egy ablax. Az az ablax tartalmazni fog legalább egy adatbeviteli mezőt is meg egy OK buttont is. Az OK button meghív egy függvényt, stb. Gondold tovább.

De lehet olyat is, hogy beolvasom a file-t (ha van exe packer, akkor kicsomagolom), majd végigmegyek rajta és kiiratom azokat a cimeket, amelyekre feltételes jump utasítás mutat. Ezek közül is nyilván csak bizonyos cimek lesznek érdekesek. Gondold tovább. Már ha tudod.

"#6: Ez filozófia kérdése :) A forráskódban még változónak hívjuk, a lefordított kódban pedig ezek a változók az optimalizáció függvényében vagy CPU regiszerek ahogy írtad, vagy hoszabb-rövidebb időre lefoglalt memória tartományok, "

Ez tömény baromság. Amit írtam, az nem filozófia kérdése. Neked van egy elképzelésed arról, hogy egy számítógép miképpen működhet, meg van a valóság. A kettő meg, hát, nem igazán fedi egymást.

Kár ebbe filozófiát meg egyéb hülyeséget belemagyarázni.

#9: Szerintem Te vagy az aki elméletben sejti hogy hogyan kellene ilyet csinálni, de még egy bináris Win alkalmazást sem debuggolt soha... Jól sejtem?

Ellenben én elég sokat.

Megnézném, ahogy egy API auto trace-el pikk-pakk (olyan könnyen ahogy írtad) kitalálod, hogy milyen függvény hívódik meg az általd példának említett "OK" gombkenomásakor :) És akkor máris eshetsz neki a licenszkulcs ellenőrzés megtörésének :D

(Most arról ne is beszéljünk hogy aztán nem csak a licenszkulcs beírásánál van ellenőrzés, hanem még X helyen... pl minimum a program indítása után, vagy adott funkciók használatakor. De most a szoftverfejlesztői logikával ne bonyolítsuk :) )

Mester, gondolom tisztában vagy hogy a Windows ablakkezelője az ablakokat kezelő alkalmazásoknak csak üzeneteket küldenek az ablakot ért eseményekről (pl: egérmozgás, bill lenyomás/felengedés, vezérlő elemen key up/down, és még vagy 1000 esetben). És nem "függvényeket" hív. Biztosan csak elírtad :D :D :D

Az üzenetet megkapó alkalmazás (akihez az adott ablak tartozik) pedig egy külön threadben vár az üzenetekre a GetMessage Win32 API hívással. Majd az üzenetet elemezve eldönti mi a ménkűvet csináljon most Ő.

Tehát az autotraceddel maximum a GetMessage API hívást találod meg. Onnantól neked kell bacakodni (és ehhez egy API trace nyilván kevés lesz) hogy megtaláld azt a kódrészletet ami érdemi részben a gombhoz tartozik. Ott sajnos elő kell venni a debuggert és seggelni előtte.

Akkor van szerencséd, ha a gomb lenyomásra olyan dolgog történik az alkalmazásban ami "statikus", pl egy hibaüzenet dialógus ablak feldobása. Mert ott belebrékelsz a processbe, és valamelyik thread hívásvermében (maradva példánál, ami a CreateDialog API-t hívta) szépen fog látszani, hogy az "OK gomb megnyomása milyen függvényhívás cumnamit indított. És abból már könyebben ki lehet indulni. De ha ilyen nincs... Hidd el nagy szívás.

Most három opció lehet: vagy én vagyok béna és rossz a metódusom, vagy TE vagy k#rva profi, vagy pedig életedben nem csináltál/láttál ilyet.

De egy Win-es alkalmazásban megkeresni hogy egy gomb lenyomására majd valahol a bináris kód lófac végén mi hajtódik végre, az egyik legnagyobb szívás.

És a amit fentebb boncolgatok csak egy "pici" részfeledat szemléltetése, egy függvény megkeresése, ami Te nagyvonalúan 2 sorban letudtál. És ennél még ezerszer bonyolultabb dolgokba lehet belefutni.