[B] Selber einen Crypter coden [Englisch]

[GODFATHER]

This article will take you through the basic steps of building an executable crypter. All of the steps performed in this article require manual setup and integration to prepare the exe for the crypter stub. The focus of this article is to walk you through the theory and know-how of how crypters work and does not attempt to create the latest greatest point and click solution.

For a basic background, here is how executable crypters work:

1) The actual processor commands of a protected binary are
crypted/obscured/munged whatever

2) When the protected application first starts, a small decrypter
stub is first run that restores all of the original processor
commands for the executable in memory.

3) Finally, the decrypter stub ends and transfers execution to the
original entry point (OEP) and the program runs normally.

In the course of this paper, we are going to manually implement a very simple 'crypter' to show you all of the development techniques, design considerations, and debugging details required to make your own.

First, let me introduce you to our target executable. It is a 28kb hello world application written in C. This simple application merely prints out "Hello World" to the screen, waits for a keypress and then exits.

To get us started, lets examine the PE structure of the executable file. Below is an image of the PE section table. You will notice that the .text section (where the actual executable code is housed) has a raw size of 4000h and a virtual size of 3DCEh .


The discrepancy in the numbers indicates that at the end of the .text section there is a certain amount of unused space not currently mapped into memory when the file is loaded. This blank spot in the executable file is good because it means we have an empty pad where we can place our own executable code.

To visually verify this you can open up the file in a hexeditor and look for a null pad. To know where to look you have to be able to find the right file offset. In our sample exe this is simplified because all of our sections have a virtual size <= their raw size and each sections raw offset = its virtual offset.

This is nice because it keeps all of the rva values in the PEheader = raw file offsets however this is not always the case. V.2 of the pe editor classes now take this into account and can calculate file offsets from rva values correctly. The assumption of rva = file offset will be made through out the remainder of this article because it holds true for this particular sample we are analyzing.

So...to see this null pad open up the original exe file in a hexeditor and check out the area between 4DCEh and 5000h (RawOffset + VirtualSize)

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00004DC0 C0 74 06 0F B6 45 0B C9 C3 83 C8 FF C9 C3 00 00 Àt..E.ÉÃÈÿÉÃ..
00004DD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004DE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004DF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

For our needs this will be more than enough space to place our simple decrypter stub. We do not necessarily need to squeeze our code into an existing section. Had we been short on space, we could have resorted to adding a new PE section and placing our code there.

Ok, we have found a home for our decrypter block, but first we have to make some adjustments to the PE section characteristics so that:

A) our decrypter code gets loaded into memory
once mapped into memory, we have write access to the main body of code
C) when the program is first loaded, execution begins with our decrypter code

As noted above, the virtual size of the section (the size loaded into memory) does not include this null pad we found in the file. Since we are going to be adding code to this area, we need to make sure that this area is loaded into memory as well. This is accomplished by increasing the virtual size for this PE section using a PE editor such as LordPE.

The second change we have to make is to make sure that the .text section is flagged as a writable area once mapped into memory. This is necessary because our decrypter stub needs to dynamically rewrite (decode) the actual processor codes to be executed. This too is easily done with LordPE from the "edit section header" dialog. Below is a graphic of the dialog sequence and field manipulations required in LordPE. Highlighted in yellow are the fields that we have altered.


Our next goal now becomes to make sure that when the executable first loads it is our decrypter stub that is first run. Since the real processor commands for the executable will not present on disk, having the program start at the original entry point would have the machine trying to execute what is essentially a jumbled block of data.

The program entry point can be directly edited from LordPEs main interface. For our demonstration lets choose to set the entry point at 4E00h. This offset sits 32 bytes from the end of our real applications code and gives us a nice easy spot to find in the hexeditor.

With the PE structure modifications out of the way, now we can move on to the actual work. Here is what we have left:

D) build the decrypter stub
E) crypt the actual executable's opcodes
F) integrate our decrypter stub into the modified binary

Lets start with some design visions for our encoding mechanism. Since this is a demo and a trainer, the encoding mechanism is going to be kept as lightweight and simple as possible. For these reasons a simple XOR encoding will be used.

The next design consideration is to enumerate what kind of variables a generic crypter stub is going to need. Basically any crypter stub is going to need three things:

1) what offset (in memory) to start decrypt data
2) length of the data to decrypt
3) entry point to transfer execution to after decrypted

Since we are designing a really simple stub, I am going to take a short cut and start the encryption routine right at the programs original entry point. While the EP is not at the very beginning of the code section, it is usually close enough that the majority of processor commands will be encrypted.

Before we get into the actual design and development of out decrypter stub, lets knock off the easy part of XORing the original opcodes first. This is a simple operation, and can be done in whatever way is the most convenient for the developer. The implementation I chose was to create a quick VB program that loops through the binary applying the XOR to the appropriate bytes representing the applications opcodes.

For a quick refresher:

Q) How do i know where the opcodes begin?
A) for our simple setup we are starting at the original program
entry point found in the PE Header

Q) How do I know how long of a block to encode?
A) Since we want to encode all of the opcodes after the entry point,
length of the data to encrypt is Original Virtual Size - Entry Point

Inline below is the VB source code used to encode the executable's opcodes:

StartAt = &H1048 'original entry point
length = &H2D86 '3DCE - 1048 (virtual size - entrypoint)

Open p2 For Binary As f

For i = 1 To length
offset = StartAt + i
Get f, offset, b
b = b Xor &HF
Put f, offset, b
Next

Close f


With that out of the way, we are now down to developing our decrypter stub. Basically what we need is a small block of ASM commands that we can paste into the encoded binary at our new entry point.

Below is the decoder block I came up with written in C:

void main(void){

int i;
char b;

char *buffer = 0x400000 ; // imagebase
long length = 0xBEEF ; // <-length of code (placeholder)

buffer += 0xDEAD ; // <- OEP offset (placeholder)

for(i=0; i < length; i++){

b = buffer[i] ;
b = b ^ 0xF ;
buffer[i] = b ;

}

_asm jmp buffer

}

Let me mention a couple points and design considerations about the above code.

* To make the stub generic you are going to have to edit the length and entry point offsets each time you use it. Make these some recognizable values in hex to make it easier to find them in the hexeditor.

* *buffer initially points to the imagebase, remember you are going to be working on memory addresses. The reason I increment *buffer latter to the entry point offset is because I will have to edit this value independently in a hexeditor.

* to transfer execution to the original entry point we just use a inline asm command jmp buffer. At this point *buffer is already pointing directly to the programs original entry point.

All in all it is a very simple decoder stub. The trick comes in debugging and implementing it. Since the decoder is designed to work on data and offsets not found in this standalone application, we can really only use the compiler to generate the opcodes for the commands we need. Debugging takes place by integrating the actual stub byte codes into our crypted exe and running that through the debugger.

Now that we have our proposed C source, we need the assembler byte codes associated with it. The easiest way I have found to get the asm byte codes from the compiler is to set a break point at the top of the code and start up the VC debugger by pressing F5.

Once VC has compiled the code, it will then launch the built in debugger which pauses execution at your preset breakpoint. Now you can right click on the main window and choose "goto disassembly" to see a mixed assortment of C and ASM commands.

Below is a stripped down ASM block generated by the compiler for us. On the left are the actual byte codes associated with the string assembler commands on the right.

C7 45 F4 00 00 40 00 mov dword ptr [ebp-0Ch],400000h
C7 45 F0 EF BE 00 00 mov dword ptr [ebp-10h],0BEEFh
8B 45 F4 mov eax,dword ptr [ebp-0Ch]
05 AD DE 00 00 add eax,0DEADh
89 45 F4 mov dword ptr [ebp-0Ch],eax
C7 45 FC 00 00 00 00 mov dword ptr [ebp-4],0
EB 09 jmp main+43h
8B 4D FC mov ecx,dword ptr [ebp-4]
83 C1 01 add ecx,1
89 4D FC mov dword ptr [ebp-4],ecx
8B 55 FC mov edx,dword ptr [ebp-4]
3B 55 F0 cmp edx,dword ptr [ebp-10h]
7D 22 jge main+6Dh
8B 45 F4 mov eax,dword ptr [ebp-0Ch]
03 45 FC add eax,dword ptr [ebp-4]
8A 08 mov cl,byte ptr [eax]
88 4D F8 mov byte ptr [ebp-8],cl
0F BE 55 F8 movsx edx,byte ptr [ebp-8]
83 F2 0F xor edx,0Fh
88 55 F8 mov byte ptr [ebp-8],dl
8B 45 F4 mov eax,dword ptr [ebp-0Ch]
03 45 FC add eax,dword ptr [ebp-4]
8A 4D F8 mov cl,byte ptr [ebp-8]
88 08 mov byte ptr [eax],cl
EB CD jmp main+3Ah
FF 65 F4 jmp dword ptr [ebp-0Ch]

In order for us to insert this into our executable, we must further strip out just the byte codes and write the hex values into our executable file. A nice way to do this is to strip out the assembler commands, remove all of the spaces, and place then in a long string such as this:

C745F400004000C745F0EFBE00008B45F405ADDE00008945F4 C745FC
00000000EB098B4DFC83C101894DFC8B55FC3B55F07D228B45 F40345
FC8A08884DF80FBE55F883F20F8855F88B45F40345FC8A4DF8 8808EB
CDFF65F4

