Category Archives: elf

Using Detect It Easy to… detect it easy

Posted on by

I love Detect It Easy. It’s my go-to tool when it comes to triaging malicious samples and it continuously exceeds my expectations… Except the times when I forget to use it EARLY in my triage process !!!

A random person from the internet contacted me today asking to help them with unpacking of some unknown linux malware. They thought it might have been protected by SHC, and since they have read my post about it, they assumed I can help…

Now, I have dealt with many *nix malware samples in the past, but I would lie saying that they make me comfortable. I am still primarily Windows-centric malware analyst and anytime I have to look at anything else (meaning: non-Windowsish) I… panic 🙂 Cuz I know that I am always behind, that it won’t stop me, and that I will want to prove to myself that ‘I still can crack the unknown’, despite it being very uncomfortable waters for me…

So…

I opened this sample in IDA, I also opened the sample in edb. Kinda in parallel. I could immediately see it’s protected, so after some back and forth I managed to oversee the unpacking, and then dump the memory regions showing all the unprotected code and data. But. I felt really strongly that it was not enough. It felt “dirty”. That’s because I suspected it may be some well-known protector at work, and me not even knowing about it had a very dramatic implication – I just suck at ELF reversing!

After the fruitful dynamic analysis with edb, my next tool of choice was upx –fileinfo <file>. It’s not a command line argument supported on Windows, but it is on Linux. It’s awesome when it works f.ex. the compressed login program I talk about later gives the following output when treated as input to upx –fileinfo <file>:

./login [amd64-linux.elf, linux/amd64]
23204 bytes, compressed by UPX 13, method 2, level 8, filter 0x49/0x02

Yup. The UPX tool tries to tell you if the file is compressed with … well.. UPX, plus all the gore technical compression type details.

The result of running –fileinfo over our sample is this tho:

upx: sample: NotPackedException: not packed by UPX

Hmm but it does really look quite familiar. Yes, I have seen UPXed ELF files before: not enough to feel comfy recognizing them all on the spot, but still enough to kinda get a ‘feel’ that ‘they might have been UPXed’ about them.

Hard to explain. When you know, you just know…

So, then I decided to compress a random ELF binary to see how the output file looks like, for science. I compressed /bin/login and there was no surprises… The way the compressed file looked in a binary editor resembled the way sample I was dealing with was looking like… very closely… (and yes, that’s the compressed login sample I referred to above).

So…

At this stage I knew that while UPX tool didn’t recognize it, it was most likely a modified UPXed sample…

Before we continue, a digression: there is a fantastic blog post written by Akamai researchers about modified UPX and ‘unpackable’ ELF binaries – sadly, I only found it during my ‘lessons learned’ stage. If you deal with ELF file analysis, I highly recommend reading that post asap.

Back to my mundane analysis — this is when DetectItEasy enters the scene.

Yes, I was wrong. I should have used it from the start, as I usually do for all the PE files, but I fooled myself thinking that ‘I probably don’t need it’ as ELF files are really not that popular and I can crack any of them in no time. Stupid, stupid me.

Loading the sample into DetectItEasy produced this result immediately:

You seeing what I see?

DetecftItEasy not only recognizes the protector (UPX), but also that it is modified, and… then… lo and behold, it gives us a hint WHAT has been modified. That ‘45564F4C’ string included in a ‘Modified’ packer section refers to the string inside the modified UPXed sample where standard UPX’s signature ‘UPX!’ has been replaced with ‘45564F4C’. Once you see it, the only thing you need to do is to edit the sample and replace all occurrences of ‘45564F4C’ with ‘UPX!’, and then save it as <patched_sample>. Then you just run ‘upx-d <patched_sample>‘ and if lucky, you will get a properly unpacked sample! If you read the Akamai post you know it won’t be that easy all the time, but Linux world is way behind Windows when it comes to code protection and we can still win many of these reversing battles pretty easily.

I have sent two versions of the findings to the ransom internet person. One was memory dumps of decompressed (and decrypted) malware taken directly from memory of the process, and then the fully unpacked version of the malware. I probably spent 45 minutes on the first part, and 5 minutes on the second. It’s a very humbling experience, because it confirmed that I truly suck at ELF file reversing!

Decrypting SHell Compiled (SHC) ELF files

Posted on by

In its recent blog post AhnLab described a campaign that relies on SHell Compiled (SHC) ELF files. I wanted to see if I can replicate their reverse engineering work and decrypt actual shell commands they had shared in their post. This turned out to be a bit more complicated than I thought, hence this post aiming at making it a bit easier for you.

Before I go into nitty-gritty details – when I try to crack new stuff I usually look for an existing body of work first. A really quick google search helped me to discover a tool called UnSHC that helps to decrypt SHC ELF files in a generic way. And I must digress here for a moment – it’s an amazing hack of a tool really – a shell script engaging lots of CLI tools trying to discover the inner working of the encryption via automated code analysis, find the decryption routine and then actually produce the decrypted script as an output. While it didn’t work for me, I feel kudos to the author are in order. Studying the inner working of UnShc was a pure pleasure. Thumbs up!

Coming back to the AhnLab post. I was intrigued by the Alleged RC4 encryption used by SHC and thought — okay, I just need to load it into a debugger, step through it, maybe instrument it here and there, and then look at the decrypted buffers. So, I did that, then I realized that despite walking through the code, I could only decrypt part of the encrypted data. I could decrypt the ‘internal’ strings of SHC, but not the final shell code. I did correctly guess where the encrypted shell script is, I did instrument the debugger to go there, but while trying to decrypt the encrypted blob… I was getting another binary blob that looked like garbage.

Hmm something was really fishy there.

After staring at the code of the sample in IDA, I realized there is a routine where the executable is trying to retrieve a value of a particular environment variable. After studying it a bit more, I realized that the SHC author engaged a clever trick to make reversers’ life a bit harder. When the program is executed a tuple of an environment variable and its value derived from a process ID, number of arguments (argc), the actual routine itself (probably to detect ‘int 3’ opcodes in it, if debugged) are added to the process environment. The program then calls execve on its own file. This makes the program restart with the same pid (the ELF image is overwritten in memory and restarted). And this finally leads to the execution of the aforementioned routine again, and this time the required tuple of environment variable and its value are present. Only then the decryption of the actual embedded shell script is possible. From a debugging/instrumenting perspective it’s unpleasant, so I had to quickly devise a way to bypass it.

It turned out that it’s easier than expected.

The solution: the very same ‘environment-operating’ routine can be called twice. The first time it will look for the environment variable, and it won’t find it there, so it will add it. The second time we execute it via instrumentation, the environment variable will be there. So, it will read the value of the environment variable, set appropriate inner variables, and with that in place we can decrypt the main shell script within a single process instance.

Let’s have a look at the example: 256ab7aa7b94c47ae6ad6ca8ebad7e2734ebaa21542934604eb7230143137342.

We load it into edb first, and then make a breakpoint on 0x400FDD — this is prior to executing aforementioned ‘environment variable’ tinkering procedure. Then we run the program (F9). We should get a break here:

We step over it F8, F8 and now we end up in 0x400FE5.

We then re-run the code above to make it look like we execute it as if we were in the new instance of the process. So. we go back to 0x400FDD and set the RIP to ‘here’ — right click and ‘Set RIP to this instruction’, or CTRL+*. We do F8, F8. And we are set.

All we have to do now is F8 many times until we reach 0x4011A7, at this stage point your dump window to the location rdi points to. Then execute decryption routine and you will see the decrypted shell script in the data dump window: