07 Nov

About FLARE 2016 contest

This year's FLARE reverse engineering contest is over. I managed to finish it on time - but I really had to force myself to keep going several times. This graph tells it all:
flare2016-progress

You can get all the challenges from the official site (password: flare) and there are already a number of writeups all over the web.

I'm not going to reinvent the wheel, so here's just my take on few of the challenges. smile

#1 - Challenge1

Time spent: 9 mins. Not much to say, it's designed to be a warmup.. Custom Base64, that's it.

#2 - DudeLocker

Time spent: 1h 20mins. The buzzword for year 2016 is "ransomware". Every self-respecting reversing challenge has to have one. It was fun and kinda easy for me - but in my opinion it was too hard for level 2.

#3 - unknown

Time spent: 7h 45mins. Since challenge starts at 3AM in Europe, one needs to get some sleep..

As for the task - reverser has to figure out the correct filename from PDB entry and then the challenge becomes solvable. No, it doesn't have anything to do with actual reversing, just a random crap obstacle thrown into your way.

#4 - flareon2016challenge

Time spent: 1h 20mins. "Play me a song, have me play along.." Given a DLL, one must figure out the correct order in which to call exported functions to play a song. Original idea, kinda refreshing.. smile

#5 - smokestack

Time spent: 1h 45mins. And, of course, every challenge has to have custom Virtual Machine. This one was just the right difficulty and offering several ways to break it. Nice.

#6 - khaki

Time spent: 2h 20mins. Obfuscated python bytecode. Considering that it was my first time directly patching python bytecode, I enjoyed it a lot. In my opinion, one of the most interesting of challenges this year.

Fun fact - opcode for nop in Python is 0x09.

#7 - hashes

Time spent: 5days 2h 22mins. This is where I got really annoyed and stopped playing.

Not only they throw in a Linux challenge into the mix, they use Go programming language and compile binary in a way that requires libgo.so.7 - which is not available on certain Linux distributions (like Debian).

So, one has to figure out which bloody Linux distribution has support for it, install that in a Virtual Machine, then find a way to install Go language, then fight with SELinux - and all that just to be able to debug the binary provided by challenge. That's just frigging stupid. How hard it is to tell the OS requirements before the challenge starts? angry

Once I got over my enrage and disgust, it was actually pretty easy. My "solution" generated ~60GB of data files - just because I let my hash generation code run while still analyzing the challenge code.. wink

#8 - CHIMERA

Time spent: 2h 10mins. The actual check was hidden in the DOS stub. There were some nice hints and neat and clean code, I loved everything about this challenge! smile

The fact that I got to boot up my Windows XP virtual machine and use debug.exe - that was just an icing on the cake.

#9 - GUI

Time spent: 1h 35mins. Mandatory .NET assembly thrown in the mix. Apparently FLARE team was running out of ideas, so they just used ConfuserEx. Three times.

To solve it, all you need to know is that DNSpy exists. I have no idea why this challenge was put as #9, difficulty wise it was more appropriate as #3..#5.

#10 - flava

Time spent: 35.5 days. Difficulty: 9, fun factor: 0.

This was just frigging stupid. I know, it's a final challenge. But it required so much of a very specialized knowledge, that it's insane.

First you need to get through 3 layers of JavaScript obfuscation. Hard but doable. Then you'll arrive at some serious crypto. Normal person can't know this is bugged Diffie-Hellman key exchange which was used by Angler exploit kit and got broken by Kaspersky Labs. So, if you're not a crypto wizard or you don't focus on exploit kit research, you're screwed.

Once you figure out this crap, you still have to get through 3 layers of Flash. First SWF is easy but second one is obfuscated and solving involves a lot of guesswork. You're supposed to guess that RC4 key is reused and decrypting other binary data with the same key stream will get you the required values to get to 3rd layer. How you're supposed to figure that one out? Well, just "do some random stuff and hope it works™".

The final layer has slightly obfuscated ActionScript code but nothing JPEXS can't handle. It is there just to generate the answer.

Conclusion

If I compare this year's FLARE with LabyREnth, LabyREnth wins hands down. In my opinion LabyREnth's Windows track was much more fun and tasks were much more reverse engineering related. But that's just my opinion..