From here, you can copy the text string and write the associated hex values directly into the binary using the Winhex hexeditor by highlighting the start offset (4E00h) pressing Ctrl-B (write clipboard) and then choosing the "ACII Hex" clipboard format.

Once that is done, all we have left is to edit the data length and start offset placeholders compiled into the stub and it will be configured for this binary. If you wrote the stub in starting at offset 4E00h then you will find the BEEFh data length marker at offset 4E0Ah , and the DEADh entry point marker at offset 4E12h.

Note that both of these values are in little endian format. When you go to modify them with the actual values, remember to also write the new values in little endian format.

Below are hexeditor views of the modifications made.

Offset 0 1 2 3
00004E10 .. .. AD DE (DEAD)
00004E10 .. .. 48 10 (1048)

Offset 0 1 2 3 4 5 6 7 8 9 A B
00004E00 .. .. .. .. .. .. .. .. .. .. EF BE (BEEF)
00004E00 .. .. .. .. .. .. .. .. .. .. 86 2D (2D86)

With our decrypter block in place, our main code crypted, and the entry point now aimed at the decrypter, everything should be set and ready to run !

Open it up in Olly, give it a shot and see what happens. Before you start stepping through code, look around the original entry point and see what the disassembly looks like.

004010DC 12 DB 12
004010DD 05 DB 05
004010DE 0F DB 0F
004010DF 0F DB 0F
004010E0 AE DB AE
004010E1 53 DB 53
004010E2 63 DB 63
004010E3 4F DB 4F
004010E4 0F DB 0F
004010E5 AC DB AC
004010E6 6F DB 6F
004010E7 63 DB 63
004010E8 4F DB 4F

Yup, thats a jarbled mess characteristic of a data block or encrypted opcodes... Now go back to the end of the decrypter block and set a breakpoint on the final "jmp buffer" command:

00404E55 >^FF65 F4 JMP DWORD PTR SS:[EBP-C] ; final.00401048

After reaching this point, scroll back up again and take another look at the original entry point 401048. If you still see a junk block of commands such as the above mess, it is because Olly has not yet analyzed the new byte values for processor commands. To fix this, right click in the main disassembly window and choose 'analyze code'. Now you should see the actual decoded instructions:

00401048 /. 55 PUSH EBP
00401049 |. 8BEC MOV EBP,ESP
0040104B |. 6A FF PUSH -1
0040104D |. 68 B8504000 PUSH final.004050B8
00401052 |. 68 9C244000 PUSH final.0040249C ; SE handler installation
00401057 |. 64:A1 00000000 MOV EAX,DWORD PTR FS:[0]
0040105D |. 50 PUSH EAX
0040105E |. 64:8925 000000>MOV DWORD PTR FS:[0],ESP
00401065 |. 83EC 10 SUB ESP,10

Now you can hit the run button and Voila ! It should all function just as expected !

Looks like everything is in place and running just as it should be

Note that using C to generate the Opcodes can make the decoder a bit bloated. If you wanted to write your decoder directly in asm you could use a stub similar to the following: (even this could be optimized further)

00404E3A B8 48104000 MOV EAX,401048 ;start offset
00404E3F B9 862D0000 MOV ECX,2D86 ;length
00404E44 8BD0 MOV EDX,EAX ;copy of start offset (OEP)
00404E46 8030 0F XOR BYTE PTR DS:[EAX],0F ;top_of_loop decode inst
00404E49 40 INC EAX ;next byte
00404E4A 49 DEC ECX ;dec counter
00404E4B ^75 F9 JNZ SHORT 00404E46 ;counter !=0 goto top_of_loop
00404E4D FFE2 JMP EDX ;jmp OEP

As one last little nugget, let me throw out a quick tip you can use to restore a crypted exe such as this to its former state

Lets assume the decrypter stub did some actual encryption that we do not want to try to reverse engineer. If the crypter stub only operated on an uncompressed data block that was fully present in the exe and did not perform any other tricks or manipulations the restoration of the executable can actually be very simple.

Give this a shot..load the exe in olly and break on the last jmp buffer. Here the actual executable code is fully decrypted in memory and ready to be run. Now fire up LordPE and dump the 401000 - 405000 memory address range to grab the full .text section from memory. You now have all of the decrypted opcodes saved to disk

Write down the address of the original entry point that the jmp command was going to take you to and exit olly. Open up the memory dump and the crypted exe in Winhex and write the entire dump of the .text section over the crypted .text section in the executable.

Save it, then change the entry point back to the original you wrote down and give it a click. Tadaahhh magic.....kinda..well not really...but you know. *shrugs*

