Um welche Art von Schutz handelt es sich?

[blub33]

Hallo Leute
ich hab hier eine DLL die auf mich gecrytet wirkt.
Nach dem ich mir jetzt paar Tutorials angeguckt habe ,hab ich festgestellt mit so Sachen wie antidebuger hat das nicht viel zu tun.
Es ist eher eine Art Verschlüsselung von 2-3 Subroutinen um Cracken zu verhindern/erschweren.

Mit Peid ist nichts erkennbar,es wird lediglich Visual Studio C++ angezeigt.

Auffälig ist vor allem das es exakte Bereiche betrifft und nicht die gesamte DLL außerdem
sind doch Text Strings nicht zu Lesen.

Hier mal ein paar Beispiele:

Normale Stelle:

Text strings referenced in Test:.text, item 1623
Address=10057EDB
Disassembly=PUSH Test.100781E8
Text string=ASCII "remove one 25b0 msg"

Gecryptete Stelle (selbe DLL):

Text strings referenced in Test:.text, item 1611
Address=10057720
Disassembly=ASCII "25Ô#?b?a,?,"

Auszug:

100404E5 . 38 3A 63 57 FB 00 ASCII "8:cW?",0
100404EB 2C DB 2C ; CHAR ','
100404EC 57 DB 57 ; CHAR 'W'
100404ED 76 DB 76 ; CHAR 'v'
100404EE BD DB BD
100404EF BE DB BE
100404F0 45 DB 45 ; CHAR 'E'
100404F1 CB DB CB
100404F2 E4 DB E4
100404F3 CF DB CF
100404F4 22 DB 22 ; CHAR '"'
100404F5 DC DB DC
100404F6 BD DB BD
100404F7 FE DB FE

oder

Normal:

1001C060 /$ 8B5424 08 MOV EDX,DWORD PTR SS:[ESP+8]
1001C064 |. 53 PUSH EBX
1001C065 |. 8BD9 MOV EBX,ECX
1001C067 |. 55 PUSH EBP
1001C068 |. 33ED XOR EBP,EBP
1001C06A |. 56 PUSH ESI
1001C06B |. 8B83 58600000 MOV EAX,DWORD PTR DS:[EBX+6058]

Crypted:

1003FBF5 . 2D E1F9FE3B SUB EAX,3BFEF9E1
1003FBFA . 34 60 XOR AL,60
1003FBFC . ED IN EAX,DX ; I/O command
1003FBFD . 15 C0D0CCF1 ADC EAX,F1CCD0C0
1003FC02 . FC CLD
1003FC03 . 19DE SBB ESI,EBX
1003FC05 . EE OUT DX,AL ; I/O command
1003FC06 . 21F5 AND EBP,ESI
1003FC08 . 52 PUSH EDX
1003FC09 . E1 2A LOOPDE SHORT silk.1003FC35

Wie kann ich nun an sowas herangehen?
Ich hab gehört es sollte sich wenn die DLL geladen ist uncryted im Speicher befinden, allerdings komm ich damit nicht groß weiter.

thx =)

 

[CDW]

Wie kommst Du darauf, dass die DLL verschlüsselt wäre? Eine DLL hat ja nicht nur code, sondern auch data - Bereiche. Der von Dir gepostete Auszug

2C DB 2C ; CHAR ','
100404EC 57 DB 57 ; CHAR 'W'
100404ED 76 DB 76 '

schaut mir stark nach Relocations aus (dieselben wiederholendne Muster wie relative Adresse - xy DB zz, xz DB zz ).
Grundsätzlich ist es recht schwer, ohne geeignetes Aufrufprogramm oder Dokumentation (was die DLL können muss) vorzugehen, da man dann keinerlei Kenntnisse über Parameteranzahl und Parameterart, Rückgaben, Laufzeitverhalten usw der Funktionen hat.

Wenn ein "Aufrufpogramm" vorhanden ist, könnte man so vorgehen: mit einem PE Editor die Exports der DLL anschauen. Das Aufrufprogramm mit einem Debugger laden und schauen, was passiert, wenn einzelne Funktinen der DLL aufgerufen werden.
Bei OllyDbg wäre z.B eine Möglichkeit, unter "Options->Debugging Options->Events" das "Break on new modul DLL " einzustellen. Sobald die DLL geladen wurde, pausiert Olly und man kann auf den ganzen Exportfunktionen Breakpoints platzieren und schauen, ob der vermutlich verschlüsselte Code nicht irgendwann entschlüsselt wird (z.B in dem man einen Hardware Breaktpoint "on read" oder "on write" auf die (vermeindlich verschlüsselte) Code stelle setzt) und ob diese Codestellen überhaupt ausgeführt werden.
Wenn diese Stellen entschlüsselt werden (die DLL liegt also entschlüsselt vor), kann man i.R entweder mit dem Debugger oder einem entsprechenden Programm (LordPE, PE Tools) ein Speicherabbild (->Dump) erstellen. Nur hast Du dann das Problem, dass es damit i.R nicht getan ist. Ob man es machen muss, kommt allerdings auf das Problem an.
Ansonsten besteht durchaus die Möglichkeit, dass bestimmte Funktionen der DLL wirklich "per Hand" verschlüsselt wurden - das wird ein Analyseprogramm wie PEID oder RDG meistens nicht erkennen (dafür aber oft benutzte "offizielle" Algorithmen wie AES, DES, RSA oder Hashalgos).

