I've been primarily writing for Infosec Institute these days; so there's very few updates on my blog. I could duplicate stuff here; but that's not of much use to me or anyone :). So if you're interested in what I'm writing about, do take a look here.
Tuesday, 7 February 2012
Sunday, 25 September 2011
I've talked quite a bit about what tools to use and when in general. While all that is correct in principle, I recently, after a lot of painful 'research' [mostly already out there somewhere] , came up with a process for myself to use the right tools at the right time. Here is a short summary of the same:
1) Do your dynamic analysis and document what you found.
2) To learn more you have to now do static analysis; don't start off with IDA Pro; it overwhelms you very quickly... specially if you are new.
3) Put the EXE through Olly or Immunity and start identifying what each function does, step by step. I'm just saying... don't be worried initially about understanding everything about the malware. If you can even confirm what you found in dynamic analysis, via static analysis and say that...I know what these 5 functions do...that's good enough for a start.
4) Now once you know what these 5 functions do, open the EXE up in IDA Pro and rename the 'known' functions from sub_4012345 to something meaningful, like sub_malware_connect_irc. Repeat for each function you know. Go back to Olly now.
5) Now take each function(known); say sub_malware_connect_irc and identify all of its system function calls.. connect() send() getcommandline() etc etc.
6) Look at MSDN and understand the arguments that are passed to each. See where these arguments are stored in the disassembly you have. Is it stored on the stack or in a variable?
7) If its in a variable go to IDA and give that variable a meaningful name. So for e.g rename something like dword_ptr_401324 to malware_irc_host-name. This will result in every single place where that variable is accessed, getting renamed to the new variable. So dword_ptr_401234 will no longer exist; it will be referred to as malware_irc_host-name. Repeat this process for all known functions and all known variables.
8) Once you have a few functions and all corresponding variables renamed, use the GroupNodes feature in IDA (Right click on any block, select GroupNodes) to collapse blocks you have already analysed. Give each block a name that you will recognize instantly, without having to look at the disassembly again. Repeat this for all blocks that you have analyzed. So this will reduce the disassembly that you have to look at, in other parts of the program you have not yet analyzed.
9) So now, to summarize, for all known functions you have renamed the functions, renamed the variables, and grouped blocks of code that you have already analyzed and named the block. This should give you a nice 'pseudo codish' flowchart in IDA for quite a few functions :)
10) Now use the 'Functions' submenu in IDA and sort by the first column to see how many functions are pending; you can get this by seeing how many start with sub_.
11) Go to each function and see where it is called from. You can do this first in Olly 1.10 by highlighting the first line (usually PUSH EBP) of the function and looking in the middle pane on where all it is called from. Visit each of the calls in the middle pane and see where they were called .. and so on. Do this till you get to the root of the call.. see if you can now understand 'when' it was triggered.. 'What' behavior triggered it? Do the renaming and grouping as before. If you can't understand.. at least give the function a name.. some name.. like dummy_notunderstood_1, dummy_notunderstood_2 and so on. That still is better than sub 401237.
12) At the end of all of this you should have a .IDB file fully named (as much as possible) and fully grouped. Now ..only now should you start drilling down into HOW exactly each function works...the exact algorithm behind each function and so on. Repeat this for as many interesting functions that you want.
13) Once this also is done, if you WANT , try rewriting this in a high level language, at least pseudo code so you can quickly refer back to it when you want.
I guess, this is all very intuitive for most reversers who have learnt this on their own or been reversing for a long time. It took me a long time though, to reach this level and hope it is helpful to any relative newbie reading this blog post and feeling lost. I know I was one a few months ago ;).
p.s.... Make sure you back the .IDB file up ;)
Here are 2 sample screen-shots:
1) Do your dynamic analysis and document what you found.
2) To learn more you have to now do static analysis; don't start off with IDA Pro; it overwhelms you very quickly... specially if you are new.
3) Put the EXE through Olly or Immunity and start identifying what each function does, step by step. I'm just saying... don't be worried initially about understanding everything about the malware. If you can even confirm what you found in dynamic analysis, via static analysis and say that...I know what these 5 functions do...that's good enough for a start.
4) Now once you know what these 5 functions do, open the EXE up in IDA Pro and rename the 'known' functions from sub_4012345 to something meaningful, like sub_malware_connect_irc. Repeat for each function you know. Go back to Olly now.
5) Now take each function(known); say sub_malware_connect_irc and identify all of its system function calls.. connect() send() getcommandline() etc etc.
6) Look at MSDN and understand the arguments that are passed to each. See where these arguments are stored in the disassembly you have. Is it stored on the stack or in a variable?
7) If its in a variable go to IDA and give that variable a meaningful name. So for e.g rename something like dword_ptr_401324 to malware_irc_host-name. This will result in every single place where that variable is accessed, getting renamed to the new variable. So dword_ptr_401234 will no longer exist; it will be referred to as malware_irc_host-name. Repeat this process for all known functions and all known variables.
8) Once you have a few functions and all corresponding variables renamed, use the GroupNodes feature in IDA (Right click on any block, select GroupNodes) to collapse blocks you have already analysed. Give each block a name that you will recognize instantly, without having to look at the disassembly again. Repeat this for all blocks that you have analyzed. So this will reduce the disassembly that you have to look at, in other parts of the program you have not yet analyzed.
9) So now, to summarize, for all known functions you have renamed the functions, renamed the variables, and grouped blocks of code that you have already analyzed and named the block. This should give you a nice 'pseudo codish' flowchart in IDA for quite a few functions :)
10) Now use the 'Functions' submenu in IDA and sort by the first column to see how many functions are pending; you can get this by seeing how many start with sub_.
11) Go to each function and see where it is called from. You can do this first in Olly 1.10 by highlighting the first line (usually PUSH EBP) of the function and looking in the middle pane on where all it is called from. Visit each of the calls in the middle pane and see where they were called .. and so on. Do this till you get to the root of the call.. see if you can now understand 'when' it was triggered.. 'What' behavior triggered it? Do the renaming and grouping as before. If you can't understand.. at least give the function a name.. some name.. like dummy_notunderstood_1, dummy_notunderstood_2 and so on. That still is better than sub 401237.
12) At the end of all of this you should have a .IDB file fully named (as much as possible) and fully grouped. Now ..only now should you start drilling down into HOW exactly each function works...the exact algorithm behind each function and so on. Repeat this for as many interesting functions that you want.
13) Once this also is done, if you WANT , try rewriting this in a high level language, at least pseudo code so you can quickly refer back to it when you want.
I guess, this is all very intuitive for most reversers who have learnt this on their own or been reversing for a long time. It took me a long time though, to reach this level and hope it is helpful to any relative newbie reading this blog post and feeling lost. I know I was one a few months ago ;).
p.s.... Make sure you back the .IDB file up ;)
Here are 2 sample screen-shots:
 | |||
