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.
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:
1[i] Loading large file, it might take some time...
- 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.
- 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. Error1[x] VFSDecrypt: failed to find STELPACK signature
- 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. Error1[x] SPack catalog not found or invalid. vfsrootsize=00000000
- Very large data files can't be unpacked. Error
1[x] Exception loading extra box file
Every once in a while, I read an article about security which is so incredibly bad that I just have to comment on it.
This time, it's an article from iTWire called "When F00F bug hit 20 years ago, Intel reacted the same way". It's written by Sam Varghese who claims to have decades of experience in the field. Let's see..
Make Intel CPU to hang remotely and anonymously?
Let me write that down!
Any Intel Pentium/Pentium MMX could be remotely and anonymously caused to hang, merely by sending it the byte sequence "F0 0F C7 C8".
This statement is incorrect in so many ways!
Yes, there was a bug in Pentium CPUs. CPU would freeze when executing instruction lock cmpxchg8b eax which has the opcode "F0 0F C7 C8". Can you see the difference?
- CPU doesn't hang on merely seeing the data sequence "F0 0F C7 C8". It hangs when trying to execute these bytes. Big difference! And if someone is able to run arbitrary instructions on your CPU, you have much bigger problems than just a simple hang.
- There is no f*ing way to run any code on any CPU remotely and anonymously. You can remotely exploit a bug in firmware/OS/software to execute some code - that's called remote code execution. But that is not specific to Intel CPUs and have nothing to do with the F00F bug in particular.
Dear Sam Varghese, please stop writing about security. Open a hotdog stand or do anything else that doesn't involve computers. You just don't get them.
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!
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:
Having said that, let's go through some of the most "brilliant" Vallejo's statements!
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.
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_184.108.40.206_x86__8wekyb3d8bbwe".
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:
<Application Id="Microsoft.WinDbg" Executable="DbgX.Shell.exe" EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements DisplayName="WinDbg Preview" Description="WinDbg Preview" BackgroundColor="#777777" Square150x150Logo="Resources\WinDbg_150.png" Square44x44Logo="Resources\WinDbg_44.png" />
<uap3:FileTypeAssociation Name="newtypes" Parameters="-z "%1"" desktop2:UseUrl="true">
<uap3:Extension Category="windows.appExecutionAlias" Executable="DbgX.Shell.exe" EntryPoint="Windows.FullTrustApplication">
<desktop:ExecutionAlias Alias="WinDbgX.exe" />
Same thing goes for all other applications Vallejo "found" under C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\, like dbgsrv64.exe:
<Application Id="Microsoft.WinDbg.DbgSrv64" Executable="amd64\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements AppListEntry="none" DisplayName="WinDbg Preview DbgSrv 64-bit" Description="WinDbg Preview DbgSrv 64-bit" BackgroundColor="#777777" Square150x150Logo="Resources\WinDbg_150.png" Square44x44Logo="Resources\WinDbg_44.png" />
<uap3:Extension Category="windows.appExecutionAlias" Executable="amd64\dbgsrv.exe" EntryPoint="Windows.FullTrustApplication">
<desktop:ExecutionAlias Alias="dbgsrv64.exe" />
You can read more about aliases on MSDN: Start your app by using an alias.
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
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.
Old windbg.exe accepted parameters with “-“, for example -k. New Windbg needs /k parameter to pass the connection configuration
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
- 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_220.127.116.11_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.
- If you try to run DbgX.Shell.exe on Windows 7, it will fail with Exception:
1234567891011***FATAL ERROR ENCOUNTERED***2017-11-21:20:01:12:504 : Error : DbgX.dll : (E) System.TypeLoadException: Could not find Windows Runtime type 'Windows.ApplicationModel.Package'. ---> System.PlatformNotSupportedException: Operation is not supported on this platform.--- End of inner exception stack trace ---at DbgX.DbgEngModule.SetDbgSrvOverridePathIfNeeded(Boolean use64Bit)at DbgX.DbgEngModule.DebugCreateOutOfProc(Boolean use64BitDebugger, Boolean shouldElevate)at DbgX.EngineThread.ThreadProc()System.TypeLoadException: Could not find Windows Runtime type 'Windows.ApplicationModel.Package'. ---> System.PlatformNotSupportedException: Operation is not supported on this platform.--- End of inner exception stack trace ---at DbgX.DbgEngModule.SetDbgSrvOverridePathIfNeeded(Boolean use64Bit)at DbgX.DbgEngModule.DebugCreateOutOfProc(Boolean use64BitDebugger, Boolean shouldElevate)at DbgX.EngineThread.ThreadProc()
- 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..
- Using "Edit IL instructions" function in dnSpy, replace first 4 instructions with ldstr and nops:
- Save the module. If saving fails, remove read-only attribute from DbgX.dll and try again.
- Since we chose a simple hack, create folder C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\
- 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.
- 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.
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
While browsing through my RSS reader, I ran into article from 09-Oct-2017, called OilRig Group Steps Up Attacks with New Delivery Documents and New Injector Trojan.
One part in the article caught my attention:
The “Run” method calls functions that has a state machine that dictates the actions taken. At a high level, these state machines attempt to create a process and inject the constructed payload into the newly created process. The use of state machines complicates analysis efforts because it makes the flow of execution jump around in a non-sequential fashion.
The state values jump around dramatically, which requires an analyst to also jump around the code to determine its functionality. This is an interesting anti-analysis technique we have not seen the OilRig actors use in their other tools.
.NET? State machines? Complicated technique we haven't seen before? Show me, show me, show me! bigsmile
Finding the DLL was relatively easy, finding the method they were describing was much harder. In the end I had to search for the constant "19" they mentioned in the article.. So, here is the method, in all its beauty:
If you're screaming "Dude, that code is obfuscated!", you're right. It is obfuscated.
If you're screaming "It's .NET Reactor!", you've spent too much time reversing .NET applications.
But you're right. It's easy to recognize the .NET Reactor by first few instructions, method renaming pattern and plenty of other things.
Have you heard of de4dot?
Let's try to run de4dot on this dll:
F:\>F:\de4dot-appveyor\de4dot.exe d.dll --dont-rename
de4dot v3.1.41592.3405 Copyright (C) 2011-2015 firstname.lastname@example.org
Latest version and source code: https://github.com/0xd4d/de4dot
Detected .NET Reactor (F:\d.dll)
ERROR: Hmmmm... something didn't work. Try the latest version.
Press any key to exit...
So, apparently, the latest versions of de4dot are buggy. Let's use an older version:
F:\>F:\de4dot-3.0.2\de4dot.exe d.dll --dont-rename
de4dot v18.104.22.16805 Copyright (C) 2011-2013 email@example.com
Latest version and source code: https://bitbucket.org/0xd4d/de4dot
Detected .NET Reactor (F:\d.dll)
Press any key to exit...
And let's look at the method again.
Strings are still unreadable, but where's the state machine? It's gone! Because it was never part of the OilRig actors toolkit, it was just a part of .NET Reactor control-flow obfuscation. smile
Decode strings and rename few variables and you'll see a very ordinary RunPE (aka. process hollowing) code:
The lesson is simple - you should know the subject you're writing about. And if you don't know something, ask your friends and colleagues. Otherwise you'll just embarrass yourself and your company.
If you want to learn more about this malware, I would suggest reading analysis by DarkMatter. At least they can identify .NET Reactor correctly. wink
This was the 3rd time I played Flare-On reverse-engineering contest. And I must say, this year was much nicer than the last. Challenges were more balanced, didn't require insane arcane knowledge and rick-rolling was kept to a reasonable minimum.
As for me - I wasted too much time and effort in challenge #7 and stopped competing at that point. Later I spent few hours every weekend just to finish the entire contest on time.
I'm not planning make full-featured writeups, so here's just an overview of this year's challenges.
#1 - login.html
ROT13, what else?
Time spent: 20 seconds
#2 - IgniteMe.exe
It's XOR. For some reason I kept messing up my answer. I guess I wasn't really awake yet. bigsmile
Time spent: 30 minutes
#3 - greek_to_me.exe
Bruteforce the correct byte value which will decode valid x86 code which will get you the flag. Simples.
Time spent: 15 minutes
#4 - notepad.exe
The worst challenge in the contest. To decrypt the flag, one must get data from last years challenge files. Self-centered ego masturbation, anyone?
Time spent: 2.5 hours
#5 - pewpewboat.exe
Linux challenge in form of a Battleship game with hardcoded levels. Simple to patch to reveal all ships and equally simple to write a C# decryptor that will decrypt all levels.
Time spent: 2.5 hours
#6 - payload.dll
You get a DLL and then mess with it's exports. Reminded me very much of last year's challenge #4.
Time spent: 2 hours
#7 - zsud.exe
It's a single-player dungeon. You get a native executable that functions also as .NET CLR host and as a web server. It loads a .NET DLL which in turn decrypts PowerShell code. PowerShell code then functions as a web client, sends the player's moves to server, server validates it and sends the result back.
I followed the wrong path and got stuck. I got to the powershell code all too quickly and neglected to look at the process itself. If I had done that, I would have noticed hooked API functions and would not have wasted too much time trying to bruteforce my way through..
Time spent: way too much
#8 - flair.apk
Mandatory Android challenge. It looked like there could be some anti-debug checks but JEB worked just fine. I solved each stage be reimplementing the check in C# and then breaking it.
Time spent: few hours
#9 - remorse.ino.hex
Arduino challenge, that's a first! smile I had to learn AVR assembly, find out how to debug stuff in Atmel Studio 7 and it was a walk in the park from there.
Note to self - IDA's support for Atmega is crap. Atmel Studio kicks ass.
Time spent: few hours
#10 - shell.php
PHP challenge. Boring. It all boils down to obtaining the correct XOR key by making intelligent guesses on how the valid PHP code looks like. Repeat 4 times for extra boredom.
Time spent: few hours
#11 - covfefe.exe
It's a VM. It has one instruction. It self-modifies the code. Very nice! bigsmile I solved it by making dynamic disassembler/emulator in C#. Just after solving it, I learned about OISC and subleq in particular..
Time spent: 6-8 hours in total?
#12 - [missing]
This was probably my favorite CTF challenge ever. You get a PCAP and a malware binary. You must decode custom protocol malware uses to communicate with the bad guys and extract all the data from packets. Throw in some dynamic plugins for encryption, compression and commands and you get a whole lot of fun stuff to analyze. Awesome! bigsmile
Time spent: ~18 hours in total?
Few more trinkets in my collection. And my first LEGO figurine. smile Thank you, LabyREnth!
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!