Shareware Versionen vor Cracker schützen

[Luckie]

Ich habe diese Postings vom XP Usermanager Thread abgespalten, da sie mit ihm eigentlich nichts zu tun haben. Ich habe im ertsen Posting wieder die Demo Version angehangen, um die es hier geht.

Ich habe die Demo Version versucht etwas sicherer zu machen. Ich hoffe, es ist nun nicht mehr ganz so leicht sie zu cracken. Ihr könnt ja mal probieren. Download wieder im ersten Posting.

[brechi]

IsDebuggerPresent :)))

[Luckie]

Jupp. Macht es denn das schwieriger oder nicht?

[brechi]

nein ;>

hatte vorher net versucht aber da du danach aufgerufen hast, hab ich für beide patches etwa 40 sekunden gebraucht (das entpacken von UPX mal abgesehen)

[Luckie]

Und warum ist es nicht einfacher?

[brechi]

du meinst schwieriger?

weil das ein API call mehr ist, wo nen bp drauf gemacht wird
ich könnte da mal nen video zu machen, aber hab ledier gestern formatiert hab das prog net mehr.


könnte dir aber eins zeigen wo ich das mal mit mIRC gemacht habe, das hat 5 mins gedauert (1 mal vorher getestet, ca. 15 mins)

[Luckie]

Und wie kommt man an die Sprungadresse ohne Debugger?

[brechi]

um jetzt mal die wenigen tastenkombinationen aufzuzählen

doppelklick auf ollydbg.exe
f3
auswahl der exe
alt+e
klick auf kernel32.dll
strg+n
eingabe "isdebuggerpre"
f2
f9
3* f7
cursor nach oben
leertaste
xor eax, eax
rechtsklick druf
copy to executable
selection
fenster schließen
ja klicken
speichern klicken

und es ist gepatched, wie das mit dem fenster geht muss ich ja net sagen ^^, nur der isdebuggerpresent patch bringt ja nix

[Luckie]

Bitte noch mal probieren die Demo zu cracken. Es gibt eine neue Version. Download im Anhang vom ersten Posting.

[Olli]

Ist schon deutlich schwerer. Dumper helfen nichts, weil die zu doof sind und nichtvorhandenes eben auch schwerlich wiederherstellen können. Mein Ansatz zum "Crack" wäre entsprechend ein Loader. Offenbar immernoch mit UPX 1.24 gepackt, aber dann irgendwie durch einen Scrambler oder Crypter gelaufen. Wie üblich kann man die Debuggerdetection ausschalten, indem man an 0x7FFDF002 das Byte von 1 auf 0 patcht (== PEB.BeingDebugged), bevor man das Programm weiterlaufen läßt. Da IsDebuggerPresent() bekanntlich nichts anderes tut als jede normale NT-Debuggererkennung (IsDebuggerPresent ist eben nur wie ein Leuchtturm für den Cracker, mehr nicht *g*):

Code:

.text:77E5AC39 _IsDebuggerPresent@0 proc near
.text:77E5AC39                 mov     eax, large fs:18h
.text:77E5AC3F                 mov     eax, [eax+TEB.Peb]
.text:77E5AC42                 movzx   eax, [eax+PEB.BeingDebugged]
.text:77E5AC46                 retn
.text:77E5AC46 _IsDebuggerPresent@0 endp

Damit ist dann schonmal die halbe Miete eingefahren. Denn jeder nicht allzu dumme Mensch weiß, daß NTDLL und Kernel32 nicht relozierbar sind und sich deshalb (Billseidank :lol:) immer an der gleichen Stelle im Speicher befinden, nämlich an 0x77880000 respektive 0x77E40000 (und User32 an 0x77D00000; die Adressen unterscheiden sich je nach OS-Version). Der PEB sitzt ebenfalls immer einheitlich an 0x7FFDF000 (bisher bei jedem NT). So ist es nun ein leichtes, nachdem wir den Debuggermist ausgeschalten haben, einen Breakpoint auf eine der definitiv aufgerufenen Funktionen (z.B. erstmal LoadLibrary, dann MessageBoxA/W) zu setzen um das wunderbar entpackte Programm zu begutachten. Der Rest (d.h. das Patchen) wäre dann Aufgabe des Loaders als Hauptbestandteil eines Cracks. Alternativ kann man natürlich das Programm dumpen und dann die Strukturen wiederherstellen. Aber wozu - das wäre ungleich schwerer.

Fazit: Wie gesagt, es ist deutlich schwerer im Vergleich zu den vorigen Malen. Es ist aber mit ein wenig Mehraufwand möglich, den ich aktuell aus Zeitmangel aber nicht investieren möchte.

Ich vergaß zu erwähnen: Natürlich kann man an 0x0053B034 die beiden DWORDs nach dem Start beobachten, denn der PE-Loader ist ja so nett uns schonmal die Adressen der beiden importierten Funktionen einzufüllen:

Code:

.idata:0053B034 ; Segment type: Externs
.idata:0053B034 ; _idata
.idata:0053B034 ; FARPROC __stdcall GetProcAddress(HMODULE hModule,LPCSTR lpProcName)
.idata:0053B034 GetProcAddress dd offset kernel32_GetProcAddress
.idata:0053B038 ; HMODULE __stdcall LoadLibraryA(LPCSTR lpLibFileName)
.idata:0053B038 LoadLibraryA dd offset kernel32_LoadLibraryA

Danach muß nur noch zu diesen Adressen gegangen werden und ein Brakpoint gesetzt werden. Ich habe es mit dem Patchen von 0x7FFDF002 (s.o.) geschafft, daß das Programm normal im Debugger läuft. Dank IDA kann man einen Teil dieser Aufgaben mit einem kleinen IDC-Script automatisieren, wobei auch nach einem Neustart des Programms die Analyse deutlich beschleunigt wird *g*
Interessant ist dieser Packer oder Crypter oder Packer mit Scrambler oder Crypter allemal, weil dort noch Stacktricks verwendet werden, von denen ich nicht sicher wäre, ob die bei XP SP2 noch laufen. Scheinen sie ja aber - kann das mal jemand testen?