PcTek9
Well-Known Member
- Reaction score
- 87
- Location
- Mobile, AL
If you want to analyze a malware on a windows machine. Download windbg from microsoft. You can use windbg to attach to a malware process running in the machines memory, (ideally one would use a vm and infect that, and use windbg in the vm right????), you can stop the process, set breakpoints, and so on.
It is helpful to get a book on assembly language programming, and read it. I highly recommend Kip Irvine's book, it's simply great for learning assembly.
As code runs through the commands as it executes, (the programming commands), it goes from line to line, or jumps around a lot. Assembly language jumps around a lot. In most languages that is highly discoruaged, and people sometimes refer to it as "spaghettii code". You won't find this sort of activity in procedural languages like cobol. Assembly jumps around in the code so much that there is more than one jump command. And in fact the command is called just that... Jump, abreviated jmp. The other commands like JNZ or jump not zero, JAB jump above, JBE jump below, JGE jump greater than or equal to, and so on... are all 3 letter acronyms for the command. So a lot of jumping going on.
Anyway... In programming languages, it is possible to let a program run through the program from the start, to a point you set for it to stop, so you can look at certain values in memory and in variables, and so on. This is called setting a break point (bp). When you set a breakpoint in windbg, the program will run to that location and stop, then you can check what values are in different variables, literally print any variable you have a question about, in that point in time to the screen. Very helpful to programmers.
After you look at what's in the variables you can resume the program, usually with f5. And let the trojan/virus run to the next breakpoint or to the end... or until it stops on it's own waiting for something like user input, or a message on a socket from a server in china... etc.
How does this help? Well if you know the activity you are looking for, it's possible to search for that activity using windbg, and set a breakpoint, then ... you can get the calling routines address or addresses off the stack, and use those to go to that part of the code and read it to see how it got there and what it is doing. How? Well. If you are waiting on the malware to call an interuppt for display, or disk, or something else, you'd look for that interupt to be called. So entering bp for an interupt example: bp int21h would cause the malware to stop when that interrupt gets called. If you are waiting for something to come in from the net, then enter bp recv(), and the program stops there... Then get the calling address off the stack by simply clicking on the hyperlink. Write these down.
Next download a program like The Borg, or any other windows disassembler program, (there's about 20 I know of...). You can find the malware executable and load it into borg, and literally disassemble it into assembly code. Once you do that, you can check the addresses (equivalent to line numbers sort of) in the code that you got from the stack to find out what called that subroutine, and what that subroutine does.
Sometimes you do have to use a program that decrypts the trojan or virus before you can use a disassembler. There are programs circulating the net for this, some people call them "unpackers", b/c they decrypt and unpack an executable into normal executable code. This way your disassembler can just grab it and open it up like a delicious box of white cheddar cheez-it snack crackers. Once you see the code, if it's your first time, you will probably be in shock.
Even a small trojan or virus can be thousands of lines of code... Though mostly a good understanding of assembly language will help you so much in comprehending what is going on. If you complete Kip's book, you'll be writing assembly language programs in no time, and focusing on this technically intense aspect of malware will become like second nature to you.
It is helpful to get a book on assembly language programming, and read it. I highly recommend Kip Irvine's book, it's simply great for learning assembly.
As code runs through the commands as it executes, (the programming commands), it goes from line to line, or jumps around a lot. Assembly language jumps around a lot. In most languages that is highly discoruaged, and people sometimes refer to it as "spaghettii code". You won't find this sort of activity in procedural languages like cobol. Assembly jumps around in the code so much that there is more than one jump command. And in fact the command is called just that... Jump, abreviated jmp. The other commands like JNZ or jump not zero, JAB jump above, JBE jump below, JGE jump greater than or equal to, and so on... are all 3 letter acronyms for the command. So a lot of jumping going on.
Anyway... In programming languages, it is possible to let a program run through the program from the start, to a point you set for it to stop, so you can look at certain values in memory and in variables, and so on. This is called setting a break point (bp). When you set a breakpoint in windbg, the program will run to that location and stop, then you can check what values are in different variables, literally print any variable you have a question about, in that point in time to the screen. Very helpful to programmers.
After you look at what's in the variables you can resume the program, usually with f5. And let the trojan/virus run to the next breakpoint or to the end... or until it stops on it's own waiting for something like user input, or a message on a socket from a server in china... etc.
How does this help? Well if you know the activity you are looking for, it's possible to search for that activity using windbg, and set a breakpoint, then ... you can get the calling routines address or addresses off the stack, and use those to go to that part of the code and read it to see how it got there and what it is doing. How? Well. If you are waiting on the malware to call an interuppt for display, or disk, or something else, you'd look for that interupt to be called. So entering bp for an interupt example: bp int21h would cause the malware to stop when that interrupt gets called. If you are waiting for something to come in from the net, then enter bp recv(), and the program stops there... Then get the calling address off the stack by simply clicking on the hyperlink. Write these down.
Next download a program like The Borg, or any other windows disassembler program, (there's about 20 I know of...). You can find the malware executable and load it into borg, and literally disassemble it into assembly code. Once you do that, you can check the addresses (equivalent to line numbers sort of) in the code that you got from the stack to find out what called that subroutine, and what that subroutine does.
Sometimes you do have to use a program that decrypts the trojan or virus before you can use a disassembler. There are programs circulating the net for this, some people call them "unpackers", b/c they decrypt and unpack an executable into normal executable code. This way your disassembler can just grab it and open it up like a delicious box of white cheddar cheez-it snack crackers. Once you see the code, if it's your first time, you will probably be in shock.
Even a small trojan or virus can be thousands of lines of code... Though mostly a good understanding of assembly language will help you so much in comprehending what is going on. If you complete Kip's book, you'll be writing assembly language programs in no time, and focusing on this technically intense aspect of malware will become like second nature to you.
