Athcon 0x7DB.

Exploiting Anti-Reversing Techniques

-A Case Study By Economou kyriakos-

Attacking Armadillo’s Loader under Xenocode Application

Virtualization.

What is Armadillo…

Commercial Software Protection

It is actually an executable/dll packer.

Offers very good protection against Reverse

Engineering.

It is very popular among commercial software developers.

Armadillo’s Anti-Reversing Tricks

PE Header Elimination Code Splicing Imports Redirection IAT Elimination Debug Blocker CopyMemII Nanomites Debugger Detection through IsDebuggerPresent() Crashes Olly Debugger through OutputDebugString()

with strings of “%s%s%s%s” format. CRC checks on runtime.

What is Xenocode…

A set of application virtualization and portable application creation technologies developed by Code Systems Corporation.

On June 5, 2010 the name Xenocode was changed to Spoon.

Xenocode packs the whole application including its modules and dependencies into a single executable file.

It actually emulates the OS features necessary for the application to run such as DLL files and even entire runtimes and components like .NET Framework 2.0, 3.0, 3.5, and 4.0, Java, AIR, Silverlight, and Flash.

The virtualized application runs independently from the other software that is installed on the host PC.

Has Armadillo been reverse engineered?

YES!!!

Does Xenocode provide any anti-piracy protection?

NO!!! -at least not on purpose-

Then, why bother?!?

This is the first time that Armadillo packer gets involved into application virtualization.

There is a lot to learn regarding “choosing the appropriate software protection” because…

…we will demonstrate a case in which we can exploit an anti-reversing technique, thus use it against the protection itself.

Our case…

The virtualized application has been written for the .net framework.

The Armadillo protection had been applied to one of its DLL libraries before the virtualization.

When we run the application, Xenocode will load in memory all the necessary modules including the Armadillo packed DLL, which is used for the license management (trial days remaining, license verification etc..)

The tricky part…

All the necessary modules are loaded on run-time -no HD I/O-, hence no physical access to these files on disk -No patching!-.

We could attempt to dump from memory and modify the Armadillo packed DLL or any other module, but that would be useless, because Xenocode will always load in memory the original one.

The ImageBase of all modules including the Armadillo packed DLL is always different in memory when loaded.

The Armadillo packed DLL will allocate some extra memory on run-time and will write there some extra code where the license system performs its checks -also known as “ArmAcess.dll”- from the earlier versions of Armadillo.

…which means that the VA of that specific code block regarding the license check will also be different every time.

So know what?!?

We need to code a loader that will always locate in memory that specific code block and modify it on run-time….

….or we could try to write our own inline functions inside the executable itself that will do the job on run-time.

Our way in…

The virtual DLL written somewhere in memory by the Armadillo packed DLL is going to use the OutputDebugString() win API in order to crash Olly Debugger.

This is a specific anti-debugger attack, but it is used anyways.

We can use this fact as our way into the Armadillo’s virtual DLL (ArmAccess.dll)

…and from the stack we shall learn

Enter the ArmAccess.dll

Licence check references

Follow back in Disassembler

The magic byte issue

It is always zero by default.

It must “always” be !=0

The VA where this byte is located it is always different due to the dynamic ImageBase of the virtual DLL.

We need to know every time what is the VA of the magic byte.

Putting things together

We can always know a VA in the address space of the virtual DLL through the stack when the OutputDebugString API is called.

We also now know a VA of the magic byte.

The virtual DLL’s structure is always the same, hence the difference in bytes between those 2 locations is constant.

We just need the RVA of the magic byte to a VA where a call to OutputDebugString API is made from the virtual DLL.

Calculating magic byte’s RVA

MagicByteRVA = MagicByteVA – RET from CALL to OutputDebugStringVA

Where:

MagicByteVA = The VA of the magic byte in this running instance of the process.

RET from CALL to OutputDebugStringVA = The RET VA after a CALL to OutputDebugStringA from the virtual DLL.

In this case:

MagicByteRVA = 0x6323E1E – 0x62677CD = 0xBC651

Things to keep in mind

The RVA calculated will be always constant if…

You always refer to the VA of the same CALL to OutputDebugString from the virtual DLL, because more CALLs may be made from different location inside the virtual DLL.

You work on the same version of the specific application.

Issues to take in consideration

The license check routine may be executed more than once inside the virtual DLL which means that:

The state of the magic byte may be changed back again to zero.

You need to know after how many times the OutputDebugString is called, it is safe to modify the magic byte…

…which means that in this software protection mechanism you may need to calculate the RVA of the magic byte by counting how many times the OutputDebugString has been called and taking in consideration the “safe” VA where a call to OutputDebugString from the virtual DLL is made in different versions of the same application.

One step further…

We cannot write an inline function that directly modifies the magic byte in the Armadillo’s license system, because this code it is going to be written somewhere in memory on run-time by the Armadillo packed DLL.

We need to prepare the inline function that is going to be executed on run-time while we still control the executable from where the Xenocode VM is going to be launched.

We are going to exploit the OutputDebugStringA anti-reversing trick by modifying the API’s code inside kernel32.dll or kernelbase.dll depending on Windows version.

This modification must occur on run-time by another inline function each time we launch the application.

Chained inlining – 1st Inline Function

• We first need to add some extra strings inside the code cave.

• Notice that we use unicode for the system DLL names. This is because the application is using the unicode version of LoadLibrary API which we also need. Therefore, we will use in our favour application’s IAT too…

