CHALLENGE MATERIALS:

filename:		you_are_very_good_at_this		DOWNLOAD
md5		51105503d77689facbf2b8a8b4fd040b
size		4 k (4,608 bytes)
type		Win32 Console App
Original FLARE Author		Nick Harbour
tool:		OllyDbg 2.01 / Debugger		Visit Website
tool:		Your favorite C/C++ compiler

SUMMARY:
The original console app from challenge #1 and #2 is back with a vengeance. When you finish, you'll be surprised the code fits within this 5 k executable!

FIRST LAUNCH:
A hex dump of the first few bytes of the supplied file reveals that it is a Windows PE executable image. Renaming to EXE and launching from the command line begins the challenge with a taunting password prompt. Typing the wrong password results in the familiar "You are failure" message:



STATIC ANALYSIS? -- DON'T WASTE YOUR TIME:
Lets see what IDA can tell us about the executable. Right away, IDA gives us "The imports segment seems to be destroyed..." warning. This has never stopped us before, so we continue to the "Exports" tab to follow the entry point labeled "start". The entry point begins with a "JMP start_0" instruction. Following the target, we are taken to a chunk of code with the "sp-analysis failed" error in red a few lines down. The code makes room for a DWORD on the stack, and sets it to 401091 in a non-straightforward way, just before executing a RET instruction. Because RET is designed to pop the value off at ESP and jump to it, we jump to address 401091. Right off the bat, IDA is confused, probably because the only path into this block was a JMP, not a CALL, so the RET has confused it. This is one of the many anti-disassembly tricks you'll see in this challenge.



If you scroll to the top of the disassembly window, you'll notice IDA has found a familiar-looking function that invokes GetStdHandle() twice, then WriteFile(), and finally ReadFile(). Following the call to ReadFile() is a call to what would seem to be the validation function. Upon return from the validation function are the branches to output either the success or failure messages. This entire function is a decoy. One clue is the password prompt only displays "I have evolved since the first challenge." without the rest. The function is not referenced by the program during an actual run and the program crashes after the validation function is called if you force the debugger to run the code by manually setting EIP. The validation function self-destructs the remainder of calling function by writing some invalid opcodes where the return address is pointing that cause an an "Illegal Instruction" exception when the validation function returns. While it may have been used during development to get the opcodes needed to plug into different parts of the program (we'll get to that in a minute), the author cleverly left it in to send you down the wrong path.

DEBUGGING THE APP:
IDA isn't "the best tool for the job" for this challenge. You'll soon see why manually fixing up the program in IDA each time an anti-disassembly technique is reached would be a lost cause. More mileage can be made in the debugger. Fire up the program in OllyDbg and you should find yourself at the entry point 401C48:


Since this program intentionally avoids making proper use of CALL/RET pair as one of its anti-disassembly techniques, you will almost exclusively be using the step-into (F7 key) feature to the step through the code. Stepping-over a CALL that never returns is like running the app from its current position.

Step past the initial JMP and down to the RET in the next block of code. This unconventional use of RET is anti-disassembly trick #1. It is only used to transfer control to 401091, but had the author used a "JMP 401091", static analysis tools like IDA would have marked the target address as the beginning of code and would traverse it automatically. Because static disassemblers don't emulate code, but rather they focus mostly on paths made through code via the branch control instructions like JMP, Jxx, matching CALL/RET, LOOP and the like, they can't handle this construct. This causes the majority of the program to be marked as data and not code.

Since the CALL instruction is designed to push onto the stack the address of the next instruction prior to jumping to the target address, the RET within the called block was designed to pop the return address pointed at by ESP into EIP to resume execution just past the CALL. In this case, the code manually builds the jump target address on the stack so it is the first to be pulled off and jumped to when the RET is executed, just like an unconditional jump.



Stepping to 401091 appears to show us that we are executing raw data, rather than code instructions. The processor is still executing instructions whether or not OllyDbg is confused as to whether we are in a code or data block. OllyDbg thinks this is data because it scans the entry points automatically during module load just like IDA does, and like IDA it didn't find a path into the code currently being executed. Because OllyDbg thinks this is data, it uses a common assembler DB (Define Byte) syntax to display the raw hex bytes.



