I posted up a link the other day about the F-secure 2008 Reversing challenge, or khallenge. I got a little side tracked with things to do around the house Pre Vegas, and the prerequisite quality time so my bride isn’t completely pissed at me. I took a quick look at it Friday before leaving work but completely dropped it until this evening. When you first load it up in Ida Pro and browse through it you will see there is a lot of XOR’ing of 8 bit registers with Bytes. When you jump to the bytes in IDA, some of them already have values (initialized) and others don’t.

This challenge is going to be much easier utilizing dynamic, versus static analysis so it’s off to Olly or Immunitydbg we go! From either Ida Pro, or your debugger of choice you can see after the printing of the message, printing of the input request, and subsequent scanning thereof there is a loop followed by a comparison.

If you happen to have Hex-Ray’s, you can cheat a little, hit F5 and get some pseudo code. Otherwise, you have to figure out this is a compiler optimized strlen function. Although it’s not necessarily important it may trip you up. All it’s doing is scanning the string byte by byte looking for the terminating zero (text cl,cl).

After our compiler optimized strlen, we see a cmp eax, 4. This is testing that our input is 4 bytes long. If not, we jump to a “sorry…” message. So, we can conclude our input is 4 bytes long, or 4 chars.

Next we get into a crap load of XOR’s with bytes, and registers. There’s a lot going on here so it’s really important to:

• Keep a piece of paper handy
• Set a break point at every address within the algorithm
• Put in well crafter input (such as 1234, abcd)

Point number 3 was something I completely neglected. Working with MC for so long I got used to putting a stream of A’s, as my input I did the same here. It hindered me more than anything because I couldn’t differentiate the input at first. I left my comments in the screen shot for you to follow down (and for my own sanity while I was working on it).

I used the input “abcd” which allowed me to follow the data movements since it was not sequential. Our first instruction moved a PTR to EDX, when we press F9 in ImmunityDBG we see the value 63 or “c” loaded in the EDX register. Our next instruction moves the value in input1 (“a”) to the EAX register.

We see 3 XOR Operations, 2 with AL and one with DL. As we follow the program through the debugger we discover that only the last XOR is valid. Going back to Ida Pro we jmp to the byte definition for the last XOR to find out it’s value. As it turns out the byte is initiated with a value of 0×70 The instruction that follow from:

1
2
3
4

690010B3  . 0FB615 0331006&gtMOVZX EDX,BYTE PTR DS:[69003103
 
To:
690010C7  . 3005 D9300069  XOR BYTE PTR DS:[690030D9],AL              XOR 0x20, arg 2

Are crap instructions. I mean, they do something but they are overwritten starting in the next instruction.

We pick back up with:

1

690010CD  . 8A0D D5300069  MOV CL,BYTE PTR DS:[690030D5

Again we used Ida Pro to find the value of the byte ptr, it turns out to be 0×2e.
After this we move the 3rd byte into EDX, and the 4th into EAX. The second byte, still loaded in CL is XORED with 0×2e, the 3rd byte Xored with 0×76, and the 4th xored with 0×68.

After all the Xoring madness stop’s, we find outselfs at a cmp instruction. We need the second argument to somehow turn out a value 0×61 after being xored with 0×2e. Following the Code down, we see other comparison’s. We just need to figure out what byte ptr’s they are referring to by looking back at the instructions.

Easy, Inverse XOR the values to arrive at X. Really the hardest part is following the byte ptr’s around and keeping track of what is being compared.

We arrive at

Arg 1: x = 0×70 ^ 0×32, x = 0×42 or “B”
Arg 2: x = 0×61 ^ 0×2e, x = 0×4F or “O”
Arg 3: x = 0×30 ^ 0×76, x = 0×46 or “F”
Arg 4: x = 0×79 ^ 0×29, x = 0×50 or “P”

When we restart the debugger and enter “BOFP” we are quickly directed (after removing our breakpoints) to:

This gives us the Email address to send an email to in order to receive challenge 2! Unfortunately I didn’t get this knocked out till a little while ago!

 Subscribe in a reader

An Opaque predicate is a line of code, or lines of code that are basically useless. They actually do something, but in terms of usefulness they don’t do anything. Does that even make sense? Anyway they are designed to make it appear as if the code was doing something to divert the attention of an analyst. The purpose of an opaque predicate is to add a layer of obfuscation into code that makes reversing the code more time consuming. As you sift through useless instruction you realize the code is more of a distraction than anything else. Opaque Predicates make static analysis more time consuming because they are often difficult to discover. You stumble upon a code block only to find after a few minutes that it’s dead.

So what does an opaque predicate look like?

In a high level language such as C/C++ we can have the most basic opaque predicate as a simple IF Insertion. Inserting IF statements to always come back true will surely not be effective on performance but in terms of static analysis it can throw off an analyst for a few minutes as they chase down a rabbit hole.

So we have something similar to this:

1
2
3
4
5
6
7
8
9

if(true)
{
Dosomething</code>
 
}
else
{
Dosomething
}

True will always come back as true. The first branch will always be the one chosen in actual execution. However, the code in the first branch and the second branch will be the same. This adds an additional branch to a graph in IDA, and adds more code the analyst must sort through. Just two are manageable, imagine if you had multiple if else’s in the code!

Ida Graph

And here is the deadlist

You can add an additional level of complexity to the code with math operations. An opaque predicate such as:

1
2
3
4
5
6

int    add,q = 2;</code>
 
if(((q+q^2)%2)==0)
printf("here");
else
add = 2+8;

Utilizes Dead code insertions. The else operation can be anything you want, for simplicity sake I chose the addition of two numbers and the assignment into a variable. However in real examples the code should be more complex. It should be dead code so that it may be functional but does not truly serve a purpose to the program. This will often lead the analyst down a path where they may spend anywhere from 10 minutes to an hour with their attention diverted from the real path. This type of predicate has the general layout of

1
2
3
4

if(math expression that always resolved)
Real work
Else
Dead code

In IDA this would graph similar to:
Graph
The dead listing would look like the following:
Dead List

These examples are rather simple, but adding complex junk code to them can often divert an analyst’s attention for a period of time. Especially if you make the junk or dead code seems more interesting then the code behind the real work!

A while back dean sent me some malware that he had been collecting off client systems. He didn’t ask me to do an analysis on them but I started doing it anyway. The first aspect of this malware was a delivery system that actually got some type of client side execution on the system.

The delivery has three aspects of it and is served via javascript.

First in the event javascript is disabled the visited page displays a link for the user to click. The title simply says “Please download”. If javascript works, it attempts to a function in MDAC by creating and ADODB stream and downloading the file. The file downloaded is then named svchosts.exe, and the shellexecute function is called with the svchosts.exe file name passed to it. On a Linux machine, an automatic save box is displayed within about 10 seconds. An example of the javascript decoded by dean can be found here. WARNING – It is set up to automatically download and launch a file called video.exe. I have copied a safe version of calc.exe to the web root so don’t get your pants in a bunch when it either launches, or attempts to downoad… If it does launch, you need to 1) stop using windows/internet explorer and 2) patch your system.