• 00404C54 . 6B00 6500 720>UNICODE "kernelba“• 00404C64 . 7300 6500 2E0>UNICODE "se.dll",0 • 00404C72 00 DB 00• 00404C73 . 6B00 6500 720>UNICODE "kernel32“ • 00404C83 . 2E00 6400 6C0>UNICODE ".dll",0• 00404C8D 00 DB 00• 00404C8E . 4F 75 74 70 7>ASCII "OutputDebugStrin"• 00404C9E . 67 41 00 ASCII "gA",0• 00404CA1 00 DB 00• 00404CA2 . 56 69 72 74 7>ASCII "VirtualProtect",0

Chained inlining – 1st Inline Function

• 00404CB5 > 55 PUSH EBP• 00404CB6 . 8BEC MOV EBP, ESP• 00404CB8 . 83E4 F8 AND ESP, FFFFFFF8• 00404CBB . 60 PUSHAD• 00404CBC . 9C PUSHFD• 00404CBD . 68 544C4000 PUSH MindWork.00404C54 ; /FileName = "kernelbase.dll"• 00404CC2 . FF15 50608B00 CALL DWORD PTR DS:[<&KERNEL32.LoadLib>; \LoadLibraryW• 00404CC8 . 85C0 TEST EAX, EAX• 00404CCA . 75 0B JNZ SHORT MindWork.00404CD7• 00404CCC . 68 734C4000 PUSH MindWork.00404C73 ; /FileName = "kernel32.dll"• 00404CD1 . FF15 50608B00 CALL DWORD PTR DS:[<&KERNEL32.LoadLib>; \LoadLibraryW• 00404CD7 > 8BF0 MOV ESI, EAX• 00404CD9 . 68 8E4C4000 PUSH MindWork.00404C8E ; /ProcNameOrOrdinal =

"OutputDebugStringA“• 00404CDE . 50 PUSH EAX ; |hModule• 00404CDF . FF15 4C608B00 CALL DWORD PTR DS:[<&KERNEL32.GetProc>; \GetProcAddress• 00404CE5 . 8BF8 MOV EDI, EAX• 00404CE7 . 68 A24C4000 PUSH MindWork.00404CA2 ; /ProcNameOrOrdinal = "VirtualProtect"• 00404CEC . 56 PUSH ESI ; |hModule• 00404CED . FF15 4C608B00 CALL DWORD PTR DS:[<&KERNEL32.GetProc>; \GetProcAddress• 00404CF3 . 8BF0 MOV ESI, EAX

Chained inlining – 1st Inline Function

• 00404CF5 . 68 00504000 PUSH MindWork.00405000• 00404CFA . 6A 40 PUSH 40• 00404CFC . 6A 24 PUSH 24• 00404CFE . 57 PUSH EDI• 00404CFF . FFD6 CALL ESI• 00404D01 . 8BF7 MOV ESI, EDI• 00404D03 . 83C6 24 ADD ESI, 24• 00404D06 . C606 00 MOV BYTE PTR DS:[ESI], 0• 00404D09 . C707 609C8005 MOV DWORD PTR DS:[EDI], 5809C60• 00404D0F . 8977 04 MOV DWORD PTR DS:[EDI+4], ESI • 00404D12 . 66:C747 08 01>MOV WORD PTR DS:[EDI+8], 8001• 00404D18 . C647 0A 3D MOV BYTE PTR DS:[EDI+A], 3D• 00404D1C . 8977 0B MOV DWORD PTR DS:[EDI+B], ESI• 00404D1F . C647 0F 03 MOV BYTE PTR DS:[EDI+F], 3• 00404D23 . C747 10 74039>MOV DWORD PTR DS:[EDI+10], 619D0374• 00404D2A . C747 14 C38B4>MOV DWORD PTR DS:[EDI+14], 24448BC3• 00404D31 . C747 18 2405B>MOV DWORD PTR DS:[EDI+18], 6BBB0524• 00404D38 . C747 1C 0B00C>MOV DWORD PTR DS:[EDI+1C], 0C6000B• 00404D3F . C747 20 019D6>MOV DWORD PTR DS:[EDI+20], C3619D01• 00404D46 . 9D POPFD• 00404D47 . 61 POPAD• 00404D48 .^ E9 58F4FFFF JMP MindWork.004041A5

Chained inlining – 2nd Inline Function

When the 1st inline function ends, the OutputDebugString API will have been changed into the following…

• 759FD4F5 > 60 PUSHAD• 759FD4F6 9C PUSHFD• 759FD4F7 8005 19D59F75 0>ADD BYTE PTR DS:[759FD519], 1• 759FD4FE 803D 19D59F75 0>CMP BYTE PTR DS:[759FD519], 3• 759FD505 74 03 JE SHORT KERNELBA.759FD50A • 759FD507 9D POPFD • 759FD508 61 POPAD• 759FD509 C3 RET• 759FD50A 8B4424 24 MOV EAX, DWORD PTR SS:[ESP+24]• 759FD50E 05 BB6B0B00 ADD EAX, 0B6BBB• 759FD513 C600 01 MOV BYTE PTR DS:[EAX], 1• 759FD516 9D POPFD• 759FD517 61 POPAD• 759FD518 C3 RET• 759FD519 00

The 3rd time we arrive here, this function is going to retrieve the return address to the Armaccess.dll, calculate the RVA between that address and magic byte’s address and modify it to 1.

A lesson to learn

A software protection that it is good for one case may not suit your needs. In fact, the software I worked on for this presentation was considered “uncrackable”!

Even worse, it may be proved your worst enemy, and remember you have paid for it!

An anti-reversing trick was turned into a path inside the protection itself, think about it!

Next time, put some anti-reversing tricks inside your code too, and don’t rely only to the commercial software protection…

…and dude, use a little bit of imagination. I did! :o)

Thank you :0)

There are 10 types of people in the world:

Those who understand binary and those who...have a life.