Tuesday, August 30, 2016

FLARE On 2015 - Challenge 9


This is the 9th challenge from FireEye's 2015 "FLARE On" challenge (http://flare-on.com/)


From hearing what other people had written about this one, it sounded like this was where things start getting pretty difficult.

Challenge 9 was somewhat of a repeat of Challenge 1 & 2, however this one had a number of tricky anti-analysis tricks thrown in.

It starts out by letting you know it's evolved from the first challenge:

Taking a look at the strings, it looks like we may be able to trace back from the spot in the code that uses "You are success" again...

... but after some basic debugging & breakpoint-setting, it becomes clear we don't actually hit that section of the code. Something funny's going on... :-/

(As it turns out, that entire subroutine is a decoy and is not used at all in the validation process...)

Let's break out IDA and take a look:

Almost immediately after we start stepping through the code, we hit some early trickery designed to throw off static analysis by jumping to the middle of an instruction:

This is pretty standard stuff, and since we're going through it with our debugger, it's no problem -- we can just have IDA re-disassemble the instruction, this time starting from the new EIP address.

As we keep going, it becomes clear they're also doing sneaky things by manually crafting/modifying stack frames (as opposed to simple call/return patterns).

After determining things were going to be not simple, I decided to do a execution trace, like so:

This unfortunately ran into issues related to my IDA version being the free version :-(

But it provided enough information to be useful -- it's now clear that they're crafting/assembling tables of some kind based off of static hex values, with lots of anti-analysis crap stuck in between:

Grabbing those tables out of memory and stepping through the program one more time let's us see that the tables are (a) used as XOR key values, (b) used as lookup values, (c) as ROR values, and (d) as the final expected values to validate the email address.

Reversing the logic gives us the final answer:


No comments:

Post a Comment