| Sample Graph of Grouped Functions |
 |
| Renamed functions - A sample list |
Thursday, 22 September 2011
Recently I was debugging a piece of malware which launched numerous threads inside, after it ran. Now, after the thread spawned, I could no longer F7 or F8 my way through the malware and understand things. This was because it was the thread which was doing all the work. So somehow I needed to get into the thread.
The first thing I did was 'Right click' and then select a thread from the Threads sub menu. That though just seemed to take me to system space, which was kind of useless. I wanted to see what the Thread did in User Space.
I looked at the CreateThread API then, which was what was being used. The 3rd argument to the function was a start address for the thread. I did a Ctrl+G, went to that address in Olly and put a breakpoint there, and then restarted the program. Went on as normal till CreateThread and then F9'd to run till next breakpoint. The main thread still "hung" but I did break inside UserMode for the Thread and could debug it.. yay :)
If you want to break even before UserMode and want to track it the moment the thread is launched, you can set debugging options in Olly to break each time a new thread is started or stopped. There's simple check boxes under the Options menu. Go search :)
The last bit is when the Thread itself exits..it just says Thread Terminated and you again cannot F7 or F8 because there is nothing left to F7 or F8 into. You need to get back to the main thread, where the CreateThread API was called. Makes sense ..rt? Main.. created a thread...I debugged thread...now I come back to main...once I finish debugging the thread.
To do so, pause the program(F12) after the thread terminates and hit Alt+F9 to return to user mode. This will bring you right to the spot after CreateThread was first called.
Hope this helps someone newish to reversing :). Have fun!!
The first thing I did was 'Right click' and then select a thread from the Threads sub menu. That though just seemed to take me to system space, which was kind of useless. I wanted to see what the Thread did in User Space.
I looked at the CreateThread API then, which was what was being used. The 3rd argument to the function was a start address for the thread. I did a Ctrl+G, went to that address in Olly and put a breakpoint there, and then restarted the program. Went on as normal till CreateThread and then F9'd to run till next breakpoint. The main thread still "hung" but I did break inside UserMode for the Thread and could debug it.. yay :)
If you want to break even before UserMode and want to track it the moment the thread is launched, you can set debugging options in Olly to break each time a new thread is started or stopped. There's simple check boxes under the Options menu. Go search :)
The last bit is when the Thread itself exits..it just says Thread Terminated and you again cannot F7 or F8 because there is nothing left to F7 or F8 into. You need to get back to the main thread, where the CreateThread API was called. Makes sense ..rt? Main.. created a thread...I debugged thread...now I come back to main...once I finish debugging the thread.
To do so, pause the program(F12) after the thread terminates and hit Alt+F9 to return to user mode. This will bring you right to the spot after CreateThread was first called.
Hope this helps someone newish to reversing :). Have fun!!
Sunday, 28 August 2011
Saturday, 30 July 2011
In the last part we saw that a part of the code launches an embedded instance of IE. We also have Wireshark running so we can capture any network traffic that is sent by the malware. We also broke last time at 40B511, exiting from the thread that created IE. Lets move forward quicker now and see what else happens.
Remember that the more functions you can identify; the easier it is for you to analyze the overall purpose of the executable. There are a few CALLs that happen which just try and find out which directory a file was from or do other relatively unimportant operations from a malware perspective. We then come to a call - CALL 0040B849. On going deeper into this function you will find that its a very interesting function which logs all the operations of the malware into a file in C:\. So that now is another bit of information that we can tally with our dynamic analysis. And since its logging stuff... it also gives us some nice inputs about what the malware is doing at a specific amount of time. Open up the file soft_AOL.log in C: and see for yourself. Another key point that you'd want to know is that this function is also a very common function - look at the middle pane again in Olly just after you step into it. It has a lot of addresses from where a call was made. For e.g:
Local calls from 00401729, 00401754, 004017D8, 004019B6, 004019D8, 00401B85, 00401C5B, 00401D13, 00401D6C, 00401F3E, 00401F99, 004026F6, 0040278B, 004027C6, 00402894, 0040293D, 00402ACE, 00402B1F, 00402B69, 00402B71, 00402B7B, 00402BA5, 00402C4A, ...
At 40B56B the existence of a file c:\Windows\lgv is checked. Its not too clear why it does this at this point; maybe its confirmation that the malware is active and more stuff can be done. Keep looking at Wireshark by the way - the moment you see some data there, you know you have to stop and go back and see where the traffic came from. So lets F8 on till we come to a call at 0040b679 - CALL 004029B8. Step over this as well and then quickly look at Wireshark..its suddenly filled up with traffic. That means the previous CALL was very important. Put a breakpoint on that call and restart; when you get to the CALL step into it. Starting at 4029B8 F8 on till 402A08 where Wireshark starts filling up again. Put another breakpoint, restart and step into the CALL at 402A0B this time. And so on..you keep stepping in till you find out exactly where the call is and why Wireshark is filling up. Once you step into the CALL at 402A0B you reach the address at 0040B01A. Now look at the code below..lots of comments there and some very interesting ones. I won't talk about every single CALL, I'll never finish that way ;). Before you move on though, do step into the call at the address 40B04B - its the routine which decides the list of domains that the malware will talk to at some point. There's a small encryption algorithm in there.. do try and see how the names of those domains are generated. Notice all that text btw? "scan domain attempt" or "check inet"... all of that goes into that log file in C: . Have a look.
Go on till you reach 40B0AC where there is a JMP 40B113. This means that control flow switches to this address. F8 so the JMP happens and at the very next instruction jumps back to 40B0AE. F8 on till you reach 40B0CB and look at the EAX register on the right side. You see a weird looking site there? Yes you do :). Now that is a big piece of information..maybe maybe the malware connects there for some purpose? Go on til 40B0E2 and look at EAX again. You see something called .sys.php? Looks like a part of some URL. Things are getting interesting now..aren't they? Go on till 40B0F8. Look at Wireshark and notice that nothing has happened so far. F8 over the CALL 405086 statement and now look at Wireshark. Yesss!! Traffic seen..and its a HTTP request made to that site we saw in EAX and for the file .sys.php. Look at the response to the request though in Wireshark - its a 404 not found. The malware did not find what it was looking for. How does it respond? F8 on and you'll notice that you get to the same point where you jump back to 40B0AE and repeat this same stuff with a new site. This process continues until some site responds with a 200 OK message, saying "Yes I have that file". Put a breakpoint on 40B17B so the code just doesn't connect and complete the remaining process before you can intervene.
The code returns eventually to 402A10 and continues from there. Lots of interesting stuff but just continue on till you reach 402BA0. "Crypted Code detected".. hmmm. Something encrypted was returned when we made a request for .sys.php and the malware is decrypting it for some reason. How does this decryption work? Do not know. F8 on till you reach 402BE5. Look at the contents of the EBX register now? See a message there with a URL that looks like Internet Spam?? Right click on the EBX register and say "Follow in Dump". The whole URL is very clearly visible now!!
I think the rest is guessable. This malware connects to a huge list of random sites, finds an active on, requests a URL from it, gets an encrypted message, decrypts it and then posts it on lifestream.aol.com which is AOL's social media platform using some user ID and password. If you continue stepping through the code you will also find out the credentials that are used each time. I tried it 3 times and found 3 different passwords - I think it creates a new account, posts Spam and logs out. But hey..don't take my word for it. Try it out for yourself :)
At one point of time the Embedded IE window can be viewed completely and you can actually see malware entering credentials into it and coming back with a "Cannot Login" message.
I still have questions about some parts of this malware and could not fully understand every bit. For e.g I could not find out how the SSL connection which we talked about during dynamic analysis was established. But I'm sure its all a matter of time and thought that all of this itself is a good learning and many newbies to this field can gain something from it.
I hope you enjoyed this and you feel reversing is doable by you as well. Until next time goodbye :)
Remember that the more functions you can identify; the easier it is for you to analyze the overall purpose of the executable. There are a few CALLs that happen which just try and find out which directory a file was from or do other relatively unimportant operations from a malware perspective. We then come to a call - CALL 0040B849. On going deeper into this function you will find that its a very interesting function which logs all the operations of the malware into a file in C:\. So that now is another bit of information that we can tally with our dynamic analysis. And since its logging stuff... it also gives us some nice inputs about what the malware is doing at a specific amount of time. Open up the file soft
Local calls from 00401729, 00401754, 004017D8, 004019B6, 004019D8, 00401B85, 00401C5B, 00401D13, 00401D6C, 00401F3E, 00401F99, 004026F6, 0040278B, 004027C6, 00402894, 0040293D, 00402ACE, 00402B1F, 00402B69, 00402B71, 00402B7B, 00402BA5, 00402C4A, ...
At 40B56B the existence of a file c:\Windows\lgv is checked. Its not too clear why it does this at this point; maybe its confirmation that the malware is active and more stuff can be done. Keep looking at Wireshark by the way - the moment you see some data there, you know you have to stop and go back and see where the traffic came from. So lets F8 on till we come to a call at 0040b679 - CALL 004029B8. Step over this as well and then quickly look at Wireshark..its suddenly filled up with traffic. That means the previous CALL was very important. Put a breakpoint on that call and restart; when you get to the CALL step into it. Starting at 4029B8 F8 on till 402A08 where Wireshark starts filling up again. Put another breakpoint, restart and step into the CALL at 402A0B this time. And so on..you keep stepping in till you find out exactly where the call is and why Wireshark is filling up. Once you step into the CALL at 402A0B you reach the address at 0040B01A. Now look at the code below..lots of comments there and some very interesting ones. I won't talk about every single CALL, I'll never finish that way ;). Before you move on though, do step into the call at the address 40B04B - its the routine which decides the list of domains that the malware will talk to at some point. There's a small encryption algorithm in there.. do try and see how the names of those domains are generated. Notice all that text btw? "scan domain attempt" or "check inet"... all of that goes into that log file in C: . Have a look.
Go on till you reach 40B0AC where there is a JMP 40B113. This means that control flow switches to this address. F8 so the JMP happens and at the very next instruction jumps back to 40B0AE. F8 on till you reach 40B0CB and look at the EAX register on the right side. You see a weird looking site there? Yes you do :). Now that is a big piece of information..maybe maybe the malware connects there for some purpose? Go on til 40B0E2 and look at EAX again. You see something called .sys.php? Looks like a part of some URL. Things are getting interesting now..aren't they? Go on till 40B0F8. Look at Wireshark and notice that nothing has happened so far. F8 over the CALL 405086 statement and now look at Wireshark. Yesss!! Traffic seen..and its a HTTP request made to that site we saw in EAX and for the file .sys.php. Look at the response to the request though in Wireshark - its a 404 not found. The malware did not find what it was looking for. How does it respond? F8 on and you'll notice that you get to the same point where you jump back to 40B0AE and repeat this same stuff with a new site. This process continues until some site responds with a 200 OK message, saying "Yes I have that file". Put a breakpoint on 40B17B so the code just doesn't connect and complete the remaining process before you can intervene.
The code returns eventually to 402A10 and continues from there. Lots of interesting stuff but just continue on till you reach 402BA0. "Crypted Code detected".. hmmm. Something encrypted was returned when we made a request for .sys.php and the malware is decrypting it for some reason. How does this decryption work? Do not know. F8 on till you reach 402BE5. Look at the contents of the EBX register now? See a message there with a URL that looks like Internet Spam?? Right click on the EBX register and say "Follow in Dump". The whole URL is very clearly visible now!!
I think the rest is guessable. This malware connects to a huge list of random sites, finds an active on, requests a URL from it, gets an encrypted message, decrypts it and then posts it on lifestream.aol.com which is AOL's social media platform using some user ID and password. If you continue stepping through the code you will also find out the credentials that are used each time. I tried it 3 times and found 3 different passwords - I think it creates a new account, posts Spam and logs out. But hey..don't take my word for it. Try it out for yourself :)
At one point of time the Embedded IE window can be viewed completely and you can actually see malware entering credentials into it and coming back with a "Cannot Login" message.
I still have questions about some parts of this malware and could not fully understand every bit. For e.g I could not find out how the SSL connection which we talked about during dynamic analysis was established. But I'm sure its all a matter of time and thought that all of this itself is a good learning and many newbies to this field can gain something from it.
I hope you enjoyed this and you feel reversing is doable by you as well. Until next time goodbye :)
Make sure you read the previous post before you start on this one. We started doing some analysis on a piece of malware and looked at the basics of how to start static analysis. We'll pick off where we left off last time. Now if you look at the assembly code and scroll up and down you will see a huge number of CALL statements and many JMP statements and many other loops. Yes you could, as we discussed last time Step Into each and every call ..mark it and go on till you reach the end of the program. That's just fine. So for example - I did this for the next few CALL statements.. just to get a clearer picture and see if this strategy works.
00411D9E . E8 DD0A0000 CALL aolsbm_1.00412880 ; Nothing here - intermediate function
00411DA7 . FF15 28014200 CALL DWORD PTR DS:[<&KERNEL32.GetStartupInfoW>] ; \-------------- Windows appearance at startup
00411DBC . FF15 2C014200 CALL DWORD PTR DS:[<&KERNEL32.HeapSetInformation>] ; --------------------- Heap memory
00411E0B > \E8 44050000 CALL aolsbm_1.00412354 ; ------------- Heap memory create
00411E1C > \E8 90410000 CALL aolsbm_1.00415FB1 ; --------------- Process and thread info gather
00411E27 . E8 42FFFFFF CALL aolsbm_1.00411D6E ; Some common function (Later)
00411E2D > \E8 824D0000 CALL aolsbm_1.00416BB4 ; ---------------- Some ntdll function
00411E35 . E8 9F0A0000 CALL aolsbm_1.004128D9 ; -------------------- Get file handles
00411E45 . 59 POP ECX ; All process setting up till here - ignore
00411E46 > \FF15 30014200 CALL DWORD PTR DS:[<&KERNEL32.GetCommandLineA>] ; Get Program's Command Line arguments
00411E51 . E8 BF750000 CALL aolsbm_1.00419415 ; Environment strings
00411E5B . E8 FA740000 CALL aolsbm_1.0041935A ; ------------------------ Get module file name
00411E6C > \E8 73720000 CALL aolsbm_1.004190E4 ; -------------- Getting user directories, startupinfo, env variables etc
00411E90 > \E8 F0710000 CALL aolsbm_1.00419085 ; --------------------- Some path parsing of the executable path again
Yeah that'll do...I've stepped into each and every one of these call functions(user defined) and studied them briefly and decided whether to delve deeper into them or not. The question each time is - Does this bring me closer to understanding what the malware does? If the answer is NO, just comment it and move on. All ok? Yeah ok...except its going to take a huge amount of time to get to the end of the program. So it is probably a good idea to step back a bit and try and see if your dynamic analysis can help you move forward a little quicker.
Now you know that the malware definitely connects out to the Internet and does some stuff there. So why not startup Wireshark and see what goes out..as you Step Over and Step Into various bits of code? Right? Lets start Wireshark up then. What else? Well.. we know that if a connection to the Internet is made it must use some 'Windows Socket functions' to do so...like 'connect', 'send', 'gethostbyname' and so on. So we want to stop the program whenever these functions are used..which translates to 'We want to break..or we want to set a breakpoint'. So we want to now find out where these functions are being used in the program and break there. So we just hit Ctrl+N and search for the 'connect' function. Now if you look at the Ctrl+N window in Olly 1.10 and you're a newbie like me, you'll get confused because you won't see any 'connect' functions there and you'll spend time moaning about everything ;). But if you used Olly 2.0x and search you'll see a line which has WS2_32.connect in the comments section. The function name is WS2_32.#4. So come back to Olly 1.10(We'll primarily use this as it has more features), right click on the line for WS2_32.#4 and click 'Find references to import'. Promptly a box with an address 00403FD3 comes up..it means there is something at this address which calls the connect function. Right click on this line and set a breakpoint (Toggle breakpoint). So now..whenever the code reaches the line with the address 00403FD3 it will stop and you can analyze the function that called it and work your way backward from there. Easy? No.. not really if it is your first time... but logical..yes. It'll get easier the more you do...lets go on.
So that's another rule learnt then, if you are sure that the malware MUST use certain Windows functions for a specific purpose, which you know because you've done dynamic analysis - read up on MSDN about all those functions and set breakpoints accordingly on all these functions. That'll narrow down the scope quite a bit. Lets then quickly run through what we've done so far:
--- We understood how to navigate through code
--- We commented functions we didn't know anything about at the moment
--- We stepped over all those functions but soon realized that this way though exhaustive, is extremely time taking
--- We re-visited our dynamic analysis learnings and identified functions that could definitely be used and set breakpoints on them
--- We started Wireshark so we could see what traffic is sent by the executable at every step
Not bad at all. Lets move on. So keep hitting F8 till you pass 00411E90. I'm saying this because I've analysed it till there and am quite sure that none of those directly affect the malware in any way..look at the comments I've made. If you want though, feel free to F7 into each of those until you are satisfied :). Well now what? Lets try and run the program directly and hit F9. At some stage, though we don't know when.. we must break at the 'connect' breakpoint we have set. So hit F9. We do break as predicted...but even before that we see a new window open up :). Now there's a big chance that this relates in some way to the malware..so we want to find out how that window appeared.
A good way and probably the most intutive way when you're starting off is to just keep hitting F8 till you see the window pop up. Yes, there probably are more intelligent ways to solve this problem but it'll do for now. So lets do just that...hit Ctrl+F2 and restart the program. Now you know that there is nothing till 004011E90 for sure so instead of hitting F8 till there, lets right click - Go to Expression - 4011E90 - OK and jump there. Once you're there hit F4..this makes the program 'Run to selection'. You can also scroll down to that location if its not too far. Once you reach 4011E90 start hitting F8 as you don't know where the popup is going to come. You don't have to wait too long :).....
Pause for a moment when you reach 4011EAC and note this location down somewhere. Now hit F8 again. Boom!! There's your popup. What does this mean? It just means that there was something INSIDE the function that was called at 4011EAC which caused a popup to appear. This means that the function CALL 00419085 is interesting and we need to know something more about it. So we set a breakpoint here by highlighting that line and pressing F2. Now lets Ctrl+F2 again and hit F9 this time.. this effectively tells the program to run till it breaks. It does just that and halts at 4011EAC. Now since we want to know more about this CALL we hit F7 and not F8. We immediately are taken to 00419085. Notice there isn't any popup yet.. it is some place inside this function which does it. We need to F8 till there to find this out. Repeat this process and you see the popup again at the address 40BBA5. Can you see something at 40BBA5 that makes the popup appear? No, its another call. Put a breakpoint here and restart the program and reach 40BBA5. Now step into the call(F7) at this address (CALL 0040B48F). Once in this call start hitting F8 again till you reach the address 0040B4F7. Pause a bit and look at the instruction here -- 'CreateThread'. Another system function...lets look at what MSDN says.
MSDN:
CreateThread - The CreateThread function creates a new thread for a process.
So we're starting something here..mostly this thread causes the popup to appear...the third argument to this function is the address of the code this thread must execute. That argument is defined at the address 0040B4E7 by the instruction PUSH 0040D1AA. So this thread creates whatever there is at 40D1AA. Lets see what there is at 40D1AA. Right click - Go to Expression - 40D1AA. The range is from 40D1AA to 40D28C(RETN function specifies the end of the function). Its this function which is creating the popup. Lets put a breakpoint at 40D1AA and see if the thread jumps here. So hit F2 while at 40D1AA and then Ctrl+F2 again. Arrive till 0040B4F7 and F8 over the CreateThread function...immediately you see the code jumps to 40D1AA and stops. Yes!! Our understanding was correct. Lets F8 step by step now..
You pass over 2 system functions here - Ole32.coinitialize and Kernel32.GetModuleHandleA. I wont explain these here..you can get into the habit of having Google permanently open for MSDN ;). However there is another call here - CALL 404A22 here..at address 40D1E5. Lets F7 into that..and you see its another function which ranges from 404A22 to 404ABA. Just browse through it...anything interesting?? Aha..there is a call to the CreateWindowEx function with its 2nd argument as "IEEmbedded".... very interesting. Remember we found strings called IEEmbedded in dynamic analysis?? Read up a little about this and you will find that this function creates a window of a specific size :). After a few more calls we're back in the previous function at address 40D1EA.
Go on reading. Now there's a ShowWindow call with 2 arguments - the first argument is the handle returned by CreateWindow and the second argument is the number 5. MSDN says that 5 stands for display the Window that was created. Right..step over ShowWindow. Yes!! The window appears. More F8 reveals navigation inside a loop consisting of the functions TranslateMessage, DispatchMessage and GetMessage. We dont want to remain in this loop now...we sort of know what it does..it does things with the window. That's good enough. Lets go back to the previous function and put a breakpoint at 40B511 .. any location after the CreateThread will do - we just want to get out of that thread now that we know what it does. Remove all the breakpoints except that at 40B511 and hit F9. You should get a Window popup and your code should halt at 40B511. Got it?
So effectively to dig out all the information about a particular call we might have to dig in extremely deep into the code. You saw...that to just get to the function which created a window we had to go 4 or 5 calls deep into the code. Its the same methodology we have to follow for every single call that we're interested in. So to sum up what we have learnt so far:
--- Comment code a lot
--- Step Over calls you dont have use for
--- Think of the actual behavior of the program wrt dynamic analysis and break on specific functions
--- Look at the runtime behavior of the program and dig into CALL statements accordingly
--- Understand API's better and set breakpoints accordingly
These are the basics of reverse engineering ..really. Keep digging till you find what you want. In Part 3 we'll use these same concepts and move much faster and conclude our analysis of this piece of malware.
00411D9E . E8 DD0A0000 CALL aolsbm_1.00412880 ; Nothing here - intermediate function
00411DA7 . FF15 28014200 CALL DWORD PTR DS:[<&KERNEL32.GetStartupInfoW>] ; \-------------- Windows appearance at startup
00411DBC . FF15 2C014200 CALL DWORD PTR DS:[<&KERNEL32.HeapSetInformation>] ; --------------------- Heap memory
00411E0B > \E8 44050000 CALL aolsbm_1.00412354 ; ------------- Heap memory create
00411E1C > \E8 90410000 CALL aolsbm_1.00415FB1 ; --------------- Process and thread info gather
00411E27 . E8 42FFFFFF CALL aolsbm_1.00411D6E ; Some common function (Later)
00411E2D > \E8 824D0000 CALL aolsbm_1.00416BB4 ; ---------------- Some ntdll function
00411E35 . E8 9F0A0000 CALL aolsbm_1.004128D9 ; -------------------- Get file handles
00411E45 . 59 POP ECX ; All process setting up till here - ignore
00411E46 > \FF15 30014200 CALL DWORD PTR DS:[<&KERNEL32.GetCommandLineA>] ; Get Program's Command Line arguments
00411E51 . E8 BF750000 CALL aolsbm_1.00419415 ; Environment strings
00411E5B . E8 FA740000 CALL aolsbm_1.0041935A ; ------------------------ Get module file name
00411E6C > \E8 73720000 CALL aolsbm_1.004190E4 ; -------------- Getting user directories, startupinfo, env variables etc
00411E90 > \E8 F0710000 CALL aolsbm_1.00419085 ; --------------------- Some path parsing of the executable path again
Yeah that'll do...I've stepped into each and every one of these call functions(user defined) and studied them briefly and decided whether to delve deeper into them or not. The question each time is - Does this bring me closer to understanding what the malware does? If the answer is NO, just comment it and move on. All ok? Yeah ok...except its going to take a huge amount of time to get to the end of the program. So it is probably a good idea to step back a bit and try and see if your dynamic analysis can help you move forward a little quicker.
Now you know that the malware definitely connects out to the Internet and does some stuff there. So why not startup Wireshark and see what goes out..as you Step Over and Step Into various bits of code? Right? Lets start Wireshark up then. What else? Well.. we know that if a connection to the Internet is made it must use some 'Windows Socket functions' to do so...like 'connect', 'send', 'gethostbyname' and so on. So we want to stop the program whenever these functions are used..which translates to 'We want to break..or we want to set a breakpoint'. So we want to now find out where these functions are being used in the program and break there. So we just hit Ctrl+N and search for the 'connect' function. Now if you look at the Ctrl+N window in Olly 1.10 and you're a newbie like me, you'll get confused because you won't see any 'connect' functions there and you'll spend time moaning about everything ;). But if you used Olly 2.0x and search you'll see a line which has WS2_32.connect in the comments section. The function name is WS2_32.#4. So come back to Olly 1.10(We'll primarily use this as it has more features), right click on the line for WS2_32.#4 and click 'Find references to import'. Promptly a box with an address 00403FD3 comes up..it means there is something at this address which calls the connect function. Right click on this line and set a breakpoint (Toggle breakpoint). So now..whenever the code reaches the line with the address 00403FD3 it will stop and you can analyze the function that called it and work your way backward from there. Easy? No.. not really if it is your first time... but logical..yes. It'll get easier the more you do...lets go on.
So that's another rule learnt then, if you are sure that the malware MUST use certain Windows functions for a specific purpose, which you know because you've done dynamic analysis - read up on MSDN about all those functions and set breakpoints accordingly on all these functions. That'll narrow down the scope quite a bit. Lets then quickly run through what we've done so far:
--- We understood how to navigate through code
--- We commented functions we didn't know anything about at the moment
--- We stepped over all those functions but soon realized that this way though exhaustive, is extremely time taking
--- We re-visited our dynamic analysis learnings and identified functions that could definitely be used and set breakpoints on them
--- We started Wireshark so we could see what traffic is sent by the executable at every step
Not bad at all. Lets move on. So keep hitting F8 till you pass 00411E90. I'm saying this because I've analysed it till there and am quite sure that none of those directly affect the malware in any way..look at the comments I've made. If you want though, feel free to F7 into each of those until you are satisfied :). Well now what? Lets try and run the program directly and hit F9. At some stage, though we don't know when.. we must break at the 'connect' breakpoint we have set. So hit F9. We do break as predicted...but even before that we see a new window open up :). Now there's a big chance that this relates in some way to the malware..so we want to find out how that window appeared.
A good way and probably the most intutive way when you're starting off is to just keep hitting F8 till you see the window pop up. Yes, there probably are more intelligent ways to solve this problem but it'll do for now. So lets do just that...hit Ctrl+F2 and restart the program. Now you know that there is nothing till 004011E90 for sure so instead of hitting F8 till there, lets right click - Go to Expression - 4011E90 - OK and jump there. Once you're there hit F4..this makes the program 'Run to selection'. You can also scroll down to that location if its not too far. Once you reach 4011E90 start hitting F8 as you don't know where the popup is going to come. You don't have to wait too long :).....
Pause for a moment when you reach 4011EAC and note this location down somewhere. Now hit F8 again. Boom!! There's your popup. What does this mean? It just means that there was something INSIDE the function that was called at 4011EAC which caused a popup to appear. This means that the function CALL 00419085 is interesting and we need to know something more about it. So we set a breakpoint here by highlighting that line and pressing F2. Now lets Ctrl+F2 again and hit F9 this time.. this effectively tells the program to run till it breaks. It does just that and halts at 4011EAC. Now since we want to know more about this CALL we hit F7 and not F8. We immediately are taken to 00419085. Notice there isn't any popup yet.. it is some place inside this function which does it. We need to F8 till there to find this out. Repeat this process and you see the popup again at the address 40BBA5. Can you see something at 40BBA5 that makes the popup appear? No, its another call. Put a breakpoint here and restart the program and reach 40BBA5. Now step into the call(F7) at this address (CALL 0040B48F). Once in this call start hitting F8 again till you reach the address 0040B4F7. Pause a bit and look at the instruction here -- 'CreateThread'. Another system function...lets look at what MSDN says.
MSDN:
CreateThread - The CreateThread function creates a new thread for a process.
So we're starting something here..mostly this thread causes the popup to appear...the third argument to this function is the address of the code this thread must execute. That argument is defined at the address 0040B4E7 by the instruction PUSH 0040D1AA. So this thread creates whatever there is at 40D1AA. Lets see what there is at 40D1AA. Right click - Go to Expression - 40D1AA. The range is from 40D1AA to 40D28C(RETN function specifies the end of the function). Its this function which is creating the popup. Lets put a breakpoint at 40D1AA and see if the thread jumps here. So hit F2 while at 40D1AA and then Ctrl+F2 again. Arrive till 0040B4F7 and F8 over the CreateThread function...immediately you see the code jumps to 40D1AA and stops. Yes!! Our understanding was correct. Lets F8 step by step now..
You pass over 2 system functions here - Ole32.coinitialize and Kernel32.GetModuleHandleA. I wont explain these here..you can get into the habit of having Google permanently open for MSDN ;). However there is another call here - CALL 404A22 here..at address 40D1E5. Lets F7 into that..and you see its another function which ranges from 404A22 to 404ABA. Just browse through it...anything interesting?? Aha..there is a call to the CreateWindowEx function with its 2nd argument as "IEEmbedded".... very interesting. Remember we found strings called IEEmbedded in dynamic analysis?? Read up a little about this and you will find that this function creates a window of a specific size :). After a few more calls we're back in the previous function at address 40D1EA.
Go on reading. Now there's a ShowWindow call with 2 arguments - the first argument is the handle returned by CreateWindow and the second argument is the number 5. MSDN says that 5 stands for display the Window that was created. Right..step over ShowWindow. Yes!! The window appears. More F8 reveals navigation inside a loop consisting of the functions TranslateMessage, DispatchMessage and GetMessage. We dont want to remain in this loop now...we sort of know what it does..it does things with the window. That's good enough. Lets go back to the previous function and put a breakpoint at 40B511 .. any location after the CreateThread will do - we just want to get out of that thread now that we know what it does. Remove all the breakpoints except that at 40B511 and hit F9. You should get a Window popup and your code should halt at 40B511. Got it?
So effectively to dig out all the information about a particular call we might have to dig in extremely deep into the code. You saw...that to just get to the function which created a window we had to go 4 or 5 calls deep into the code. Its the same methodology we have to follow for every single call that we're interested in. So to sum up what we have learnt so far:
--- Comment code a lot
--- Step Over calls you dont have use for
--- Think of the actual behavior of the program wrt dynamic analysis and break on specific functions
--- Look at the runtime behavior of the program and dig into CALL statements accordingly
--- Understand API's better and set breakpoints accordingly
These are the basics of reverse engineering ..really. Keep digging till you find what you want. In Part 3 we'll use these same concepts and move much faster and conclude our analysis of this piece of malware.
Subscribe to:
Posts (Atom)
