hahayes-pub-blog

[hahayes-pub-blog]

Something Awesome 1

401loc‘7Before I go into blogging about my first packer, it’s probably a good idea to describe what packers actually are to start off my something awesome project.

Packers are basically software that compresses a binary to a smaller size, similarly to how files are compressed into archives such as .zip, while keeping the binary runnable. This is done by having adding a stub of code at the start which decompresses the ‘packed’ binary before running it. Modern packers often come with protection against reverse engineering such as obfuscation and anti-debugging techniques. The reasons for such protections could vary. For example, software publishers do not want their payed software to be cracked and shared around. On the other hand, malware as malware authors do not want people to figure out how to detect/disarm their malware.

Why bother going through the effort of debugging instead of just debugging straight away? The answer is that packed binary’s opcodes have all been compressed and so cannot be decompiled, making static analysis almost impossible.

Packer 1: UPX

The challenge I will be walking through is codeengn.com’s Basic RCE L09.

When running 09.exe, we get the window:

and after pressing OK:

UPX The Ultimate Packer for eXecutables) is a free, open-source packer that is currently available at https://github.com/upx/upx. After some googling I found that UPX comes with an unpacker, so out of curiousity, I tried using it:

However, when I run it afterwards:

Something’s wrong. Let’s try manually unpack it - but how? After some more time googling and browsing through write-ups and blogs, it seems that for simple packers like UPX all we need to do is run the binary until it has been fully decompressed into memory, dump it, find the original entry point of the binary and fix the dump’s entry point and IAT (Import Address Table).

It sounded like a lot of work, but it turns out that there are many tools that are available that makes the process much easier.

Finding the Entry Point

To find the entry point, I first loaded the binary in a debugger. I chose Ollydbg since it seemed to be a popular debugger for Windows x86 programs.

The first instruction is pushad, which saves all registers and flags onto the stack. Apparently UPX, and many packers start off by saving all the registers and flags before going into the routines that do the decompressing, and then restores the registers and flags before jumping to the original entry point.

There are multiple ways to find where the registers are restored. One would be to see if there is a popad (pop all registers and flags from the stack). However this approach would not work if there are multiple uses of pushad/popad throughout the decompressing routine. Another way is to put a hardware breakpoint on the stack address where the registers are pushed to which means that when the registers are popped, it will trigger a breakpoint.

Going with the 2nd approach, we break at a popad:

Before continuing, there seems to be a few interesting things here.

0x0 and two strings are pushed onto the stack, the exact same strings that we saw on the window that appeared when running the binary.

Another thing is that there are a few lines of code at 0x0040737A to  0x00407384 that seem to accomplish nothing (it pushes 0x20 number of 0′s and then resets the esp to before pushing the 0′s). Probably a red herring to throw people off as part of the challenge.

At the end there’s a jump to 0x0040100c, which I assume is the OEP (original entry point).

Following the jump, we find that there is a call to 0x0040109f which is a call to an imported function which Ollydbg cannot identify for some reason. However stepping over it makes this window pop up again:

So I’m going to assume the imported function is most likely Window’s MessageBoxA function.

Checking Microsoft’s documentation, MessageBoxA should have 4 arguments, but only 1 argument (0x0) is pushed before the call. This is because the last 3 arguments were pushed on earlier before the jump (the 0x0 and the 2 strings). It looks like some of the code that should’ve been in the original binary was taken out and put in the packer’s stub. This type of obfuscation is fittingly called ‘stolen bytes’.

So how do we fix this? We can just copy the instructions back into the binary.

Dumping

Now that we have the binary all unpacked in memory, we can dump it as a file. Ollydbg has many plugins to do this, and I will be using OllyDumpEx.

Note how we set Entry Point to the original entry point of the binary after restoring the stolen bytes which is 0x401000.

Fixing IAT

If we try running the dumped file, it will crash. Why? This is because UPX messes with the IAT of the original binary to make it smaller in size, and when we dumped the binary from memory, the dumped PE file’s header does not have a proper Import Table Directory. To fix this I will be using the tool ScyllaDump.

We put in the proper value for the OEP, and the Virtual Address of the IAT and the IAT’s size and press Fix Dump, and select our dumped file.

Let’s try running 09_dump_SCY.exe:

Nice! It runs without any errors.

Now that it’s unpacked, if we load it into a disassembler such as IDA:

we can see that it manages to disassemble without any problems.

BONUS:

Although the original challenge was to just unpack the binary, I realised that the packed binary was actually a simple crack-me so I had a quick look at it too.

The crack-me tries to find a file called “abex.l2c” that is 0x12 bytes in size, and if found creates the message box with the winning message. To crack this, we can just patch the conditional jump after the file check to always jump to the winning message.

[hahayes-pub-blog]

Week 4 Case Study

For this week’s case study, we had to discuss ways in which we could physically secure a research facility so that information would not be leaked outside. Some suggestions were:

Airgapping - making sure there are no internet connections and all the networks are internalised in the facility

Biometric authentication + password + key card to cover the 3 methods of identification.

Physical guard to prevent people from brute forcing their way into the facility.

Ensuring that all electronics are removed from personnel before entering the facility.

[hahayes-pub-blog]

Week 3 Case Study

With over 100,000 flights on average every day, security in airports and on airplanes is crucial to ensure the safety of millions of people. In this week’s case study, we discussed ways in which we could reduce the likelihood of mid-flight airplane incidents.

My group came up with 3 suggestions:

Each pilot has a registered fingerprint and a password for access to the cockpit. This removes a single point of failure by making sure that a pilot cannot be locked out of the cockpit by the other pilot.

The ground air traffic control should be able to take control of the plane in case of an emergency (e.g. pilots lose consciousness)

Periodic checks between air control and pilots to ensure that there are no problems.

Among the other suggestions from the class, some notable ones included:

Reduce the need for pilots to leave the cockpit (e.g. build a toilet accessible from the cockpit).

Medical and psychological screenings of the pilots.

Most of our suggestions were not perfect (although it is near impossible make things perfectly secure) and some were hard to implement due to the costs and lack of laws involved. However I believe that many of these would contribute to a safer flying experience.

[hahayes-pub-blog]

Woops I’m Late

Due to personal reasons I couldn’t attend the first 2 week’s worth of lectures, so I did not find out about blogging until my first analysis session. I will be blogging about things starting from week 3′s material and security things in general from now.

Better late than never!

[hahayes-pub-blog]

Something Awesome Proposals

Idea

I will learn about different packers (e.g. UPX, Armadillo, ASProtect) and I will create a write-up on how each one works, and how to unpack them.

With each packer that I study, I will also do an unpack-me for that packer and include a write-up for it as well.

Originally I was going to pick one packer and try to write a tool to unpack binaries protected by the packer. However I changed my idea as that narrowed my scope too much to a single packer, and I want to learn about a variety of packers.

Planning

For each iteration I will:

Decide on a packer to study and a respective unpack-me to solve.

Learn about the packer and try to solve the unpack-me.

Create a write-up on what I have learnt and a write-up for the unpack-me.

Extension

Some of the more modern packers such as VMProtect and Themida have virtualisation as an additional method of protection. As an extension I could also try learn about how that works and how to devirtualise (unvirtualise?) binaries.

Criteria

FL: 0 packers studied

PS: 1 packer studied

CD: 2 packers studied

DN: 3 packers studied

HD: 3 packers studied + write-up about virtualisation