Edit: ich sehe gerade, dass Du Vista 64 benutzt. K.A ob es da schon gescheite Debugger gibt. Eventuell musst Du Dich entweder mit dem MS-Debugger anfreunden oder kurzfristig irgendwo (z.B VirtualPC) ein 32-Bit XP/2000/(eingeschränkt)Vista System installieren, da die meisten bewährten Tools noch nicht für 64-Bit gibt.

 

[blub33]

Also mit Vista hab ich eigentlich weniger Probleme als ich überall lese,Speicher verändern,Olly Dbg, das funzt alles.
Nur muss bei Olly Dbg, Olly Advanced auf 64Bit eingestellt werden und die Programme brauchen Admin Rechte, sonst funktioniert bei mir mitlerweile alles wie bei XP =D .
(die DLL ist ja nicht in 64bit geschrieben , so wie fast alle Programme noch 32Bit sind )


Das die DLL verschlüsselt ist vermute ich deswegen weil die letze Dll Version genau an den betroffenen Stellen anders aussah und der ASCII Code lesbar war was jetzt nicht mehr ist.

Da es sich um eine DLL handelt die Injected wird, glaube ich werde ich kaum Exports finden.DIese wird mit einem Loader direkt beim Start injected.

Breakpoints kann ich auf die Bereiche setzen die ich angesprochen habe allerding killt dies meist den kompletten Prozess.

Das mit dem Dumpen klingt sinnvoll aber ich befürchte der wird mir die selbe Datei wieder auspucken die ich habe wenn ich mit Olly den Prozess attache.

 

[CDW]

Wie setzt Du die BPs in Olly, so dass der Prozess gekillt wird? Falls es nicht um Anti-Debugmaßnahmen handelt, tippe ich darauf, dass die BPs (die "gewöhnlichen" - also INT3) die Entschlüsselung direkt stören (durch ihr vorhandensein - es ergibt sich einfach falscher Code).
Hier sollstest Du mal mit HardwareBPs probieren (Rechtsklick auf den Code -> BPs ->Hardware. In der Regel kann man im Originalolly HardwareBPs "on read" und "on write" nur im Dumpfenster setzen - daher muss man zuerst die gewünschte Codestelle rechtsklicken und "Follow in dump" machen). Diese sind zwar begrenzt, dafür wird der Code aber auch nicht verändert (im Gegensatz zu SoftwareBPs - die man in Olly mit F2 setzt.In Olly-Code-Anzeige selbst sieht man zwar nichts, aber in Wirklichkeit schreibt Olly in den Code für die BPs jeweils einen INT3 (Opcode=0xCC) was sich dann bei ent/verschlüsselung fatal auswirkt)

Da es sich um eine DLL handelt die Injected wird, glaube ich werde ich kaum Exports finden.DIese wird mit einem Loader direkt beim Start injected.

kommt zwar auf die Injectionmethode an, aber zumindest ein DLL-Entrypoint(DLL Main oder wie auch immer der genannt wird) sollte vorhanden sein und genutzt werden.

Das kannst Du ausnutzen:
Patche den Entrypoint der DLL auf EB FE um. Das ist ein
0001 JMP 0001 (also die kleinstmögliche Schleife). Wenn die DLL geladen wird (wie gesagt, hängt von der Methode ab, aber i.R wird die WinAPI LoadLibrary genutzt, die die DLL lädt und dabei automatisch die DLL-Main aufruft) ist die erste Anweisung die von der DLL ausgeführt wird EBFE und damit hast Du komfortabel viel Zeit die Anwendung in Olly zu attachen, die DLL zu finden, den EBFE wieder zu korrigieren und dann zu beobachtenl, was gemacht wird.
In LordPE würde es z.B so gehen:
unter "EntryPoint" den Wert merken, "FLC" Button aufrufen, "RVA" anklicken, den Wert eintragen - nun zeigt das Editfeld unten die Bytes an (i.R irgendwas mit 55 8B ...) die überschreibst Du mit EB FE und speicherst das ganze.

Dank OllyAdvanced sollten eigentlich auch kleinere Antidebugtricks nicht ins Gewicht fallen. Allerdings würde ich bei selbstmodifizierendem Code trotzdem auf HardwareBPs setzen.

 

[blub33]

So ich bin jetzt so weit gekommen das es sich um Themida handelt.
Wahrscheinlich eine neuere version, Peid findet aber nix.
Ich probier mich mal mit unthemida.
Mit dem Dumpen komm ich grade irgendwie nicht weiter.