Dean was able to pull a copy of video1.exe from the server hosting this piece of malware. I took a look at it for analysis a few day’s ago. Initial tests for packing came up empty, but it would seem there is slight obfuscation in the code. There are many places where analysis fails, there are absolutely no strings, and some of the code seems to jump around to non existent addresses. I am still attempting to identify what type of encryption/packer was used on the code to optimize my disassembly. Until then I have barely any strings and only a few imports.

The few imports I do have lead me to recreate the file video1.exe. All of the imports came from Wininet which is the windows API for internet data. I set about researching a few of the api’s and pieceing together the logic and code behind video1.exe. I’ve concluded that it downloads and executes a file from another place using the functions in Wininet. Further preparing my infrastructure for penetration testing I wanted to create my own dropper for custom trojans and thinks beyond meterpreter.exe. I wanted something that would not be flagged by Anti Virus and that I can keep relatively small.

What I did was create Droplet. I finished the code last night and It’s pretty light weight. I did not encorporate any of the ftpGetFile, or Gopher functions from Wininet. I simply wanted a file dropper that would download code, copy it to a file and then execute it.

The basic flow of the program is

InternetOpen
InternetConnect
HttpOpenRequest
HttpAddRequestHeaders
HttpQueryInfo
HttpSendRequest
Either InternetReadFile or URLDownloadToFile

From this point if you are using InternetReadFile you can use the Windows API to create the file and copy the data too. I’m still working bugs out with this method.

URLDownloadToFile seems to be the better choice since it is designed to copy the data to a file instead of to a buffer. I think I might head out to the river this weekend but I’m hoping to have some time that I can play with the FTP Functions inside WinInet.

Anyway, Malware Analysis is pretty cool because you can learn how people smarter than you carry out nefarious biddings. Hopefully you learn from it and you can either apply it to your penetration testing, or for your own biddings!

-E

As many of the readers here know I’ve been on my grind lately in an effort to become really proficient in reverse engineering. Two of my associates have made comments regarding a skill gap they have in the field of reverse engineering. Everyone has a different learning curve, and everyone certainly has a different skill set. Some skill sets are more advanced than others but when you work in a team effort one skill set can often complement another. Groups from back in the day used to be pretty bad ass. Personally I was never part of a group, I guess I just never found my way into one. I really wish I had been part of one because I’d probably be bad ass right now instead of losing sleep at night in an effort to walk in the presence of some of the top guys in Austin and around the world. There are a lot of dude’s I look up to and often read their material. Indirectly, they are teaching me lots and I appreciate it!

