Chris Gerling

Hey guys, thanks for watching!  I pretty much detailed everything out in the show notes, but if there are any other questions feel free to contact me!

Hey guys,

Darren was nice enough to include the full notes I sent to him in the actual posting on Rev3, but here’s a copy in case you wander over this way.
If you’re ever in a position where you have to perform forensic imaging duties on a machine, this segment may be useful to you!  The overall goal is to be able to load a forensic .dd image into an environment where you can interact at the user level with it, and perform some initial analysis that may help to paint the overall picture of what happened later on.

Requirements:  A Helix live CD (any of their versions should work, but I recommend 2.0)
Any machine that has an OS which is compatible with VMware
Either a removable drive, or enough free space on a network share in order to push the .dd image out to it.
Live View
Having VMware Workstation is a plus, but if not, Live View will automatically download and install VMware Server and the DiskMount utility for you, if you so choose.

Helix is a forensic Live CD with loads of tools.  We’re focused on just the image acquisition part today.  For the most part, the default options are fine, just specify where you are outputting the .dd image to and you’re on your way!

Install Live View and make sure you either let it install the necessary components, or already have VMware installed ahead of time.  It tends to not like the absolute newest version of VMware Server, so ideally use the older one that it suggests.  Open the .dd image with Live View, and either Start it directly or Generate the config files.  Should you encounter problems with Starting it directly, use the generate config files option and then manually open the .vmx/.vmdk file from within VMware itself.  Don’t forget to check the settings on the new VM and make sure the operating system is set correctly, the program does not always autodetect it.

In layman’s terms, this takes the forensic image and converts it to a virtual machine format, so you can interact with it as if you were the user.  It does not write anything to the .dd image at all, but obviously I suggest using this with a COPY of the original .dd image you make of the suspect machine.

Have fun!

I must apologize again for the lack of show notes lately.  I didn’t make the time I should’ve.

Anyway, getting down to business:

I focused in on a couple of things during this series, as trying to compact the entirety of the OSI model and TCP/IP/wireshark would just be impossible, and I would probably have to charge you money.

I wanted to really focus on allowing people to understand the foundation of how the internet is kind of built, without having to memorize all sorts of terms.  At the same time, I wanted to delve a little deeper into the TCP/IP portions of a packet and really allow people to understand what a packet is and does in terms of communication.  Finally, I wanted to show them a tool that pretty much every seasoned IT professional has used to look at packets and perform analysis of any sort.

For 406/408, I highly reccommend just reading wikipedia articles and RFC’s if you are really interested in learning more about this.  I also suggest finding a decent TCP/IP book.  I don’t want to be an advertising link whore so I won’t be spewing out an amazon associate link to a random IT book here.

In 409, I used wireshark’s own manual and wiki, which is just stellar.  Here is a link to their documentation page:  http://www.wireshark.org/docs/.  Trust me, there are far more advanced things you can do with their filters/expressions.

If you have any specific requests, please contact me either via feedback@hak5.org, this site, or you can also IM me through my digsby widget on the front page of the site if you allow it.

Hey guys,

Thanks for watching part 2 of the reverse engineering series.  HUGE thanks to Chris Gates of LSO as well as Pedro D’Aquino whose solution I drew heavily on in order to create a logical walkthrough of how to solve the Crackme.

Crackmes are pieces of software that allow people to gain practical experience in reverse engineering without having to resort to less legal means of exercising their skills.  There are numerous sites out there that offer them.

Chris Gates, a friend of mine, started releasing crackmes as contests awhile back, and I covered one of them on 3×07.  The basic overview of this particular executable is that there are 4 buttons that appear in a GUI when the program is launched.  The top 3 buttons play tones, and the bottom button plays 3 tones that are supposed to match the top 3 tones.  Initially, they do not match, so it is up to you to figure out how to modify that executable in order for it to match.

We use Lutz Roeder’s .NET Reflector to open up the .exe initially, as it looks like managed code.  From there, after a little looking around, it’s apparent that something is amiss with this code, and that it’s not displaying like it should.  The problem is that the real .exe is compressed within this using something called NETZ.  In the show we go through how to unpack this .exe.  Here is the full python script:

#import zlib library
import zlib
#open the file which contains the compressed executable
fZip = open(“zipped.zip, “rb”) #we use ‘b’ as it is a binary file
#create the file in which we will store the unpacked exe
fUnzip = open(“Crackme03Original.exe”, “wb”)
#read the contents of the zipped file
compressedData = fZip.read()
#..and unzip it
uncompressedData = zlib.decompress(CompressedData)
#Write it to the file and we’re done!
fUnzip.write(uncompressedData)
fZip.close()
fUnzip.close()
exit()

After this, we open up the new .exe in .NET Reflector and find that the main windows form is called Form1, and Play_Click gives us a big tell that we’re closing in what we have to modify.  The program is checking the tones through comparision of hardcoded values of an array against hardcoded constants.  If you look in the dropdown menu under the toolbar there should be an IL selection, which shows the way the array is initialized.

Hovering the mouse over the instruction should give you the bytecodes you need.  From there, it’s as simple as converting hex and replacing values as shown in the segment.

For the full solution, please head over to LSO and to Pedro’s solution.  All the credit goes to him as he has an extremely good writeup that is very easy to follow.

See you next time!

PS:  cowboy informed me that there is a plugin for .NET Reflector called ReflixII that will help patch the .exe a little easier than manual hex editing.

Hey guys.  Hope ya liked the Episode.  I was trying not to go too fine grain, while also covering the basics.  I think it’s important to note that, with most of the really technical segments, unless it’s something being built (either hardware or software), it’s hard to go in depth enough to feel satisfied unless it was a 30 minute segment.  I strongly encourage you guys to use google to find more information, and to do research.  You won’t learn enough to be too dangerous without fully understanding the theory yourself.  Thanks for watching!!!!

In part 1 of Reverse Engineering I go over some basic theory and demo some tools associated with the Crackme scene of reverse engineering.  This is not hardcore reverse engineering that will get you on the RELOADED team, but it’s a nice peek into things.

Tools of the trade (there are MANY MANY more):

WINDASM (W32DASM):  I cannot link you to anything official as it’s no longer obtainable from the original vendor, so you’ll have to google for it.  Be wary of any copy you download, virus scan it, and run it in a VM or on an isolated machine first.  No guarantees.

IDA Pro:  Industry standard.  Extremely useful for almost any kind of file.  We demo the older free version for lack of $500.
OllyDbg:  Debugger similar to IDA Pro
PEiD:  Detects packers, cryptors, and compilers.
.NET Reflector:  Typically used for disassembling .NET applications.

Big Endian is akin to SONAR being sent as SON AR
Little Endian is akin to SONAR being sent as AR SON

Registers = Variables
32 bit = e
16 bit = different size, ax, bx, cx, dx, di, si, sp, bp
8 bit:  al, ah, bl, bh, cl, ch, dl, dh.  l means lower 8 bits of 16 bit reg, h means higher
Flags = boolean values, 1 or 0.  Zero flag can get 0 or non zero (1) values.

The idea is to debug and disassemble to find out exactly how a program works, thereby enabling you to modify characteristics of that program to suit your needs.

In Part 2 we finish these notes and actually show you how to navigate through code.