Anyway, this was a fun bit to design and figure out how to do. Hopefully this takes some of the "magic" out of how executable crypters work and should be enough to help someone else along.

I also caved in and wrote an quick point and click utility to integrate this crypter stub into arbitrary executables. You can snag the app plus VB source here. (also has a nice set of classes for PE header manipulation)

[nothilvien]

Die bilder sind direct linked von einem anderen server (traffic klau) und der text ist nicht von dir, daher solltest du anstandshalber credits geben.

Ansonsten sehr informativ (:
zumal auf der orginal seite aber noch beispiele zum downlaoden sind, die hier iwie fehlen. Die waeren wohl auch noch hilfreich.

[GODFATHER]

Laber nicht so ein Bullshit ich habe es von einer Seite geleecht und es waren Keine Credits dabei. Wären welche dabei gewesen hätte ich sie mitraufgeklatscht....

[Gondolin]

wow geiles tut thx

hat mir echt weitergeholfen... thx

[uploader freak]

nice tut aber wenns übersetzen würdest wäre echt super

[DerNovice]

Übersetzung~

Dieser Artikel führt Sie durch die grundlegenden Schritte für den Bau einer ausführbaren crypter. Alle Schritte, die in diesem Artikel erfordern manuelle Konfiguration und Integration, um die exe für die crypter Stub. Der Schwerpunkt dieses Artikels ist es, Sie durch die Theorie und das Know-how, wie crypters und nicht versuchen, die neuesten größte Punkt und klicken Sie auf "Lösung.

Für eine grundlegende Hintergrund ist hier, wie ausführbare crypters Arbeit:

1) Die tatsächliche Prozessor-Befehle von einem geschützten binäre sind
crypted / verdeckt / munged unabhängig

2) Wenn die geschützte Anwendung zum ersten Mal, eine kleine Decrypter
Stub ist zunächst, dass wieder alle der ursprünglichen Prozessor
Befehle für das Programm im Speicher.

3) Schließlich ist der Decrypter Rumpfgeschäftsjahr endet und Transfers Ausführung der
Original-Zugang (OEP) und das Programm läuft normal.

Im Zuge dieser Arbeit werden wir von Hand eine sehr einfache "crypter", um zu zeigen, alle Techniken, die Entwicklung, Design-Überlegungen und Debugging-Informationen benötigt, um Ihre eigene.

Zunächst möchte ich Ihnen unser Ziel ausführbar. Es ist eine Welt 28kb hallo Anwendung geschrieben in C. Diese einfache Anwendung nur druckt "hallo Welt" auf dem Bildschirm angezeigt wird, wartet ein Tastendruck und dann beendet.

Um uns gestartet wurde, können die PE-Struktur der ausführbaren Datei. Unten ist ein Bild der PE Abschnitt Tabelle. Sie werden feststellen, dass die. Text-Bereich (wo die tatsächlichen ausführbaren Code ist) hat eine Größe von Roh-4000H und eine virtuelle Größe von 3DCEh.



Die Diskrepanz in den Zahlen zeigt, dass am Ende der. Text Abschnitt gibt es eine bestimmte Menge des nicht verwendeten Raum derzeit nicht abgebildet in den Speicher, wenn die Datei geladen wird. Diese freien Platz in der ausführbaren Datei ist gut, weil es bedeutet, dass wir einen leeren Teller, wo wir können unsere eigenen ausführbaren Code.

Um visuell überprüfen können Sie die Datei in einem hexeditor und nach einem Null-Pad. Um zu wissen, wo Sie suchen müssen in der Lage, die richtige Datei-Offset. In unserer Stichprobe exe ist vereinfacht, weil alle unsere Teile haben eine virtuelle Größe <= raw ihre Größe und jeder Abschnitte raw offset = ihre virtuelle Ausgleich.

Das ist nett, weil es immer alle der Rva Werte in der PEheader = RAW-Datei-Offsets jedoch ist dies nicht immer der Fall ist. V.2 der PE-Editor Klassen nun dies berücksichtigen und berechnen können Datei-Offsets von Rva Werte korrekt. Die Annahme der Rva = Offset-Datei wird durch den Rest dieses Artikels, da es gilt für diese Probe wir analysieren.

So ..., um zu sehen, dieses Null-Pad öffnen, die Original-EXE-Datei in einem hexeditor und Check-Out Bereich zwischen 4DCEh und 5000h (RawOffset + VirtualSize)

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00004DC0 C0 74 06 0F B6 45 0B C9 C3 83 C8 FF C9 C3 00 00 bei E. .. ÉÃÈÿÉà ..
00004DD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004DE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004DF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00004E80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Für unsere Bedürfnisse wird dies mehr als genug Platz, um unsere einfachen Decrypter Stub. Wir müssen nicht unbedingt unsere Squeeze-Code in eine bestehende Abschnitt. Hätten wir kurz auf Raum, könnten wir Zuflucht, um einen neuen Abschnitt PE und Inverkehrbringen Code gibt.

