:wq - blog » assembly http://writequit.org/blog Tu fui, ego eris Mon, 22 Dec 2014 14:54:59 +0000 en-US hourly 1 http://wordpress.org/?v=4.1.5 Inline strlen function in assembly http://writequit.org/blog/2008/06/06/inline-strlen-function-in-assembly/ http://writequit.org/blog/2008/06/06/inline-strlen-function-in-assembly/#comments Fri, 06 Jun 2008 17:40:58 +0000 http://writequit.org/blog/?p=185

I know the strlen function in assembly has been covered on the internet before, but I figured I’ve cover it again, just in case someone like myself were searching google for it ;) ; here’s the code:

00404334 sub_404334 proc near
00404334  push edi
00404335  push eax
00404336  push ecx
00404337  mov edi, edx
00404339  xor eax, eax
0040433B  repne scasb
0040433D  jnz short loc_404341
0040433F  not ecx
00404341 loc_404341:
00404341  pop eax
00404342  add ecx, eax
00404344  pop eax
00404345  pop edi
00404346  jmp sub_4041BC
00404346 sub_404334 endp

The inputs for this function come from edx and ecx, edx holds a pointer to our string (in this example, the string is the location of the windows directory, so I’m going to say it’s “C:\Windows”). Ecx holds the maximum length of the string, which is 256 in this example. This is important as ecx is used as a countdown while the string is checked. Let’s go line-by-line:

00404334  push edi
00404335  push eax
00404336  push ecx

These 3 lines just save the variables to the stack so they’re not overwritten, standard stuff.

00404337  mov edi, edx
00404339  xor eax, eax

edx (which is a LPCSTR to “C:\Windows”) is moved into edi (you’ll see why in a second). Eax is XOR’d with itself to reset it to 0. The next instructions will compare each character in the string with al, so essentially it’s searching for the NULL character ‘\0′

0040433B  repne scasb

This instruction works from the beginning of edi, comparing each character of the string to whatever is in al (which is ‘\0′ or NULL right now). It decrements ecx for every character it compares (scans). If it does not find a match (repne – repeat-ne==Not Equal), it moves to the next character. In our example “C:\Windows” (terminated by NULL, like a good string should), ecx will decrease from 256 to 246 (C – 256, : – 255, \ – 254, W – 253, i – 252, n – 251, d – 250, o – 249, w – 248, s – 247, \0 – 246)

0040433D  jnz short loc_404341

If the end of the string was reached and there were not NULL bytes, jump to location 0x404341. In our example, it’s not jumped.

0040433F  not ecx

Flip all the bits in ecx, since ecx will be treated as a signed number, this makes ecx = -ecx. Note that if the end of the string is reached (ecx = 0), this instruction would be skipped by the jump in the previous instruction. In our example however, ecx becomes -246 (or 0xFFFFFF09).

00404341 loc_404341:
00404341  pop eax
00404342  add ecx, eax

Ecx’s starting value (256, remember?) is popped back into eax. Eax is then added to ecx and the result is stored in ecx. Therefore:

eax = 256
ecx = ecx + eax
ecx = -246 + 256
ecx = 10

The length of the string now resides in ecx, we can restore our original registers and jump away in the ending instructions:

00404344  pop eax
00404345  pop edi
00404346  jmp sub_4041BC

And that, is one way to get the length of a string in assembly.

 

]]>
http://writequit.org/blog/2008/06/06/inline-strlen-function-in-assembly/feed/ 1
Example malware unpacking and analysis: part 1, unpacking http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/ http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/#comments Fri, 09 May 2008 23:22:47 +0000 http://writequit.org/blog/?p=165 Lo! I still live! I apologize for the very very long delay that I’ve been putting everyone through lately, I’m sure I was terribly missed ;) *Ahem*, anyway, on with the post:

Introduction

Firstly, malware analysis and reverse engineering has always been incredibly interesting to me and I noticed that ever since my OEP finding tutorial for UPACK, I’ve also gotten a lot of google searches for “how to reverse malware” and other such things, so, I figured I’d share my meager knowledge, seeing as how other blogs have been so helpful thus far, and they always say the best way to learn something is to teach it. I decided that it would be cool to start a series about analysis from start to finish, explaining how I analyze the file. Anyhow, enough of my rambling, on with the analysis!

Part 1: Unpacking the malware

Disclaimer: I’m using real malware, in a Windows VM. If you don’t know what you’re doing, you can get infected. I’m not responsible for that part :)

Tools for part 1:
– Malware – For this entire series I’m going to use a piece of malware I got from the Vulnerable Minds blog, specifically from this post. It’s called “microsoft110.exe”. You can also find the malware on offensivecomputing.net under md5 “426504b6cadf2331ef980858316349ed” if you have an account (it’s free).
PEiD – For checking the type of packer used.
- Ollydbg 1.10 – For the unpacking part, I’m going to use Olly, just because it’s easier for this section of the analysis. You’ll also need the Ollydump plugin for ollydbg.
- ImpREC – For fixing imports, this is what you need.

Alrighty, microsoft110.exe uses a fairly standard packer, UPX, which is easily unpacked, both manually and automated. There are a fair number of tutorials about unpacking it already and some scripts to automatically unpack it for you, but I’m going to do it manually. You can tell that microsoft110.exe is packed with UPX by loading it up into PEiD:

Okay, now that the packer was verified, load it up into Olly, you should see the following starting instructions:

00424230 > $ 60 PUSHAD
00424231 . BE 00804100 MOV ESI,microsof.00418000
00424236 . 8DBE 0090FEFF LEA EDI,DWORD PTR DS:[ESI+FFFE9000]
0042423C . C787 00770100 >MOV DWORD PTR DS:[EDI+17700],4707FE20
00424246 . 57 PUSH EDI
00424247 . 83CD FF OR EBP,FFFFFFFF
0042424A . EB 0E JMP SHORT microsof.0042425A
... etc etc etc ...

The instruction highlighted in red (PUSHAD) is (most of the time) the indication that you can use this kind of unpacking to get an inflated executable. This instruction is used to save all the general registers onto the stack, so that UPX can do it’s decryption/decompression (I’m unfamiliar with UPX internals, so I can’t say which it is out of certainty). After unpacking, the registers are restored with the POPAD instruction and regular execution is started. So basically that’s where we need to stop and dump the process.

Anyway, back to the analysis, press F7 once to step into the PUSHAD instruction, note on the right you’ll see the registers change color, see the figure below:

We’re going to be following the stack pointer in memory, so right-click on the ESP value (00424231) and click on “Follow in dump”, the bottom window will display a hex dump of the memory at this address:

Note the values in ESP and the first value in the Address column match. Next we’re going to want to set a hardware breakpoint on the 4 bytes (08 02 91 7c) at the 0x0013ffa4 offset, so select the 4 bytes, right click and select breakpoint -> hardware, on access -> dword.

Now that a breakpoint was set, press F9 once to continue execution until we hit the breakpoint. When a breakpoint is hit, scroll up a little and you should see something like this:

0042437E .^EB E1 JMP SHORT microsof.00424361
00424380 > FF96 B0410200 CALL DWORD PTR DS:[ESI+241B0]
00424386 > 61 POPAD
00424387 .-E9 BC1AFFFF JMP microsof.00415E48
0042438C A4434200 DD microsof.004243A4
00424390 AC434200 DD microsof.004243AC
00424394 00874100 DD microsof.00418700

The blue line above is where the breakpoint stopped us, as you can see after scrolling up, a POPAD instruction (in green) was used immediately prior to the JMP instruction. In this simple example, all that’s required is to press F7 once to step into the JMP command, and you should have reached your OEP.

Now that the OEP was reached, use the ollydump plugin to dump the process in memory to a file, you can see the new OEP in this window, make sure that you uncheck the “Rebuild Import” option before dumping:

Take note of the modified OEP, which in this case is 0x15e48 (for later). Now that you have a dumped file, the imports have to be fixed, so fire up ImpREC and attach to the process for microsoft110.exe

In the box labeled OEP, put your new OEP (00015e48) and click on IAT AutoSearch, hopefully you will see this:

Which means the import address table was found. Now you can click on “Get Imports” and then “Fix Dump”, select the executable you dumped with ollydmp and ImportREC will fix the dump. Analysis may now begin.

This post is getting overly long, so I’ll stop here and pick it up with the next post. Be on the lookout for part 2 coming soon.

Well, regardless of whether this helped someone else or not, I’m much more likely to remember the process the next time I unpack some malware since I wrote/typed it down. Currently I’d say I’ve gotten about a third of the analysis done on the actual malware itself using IDA, so it’s slow going but picking up the pace. If you have any corrections or suggestions, *please* let me know, I’m not an expert in this subject, and I appreciate any feedback I get.

]]>
http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/feed/ 3