We just need to override the default analysis by forcing OllyDbg to "un-analyze" it. Start a multi-line selection from 401091 down to the RETN instruction at 4010AA to contain all the "DB" byte lines. Right-click the selection and choose "Analysis" -> "Remove analysis from selection" (or press CTRL-Bkspc). You will now see the data turn into assembly instructions based from the selection's start. Always "un-analyze" code based from the current EIP to ensure the disassembler's instruction interpretation is in sync. If you make a mistake, its not a huge deal as the processor will still execute the proper instructions and OllyDbg automatically re-synchronizes its disassembler display at each step (more on this below). As you step through instructions in this challenge, you will frequently need to inform OllyDbg to interpret the bytes as code rather than data, so perform this step as often as necessary.



Considering that "XOR EAX,EAX" executing prior to the JE instruction essentially hardcodes the processor flags necessary to ensure the jump is always taken and is thus semantically equivalent to a JMP instruction. This is anti-disassembly trick #2. When disassemblers encounter conditional jump instructions, they will analyze both the jump-taken path and the jump-not-taken path (the next instruction). Code employing this technique cause the disassembler to analyze code paths that have no chance in executing, such as the decoy function described above. The reverse engineer can also waste time deciphering the purpose for the condition of the bogus branch, adding to the overall complexity of the program. These false branches often contain invalid instructions, or instructions that don't make any sense in the current context such as privileges instructions in a user-mode program. A variation on this trick is a CALL that is never returned to. Because the purpose of a CALL implies it will be returned-to, the code path that follows will be analyzed automatically by the disassembler (and human) leading to the same problems as those caused by the unconditional jumps made to look conditional.



Just when we've determined the JE instruction at 401093 is really an unconditional jump, this program wastes no time in employing another trick. Notice that the target address of 401096 isn't listed anywhere in the address column, as its value falls between those addresses shown. The program appears to be jumping in the middle of another instruction based on how the disassembly window has aligned with the current flow of the opcode bytes, but the processor only cares that the bytes at the target address represent a valid instruction. In a normal program, jumping into the middle of opcode bytes meant for other instructions will likely lead to a crash because the processor will misinterpret the instruction and every instructions that follows. For a specially crafted program like this, the instructions being jumped into are actually valid, but are out of sync with the disassembler display as the disassembler can only interpret any given opcode bytes as belonging to one instruction at a time. If the disassembler has been tricked into displaying invalid instructions at a particular address and then the program later jumps between them, those instructions will automatically turn into completely different and valid instructions when the disassembler re-synchronizes with the current EIP. You'll know OllyDbg re-synchronizes when the current disassembly instruction jumps to the top of the window for seemingly no other reason. As a result, the previously executing instructions disappear and the new ones appear. As long as the program doesn't generate an exception, the processor will happily execute any instructions wherever you point it to. For obvious reasons, this adds to complexity and confusion of a program. This is anti-disassembly trick #3.

OllyDbg normally draws a nice line with a slight curve to show the target of a branching instruction, but this target's line looks like it was cut off (see red arrow above). This is because a jump is targeting bytes currently occupied by other instructions. Step past the JE instruction and you'll see the disassembly window automatically re-synchronize to reflect the current EIP instruction at a "MOV EDX,EAX" which was not there before. The opcodes have not changed, only the interpretation has. The CALL instruction at 401095 is made up of opcode bytes E8 89 C2 74 09. When we jump 1 byte into this address, the processor interprets instructions starting with 89 C2 74 09 and so on. 89 C2 translates to the "MOV EDX, EAX" leaving 74 09 to be interpreted as a JE instruction. Since the program intended on the execution path containing valid instructions, we can ascertain that the originally viewed CALL instruction at 401095 was a bogus instruction (FYI: it actually points to invalid memory and would crash the program if executed).

There are even certain instruction combinations that can can be cleverly crafted such that the same byte can be used in two valid and working instructions as EIP runs through them. One simple example where a "JMP -1" jumps back inside of itself to the address occupied by the FF byte. This alters the interpretation for successive instructions producing the "INC EAX" from the "FF C0" combination.

         __
        v  \
   JMP   -1 |
    EB | FF | C0
       | INC EAX

Tip: While a program is paused, you may need to scroll around, follow jump links or explicitly visit other addresses. If you lose track of where the current instruction is or the current instruction is no longer in sync based on the current view, you can return to the current instruction by double-clicking the address shown to the right of the EIP register in the CPU registers window.

MAKING A MAP:
A module employing one or more anti-disassembly tricks is usually known as obfuscated code. Other tricks that don't fall under the anti-disassembly category can still further obfuscate the program. These tricks include "dead" code: useless instructions that don't affect the algorithm or output of the program. Another trick is constant unfolding: using more instructions than necessary to assign or adjust a value by a constant. An example of this was shown near the entry point of this challenge where 3 instructions were used to assign a constant value to a memory location, rather than a single MOV instruction.

