Quarkslab Internship Offers for 2019-2020

Mobile applications are now everywhere and handle sensitive informations. Reversing them is a tedious task when considering real world ones as they often mix Java and native code while interacting with the Android ecosystem. Even though tooling is available and useful, most of the analysis still needs to be done manually. Moreover, to protect themselves from various threats (reversers, cheaters, thieves...), application developers have a broad range of tools (packers, obfuscators, cryptography) they could use to increase the costs of such attacks and protect their IP. However, the adoption's rate of these means of protection is mostly unknown as no (or too few) large scale studies have been made on those aspects.

Building-up above tools used internally (https://blog.quarkslab.com/qbdi-070.html, https://blog.quarkslab.com/exploring-execution-trace-analysis.html), the goal of this internship is to gear up the reverse-engineer toolbox to facilitate Android reverse engineering. This will be focused on understanding how real-world Android applications are protected, at what level and to what extent.

The main difficulties of the internship are linked to 3 main points:

• Understanding the inner-working of applications (statically/dynamically)

• Tackling static/dynamic protections employed by the applications

• Improving existing tools to address such issues

• Fluent in Python (C/C++ is a plus)

• ARM & x86 (both 32 & 64 bits) main instructions

• Basics of reverse engineering (static / dynamic)

An emulator is a software that is able to simulate the behavior of hardware (at least CPU and memory). Emulation can be useful in lots of cases like testing new applications with ease, debugging programs that run only on specific hardware...

Contrarily to virtualization, emulation is aware of all the modifications done on the (simulated) hardware and this intrinsic knowledge can be used to make powerful debugging.

QEMU is a really good piece of software that can simulate many hardware, but we think that the "Translation Blocks" generation is too complex and can be improved.

The aim of the internship is to design an emulator that can run aarch64 software on x86_64 processors. The emulator should be able to log any modification during the time of execution and may offer a debugging stub and a python stub. Finally, if the core is light and efficient enough then it could be integrated in QEMU in place of the "Tiny Code Generator" to use it with all the available virtual devices.

int fib(int n){
  if (n < 2){
    return n;
  }
  return fib(n-1) + fib(n-2);
}

• Compile this .c in aarch64 and extract the aarch64 assembler

• Create a tool that converts the aarch64 instructions used by fib in x86_64 assembler.

This file aarch64.isa can help the development of the tool.

• CPU basics

• Aarch64 & x86_64 assembly

• C programming

Code obfuscation provides a challenge against the manual reverse engineering of an application. However, instead of understanding and defusing each protection, an attacker may execute the application and monitor its state at precise moments: after crucial data have been decrypted by the application, by comparing the program state before and after the execution of a function, ...

For this, reverse engineers use Dynamic Binary Analyses frameworks, which provide dynamic information about the state of the application. Luckily for us, these tools have their weaknesses. They have various effects on the execution environment of the application, which can be detected to deviate the behavior of the application and prevent the attacker from obtaining useful data. However, these tools also keep improving and such countermeasures need to be re-evaluated continuously.

The goal of this internship is to study how state-of-the-art tools affect the execution environment of applications under different platforms and implement different means of protection against them. A solution is to block these tools from performing their task by introducing certain constructions that "confuse" them. An alternative is to detect their presence and act upon it.

The work would be supervised by the Instrumentation team, which specializes in using and building dynamic binary analysis frameworks, and the Epona team, which maintains the Epona Application Protection solution offered by Quarkslab.

• https://epona.quarkslab.com/

• https://qbdi.quarkslab.com/

• https://www.dynamorio.org/

• https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool

• https://www.frida.re/

• Master 2 or last year of engineering school.

• Technical requirements: C++, reverse engineering.

Nowadays, firmware are everywhere: mobiles, routers, ECU, IoT devices, Set-Top boxes, … Sometimes, they are as simple as a filesystem, which can just be accessed like every other filesystem. But most of the time, they are compressed and encrypted, sometimes using custom algorithms.

However, when one wants to analyze what is inside the firmware, the first step is always to reach its inside, hence opening it.

The goal of the internship is to work on a generic engine able to deal with multiple kinds of firmware to access to the files it contains.

• Improve our framework to handle file systems

• We will select multiple firmware, and you will have to support them in the framework

  • Study encryption and compression if any

  • Develop the appropriate unpacking capabilities

  • Test on various firmware of the same family (yes, sometimes, there are surprises ;)

• Automate unpacking based on our Irma framework

• Fluent in Python

• Good knowledge in cryptography and algorithms

• Preferably some experience in reverse engineering in ARM and/or unpacking malware

The Android OTA Package Tools [2] support building full and incremental updates, that can later be applied to a device. Take a look at the building tool from the AOSP source tree [3] and implement your own unpacker for this format, preferably using Python.

You can use the building script to make your own packages, but your tool should be able to extract at least the following packages: [4] (full update) and [5] (incremental update that should be applied on top of the other one).

Once you are satisfied with your unpacking script and are ready to show it to us, please also write a small report explaining how you designed it.

A question that often arises while using application protection tools is: "How well protected is my application?"

The question in itself is vague. To avoid an awkward silence as an answer, it is often required to sit down, detail a precise knowledge of what "protected" means [6] and perform a manual evaluation of the application protection.

The main goal of this internship will be to investigate the automation of some parts of such an evaluation process. The main focus of the internship will be on the Epona Obfuscating Compiler and thus will require to implement attacks against it.

For example obfuscations do more work than making the code ugly, they also provide certain guarantees: the sensitive constant 0xcc9e2d51 won't appear in the final binary; the string "my_very_user_secret" will be encrypted; the program evil-debugger won't be able to debug the application, etc. For each of these protections, one may try to attack and get around them: profile the code and identify instructions that always yield to the same constant; wait until just before the string is used in context to see its unencrypted content; identify calls that match those made by anti-debuggers and remove them, etc. And conversely, one may try to counteract these attacks with more defense mechanisms.

A first step of the internship will be to identify a series of meaningful reference codes, to implement simple automated attacks to retrieve target assets inside these codes, and then to apply some protections or obfuscations to the reference codes and see which attacks still succeed and which don't. In a second time, more complex attacks may be implemented and tested against our protections.

These reference code and attacks could then be used to provide a sense of the set or level of skills that an attacker should master to defeat the protections: If more skills are needed, one could assume the code is better protected.

This also represents a first brick towards implementing a fully automatic obfuscation tool (given the assets to protect and the attacks against which they must be protected, infer a protection scheme that will defeat the specified attacks).

Master 2 or last year of engineering school.

Technical requirements: C++, program analysis