Ok, haben wir ein Haus für unsere Decrypter Block, aber zuerst müssen wir einige Anpassungen an die PE Abschnitt Eigenschaften, so dass:

A) Unsere Decrypter Code in den Speicher geladen
einmal in den Speicher zugeordnet, haben wir Zugang zu den Hauptteil der Code
C), wenn das Programm zum ersten Mal geladen wird, beginnt die Ausführung mit unseren Decrypter-Code

Wie bereits erwähnt, ist die virtuelle Größe des Abschnitts (der Größe in den Speicher geladen) nicht, diese Null-Pad fanden wir in der Datei. Da werden wir hinzufügen Code zu diesem Bereich, wir müssen dafür sorgen, dass in diesem Bereich ist in den Speicher geladen werden. Dies wird durch die Erhöhung der virtuelle Größe für diese PE Abschnitt mit einer PE-Editor wie zum Beispiel LordPE.

Die zweite Veränderung, die wir machen müssen ist, um sicherzustellen, dass die. Text ist markiert als schreibbar einmal in den Speicher zugeordnet. Dies ist notwendig, weil unsere Decrypter Stub muss dynamisch rewrite (decode) die tatsächliche Prozessor-Codes, die ausgeführt werden soll. Auch das ist leicht getan mit LordPE aus dem "Bearbeiten Abschnittsüberschrift"-Dialog. Im Folgenden finden Sie eine Grafik der Dialog-Sequenz und Manipulationen im Bereich LordPE. Gelb hervorgehoben sind die Bereiche, die wir verändert haben.



Unser nächstes Ziel ist jetzt, um sicherzustellen, dass, wenn die ausführbare erste lädt sie ist unsere Decrypter Stub, dass zum ersten Mal laufen. Da die tatsächlichen Prozessor-Befehle für das Programm wird nicht auf der Festplatte, die das Programm beginnt am ursprünglichen Ausgangspunkt wäre die Maschine zu führen, was ist im Wesentlichen ein Block von Daten purzeln.

Das Programm Zugang kann direkt bearbeitet LordPEs wichtigste Schnittstelle. Für unsere Demonstration können sich dafür entscheiden, den Zugang zu 4E00h. Dieser Offset-sitzt 32 Bytes aus dem Ende des realen Applikationen-Code und gibt uns einen schönen Ort und Stelle leicht zu finden in der hexeditor.

Mit der PE-Struktur Änderungen aus dem Weg, jetzt können wir auf die eigentliche Arbeit. Hier ist das, was wir haben:

D) Aufbau der Decrypter Stub
E) Krypta der tatsächlichen ausführbare's Opcodes
F) unsere Decrypter Stub in der modifizierten binären

Ermöglicht mit Design-Visionen für unsere Codierung Mechanismus. Da es sich hier um eine Demo und ein Trainer, die Kodierung Mechanismus gehalten werden soll, wie leicht und einfach wie möglich sein. Aus diesen Gründen ist eine einfache XOR-Codierung verwendet werden.

Der nächste Entwurf handelt es sich um aufzulisten, welche Art von Variablen eine generische crypter Stub wird müssen. Grundsätzlich alle crypter Stub wird, müssen drei Dinge:

1) Was Offset (im Speicher), um Daten entschlüsseln
2) Länge der Daten zu entschlüsseln
3) Zugang zu übertragen, um nach Ausführung entschlüsselt

Da wir uns der Gestaltung eines wirklich einfach Stub, ich möchte einen kurzen Schnitt und die Verschlüsselung Routine Recht auf die Programme ursprünglichen Zugang. Während die EP ist nicht ganz am Anfang der Code-Abschnitt, es ist in der Regel nahe genug, dass die Mehrheit der Prozessor-Befehle werden verschlüsselt.

Bevor wir in die eigentliche Design und die Entwicklung von aus Decrypter Stub, können abschlagen der einfache Teil der XORing der ursprünglichen Opcodes zuerst. Dies ist eine einfache Bedienung, und kann getan werden, in welcher Art und Weise ist die günstigste für den Entwickler. Ich habe mich für die Durchführung war die Schaffung einer schnellen VB-Programm, dass die Schleife durch die Anwendung der binären XOR auf die entsprechenden Bytes, die die Anwendungen Opcodes.

Für eine schnelle Auffrischung:

Q) Wie kann ich wissen, wo sich die Opcodes beginnen?
A) für die einfache Installation sind wir ab dem ursprünglichen Programm
Anlaufstelle in der PE Header

