15 May

Unity3D, Mono and invalid PE files

Some time ago, Reoto asked a very nice question on Black Storm forum:

Can someone fix the .dll (.net) pe header to MS DOS?
How can I do that?
If you know about protecting .net files for Android, please help me.
I have another question.
Can I fix dnspy to resolve .dll pe header isn't .net?

Obviously, English is not author's first language but it seemed like an interesting problem, so I decided to look into it.

Here is one of the files in question: https://mega.nz/#!0g4VHaIR!KmpQirte4_3lv8MSxyjETiufjFGb-CITpFGrXwxSgGY

TL;DR: Mono loader used by Unity3D accepts invalid PE files. It can be used to break most .NET decompilers. dnlib and tools based on dnlib (dnSpy, de4dot) were updated on 20-Apr-2018 but the rest of the tools still can't handle such files.

Quick background on Unity3D and Mono

I quickly checked file in CFF and it looked like the file doesn't have proper PE header.

I fixed that. But even then it was not recognized as a .NET file.

So, the file is clearly invalid, yet it works just fine in Android! How is that possible?

Well, Android has no clue about PE files or .NET Framework. When you build your program in Unity3D and deploy it to Android, it uses Mono to run your code. Mono is supposed to be open-source alternative of .NET Framework. And it is incredibly buggy.

I'm not Unity3D or Android wizard but the whole monstrosity works something like this:

To make matters worse, even current versions of Unity3D are using a very old Mono version. Like 3+ years old. You can easily tell it by looking at the PE loader error messages. This is how it looks in IDA:

The commit df51163 is clearly missing.

Therefore, for the rest of the article I'll be using Mono sources from commit 74be9b6, so that they would more or less match the code used by Unity3D.

Cause of the problem

A good place to start looking for bugs would be Mono implementation of PE loader:

