At 21:34 2/01/97 -0500, you wrote:
How has the Windows PWL's been de-crytped ?
Also I don't like to seem too much like a rookie, but was is a polymorphic virus ? . Marc Theriault * . * + * . * Email: WILL@BBSI.NET * . * . .+ ___ . . * + ___....-----'---'-----....___ . . ========================================= + * * . ___'---..._______...---'___ * . .
Read this for an understanding of a polymorhphic virus: ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º A GENERAL DESCRIPTION OF THE METHODS BEHIND A POLYMORPH ENGINE º ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍŒ A small glossary of terms: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ENCRYPT = Transform from it's original form to an altered form. DECRYPT = Transform from it's altered form to it's original form. KEY = The register or value used to encrypt/decrypt with. SLIDING KEY = A KEY value that is INCREASED or DECREASED on each loop. COUNT = The number of bytes in the encrypted code or data. INDEX = A pointer to the encrypted code or data. SIGNATURE = A unique group of bytes that can be used to check against a programs content in the hope of detecting a particular program. HEURISTIC = A set of well defined rules to apply to a problem in the hope of achieving a known result. Question: What is a Polymorph? ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Answer: Well, the Longman English Dictionary defines it as: "POLYMORPHOUS also POLYMORPHIC adj fml or tech. EXISTING IN VARIOUS DIFFERENT FORMS." In other words, something that has the ability to change it's shape. Other ways to describe such a thing might be; Mutable, Metamorphic, Etc... Question: What is a Polymorph Engine? ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Answer: A program with the abilities to encrypt (or jumble up) another program or data and provide a unique decryptor for it, it must do this in such a way that no two encryptions of the same program or data will look alike. Example: Take the following ultra-simple decryptor: MOV SI,jumbled_data ;Point to the jumbled data MOV CX,10 ;Ten bytes to decrypt main_loop: XOR BYTE PTR [SI],55 ;XOR (un_scramble!) a byte INC SI ;Next byte LOOP main_loop ;Loop for the 9 remaining bytes This small program will XOR the ten bytes at the location pointed to by SI with the value 55. Providing the ten bytes were XORed with 55 prior to running this decryptor the ten bytes will be restored to their original state. If you are unsure as to why this is, brush up on your XOR logic!! Ok, so you might say that if you change the KEY value on each generation it will become Polymorphic? Well, yes and no! If you did that, the encrypted portion would be Polymorphic, but the decryptor would still remain mostly the same, the only change begin the KEY value! So, a signature scanner that allows WILDCARDS (and most do!) would still be able to find your decryptor! One way you could fool some signature scanners is to swap around some of the instructions. So, with this in mind, the above decryptor might look like: MOV CX,10 MOV SI,jumbled_data main_loop: XOR BYTE PTR [SI],55 INC SI LOOP main_loop As you can see, still not much of a change, not really enough to fool some of the better signature scanners. "GET TO THE POINT! WHAT IS A TRUE POLYMORPH?", I hear you cry! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Well, a "true" Polymorph would be a decryptor that looks completely different on each generation! Take the following decryptor: MOV CX,10 NOP NOP MOV SI,jumbled_data NOP main_loop: NOP NOP XOR BYTE PTR [SI],55 NOP INC SI NOP NOP NOP NOP LOOP main_loop This decryptor is the same as the one before it, but it has has a few random NOP instructions peppered throughout itself. On each generation you would vary the amount of NOPs after each instruction. This is a Polymorph in it's simplest form. Still, most of the good signature scanners would have no problem with such a simple Polymorph. They would simply skip the NOPs, thus having a clear view of the decryptor, to which they could apply a signature! No, a "true" Polymorph has to be far far more complex then this! Instead of peppering NOPs throughout the decryptor it would pepper totally random amounts of totally random 8086 instructions, including JUMPS and CALLS. It would also use a different main decryptor (possibly from a selection of pre-coded ones) and would alter all the registers that the decryptor uses on each generation, making sure that the JUNK code that it generates doesn't destroy any of the registers used by the real decryptor! So, with these rules in mind, here is our simple decryptor again: MOV DX,10 ;Real part of the decryptor! MOV SI,1234 ;junk AND AX,[SI+1234] ;junk CLD ;junk MOV DI,jumbled_data ;Real part of the decryptor! TEST [SI+1234],BL ;junk OR AL,CL ;junk main_loop: ADD SI,SI ;junk instruction, real loop! XOR AX,1234 ;junk XOR BYTE PTR [DI],55 ;Real part of the decryptor! SUB SI,123 ;junk INC DI ;Real part of the decryptor! TEST DX,1234 ;junk AND AL,[BP+1234] ;junk DEC DX ;Real part of the decryptor! NOP ;junk XOR AX,DX ;junk SBB AX,[SI+1234] ;junk AND DX,DX ;Real part of the decryptor! JNZ main_loop ;Real part of the decryptor! As you should be able to see, quite a mess!! But, still executable code. It is essential that any junk code generated by the Polymorph Engine is executable, as it is going to be peppered throughout the decryptor. Note, in this example, that some of the junk instructions use registers that we are using in the decryptor! This is fine, providing the values in these registers aren't destroyed. Also note, that now we have random registers and random instructions on each generation it makes signature scanning (even for the clever signature scanners) impossible! Instead, an HEURISTIC method must be used, which can lead to false alarms. So, a Polymorph Engine can be summed up into three major parts: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ 1 .. The random number generator. 2 .. The junk code generator. 3 .. The decryptor generator. There are other discrete parts but these three are the ones where most of the work goes on! How does it all work? Well, SMEG goes about generating random decryptors in the following way: 1 .. Chooses a random selection of registers to use for the decryptor. Leaving the remaining registers as "junk" registers for the junk code generator. 2 .. Chooses one of the compressed pre-coded decryptors. 3 .. Goes into a loop generating the real decryptor, peppered with junk code. To understand how the selected registers are slotted into the decryptors and the junk code you must look at the 8086 instructions from a binary level: XOR AX,AX = 00110001 11000000 XOR AX,CX = 00110001 11001000 XOR AX,DX = 00110001 11010000 XOR AX,BX = 00110001 11011000 You should be able to see a pattern in the binary code for these four 8086 instructions? Well, all 8086 instructions follow logical patterns, and it is these patterns that tell the 8086 processor which registers/addressing mode to use for a particular instruction. The total amount of instruction formats and the precise logic regarding the patterns is too complex to go into here. However, all good 8086 tutorials/reference guides will explain in full. SMEG exploits this pattern logic to generate junk code and decryptors with random registers, as the patterns directly relate to the registers Etc. SMEG generates junk code in the following way: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Inside SMEG there is a table of the basic binary patterns for all of the 8086 instruction set, but with one important difference, all the register/address mode bits are zero. This is called the SKELETON INSTRUCTION TABLE. The table also contains various other bytes used by SMEG to determine the relevant bit positions to "plug in" the register bit patterns. These patterns are plugged in via the logic processes OR and AND. Using this method, SMEG can generate endless amounts of random 8086 instructions without destroying any of the registers used by the decryptor proper. SMEG also contains some discrete logic for producing false CALLS to dummy subroutines and also false conditional JMPS around the junk code. SMEG generates the decryptor proper in the following way: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Inside SMEG there is a table containing a selection of common 8086 instructions used in decryptors, such as XOR [index],reg Etc. These are, again, stored in SKELETON FORM with some control bytes used by the decryptor generator. Also, inside SMEG, there are several pre-coded decryptors stored in a compressed form. On average, a complete decryptor can be described to the decryptor generator in as few as 11 bytes and adding to the list of pre-coded decryptors is both painless and economical with space! SMEG generates the Polymorphed decryptor in the following way: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ First it chooses, at random, one of the pre-coded compressed decryptors. Next it goes into a loop uncompressing each decryptor instruction, plugging in the required registers, storing it and then generating (for each real instruction) a random amount of random instructions. This loop repeats until the complete decryptor has been constructed. The final result is a random size, random register, random patterned decryptor! It should also be noted that whenever SMEG generates an INDEXed instruction it uses either SI, DI or BX at random, also it sometimes uses a random offset. For example, say the encrypted code started at address 10h, the following could be used to index this address: MOV SI,10h ;Start address MOV AL,[SI] ;Index from initial address But sometimes SMEG will generate something like the following, again based on the encrypted code starting at address 10h: MOV DI,0BFAAh ;Indirect start address MOV AL,[DI+4066h) ;4066h + 0BFAAh = 10010h (and FFFF = 10h)!! These indexed and initial values are picked at complete random, and the examples of 0BFAAh and 4066h are valid, but next time they will be completely different! The following are two decryptors that were generated with my SMEG Polymorph Engine. It should be noted that I generated 4000 examples with no two alike! Unfortunately I ran out of hard drive space! But it is fairly safe to say that the total number of decryptor combinations would run into the BILLIONS! All the lines marked with ";junk" in the following listings indicate random junk instructions that were inserted throughout the actual decryptor, note that SMEG has the ability to generate junk CALLS to false SUBROUTINES, as well as general junk conditional jumps! All lines marked with a * indicate an actual part of the decryptor proper. I chose the two generations shown because their sizes were similar, 386 and 480 bytes. SMEG produces decryptors ranging in size from as little as 288 to as much as 1536 bytes. Even if two decryptors are generated that are the same size the chances of them being the same are, literally, billions to one! Neil Tunnicliffe.