Q) Wie kann ich wissen, wie lange von einem Block zu kodieren?
A) Da wollen wir alle encodieren der Opcodes nach dem Punkt,
Länge der Daten zu verschlüsseln ist Original Virtuelle Größe - Entry Point

Inline-unten ist die VB-Source-Code benutzt, um die ausführbare Datei der Opcodes:

StartAt = & H1048 'Original-Zugang
Länge = 3 & H2D86 DCE - 1048 (virtuelle Größe - EntryPoint)

Open P2 für binäre als F

Für i = 1 To Länge
offset = StartAt + i
Holen Sie sich F-, Offset-, B
b = b Xor & HF
Put f-, Offset-, B
Nächster

Schließen f


Mit diesem aus dem Weg, wir sind jetzt auf die Entwicklung unserer Decrypter Stub. Im Grunde, was wir brauchen, ist ein kleiner Block von ASM-Befehle, wir können einfach in das codierte binäre auf unserer neuen Eintrag Nummer.

Im Folgenden finden Sie den Decoder-Block kam ich mit der in C geschrieben:

void main (void) (

int i;
char b;

char * buffer = 0x400000 / / imagebase
lang = Länge 0xBEEF; / / <-Länge von Code (Platzhalter)

Puffer + = 0xDEAD; / / <- OEP Offset (Platzhalter)

for (i = 0; i <length; i + +) (

b = buffer [i];
b = b ^ 0xF;
buffer [i] = b;

)

_asm jmp Puffer

)

Lassen Sie mich ein paar Punkte und Design-Überlegungen zu den oben genannten Code.

* Um die generischen Stub Sie sich zu haben, um die Länge und Zugang gleicht jedes Mal, wenn Sie sie verwenden. Diese einige erkennbare Werte in hex, um es einfacher, sie zu finden in der hexeditor.

* * Buffer zunächst auf die imagebase, denken Sie daran, Sie werden auf Speicher-Adressen. Der Grund, warum ich increment * buffer diesen den Zugang ausgeglichen ist, weil ich muss zum Bearbeiten dieser Wert unabhängig in einem hexeditor.

*, Um die Ausführung der ursprünglichen Eintrag Punkt, über den wir nur mit einer Inline-ASM Befehl jmp Puffer. An dieser Stelle * Puffer ist bereits darauf direkt zu den Programmen ursprünglichen Ausgangspunkt.

Alles in allem ist es eine sehr einfache Decoder Stub. Der Trick ist in das Debugging und die Umsetzung. Da der Decoder ist für die Verwendung von Daten und Offsets nicht in dieser Standalone-Anwendung, können wir wirklich nur die Compiler, um die Opcodes für die Befehle die wir brauchen. Debugging erfolgt durch die Integration der aktuellen Stub-Byte-Code in unsere exe verschlüsselt und laufen, dass durch den Debugger.

Nun, da haben wir vorgeschlagen, C-Source, brauchen wir die Assembler-Byte-Codes zugeordnet. Die einfachste Art und Weise habe ich gefunden, um die ASM-Byte-Codes aus der Compiler ist, um einen Haltepunkt an der Spitze der Code und starten Sie den VC Debugger durch Drücken der Taste F5.

Sobald VC hat den Code ein, es wird dann der Start in Debugger die Ausführung Pausen auf Ihr Preset Haltepunkt. Jetzt können Sie mit der rechten klicken Sie auf das Hauptfenster und wählen Sie "goto Demontage", um zu sehen, ein gemischtes Sortiment von C-und ASM-Befehle.

Unten ist eine abgespeckte ASM Block erzeugt der Compiler für uns. Auf der linken Seite sind die eigentlichen Byte-Codes im Zusammenhang mit der String-Assembler-Befehle auf der rechten Seite.

C7 45 F4 00 00 40 00 mov dword ptr [ebp-0Ch], 400000h
C7 45 F0 EF BE 00 00 mov dword ptr [ebp-10h], 0BEEFh
8B 45 F4 mov eax, dword ptr [ebp-0Ch]
DE 05 AD 00 00 add eax, 0DEADh
89 45 F4 mov dword ptr [ebp-0Ch], eax
C7 45 FC 00 00 00 00 mov dword ptr [ebp-4], 0
EB 09 JMP wichtigsten 43 h
8B 4D FC mov ecx, dword ptr [ebp-4]
83 C1 01 add ecx, 1
89 4D FC mov dword ptr [ebp-4], ecx
8B 55 FC mov edx, dword ptr [ebp-4]
3B 55 F0 cmp edx, dword ptr [ebp-10h]
7D 22 jge wichtigsten 6 Dh
8B 45 F4 mov eax, dword ptr [ebp-0Ch]
03 45 FC hinzufügen eax, dword ptr [ebp-4]
8A 08 mov cl, byte ptr [eax]
88 4D F8 mov byte ptr [ebp-8], cl
0F 55 F8 movsx edx, byte ptr [ebp-8]
83 F2 0F xor edx, 0Fh
88 55 F8 mov byte ptr [ebp-8], dl
8B 45 F4 mov eax, dword ptr [ebp-0Ch]
03 45 FC hinzufügen eax, dword ptr [ebp-4]
8A 4D F8 mov cl, byte ptr [ebp-8]
88 08 mov byte ptr [eax], cl
EB CD jmp wichtigsten 3 Ah
FF 65 F4 jmp dword ptr [ebp-0Ch]