do_mono_image_load calls function mono_verifier_verify_pe_data which should filter out any invalid PE file and stop loading it. For some reason (which I really don't care about), this function does nothing in Unity3D and returns success.

After that, buggy mono_image_load_pe_data takes over and uses PE parser to load PE structures and .NET metadata. It is followed by equally buggy processing of .NET metadata in both mono_verifier_verify_cli_data and mono_image_load_cli_data.

But first things first..

Invalid PE signature

First of the errors is inside do_load_header. It gets called indirectly from mono_image_load_pe_data:

It checks only first 2 bytes of PE signature, so you can change it to "PE\0\1" or "PEPE" and it will still work under Mono.

Invalid NumberOfRvasAndSizes value

Next bug is located get_data_dir used indirectly by mono_verifier_verify_cli_data.

and get_data_dir looks like this:

Both verify_cli_header and get_data_dir ignore NumberOfRvasAndSizes field in PE header and access "CLR Runtime Header Entry".

Identical bug is in load_cli_header called from mono_image_load_cli_data:

They do not use broken get_data_dir function but the check of NumberOfRvasAndSizes field is still missing. That's why our PE file can have NumberOfRvasAndSizes == 0xA and it still works under Mono.

Invalid metadata size

Mono does a very limited checking of .NET metadata size in load_metadata_ptrs.

However, this check is insufficient. For example, you can set .NET metadata size = 0, most of .NET reversing tools will break but Mono will happily accept the file.

Invalid number of .NET streams

.NET metadata streams are loaded by load_metadata_ptrs.

You can use an arbitrary large number of streams in .NET Metadata header, as Mono will ignore all the invalid data. It probably will spam Android log with "Unknown heap type" messages, but the file will still run.

Invalid number of rows in .NET tables

Final nail in the coffin is the incorrect processing on .NET metadata tables. Tables are loaded in load_tables method which seems to be correct on the first look:

However, the definition of .NET metadata table information (_MonoTableInfo) is wrong:

As a result of this definition, they ignore high-order byte in row count. You can set number of rows to, say, 0xCC000001, .NET metadata will be invalid but Mono happily accepts the file. WTF?

Extra protection by AndroidThaiMod

Game hacks created by AndroidThaiMod.com take the Unity3D/Mono abuse to the next level. They exploit all the bugs I already mentioned. In addition to that, they replace the original libmono.so with their own version. In their version there are few extra lines of code in the function mono_image_open_from_data_with_name:

This change allows AndroidThaiMod to distribute their DLLs encrypted with "extra-strong" XOR encryption. smile

Another fun fact - their cheats only hack ARM version of Unity3D runtime. x86 version, even if present in original APK, gets removed from the hacked APK. So, if you have an Android device with x86 CPU, you're out of luck - AndroidThaiMod cheats won't work there.

Few AndroidThaiMod files I was able to find on Google:
https://drive.google.com/file/d/1g2_43rP9LLrXSmGL-Lw36GTehSUmg3CJ/view
https://drive.google.com/file/d/0B7jRiqM-QmgUeUF2RldrRUFmcUk/view

Other possibilities of abuse

As I mentioned, Mono PE loader is extra buggy. Pretty much all fields in PE header are not validated properly. Plenty of fields in .NET structures are ignored. PE32+ header processing is broken beyond belief. File/section alignment is not enforced. You can have several streams named "#~" and Mono will happily use one of them. Or you could just search for a phrase "FIXME" in Mono sources - you'll find lots of other dirty hacks that can be exploited.

Can it be fixed?

Probably. But considering how broken and messy the entire Mono codebase is, I wouldn't bet on it.

For example, on 13-Apr-2018 Mono developers made this awful commit called "Verify all 4 bytes of PE signature.":

There was no explanation why it was done, what are the side effects and whether they plan to fix all the broken code or if this was just a one-off fix. What a surprise!

And, as I already mentioned, Unity3D is using 3+ years old version of Mono. So, you'll probably have to wait until year 2021 until Unity3D gets they necessary fixes. bigsmile

Workarounds

Even if Mono and Unity3D was fixed, it doesn't help us to analyze existing broken files.

One workaround was to update dnlib (commit c40e148) and reversing tools to support such broken files. It allows to analyze existing files using dnSpy and de4dot. But Reflector and other tools still won't work. So, I decided to make my own tool which will fix broken files and will allow you to use any .NET reversing tool you like.

I needed a PE/.NET reading library which is very simple and low-level. dnLib/Mono.Cecil is way too abstract. After a quick search, I decided to use parts of McCli - but any other library would do just fine.

The code is very straightforward. Read PE structure->validate->fix->repeat.. wink

Conclusion

Games and cheats made using Unity3D are great. It's possible to make very unique protections that will stop most Windows/.NET reversing tools but the program will still work on Android. Enjoy the fun times! smile

Unity3D fixer with source code: https://mega.nz/#!g4A3WajL!PBRF5f6OIj-0xkm09Zg2T_YydcmCW2XtYI9Di82aIJ8

27 Feb

February update of unpackers

Enigma Virtual Box unpacker v0.51

  • Hopefully solved the UI-freeze issues.
  • Improved loading speed for big files (100+ MB).
  • Added a warning for the user when loading big file:
  • Added support for Enigma Virtual Box v8.00.
  • Enigma Virtual Box v8.00 finally added support for TLS callbacks. My unpacker will detect such files and will try to fix TLS directory automatically.

Known issue - for x64 executables exception directory is not restored. The unpacked executable will work until an exception happens. If you find any such executable, please send it to me and I'll work to improve the unpacker.

demoleition v0.60

  • Hopefully solved the UI-freeze issues.
  • Fixed bug with certificates and overlays that I introduced few versions ago.
  • Fixed bug with multi-packed files
  • Main form shows that only Molebox v2.x is supported.
  • Improved loading speed for big files (100+ MB) and added warning for users.

demoleition VS v0.01


This is first BETA release of static unpacker for Molebox v4.x. It works for most of the files in my collection but is not well tested by any means. If you notice any bugs (trust me, you will!), please let me know.

Known limitations: way too many. Few most important ones:

  • Error checking is very limited. If something bad happens, it will most likely crash.
  • Main file is saved as _unpacked.bin. Overlay (if present) is saved as overlay.bin.
  • The biggest problem is the "hide files" feature of MoleboxVS. It does not store original filename, just the MD5 hash of it. So, in those cases it's almost impossible to restore original filenames. I added big fat warning for those cases.
  • Loading large files will make the UI freeze. I'll fix it after the bugs in unpacker itself are fixed.

So, why release it? I've had it like this for 5+ years now. It almost works. But without your feedback it will stay in this "almost working" state forever. The more bugs you report, the bigger the chance that I'll finally finish this project.. So, have fun!


Bugs reported by users. I'll work to fix the when I get some free time.

  • Some data files can't be unpacked. Error
  • Sometimes main EXE file will not be unpacked. No error message but _unpacked.bin file won't be created.
  • Mysterious unpacking problem on some files. Error
  • Very large data files can't be unpacked. Error
20 Dec 2017

December update for unpackers

This month brings us not one but two updated unpackers! smile

Updated Molebox unpacker

  • Fixes a crash with double-packed files. Thanks to whoknows for reporting the issue!

Updated Enigma Virtual Box unpacker

  • Support for Enigma Virtual Box v7.90
  • Detection of Enigma Protector. The feature was added long time ago but accidentally removed later.

I still need to work on the UI-freeze issue. When unpacking very large files, UI will appear to be frozen until unpacking process completes. It may take 5+ minutes on very large files, please be patient!

21 Nov 2017

Running WinDbgX on Windows 7

Motivation

Main reason for writing this blog-post is the extremely crappy article by Vallejo named "Installation and First Contact With the New WinDbg". I read it, cried for a few minutes and decided to fix it.

Mandatory XKCD reference:
Someone is wrong on the Internet

Having said that, let's go through some of the most "brilliant" Vallejo's statements!

Installation

We execute WinDbg from installation shortcut and we search the main process.

Dude, when your article is called "Installation and first steps..." shouldn't you start at the beginning and tell us where to get this app and how to install it?

You need to get the app from the Windows Store: https://www.microsoft.com/store/apps/9pgjgd53tn86.

No, there is no real technical reason for that, just another attempt of Microsoft to convert you to Windows 10 and make you use their Windows Store.

To make matters worse, you need to have installed the latest and greatest update of Windows 10 to do that. There is no technical reason for that, either.

After you've jumped through all those hoops, you get this nice and shiny Windows Store app. Windows Store apps get installed under "C:\Program Files\WindowsApps\" and this one is no different. At the moment of writing the application version was 1.0.16, so it got installed into "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.0.16.0_x86__8wekyb3d8bbwe".

Reparse point

The installation creates another exe here: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\WinDbgX.exe. It is zero bytes, and if you try, for example, to copy it, you can’t.

Because it's a reparse point, not an EXE file.

Windows 10 processes bundled Windows Store application's AppxManifest.xml and creates appropriate appExecutionAlias'es:

Same thing goes for all other applications Vallejo "found" under C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\, like dbgsrv64.exe:

You can read more about aliases on MSDN: Start your app by using an alias.

Fsutil

I have not found a tool or way to manage or get information about these files.

Ever tried fsutil? It's been part of Windows since Windows7.. bigsmile

Here's output of fsutil reparsepoint query WinDbgX.exe:

As you can see, it's a reparse point with a tag 0x8000001b (IO_REPARSE_TAG_APPEXECLINK).

Sure, you can Google for that - but it won't tell you much, except that it's not really documented and should be left alone.

Command-line

Old windbg.exe accepted parameters with “-“, for example -k. New Windbg needs /k parameter to pass the connection configuration

Bullshit! In fact, WinDbgX accepts any of 4 different delimiters: "-", "–", "—", "/" and combinations of those..

Ok, that was enough criticism for one day. Let's do something more constructive!

Running WinDbgX on Windows 7

Remember how I said that there is no technical reason why WinDbgX should be available only on Windows 10 and only as a store app? There really isn't. smile

Here's WinDbgX running on my Windows 7 and debugging one of the FLARE2017 crackmes:

It's actually a really simple fix.

  1. You need to copy all the files from your Windows 10 machine to your other machine (Windows 7 in my case). It's as simple as selecting all files in "C:\Program Files\WindowsApps\Microsoft.WinDbg_1.0.16.0_x86__8wekyb3d8bbwe" and copy-pasting them. Don't worry about the reparse points in C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\, we'll fix that later.
  2. If you try to run DbgX.Shell.exe on Windows 7, it will fail with Exception:
  3. Let's look at that code in DbgX.dll using dnSpy:

    It's crashing on the Package.Current.Id.FamilyName, as this function is available only for Windows Store apps.

    As a simple hack, we can replace this call with an empty string. Better hack would be to use the proper folder based on the actual WinDbgX path. But the simple way will do for our demo..

  4. Using "Edit IL instructions" function in dnSpy, replace first 4 instructions with ldstr and nops:
  5. Save the module. If saving fails, remove read-only attribute from DbgX.dll and try again.
  6. Since we chose a simple hack, create folder C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\
  7. Depending on your OS (32- or 64-bit), copy files from WinDbgX\X86 or WinDbgX\amd64 folder to C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\. Rename dbgsrv.exe to dbgsrv32.exe or dbgsrv64.exe accordingly.
  8. Run the DbgX.Shell.exe shell now. It will work just fine!

There are 3 more places in DbgXUI.dll, DbgX.Util.dll and Extensions\DbgX.External.dll that might need similar fixes. But that's behind the scope of this article.

Conclusion

It is true that classic WinDbg looks really dated. So, I can totally understand why Microsoft would want to create a replacement with a better UI. However, WinDbgX falls short on everything - its installation via Windows Store is brain-dead stupid, its user interface is confusing (who would look at Model->Change Query to change debugger settings?!) and severely limited (no multiple Memory windows, seriously?). If it was a school project, it wouldn't get even a B-. But for some reason, Microsoft insists that this is the only way forward. Oh, well.. sad

At least, the DLLs are not obfuscated, so someone can take them and make a much better UI.. wink

Have fun!
kao.

04 Oct 2017

October update to Molebox unpacker

Thanks to my reader Max I have fixed another bug in the Molebox unpacker.

  • Removed memory leak that caused "out of memory" error when unpacking very large files (1.5GB+)

The usual request

I hope you find this unpacker useful. But if it doesn't work for you, please send me an error report with all the details you can and I'll try to fix it. Have fun!

22 Aug 2017

Yet another update to Molebox unpacker

Thanks to my readers I have fixed few more bugs in the Molebox unpacker.

  • Better support for non-ASCII symbols in filenames
  • Very large (4GB+) files will now unpack correctly
  • Unpacker will extract embedded files packed with old versions of Molebox (like version 2.0570)

The usual request

I hope you find this unpacker useful. But if it doesn't work for you, please send me an error report with all the details you can and I'll try to fix it. Have fun!

19 Aug 2017

Use of syscall and sysenter in VMProtect 3.1

Few days ago Xjun briefly mentioned a new feature of VMProtect 3.1 - it uses direct syscalls to check if software is running under debugger. I decided to take a quick look myself and figure out how exactly it works.

I'll give you 2 targets for the research:

  • oppo_flash_tool.exe (https://mega.nz/#!ZgJzjQxR!cNEHMwM-jKnLVgPXf4OUupyk1DNt69FYB2rEfY-5AlA) - it was given as an example by Xjun;
  • asshurt.dll (https://mediafire.com/?3xyc0ugc2hxervn) - some sort of a cheat for Roblox. I don't care about the cheat itself, it just happened to have the syscall feature enabled. And it uses different syscalls than Oppo.

In addition to that, I'll provide a very simple demo executable which replicates part of the VMProtect protection, so that you don't waste time looking at obfuscated code.

As a debugger in 32-bit OS you can use anything you like. On 64-bit OS you will really need to use WinDbg - as far as I know, it's the only debugger that can handle those tricks..

32bit OS

Let's start by debugging oppo_flash_tool.exe. First, we need to get past the usual tricks like IsDebuggerPresent and CheckRemoteDebuggerPresent. If you're reading this, I'm sure you know how to do that.

Few moments later we'll arrive here:

Remember this conditional jump. It's taken on 32bit OSes and not taken on 64-bit OS.

Let's look at 32bit OS version first. Now VMProtect prepares to call sysenter.

Since the code is obfuscated, here comes a cleaned-up version. Please note that in other applications, different registers can be used.

64-bit OS

Here it is getting interesting! smile You cannot use sysenter instruction from 32-bit code in 64-bit Windows. But, as ReWolf described few years ago, one can mix x86 code with x64 code in the same process. And that's exactly what VMProtect 3.1 is doing.

Let's go back to that conditional jump and see what happens in 64-bit OS. The jump will not be taken:

Far call?! Last time I saw that was in 16-bit Windows era..

As explained in ReWolf's article:

Summing things up, for every process (x86 & x64) running on 64-bits Windows there are allocated two code segments:

  • cs = 0x23 -> x86 mode
  • cs = 0x33 -> x64 mode

So, as soon as you execute that call, you'll switch to a 64-bit world. WinDbg happily recognizes that, all other debuggers just go astray..

x64 code does pretty much the same thing as x86 code - sets up a stack frame, sets up registers and then executes syscall instruction. Cleaned-up and shortened version follows:

You'll notice that x64 version is slightly more complex due to the way parameters are passed (registers vs. stack). It also includes a special treatment for 8 special edge cases - it will modify syscall parameters to adjust buffers and pointer sizes to satisfy requirements for 64-bit code.

NOTE - to keep code simple, I only showed the part which deals with NtQueryInformationProcess but other cases are similar.

As you can see, return back from x64 to the x86 world is a simple retf instruction. x86 code continues right where it left off:

Instruction at address 0x00ddaeba is the same for both x86 and x64 OS-es and VM continues as usual.

Different protection modes and syscalls

I provided you with 2 real-world test executables. Oppo seems to be simpler and use just 3 syscalls:

  • NtQueryInformationProcess with ProcessDebugObjectHandle class
  • NtSetInformationThread with ThreadHideFromDebugger class
  • NtProtectVirtualMemory to set protection attributes for each section in original executable

Asshurt doesn't have antidebug trick with NtQueryInformationProcess but it uses additional syscalls for some purposes:

  • NtOpenFile
  • NtCreateSection
  • NtMapViewOfSection
  • NtQueryVirtualMemory
  • NtUnmapViewOfSection
  • NtClose

Suggested workaround

Since VMProtect is using undocumented Windows features, it somehow needs to ensure that the protection will work on each and every Windows version. That's VMProtect's biggest strength and also the biggest weakness.

Windows' syscall numbers change in each version and also between major builds. Use the wrong syscall number and you're guaranteed to receive unexpected results. So, VMProtect developers had to hardcode a table with Windows build numbers and corresponding syscall id's in the executable.

You can see the syscall numbers in the j00ru's page (slightly out of date) or in tinysec's windows kernel syscall table

To obtain Windows build number, VMProtect uses information from PEB (Process Environment Block). The method is already described in The MASM Forum, so I'll just reproduce the (ugly) code from their page:

VMProtect checks only the build number and picks the corresponding syscall number. However, if the build number is not in the internal database, it will not use direct syscall and fall back to standard protection. Bingo, problem solved - no need for ugly hacks like Xjun's SharpOD plugin!

Hint: VMProtect 3.1 doesn't support Windows 10 Creators Update (build number 15063).

Demo time

As promised, here is a download link for the test application: https://mediafire.com/?niqqbs0fqcq8n23
Note: it should support most common builds of Windows XP/7/8.1/10. Windows 2003/Vista and other rare systems are not supported!

If it shows "OK" message, you've hidden your debugger well. If it shows "Debugger detected", you have a problem. smile

Have fun!
kao.

EDIT: Updated download link for Oppo. Mediafire's antivirus tends to have plenty of False Positives..

02 Jun 2017

Enigma’s EP_CryptDecryptBuffer internals

For one of my private projects, I needed to decrypt some data. Original executable uses Enigma's EP_CryptDecryptBuffer function but I needed to implement the same thing using .NET. Much to my surprise, there was no information about what encryption algorithm is used by Enigma or how it works internally. So, I started by compiling Enigma's sample project CryptBuffer and debugging the executable.

TL;DR - IDEA cipher in CBC mode, password = MD5(user_password), IV for CBC comes from IDEA.Encrypt(8-zeroes, password).

Research

After protecting my executable with Enigma, few assembly lines

got changed into something horrible that looked like an Enigma's VM:

I didn't feel like spending my time on analyzing that. Much easier solution was to put hardware breakpoints on my data and password and wait for them to trigger. In a few seconds I landed into code that looked like MD5 (notice the constants!):

and few hits later I landed into code that I didn't recognize at first:

Delphi compiler had helpfully included RTTI information telling me that this second piece of code belongs to a class called TIdeaCipher. Now I had all the information I needed, I just had to put it all together. smile

Implementing decryption in C#

There aren't many IDEA implementations in C#. In fact, there are 2: by BouncyCastle and by LexBritvin. Since I'm not a big fan of huge and complex libraries like BouncyCastle, so I took the simplest possible code: from Github and modified it a bit.

First, we need change password generation algorithm to use MD5 to generate real password:

Second, we need to add support for CBC mode. It requires both calculating correct IV value and pre/post-processing each block we're encrypting or decrypting.

Calculating IV is quite simple:

Processing each block is slightly harder but not a rocket science either. As explained in image borrowed from Wikipedia:
.

Before decrypting the data block, we need to store the encrypted values as IV for the next block. After decrypting the block, we need to XOR each byte of data with a corresponding byte of IV. Unfortunately, during encryption the data flow is different, so the simple crypt function has to be replaced with 2 functions: encrypt and decrypt.

Few more cosmetic changes and that's it! We got clean and nice implementation of EP_CryptDecryptBuffer in pure C#. smile
Download link: https://bitbucket.org/kao/ep_cryptdecryptbuffer/

Have fun!

P.S. My implementation only supports cases where data length is divisible by 8, adding support for other lengths is left as an exercise for the reader.

12 May 2017

VMProtect and dbghelp.dll bug in export processing

If your Olly is crashing when loading executable protected by VMProtect, you most likely have outdated dbghelp.dll somewhere on your path. Grab the latest version from Microsoft and put it in the Olly folder.

Well, that might be enough to work around the issue that I had - but I still wanted to know what's causing the crash.

Cause of the problem

If you try to debug Olly with another Olly, you'll see the Access Violation happening somewhere in dbghelp.dll:

Check register values in Olly:

For some reason, value in EDX is garbage and therefore access violation happens.

Call stack doesn't tell us much:

And same piece of code in IDA doesn't help much either:

So, it's debugging time! Set breakpoint to start of LoadExportSymbols, then set hardware breakpoint on write to address [ebp+ptrAllocatedMemory].

First hit is initialization of variable with 0:

Second hit stores the address of allocated memory:

And third time is a charm:

Good folks at Microsoft have left us with a nice buffer overflow. exportFunctionName is defined as byte array of size 2048 bytes. Any exported function name longer than that will cause stack overflow and (possibly) subsequent crash.

010Editor with PETemplate confirms that the export name is indeed very long (3100 chars):

From what I can tell, it's a similar (but not the same) bug to what was described by j00ru at http://j00ru.vexillium.org/?p=405 (see "PE Image Fuzzing (environment + process)")

Stay safe!

P.S Here's an example file, if you want to test your Olly: https://forum.tuts4you.com/topic/38963-vmprotect-professional-v-309-custom-protection/
P.P.S. CFF Explorer, HIEW and IDA do not show us any exports in this example file - but that's a matter of another story..

21 Apr 2017

Updated Enigma VirtualBox unpacker again

This update has been long overdue. Finally it supports files larger than 2GB! smile

Full changelog:

  • Supports files larger than 2GB. Yeah!
  • Correctly recognizes EnigmaVB 7.50-7.70;
  • You can use command-line EnigmaVBUnpacker.exe /nogui [pathToFile] to unpack file, save results to !unpacker.log and close automatically.
  • NEW: fixed "Error creating temporary file"

Hopefully I didn't break anything during the rewrite. But if I did, send me an email and I'll fix it! smile

EDIT 2x: Very stupid error fixed. /me embarrassed. Sorry.