{"id":1001,"date":"2019-01-23T11:13:08","date_gmt":"2019-01-23T19:13:08","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=1001"},"modified":"2019-01-23T11:13:08","modified_gmt":"2019-01-23T19:13:08","slug":"jeb-native-pipeline-ir-optimizers-part-2","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/jeb-native-pipeline-ir-optimizers-part-2\/","title":{"rendered":"JEB Native Analysis Pipeline \u2013 Part 2: IR Optimizers"},"content":{"rendered":"\n

In part 1<\/a> of this series, we gave an overview of the Intermediate Representation used by JEB’s Native Analysis Pipeline, as well as a simple Python script demonstrating how to use the API to access and print out IR-CFG of decompiled routines.<\/p>\n\n\n\n

In part 2, we continue our exploration of JEB IR. We will show how to write a custom IR optimizer plugin to clean-up a custom obfuscation used in a piece of code. The resulting decompiled C code will end up very readable as well.<\/p>\n\n\n\n

Before you proceed, make sure to update JEB Pro to version 3.1.1+.<\/strong><\/p>\n\n\n\n

Obfuscated Crypto-stealer Code<\/h2>\n\n\n\n

The sample<\/a> we are going to look at monitors Windows clipboards for cryptocurrency-looking wallet addresses, and replaces them with a desired target address. The sample is specifically targeting Ethereum wallet addresses. It is a neutered final stage payload – the recipient address has been scrambled to render the code ineffective.<\/p>\n\n\n\n

\"\"
PE characteristics of file 1.exe<\/figcaption><\/figure>\n\n\n\n

Although the payload is unpacked, what is interesting is that one of its key routines is obfuscated: custom garbage code was inserted.<\/p>\n\n\n\n

\"\"
Junk (useless) assignments<\/figcaption><\/figure>\n\n\n\n

The garbage code is easy to go through: a bit of manual analysis shows that junk instructions are assigning pseudo-random values to an array whose bytes are never used. Two types of assembly patterns are present:<\/p>\n\n\n\n

1- mov dword ptr [edi + offset], junk_value ; edi previously init. to
                                            ; junkarray address
2- push junk_value
   pop dword ptr [junkarray_address + offset]<\/pre>\n\n\n\n
If we decompile that code and look at the final IR (as shown below), we can see that those instructions ended up being converted and optimized to the following type of assignment:<\/p>\n\n\n\n
Assign(Mem(mem_address), Imm(junk_value))<\/pre>\n\n\n\n
Currently, the decompiled code looks like the following, hard-to-digest blob:<\/p>\n\n\n\n
\"\"
Snippet of decompiled code (obfuscated)<\/figcaption><\/figure>\n\n\n\n
Although quite painful to read, we can follow the program’s logic by abstracting away the junk assignments. (Essentially, win32 functions’ OpenClipboard, GetClipboardData, and SetClipboardData are used to retrieve, check, and replace copy-pasted Ascii and Unicode text, if they match the following pattern “\/0x(..){20}\/”. The replacement string target wallet address, previously decrypted by sub_401000.)<\/p>\n\n\n\n
Cleaning the Intermediate Representation<\/h2>\n\n\n\n
Recall that the native analysis pipeline can be simplifed as the workflow below:<\/p>\n\n\n\n
CodeObject (*)
  -> Reconstructed Routines & Data
    -> Conversion to IR (low-level, non-optimized)
      -> IR Optimizations<\/u><\/strong> <--- this is where we'll work<\/em>
        -> Final IR (higher-level, optimized, typed) 
          -> Generation of AST
            -> AST Optimizations
              -> Final AST (final, cleaned) 
                -> High-level output (eg, C variant)<\/pre>\n\n\n\n
Our custom IR optimizer will look for junk assignments and remove them. The important criteria are: What is the junk array start and end addresses? Is it common to all routines in the binary, or is there one array per routine? Those questions may be hard to answer in the general case. However, for our specific sample file, we can assert with a high-degree of certainty that the junk array:
– starts at address 0x415882
– is at most 256 bytes long
– is used solely by sub_401171, the routine we want to analyze<\/p>\n\n\n\n
Because of the above restrictions, the IR optimizer we are going to write should be qualified as a custom<\/em> or ad-hoc<\/em> IR optimizer. Chances are, we won’t be able to reuse it as-is in other programs without some amount of tweaking.<\/p>\n\n\n\n
Let’s get started, we will:
– create an Eclipse project with scaffold code for a Java back-end plugin
– write and test a custom IR optimizer with a headless client
– deploy the plugin and make it usable and accessible from the UI desktop client<\/p>\n\n\n\n
Creating a Plugin Project<\/h3>\n\n\n\n
Before we proceed, make sure to:<\/p>\n\n\n\n