Um für uns, um diese in unsere ausführbare, müssen wir weitere Streifen aus nur der Byte-Code und geben Sie die Hex-Werte in die ausführbare Datei. Ein möglicher Weg, dies zu tun ist, um die Streifen der Assembler-Befehle, entfernen Sie alle der Räume, und dann in einer langen Zeichenkette wie diese:

C745F400004000C745F0EFBE00008B45F405ADDE00008945F4 C745FC
00000000EB098B4DFC83C101894DFC8B55FC3B55F07D228B45 F40345
FC8A08884DF80FBE55F883F20F8855F88B45F40345FC8A4DF8 8808EB
CDFF65F4

Von hier aus können Sie die Text-String und geben Sie die zugehörigen Hex-Werte direkt in die mit dem binären Winhex hexeditor, indem Sie den Start-Offset (4E00h) Drücken von Strg-B (schreiben Zwischenablage) und dann die Wahl der "ACII Hex" Zwischenablage-Format.

Sobald dies getan ist, alles, was wir haben ist die Bearbeitung der Daten Länge und Offset-Platzhalter in die Stub kompiliert und konfiguriert werden für diese Binärzahl. Wenn Sie schrieb in der Stub ab Offset 4E00h dann finden Sie die Daten BEEFh Länge Marker bei Offset 4E0Ah, und der Punkt-Marker DEADh Eintrag bei Offset 4E12h.

Beachten Sie, dass diese beiden Werte werden in Little-Endian-Format. Wenn Sie zu ändern mit den tatsächlichen Werten, Denken Sie auch daran, schreiben die neuen Werte im Little-Endian-Format.

Im Folgenden finden Sie hexeditor Blick auf die Änderungen.

Offset 0 1 2 3
00004E10 .. .. AD DE (DEAD)
00004E10 .. .. 48 10 (1048)

Offset 0 1 2 3 4 5 6 7 8 9 A B
00004E00 .. .. .. .. .. .. .. .. .. .. EF BE (Rindfleisch)
00004E00 .. .. .. .. .. .. .. .. .. .. 86 2D (2D86)

Mit unseren Decrypter Block vorhanden, unsere wichtigsten Code verschlüsselt, und der Zugang nun auf die Decrypter, alles sollte und ready to run!

Öffnen Sie sie in Olly, geben Sie ihm ein Bild und sehen Sie, was passiert. Bevor Sie beginnen Schritt durch den Code, sich um den ursprünglichen Eintrag, und sehen, was die Demontage aussieht.

004010DC 12 dB 12
004010DD 05 HE 05
004010DE 0F DB 0F
004010DF 0F DB 0F
004010E0 AE AE DB
004010E1 53 dB 53
004010E2 63 dB 63
004010E3 4F DB 4F
004010E4 0F DB 0F
004010E5 AC DB AC
004010E6 6F DB 6F
004010E7 63 dB 63
004010E8 4F DB 4F

Yup, thats a jarbled Chaos Merkmal einer verschlüsselten Daten sperren oder Opcodes ... Nun gehen Sie zurück bis zum Ende des Decrypter Block und einen Haltepunkt an der letzten "jmp Puffer"-Befehl:

00404E55> ^ FF65 F4 JMP DWORD PTR SS: [EBP-C]; final.00401048

Nach Erreichen dieses Punktes, blättern Sie wieder zurück und nehmen noch einmal auf den ursprünglichen Eintrag Nummer 401.048. Wenn Sie noch eine Junk-Block von Befehlen, wie die oben genannten Chaos, weil Olly noch nicht analysiert die neue Byte-Werte für Prozessor-Befehle. Um dieses Problem zu beheben, klicken Sie rechts in die Demontage-Fenster und wählen Sie "Analyse-Code". Jetzt sollten Sie die tatsächliche decodierte Anweisungen:

