Copy Link
Add to Bookmark
Report
29A Issue 01 02 01
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 *
