Encryption: theory ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> VirusBuster As an introduction to Blade Runner's decryption practices, and for those of you whose knowledge isn't just that advanced, we'll describe brielfy the grounds of encryption. 1. Very basic introduction ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ First viruses ever had their code very visible. They didn't use encryp- tion techniques, neither did they use polymorphic routines in order to variate their code. All the code was nude, without any kind of "trick" which could stop others from disassembling them. Nevertheless, someday, someone (one of the first encrypted viruses was Alexander.1951, from Romania) had the briliiant idea of "hiding" his code from people's curious eyes, and invented something called "encryption". With this technique, we were able to change whatever portion of code we wanted, so when someone else tried to disassemble that code, would get a bunch of garbage instead of "readable" code. 2. Theory ÄÄÄÄÄÄÄÄÄ There are several different encryption levels. Some of them use a simple operation such as OR, XOR, ..., and there are other ones that combine ma- ny ORs, XORs, NOTs,... etc. An encrypted virus has the following execution structure: + It may have a jmp to the virus code (eg Maltese Amoeba) or it may have the viral code at the begining of the file (Jerusalem). + Decryption routine. + Virus code. + Jump to the infected file's code. The decryption routine consists of a series of instructions that turn en- crypted code into real instructions. In order to do this, several logical operations (ie OR, XOR,...) are performed on the encrypted bytes. It is not our duty here to explain how en/decryption routines work, the- refore i'll explain the different methods of decrypting a virus and how to identify a yet encrypted one. 3. Decryption methods ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Overall i must advise experience gives it all. The more viruses you de- crypt, the better your bets will be towards fucking this new virus we've just discovered. Some viruses decrypt themselves from top to bottom. I mean, they start decrypting at cs:0130 and continue downwards (cs:0132, cs:0135...). I say from top to bottom but it really goes from the lowest position to the hi- gher ones :) Some other viruses decrypt themselves from the bottom to the top. I mean from the highest position to the lower ones (cs:4567, cs:4563... cs:0116) Classic decryption formulas are: cs:0100 decrypted code . . . cs:0115 xor dl,5e . . . cs:0124 cmp ax,0 cs:0127 je 13d cs:012a jmp cs:0115 cs:012d encrypted code Btw, I don't pretend the adresses to be the real ones :) Well, we can see in cs:0115 a logical operation being performed, and then in cs:0124 a comparison being done, and depending on the result, it will go in each direction. In the above example AX is compared to 0 (being true when all bytes have been decrypted). This is a typical structure in encrypted viruses. When we reach a value, we jump to the next instruction after the jmp that would execute the decryption routine once again. What must we do to decrpyt this possible virus? nothing more than trace the code till you reach cs:012d, as this is the point where code is al- ready decrypted. I leave to you the way to save decrypted code to disk so as to look it with a bit more of calm. Debug users may write with "w cs:0100 0 40 4" (which would save code from cs:0100 to cs:0900 in drive A, at sector 40h (64d), and would save 4 512- byte sectors which would make up to cs:0900), or either overwriting di- rectly the encrypted file, stating its length at CX and performing a disk write (w). If you use Turbo Debugger, strike Tab till you are at the "dump" window. Once there, press alt+f10, select "Block" and then "Write", where you'll change the file name, the adress and the number of bytes to write. For AVPUtil users, press alt+w and specify the file name and the number of bytes to write in that file. Returning to the structures, we can find the "loop" one: cs:0100 decrypted code . . cs:0114 or al,al . . cs:0140 loop 114 cs:0142 encrypted code In this case it would be enough to let the loop decrypt the virus. There are a few variants but the base is the same: cs:0100 decrypted code . . cs:0116 stuff . . cs:0150 jmp to stuff cs:0156 decrypted code What we must do is reach the instruction after jmp to stuff, coz while it continues to jump upwardly it's decrypting. In viruses which get decrpyted from top to bottom, this is easily done. You let it perform a couple jumps and then breakpoint the instruction af- ter the jmp. Then you only have to let it run. As soon as the code is de- crypted, we'll get the control back. There may be more problems if we're to use DOS's debug when working on a top-to-bottom decrpyting virus. Why? well, the next instruction to the jump will remain encrypted till the end, and it would be difficult to set a breakpoint after just two jumps. Then we may: 1) Use Borland's (TD) or AVP's debugger. 2) Being patient and do it manually. 3) Move the decryption routine and something more to another segment, get onto that segment, breakpoint the instruction after the jump and then run the virus. To do this last step: -mcs:0100 400 3000:01009 -rcs 3000 I think with all of this it's ok. Well, and still remain all those virii that hang off int 1 or int 3 and don't let us debug them. In this case, i usually run the virus and note down int 21h's vector, writing to disk the virus length. Another solution is to patch int 21h where the virus gets to hang from int 1 or int 3 with a couple of nops. 4. Examples ÄÄÄÄÄÄÄÄÄÄÄ Here you have Maltese Amoeba virus (one of its variants) when encrypted: 0c39:000a pushf 0c39:000b nop 0c39:000c nop 0c39:000d push ax 0c39:000e push bx 0c39:000f jmp 0011 0c39:0011 xchg cx,ax 0c39:0012 xchg cx,ax 0c39:0013 mov ah,ah 0c39:0015 push ds 0c39:0016 cmc 0c39:0017 push es 0c39:0018 clc 0c39:0019 push cs 0c39:001a pop es 0c39:001b cld 0c39:001c stc 0c39:001d push cs 0c39:001e pop ds 0c39:001f mov al,al 0c39:0021 mov cx,cx 0c39:0023 sahf 0c39:0024 cld 0c39:0025 mov di,004f 0c39:0028 mov dl,dl 0c39:002a mov cx,04a6 0c39:002d mov si,di 0c39:002f mov ax,ax 0c39:0031 mov bx,bx 0c39:0033 lodsw 0c39:0034 xor ax,a451 0c39:0037 clc 0c39:0038 jmp 003a 0c39:003a stosw 0c39:003b loop 0033 ^^^^ Here you have the famous jump that returns to the above adresses. 0c39:003d cli 0c39:003e pop ax 0c39:003f xchg cx,ax 0c39:0040 xchg cx,ax 0c39:0041 mov ah,ah 0c39:0043 add [01c3],ax 0c39:0047 cld 0c39:0048 mov al,al 0c39:004a add [0086],ax 0c39:004e nop 0c39:004f stosw 0c39:0050 db 69 0c39:0051 dec bp 0c39:0052 das 0c39:0053 mov bp,172f 0c39:0056 pop ax 0c39:0057 fistp qword ptr [si-26] 0c39:005a repnz 0c39:005b stosw 0c39:005C imul cl 0c39:005E mov dl,7a 0c39:0060 sbb ax,a212 0c39:0063 pushf 0c39:0064 test bp,[si-59] 0c39:0067 inc di And once decrypted: [...] 0c39:0034 xor ax,a451 0c39:0037 clc 0c39:0038 jmp 003a 0c39:003a stosw 0c39:003b loop 0033 0c39:003d cli 0c39:003e pop ax 0c39:003f xchg cx,ax 0c39:0040 xchg cx,ax 0c39:0041 mov ah,ah 0c39:0043 add [01c3],ax 0c39:0047 cld 0c39:0048 mov al,al 0c39:004a add [0086],ax 0c39:004e nop 0c39:004f cli 0c39:0050 int 1c 0c39:0052 mov bp,sp 0c39:0054 mov ax,[bp-04] 0c39:0057 mov ds,ax 0c39:0059 mov dx,[bp-06] 0c39:005c push dx Just trace into every call you find, and don't forget to take care of your HD... it might be a YAM virus ;) * VirusBuster *