00401048 /. 55 PUSH EBP
00401049 |. 8BEC MOV EBP, ESP
0040104B |. 6A FF PUSH -1
0040104D |. 68 B8504000 PUSH final.004050B8
00401052 |. 68 9C244000 PUSH final.0040249C; SE Handler Installation
00401057 |. 64: A1 00000000 MOV EAX, DWORD PTR FS: [0]
0040105D |. 50 PUSH EAX
0040105E |. 64:8925 000000> MOV DWORD PTR FS: [0], ESP
00401065 |. 83EC 10 SUB ESP, 10

Jetzt können Sie drücken die Taste "Ausführen" und voila! Es sollte alle Funktionen, wie erwartet!

Sieht aus wie alles ist vorhanden und läuft nur, wie sie sein sollte

Beachten Sie, dass mit C, um die Opcodes können die Decoder ein wenig aufgeblasen. Wenn Sie wollte schreiben Sie direkt in asm-Decoder können Sie einen Coupon, die der folgenden ähnelt: (auch diese könnten noch optimiert werden)

00404E3A B8 48104000 MOV EAX, 401048; Start-Offset
00404E3F B9 862D0000 MOV ECX, 2D86; Länge
00404E44 8BD0 MOV EDX, EAX; Kopie von Start-Offset (OEP)
00404E46 8030 0F XOR BYTE PTR DS: [EAX], 0F; top_of_loop dekodieren inst
00404E49 40 INC EAX; nächsten Byte
00404E4A 49 DEC ECX; Dezember counter
00404E4B ^ 75 F9 JNZ KURZE 00404E46; Zähler! = 0 goto top_of_loop
00404E4D FFE2 JMP EDX; jmp OEP

Als eine letzte kleine nugget, lassen Sie mich werfen Sie einen schnellen Tipp, den Sie verwenden können, um wieder einem verschlüsselten EXE-wie dieser zu seinen früheren Zustand

Nehmen wir an der Decrypter Stub hat einige tatsächliche Verschlüsselung, dass wir nicht wollen, um zu versuchen, Reverse Engineering. Wenn die crypter Stub nur betrieben auf einem unkomprimierten Daten blockieren, die voll in die exe-Datei und hat keine andere Tricks oder Manipulationen die Wiederherstellung der ausführbaren tatsächlich sehr einfach.

Geben Sie dieser einen Schuss .. laden Sie die exe in olly und Pause am letzten jmp Puffer. Hier wird die tatsächliche ausführbare Code ist entschlüsselt im Speicher und fertig zu werden. Nun starte LordPE und die Dump-401000-405000-Speicher-Adressbereich zu greifen, die voll. Textabschnitt aus dem Speicher. Sie haben nun alle die entschlüsselten Opcodes auf der Festplatte gespeichert

Notieren Sie sich die Adresse des Original-Eintrag, dass der Befehl jmp ging, die Sie zu und Ausfahrt olly. Öffnen Sie das Speicherabbild und die verschlüsselten EXE in Winhex und schreiben Sie den gesamten Dump der. Textabschnitt über die verschlüsselt. Textabschnitt in die ausführbare Datei.

Speichern Sie es, dann ändern Sie den Eintrag Nummer wieder auf den ursprünglichen Sie schrieb und ihm einen Klick. Tadaahhh Magie ..... kinda .. auch nicht wirklich ... aber Sie wissen. * zuckt *

Wie auch immer, dies war ein bisschen Spaß zu gestalten und herauszufinden, wie zu tun ist. Bleibt zu hoffen, dass dies einige der "Magie" aus, wie ausführbare crypters Arbeit und sollte ausreichen, um eine andere Person an.

Ich habe auch eingebrochen und hat einen schnellen Punkt und klicken Sie auf Dienstprogramm zur Integration dieser crypter Stub in beliebige ausführbare Dateien. Sie können die Haken ca. plus VB Quelle hier. (hat auch eine schöne Reihe von Klassen für PE Header-Manipulation)

[Paulolafritte]

echt nice. danke. lob für die mühe es zu übersetzen !!!!


ps: merke gerade das es alles google translate ist -.-. ^^

[Gondolin]

thx...^^

ich denke mal das hat ein translator übersetzt.
wollt nur mal fragen welcher?

aber thx^^

[blackberry]

nice tut aber wenns übersetzen würdest wäre echt super

Wenn du es nicht verstehst such dir ein Wörterbuch - der Inhalt des Tuts ist echt gut.
Außerdem ist die Sprache des Internets doch (grob gesagt) Englisch - gute Englischkenntnisse sind also ein Muss!

PS: die Übersetzung von DerNovice ein Verbrechen an der deutschen Sprache, die Englische Version ergibt viel mehr Sinn!


mfG. BlackBerry

[DerNovice]

Beschwer dich dann bei google

Ihr woltet den Text auf Deutsch?
Da habt ihr ihn?

Wer kein Englisch versteht ist klar im Nachteil!