In the 2011 RSA Conference Cryptographers' Panel, Martin Hellman states:
| DES was a gift from the Gods to those of us working in academic cryptography. Aside from its commercial implications in terms of actually giving us a system people could use, it gave us a target, it gave us something to cut our teeth on, and we cut our teeth on it crypto-analytically, and learned a lot from it. |
We believe that in order to make progress in software protection and reverse engineering of obfuscated/tamperproofed code, we need publically accessible tools of the trade (obfuscators on the one hand, and de-obfuscators on the other), to give us targets to cut our teeth on, in a similar way that DES did for cryptography. We hope Tigress will be one such tool, among many.
Security competitions have also become an important way for students to hone their skills and for researchers to develop new attacks and defenses. To encourage research in reverse engineering of obfuscated code, we here provide challenge programs generated by Tigress, and we invite the community to attack them.
Eventually, we hope that the community will come together to create collections of such challenge programs, to help us develop uniform evaluation practices for software protection and reverse engineering techniques.
Generating Challenges
We use Tigress' RandomFuns transformation to generate random programs with a SECRET function that is the target of the attack. We next use Tigress to obfuscate this function:
We do not reveal the seeds used to generate the challenges to the attacker, but for most of the challenges we publish the obfuscation scripts. In most real situations, of course, the attacker would not know the sequence of transformations the defender has applied. We use random.org to generate the seeds.
Types of Attacks
One can imagine four different types of information that a reverse engineer would want to recover from a challenge program:- In a source recovery attack the task is to identify the algorithm that computes SECRET.
- In a data recovery attack the task is to extract a specific run-time or compile-time data item. This could, for example, be an IP address, a cryptographic key, or a password.
- In a metadata recovery attack the task is to identify the sequence of transformations that resulted in SECRET, along with arguments to those transformations, such as the dispatch method used in a virtualization.
- In a location attack the task is to identify the code bytes of the program that comprise the obfuscated SECRET function.
Additionally, in a tampering attack the task is to modify the behavior of the program, such as removing a license check. Our current challenges are all source recovery attacks.
Contest Rules
- Attacks are expected to based on some sort of reverse engineering effort
(broadly construed). This includes, but is not limited to:
- static, dynamic, symbolic attacks, and combinations thereof;
- manual and automated attacks, and combinations thereof;
- side-channel attacks (attacks that feed inputs to the program and examine behavior such as energy use).
- Thus, attacks not based on reverse engineering are not accepted.
This includes, but is not limited to:
- black-box attacks, (guessing the internals of SECRET simply by feeding it inputs and examining the outputs);
- social engineering attacks (tricking me into giving you the answer);
- rubber hose attacks (beating the answer out of me);
- intrusion attacks (breaking into my computer, be it physically or virtually).
- In a source recovery attack, the de-obfuscated source should be provided in C, compilable with gcc, and should have the same behavior as the original binary. There is no requirement that the recovered program be identical to the source program, but it should be idiomatic C, i.e. have a structure that makes it amenable to further analysis by a skilled reverse engineer. For example, we expect loops in the source program to have corresponding loops in the recovered program, rathery than being unrolled, and compound data types (arrays, structs, and unions) should be identified as such.
- The winner is determined by the time of arrival of the email at our servers.
- A detailed description of the nature of a successful attack has to be provided. If proprietary tools were employed in the attack, a detailed description of their design and capabilities must be provided.
- A panel of judges from DAPA will determine whether a submitted solution constitutes a successful breach or not.
- Most challenges consist of multiple random programs obfuscated with the same sequence of transformation, but different randomization seeds. To encourage the development of automatic (class) attacks over manual hacking, a successful attack must successfully attack all programs of the challenge.
- Individuals as well as teams may participate.
- The winner(s) may be awared a small prize. In case of a winning team, the team itself is responsible for dividing the prize among the team members. Any taxes, etc., are the responsibility of the winners.
Submission Procedures
A successful submission should contain the following information:
- names, email addresses, and affiliation of the attacker(s) (we will not accept anonymous submissions) plus a short description of their educational and professional background;
- for a source recovery attack, the recovered sources for all programs of the challenge;
- a detailed description of the tools and techniques used in the reverse engineering effort;
- an estimate of the amount of time (in person hours) used in the attack.
The attack description should be sent in an email to us, consisting of all the relevant information above.
Current Challenges
Our current challenges are source recovery attacks. Each of the challenges below consists of a collection of programs obfuscated with Tigress, compiled to stripped binary executables, and the goal of the challenge is to recover de-obfuscated source code that is as close to the original as possible.
| Challenge | Description | Number of binaries |
Difficulty (1-10) |
Script | Prize | Status |
|---|---|---|---|---|---|---|
| 0000 | One level of virtualization, random dispatch. | 5 | 1 | script | Certificate issued by DAPA | Solved |
| 0001 | One level of virtualization, superoperators, split instruction handlers. | 5 | 2 | script | Signed copy of Surreptitious Software. | Solved |
| 0002 | One level of virtualization, bogus functions, implicit flow. | 5 | 3 | script | Signed copy of Surreptitious Software. | Solved |
| 0003 | One level of virtualization, instruction handlers obfuscated with arithmetic encoding, virtualized function is split and the split parts merged. | 5 | 2 | script | Signed copy of Surreptitious Software. | Solved |
| 0004 | Two levels of virtualization, implicit flow. | 5 | 4 | script | USD 100.00 | Solved |
| 0005 | One level of virtualization, one level of jitting, implicit flow. | 5 | 4 | script | USD 100.00 | Solved |
| 0006 | Two levels of jitting, implicit flow. | 5 | 4 | script | USD 100.00 | Open |