When manually stepping through obfuscated code in the debugger, or even code that is difficult to understand due to an optimizing compiler or any number of other reasons, I recommend making a "map" of the disassembly. This will serve as a makeshift static analysis worksheet since traditional static analysis is probably not an option. If there is a specialized tool designed for the specific obfuscation method in a module you are analyzing, and you have access to such a tool, use it by all means.

When I make a map, I open up a text editor like notepad. In the debugger, when I arrive at the beginning of the code I'm trying to understand, I copy and paste the disassembly for the current code block. When a branch instruction (JMP, Jxx, CALL, etc.) jumps to another code block I make a little separator line below the current block (such as '---') and paste a copy of the disassembly for the new block below it. Continue doing this until you have all of the blocks for the code being analyzed. If the branch is unconditional but made to look conditional, I add a comment stating that fact. I also comment CALL's that never return or RET's used only to jump instead of return from a subroutine. When branching instructions jump "between" instructions as described earlier, no matter how close the new block of code is to the one performing the jump, you still treat it as a separate block the same as any other block. Also when jumping "between" instructions, since the debugger's disassembly of previous instructions will disappear as the disassembler re-synchronizes, you can easily look backwards by referring to your map. When making your first pass, I recommend focusing primarily on building the different blocks of code as a result of the branching instructions. For code that jumps several times between high and low addresses as a layer of obfuscation, your map automatically removes this layer as it naturally represents the order of execution. Because the map will contain memory addresses, you can quickly navigate to any spot in your code and easily refer to the address for setting debugger breakpoints. At this point you can make as many passes as necessary to add comments, manually fold constants, turn conditional jumps that are in fact unconditional into plain JMPs, remove boundaries between adjacent blocks that are related (such as when code jumps around multiple consecutive times effectively doing nothing but trying to be confusing, you remove the series of jumps), and any other algorithm distilling methods you deem necessary such as converting assembly into pseudocode. Keep refining until you have a grasp for what is going on.

One final anti-disassembly trick employed by this challenge is building "other code" directly on the stack and executing them to further obscure the "sensitive" key functionality. This is anti-disassembly trick #4. No static analysis tool I know of supports displaying the dynamic code built on the stack, but the map you build will (I like to annotate this fact). Unless the code is self-modifying, the map will help reduce the complexity of understanding the dynamic stack-built code.

Following the basic principles described above, below is a basic map from the the program's entry point up to the ReadFile() API call where user input is gathered. This map only connects one block of code to the next and has very little distillation going on. You can think of it as only pass #1. We won't distill this code further because it is only getting us from the entry point to the ReadFile() call, and whatever obfuscated steps it does, has nothing to do with the password algorithm. It is included here for educational purposes as a real example of a map.