I wish to express my deepest gratitude to fellow reversers who kept me going when I got really angry and upset: Extreme Coders, fasya and Levis. Your hints were invaluable, thank you so much!

16 May

Quickpost: application reversing becoming legal in USA?

Last Friday authors of Dotfuscator made quite an interesting blogpost, claiming that reverse engineering applications in USA is becoming a legal means for acquiring intellectual property, thanks to the Defend Trade Secrets Act of 2016.

I am not a lawyer, and such statements coming from authors of obfuscator should be taken with a grain of salt - but it's an interesting read nevertheless. What's your take on that?

29 Apr

How to learn Reverse Engineering

Every other days or two a new guy appears at Tuts4You asking "I want to learn Reverse Engineering, where do I start?".

Hmmm...

There are lots of suggestions, eg. in this Reddit thread. One of the most common recommendation is to with Lena151's tutorials. And there's a good reason for that - these tutorials give a good overview of most common tasks, most common tools and provide "instant gratification". But do they actually teach you Reverse Engineering? I don't think so.

Why Lena151's tutorials are bad

Apparently I'm not the only one who thinks so:

I have been thinking about why this happens. Thinking back to myself, I started learning reverse engineering by reading the Lena151 tutorials. I thought they were awesome until Daeken told me that was an awful approach to learn reverse engineering.

At first I didn’t understand why they were so bad. After all, Lena’s tutorials had taught me how to crack my first software.

And that's exactly the problem. You managed to crack your first software. Instant gratification! But what did you actually learn? Run some common tools, find the "bad boy jump" and patch it? Wow! You must be so l33t!

In reality, these tutorials have produced entire generation of wanna-be-crackers who can only use ready-made tools, but are actually unable to think for themselves. For every problem they need a video tutorial. For every small obstacle they create a new topic asking for help.

And that's only half of the problem.

Video tutorials made by beginners are even worse

Albert Einstein once said:

The more I learn, the more I realize how much I don't know.

Beginners who watched Lena151's series don't realize that. They cracked their first program and they consider themselves to be reversers. And what's even worse, they try to spread their "knowledge" by making an incredible amount of incredibly crappy video "tutorials" to be watched by next generation of wannabes.

I've actually watched a 15 minute movie titled "How to unpack CryptoObfuscator". You know how? You drag-and-drop the file on de4dot. Yes, that simple. Yes, someone made 15 minute movie to teach you that.

So, what's the alternative?

ReverseWithMe blog suggests to learn:

  1. x86 assembly (electronics and wires in the car analogy)
  2. How operating systems work and how they manage memory (the engine of the car)
  3. The compiling process from C-code to assembly (this is equivalent to knowing how a car-fabric is assembling a car)
  4. The life of a binary (equivalent to everything that happens in the car from the key-switch to the off-switch)

I don't think this is the correct approach either.

It's like learning a foreign language by reading a dictionary. Start with an "a", and once you finish with "z", you'll know all the words. Maybe. But you won't be able to make a proper sentence, let alone speak or understand a native speaker.

To put it into context: I've been reversing .NET executables for 10 years now. I've written unpackers for pretty much every .NET protection there is. And yet I still don't know IL assembly "by heart". Why? Because I don't need to. What's the mnemonic for "branch-if-equal"? Is it be, beq or bre? Does it pop one or two arguments from stack? I don't know. If I'll ever need that, the answer is one Google search away.

Yes, to be a great reverser, you will need to master most of those items. But you don't need to know all that at the start of your journey.

Gimme a solution, goddamit!

Well, start with Lena151's tutorials. Yes, I said they are not good, but that's the best there is. And if you follow few extra advices, you'll do just fine:

  • Learn to think for yourself. That's the most important part. Don't just blindly follow tutorials, try to understand why it works and how it works.
  • Learn to search. Most questions have already been answered, you just need to find the answer. Make sure Google is your friend!
  • Learn your tools. You don't need to know every single option and feature of them. Most people use ~10% of all Microsoft Excel features. Power Users use around 20%. It's the same with RE tools. If you've mastered 10% of Olly or IDA features, you're good to go.
  • And last but not least - have fun! Nothing kills your productivity faster than boredom. If the problem is too hard, let it go, try something else and come back to it later.