I’ve been holding onto a book I picked up a while back from Wrox publishing titled “Professional Assembly.” The book is part of their programmer to programmer series. I originally found it two years ago when I was doing penetration testing and I figured it would help me out in my efforts to master exploitation. It really did give me a great understanding of functions, and the stack but beyond that I just could not wrap my attention around the book. I’ve finally got into the book and have been walking through many of the examples and creating my own in an effort to really nail down assembly language. I think I received a third rate education in Computer Science because assembly was never on our list of things taught, hell I don’t even think it was mentioned which is pretty sad.

How many times have you opened up a tutorial for reverse engineering or exploitation and saw something along the lines of “Basics of assembly language is assumed” or “No assembly knowledge necessary.” For many they browse over those lines and get lost somewhere in the second or third page. I’ll be honest I was one of them. I found myself referencing instructions far too often it was impeding my process. Now that I’ve read through the book and worked the examples not only do I find myself having the ability to optimize assembly (not that I need to in many cases) but I’ve also found I can breeze through disassembly in binaries a lot faster as I go after relevant code sections.

The morale of the story is don’t be like me and try to learn to reverse without learning assembly first. Get your assembly down packed, and many MANY concepts in reversing and exploitation will come together faster than you realize. As you read the book many concepts will click and you will go “ohhhhhh.”

Anyway, just wanted to mention the book, I found it awesome. The only con I found with it is the lack of exercises at the end of the chapters. I found myself googling for exercises and stealing many from colleges that offered assembly courses. Either way, I learned a lot from this book even recognizing certain code optimizations such as memcpy and strlen type functions. Check it out if you want to learn. Just make sure you do the exercises/examples.

Functions all start out with some type of prologue. Powerpc is no different. I was recently taking apart some firmware when I discovered the need to have an IDA Script take care of some function creations. Since the firmware was so large I didn’t really want to continue scrolling down and manually converting the data to code by pressing ‘c’.

In order to have Ida Python create functions automatically you can use two functions.

FindBinary
and
MakeFunction

the concept is to use FindBinary to locate the standard function prologue byte code and from there, create a function using MakeFunction. Using a python while loop you can create a short IdaPython script to expand your disassembly. I ran it on a fairly large piece of firmware and it ended up handling a lot of the disassembly that Ida’s auto analysis failed to complete due to the lack of a true entry point.

When it comes to PowerPC our prologue is going to look something like this

mflr r0 ; Save the link register to r0
stw r0, 4(rsp) ; Save r0 to register commonly used as stack pointer
stwu rsp,-16(rsp) ; Create frame
stw r31, 12(rsp); Save r31

For the particular piece of firmware I was playing with it was not saving the link register. Our prologue began with a stwu instruction. So, we use FindBinary to locate all instances of 0×9421. Although the method is not perfect, on a large scale it’s much easier to automate the creation of functions via IdaPython or IDC and have a few errors, than it is to manually create all the functions.

In terms of a prologue, you are usually left with some type of branching instruction. For most functions it just be a BLR instruction which is “Branch to Link Register”

When learning to pull apart code either on intel or other architectures it is sometimes difficult to get a grasp on where to start. Without objectives it becomes such a large project that it becomes infeasible, which then becomes forgotten or boring because of a lack of outcome. Lately I’ve been working my way through PowerPC and the manuals should be dished out for medication to those with sleeping problems. Reading a reference manual from front to back is counter productive! So what is helpful? If you have your books “Reversing Secrets of a Reverse Engineer” I’d like you to open up to appendix A-C. These sections are at the tail end of the book and I have to wonder how many people actually get to them! Yet they are filled with such great information that should be towards the front of the book. Building upon these foundations is a great way to learn, but also coding up bunk programs and pulling them apart to determine how they work is another means.

This brings me to my next point: What kind of programs should I be coding, what should they do? Again referring to the appendix of the RE secrets book you will see titles of the sections in bold. I’ve clipped most of them out and put them into a text file to create sort of an outline for myself. Now, if your just interested in learning Intel you can simply read through those appendix. But in my case I need to learn PowerPC, MIPS, ARM, Sparc architectures and the Intel didn’t help me. The overall design was good so I stuck with it. To give you an example we will first look at topics for Code Structures. Basically you want to code up a few different examples for each of these topics. Once you get the hang of it you can start playing with optimization and building upon the examples. Pulling apart the code and looking up any unknown opcodes is a great way (I’ve found) to learn!

CODE STRUCTURES:

1. Control Flow & program layout
2. Functions
3. Single Branch Conditionals
4. Two Way Conditionals
5. Mult Alternative Conditionals
6. Compound conditionals
7. Logical Operators
8. Switch Blocks
9. Loops
10. -Pre tested loops (while)
11. -Posttested loops (do while)
12. -Loop break conditions
13. -loop skip-cycle statements
14. -Loop unrolling
15. Banchless logic

Half assed brief intro into messing with firmware presentation that I have at AHA! last night. HERE