Category Archives: Hackme/crackme

The art of cutting corners

Posted on by

I love ROI-driven solutions and this post is about one of them. My personal cybersecurity consulting practice exposed me to many different types of ‘IT security’ jobs over last 13 years and today I will describe one of them…

Nearly a decade ago one of my clients contacted me saying that they got a USB key that belonged to their client, and their client was interested in regaining the access to the device’s content after they forgot the password.

Hmm interesting…

This was not your random USB key, but a removable device that was specifically designed to encrypt its data by default. As an input, I got a forensic ‘image’ of the USB key, plus some basic info about its vendor, and that was it – so I quickly googled around, and immediately realized the company that produced it was out business for a while…

Before I could even begin I was shot down.

To access the content of the device one needed to run their software (that was luckily present on the key in an unencrypted form), provide the password, and then the actual content of the key would be decrypted and mounted as a separate Windows device. I may not be remembering everything as it was, but the bottom line was that I got an image of an encrypted USB key and had to find a way to crack its password.

The software handling the decryption process was a mess. It was on the complexity level of today’s Rust, Go, Nim binaries – written in a language that was not very commonly used, very high-level, lots of dependencies and hard to analyze statically – definitely no dedicated tools to support analysis (I know I am vague, but it was long time ago – it could have been Visual FoxPro or something like this, I really don’t remember!).

After a few hours of static analysis in IDA I threw a towel and decided to take a different approach. I was hoping that a person that was using the encrypted key was using some simple password that is easy to remember.

So, I build a dictionary of popular English words, then ran that weird decryption software, and finally wrote a very rudimentary AutoIt script that would fetch a word from a dictionary text file (dictionary) one by one, save it to a log file in each iteration, then push it to the UI control of that software that was handling the password input, then send a key that would simulate someone pressing an ENTER key…

Luckily, the software didn’t have any anti-brute-force mechanisms built-in so I just let it ran over night. To my surprise, next morning I discovered the password was cracked!

It was a simple 5- or 6- character long English word, if I remember correctly and once I found out I was immediately ecstatic! I quickly relayed the message to my client, they did so to theirs, and we all ended up being happier and richer that day…

Is there a lesson there for us?

YES!

Sometimes stupid solutions work. You don’t need to understand everything. It’s good to be driven by ROI principles. The art of ‘hacking’ is elusive.

Heaven’s gate and a chameleon code (x86/64)

Posted on by

A so-called heaven’s gate is not only a built-in feature of a 64-bit Windows, but also a neat reversing trick. It can be used (and is) by malware authors to temporarily switch the code execution between 32- (WOW64) and 64-bit long mode. While operating in a 64-bit long mode it executes the 64-bit instructions and this can be used to execute some funny stuff before returning to 32-bit code (f.ex. can be used to detect a debugger).

The trick is very old, many blogs describe how to mix 32- and 64-bit code execution pipelines while using it and that’s why it is a part of the topic I am going to talk about today.

A few years back I was looking at a sample that used the heaven’s gate trick, but apart from this, it also contained another trick – a chameleon code – a stream of bytes that could be executed as both 32- and 64-bit code, depending on the context. I found it to be quite cool and took a mental note of that malware family.

I recently came across a different sample from the same family malware and since its analysis reminded me about that supercool trick, I thought it would be nice to write a post about it.

The sample hash is E4AB5596CB8FBE932670A6A5420E7AB9 (note it is old, from 2013).

Note: Mind you that before it reaches the heaven’s gate/chameleon code it will try to stop you by using a couple of known and lesser-known anti-reversing tricks (there is a number of them, and they are quite creative; I won’t describe it in detail not to spoil the fun in case you want to take a stab at the sample yourself).

The 32-bit code right before jumping far to 64-bit code:

heavensgate1Immediately after the far jump we land in 64-bit code.

heavensgate2Note the offsets of instructions on both screenshots.

Btw. while I am not the biggest fan of windbg for day to day work, its ability to reverse such chameleon code ‘on the fly’ comes really handy.

After some more jumps and calls the code eventually ends in these 2 places (left 32-bit, right 64-bit – 2 different VMs):

heavensgate3We can compare the opcodes and their meanings side by side:

heavensgate4They both execute in their respective modes (32- and 64-).

The inability to distinguish between code and data is a well known fact. Ability to code a program that is binary level-identical and executes flawlessly on two different architectures is a completely different animal.

For what it’s worth – it was written in fasm.