The last instruction above jumps into the repeating portion below (401BD3) that makes use of the LOOP instruction. When dealing with obfuscated code, sometimes the LOOP instruction is used as an unconditional jump, but this is not the case here. The loop executes 6 times (the initial value of ECX). When you step through the code and confirm a LOOP instruction is actually performing a loop (that you aren't interested in), set a breakpoint on the loop exit so you don't waste your time. The map helps you recognize places you've already been to, such as a giant loop that you might otherwise step through for hours.


Now that we're out of that loop, the remainder of the code bounces around until you make it to the eventual ReadFile() API call. You'll notice in the map comments that the system API calls were manually-built with code as opposed to using a traditional import to make it harder to spot where and which APIs are being used.


The code above doesn't need to be analyzed too much because we were simply using it to understand making a map of obfuscated code. To skip directly to the ReadFile() API call, as this is usually "nearer" to the validation code we need to understand, we need to set an API breakpoint. In OllyDbg, go to the "View" menu -> "Executable modules" (or ALT-e). In the modules window, right click on the DLL that contains the desired API call. In this case, ReadFile() is in kernel32, so right-click kernel32 -> "Show names" (or CTRL+n). Sort the column by name (click the header button) and/or begin typing "readfile". When the ReadFile export is selected, double-click it or hit <ENTER> to go to the function's prologue. Set your breakpoint here and run the program. Once hit, step-over instructions until you reach ReadConsoleA, where you must switch back to the debugged-console and enter the password before the debugger regains control. Continue stepping-over until you exit ReadFile() via the "RETN 14".

Now we want to set a breakpoint on whatever code starts reading your input (to skip past whatever bouncing around may happen between here and there). At this point you'll be back in the challenge module at 401736. Locate your "user input" data by scrolling the stack up a bit until you see you it (you did type something that will stand out, right?) Right click on this stack location and "follow" the pointer into the memory dump window. Right click on the first byte of your input and set a read breakpoint. Now run the program to the breakpoint. You should find yourself near the top of the algorithm loop at 401A9C. As explained above, you'll have to have OllyDbg unanalyze this code so you can view the instructions rather than the data representation.

THE ALGORITHM:
Without including a larger map of the obfuscated code that comprises the password validation routine, I'll leave debugging that section of code as an exercise to the reader. Be patient with this one. I made 4 passes through the algorithm loop in the debugger before I had a clear picture of what was going on, taking and refining my notes with each pass. The code is intentionally complex so as to hide the relatively simple algorithm. The code employs all obfuscated techniques described thus far. It is a doable task if you just have some patience and expect that you might not understand all that is going on with the first few loop iterations. If you prefer not to make a map and solely use the debugger, use OllyDbg's "comment" feature to annotate instructions by pressing the ";" key. The comments will be kept across multiple debugging sessions, so when you see your comments re-appear, you'll know you are in a familiar part.

Early on in the loop, it is apparent a successful password is 41 characters. You'll soon find the "key/password" is divided amongst 4 different tables. The first table is what I called the offset table, indexed by the current character position by processing the user input from left to right. Once this offset retrieved for the current input character position, it is used as an index into each of the other 3 tables. The 2nd table contains XOR bytes, the 3rd shift bytes, and the 4th a "magic" DWORD value whose least-significant byte was the expected encrypted password character. The most difficult part for me was locating where the expected password characters were located, as the code performing this comparison was built on the fly and executed on the stack in a different position with each iteration of the loop. Making matters worse, the comparison avoided the use of CMP which would have stood out and instead used a "CMPXCHG BL, DL" instruction for an *implied* comparison between the destination operand and the AL register (where the expected password character was)! I missed this on multiple passes because the AL register wasn't listed as an operand and therefore wasn't on my "radar". This is why it is handy to have your Intel x86 assembly reference handy. On top of that, the result of the comparison that sent you to the "failure" branch was delayed until the loop body executed the number of times of the length of the expected password (regardless of the user input size)! If you didn't type in a full 41 characters, 41 bytes of whatever artifacts were in the user input buffer were compared regardless.

As previously mentioned, the important parts dealing with the key were executed by code built on the stack by other code. Setting breakpoints on the stack aren't very useful in general because the stack is constantly growing and shrinking causing those breakpoints to be constantly triggered by other code. This is why making a map is useful; the location of the currently executing code on the stack isn't important so much as the instructions, because they are mostly the same, just accessing different indexes into the same buffers. In the map snippet below, the stack addresses reflect those of the first loop iteration for the encrypted password comparison code. An understanding of the algorithm isn't usually affected by changing stack addresses for stack code unless the generated code is drastically different between iterations. In this case, the code was always a "CMPXCHG BL,DL" followed by a RETN. After you do multiple passes through the loop you'll be able to identify the pattern with the code being placed on the stack to distill the important algorithm pieces. Here's the snippet from my map where the encrypted character comparison was built and executed on the stack:


NOTE: Despite the limited usefulness of stack breakpoints, that doesn't mean there aren't instances where they are useful. In this challenge I did in fact set a memory write breakpoint at a specific stack location to figure out which routine was responsible for placing the "You are failure" message to be picked up by WriteFile().

Once I had an understanding of the algorithm, I used breakpoints to manually gather the values from the XOR, SHIFT and MAGIC tables for each position of the password. I hardcoded these tables into a small C++ program to run the algorithm in reverse on the encrypted password (stored in the low byte of the "magic" table). The program source is shown below:


CRACKING THE PASSWORD:
After building the program, we run it to produce the decrypted password. The result is then double-checked in the challenge program.



Success!

CONCLUSION:
The official solution confirmed my findings about the decoy function at 401000 (the default entry point used by Microsoft linkers) . I suspect the decoy resembles the original unobfuscated version of the program. I didn't catch the use of the NtGlobalFlag "debugger present" check that was added to throw off the results when the program was running in a debugger. This didn't affect me because I wasn't using the debugger to test password characters, such as with a brute force method. The author ultimately developed a Python script using the same algorithm as in my C++ decoder.

E-MAIL RESPONSE:
Response from Is_th1s_3v3n_mai_finul_foarm@flare-on.com:

---

<< Flare-On 2015 Index  --  Go on to Challenge #10 >>