Application security

Software Security - Anti-Patching

Jamal Chahir
December 27, 2016 by
Jamal Chahir

Introduction

In this series of articles, we will discuss some of the techniques that will help better protect our software against reverse engineering. This first article aims to cover an anti-patching technique which will allow us to detect if our software has been tampered with or patched.

Note: You must have some knowledge of Assembly language and know how to use debuggers such as Ollydbg.

Tools needed

  1. The target file (crackme.exe)
  2. Ollydbg

Target software

A CrackMe that requires a Registration Code was made in Assembly to demonstrate the technique that we will cover in this article.

Scanning -> crackme.exe

[Hash] MD5 (16) -> 285d46d9ac8bc9d87fff1618063a0879

[Hash] SHA1 (20) -> f08838efcb80b05293ef0ae131c57700898007be

[Hash] CRC32 (04) -> ead8bc3c

- Hashing Took : 0.16 Second(s) [000000010h (16) tick(s) (3 function(s)) (16.0 byte(s)/s)]

File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 3072 (0C00h) Byte(s) | Machine: 0x14C (I386)

Compilation TimeStamp : 0x58600B7D -> Sun 25th Dec 2016 18:10:05 (GMT)

[TimeStamp] 0x58600B7D -> Sun 25th Dec 2016 18:10:05 (GMT) | PE Header | - | Offset: 0x000000E0 | VA: 0x004000E0 | -

[File Heuristics] -> Flag #1 : 00000000000001001100000000000000 (0x0004C000)

[Entrypoint Section Entropy] : 4.93 (section #0) ".text " | Size : 0x132 (306) byte(s)

[DllCharacteristics] -> Flag : (0x0000) -> NONE

[SectionCount] 4 (0x4) | ImageSize 0x5000 (20480) byte(s)

[ModuleReport] [IAT] Modules -> user32.dll | kernel32.dll | comctl32.dll

[CdKeySerial] found "Registration Code" @ VA: 0x0000304B / Offset: 0x0000084B

[CdKeySerial] found "Registration Code" @ VA: 0x00003069 / Offset: 0x00000869

[CompilerDetect] -> MASM

[!] File appears to have no protection or is using an unknown protection

- Scan Took : 0.188 Second(s) [0000000BCh (188) tick(s)] [506 of 580 scan(s) done]

Securing

What interests a reverse engineer the most in a Software is the serial key checks or any of the many authentication procedures, and that is what interests too.

The picture below shows how our serial check routine looks like just a hard coded serial (s0me_r@nDoM_rEg_c0dE) and two message boxes.

Assuming another case where the serial is not hard coded, Patching it is easy, just a NOP at address 0x40107A will trigger the good boy (Registration code is correct). However, after we apply our anti-patching method, this will not happen.

For this method to work properly we need:

  1. Start address of the part to secure
  2. End address of the part to secure
  3. Size of the part to secure (End address – Start address)
  4. Algorithm (might be hashing or encryption…)

Since we only want to secure the serial check routine (picture above) we have the following:

  1. Start address : 0x401052
  2. End address : 0x4010A6
  3. Size of the part to secure : 0x4010A6 – 0x401052 = 0x54 (84d)
  4. Algorithm: we will only use XOR for demonstration

Now that we have what is required let's see how our algorithm looks like.

In the above picture we have our XOR algorithm which basically does ADD and XOR through each byte of the serial check routine starting from address at esi (0x401052) till it reaches the end which is ecx (0x54), and the result which is stored in eax is 0x110342F7 this is basically a unique checksum so if something changes in the serial check routine the message at address 0x4010E7 will be triggered and the CrackMe will not start.

However, for this to work there should be a call to that algorithm (0x4010BE) somewhere, the best place is at the beginning of the CrackMe.

Now let's check if this anti-patching method works.

Running the app with no changes in code will have no effects since we did not change anything, the app would start normally.

Now let's see what happens when we patch it.

NOP at address 0x40107A should normally trigger the good boy message.

Running the patched app will show us the following message and the app will not start.

Moreover, that proves that our anti-patching method works perfectly.

Conclusion

This article has shown that it is possible to make things harder for a reverse engineer, but with more efforts. It could be much harder. Moreover, hope you have learned something new and useful.

11 courses, 8+ hours of training

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

Download links:

Jamal Chahir
Jamal Chahir

Jamal Chahir (aka. xsp!d3r), An Information Security Researcher from Morocco, Coder and Reverse Engineer. Interested in Software and Web Security, has a big passion for Cryptography. And has developed many tools in different programming languages. Blog: http://xspid3r.blogspot.com.