16 Oct

About FLARE 2018

For last few years I'm taking part in the FLARE-ON competition. This year I finished 4th - which is not bad at all. smile

Mandatory bragging screen:

Now that the challenge is over, it's fun to read all the solutions. Of course, there are official solutions - they explain what the challenge does and one way how to solve it. Nice but I want more. smile

Then there are "writeups" which basically say "this is my code that gets the answer". Dude, if that makes your e-penis seem bigger, feel free to twit about it. But I don't care about your code. Really.

What I do care about, is how the challenge can be solved. So, here are few selected challenges and related writeups that actually make sense.

Challenge #2 - minesweeper

I wasted too much time on it, relatively speaking. Whopping 37 minutes, on a challenge #2!

I will blame the fact that I was barely awake at the time. In the end I resorted to editing variables in dnSpy, just like @bruce30262 does in his solution.

Other solutions:
* By @mathmare_ - remove IL that triggers failure.
* By @jared703 - find the correct spots.
* By @Eleemosynator - another "find the correct spots".
* By @bruce30262 - edit variables in dnSpy.

Challenge #5 - webassembly

It was my first real encounter with Webassembly, so I just used Chrome to debug it. Plus wabt just to get a better look at the disassembly. It wasn't that bad in this particular case.

Since I don't really do Linux and gcc, I wasn't able and willing to try WASM-to-C conversion and compilation to x86 code. bigsmile

Other solutions:
* By @ctfhacker #1 - uses Chrome, shows the recompilation as well.
* By @ctfhacker #2 - uses wasabi.

Challenge #6 - solving 666 tasks on Linux

My Linux skills suck and I wasn't able to find a reliable way to pipe output from my solver into the challenge.

So I solved the task like a trained monkey.

This bash crap uses gdb to get current challenge from process memory and feeds it to my C# solver running under Mono. Output from solver gets fed to xclip which puts solution into the clipboard. Then I right-click mouse and paste solution into the challenge window. Repeat 666 times. The entire process takes around 20-30 minutes. Click-click-click-click..

Yes, it's extremely inefficient and braindead stupid - but the result is guaranteed and faster than spending hours trying to learn how to automate Linux tools.

Other solutions:
* By @MrAdz350 - uses Unicorn, pexpect.
* By @crudd40233929 - patches original binary to generate keys, uses pexpect.
* By @0xabc0 - uses Frida.
* By @bruce30262 - uses pwntools to send answers to challenge.
* By @ctfhacker - shows how to use angr. Solver needed 28 hours to finish! bigsmile

Challenge #12 - VM inside the VM

This challenge actually consisted of 2 separate parts - 16-bit bootkit and a nasty VM in the VM. Since it was the final challenge everyone just focused on breaking the VMs. It's a shame because the bootkit part was extremely nice and deserved much more attention than it actually received.

Until the official solutions came out, I didn't know Subleq code actually ran another VM! Why? Because my solution was data-flow analysis done with pen and paper. When I finished, it looked like this:

Yes, all 10 pages are from this challenge.

Close-up of one of the pages:

Each row contains a flag that I traced, columns are the "cell indexes" of Subleq VM and values are the values I observed during the run. Plus notes, plus attempts to recover the formula..

Kids, don't try this at home! smile

Other solutions:
* By @bruce30262 - writing 2 disassemblers.
* By @SalimSolid - tracing instruction pointer.
* By @invano #1 - cat'n'grep
* By @invano #2 - disasm + recognize high-level macros.
* By @Dark_Puzzle - snapshotting VMs and bruteforcing chars.

30 Sep

September update of unpackers

Last few months have been... extra busy. I survived HDD crash, participated in Flare-On reversing contest (and finished 4th!), had quite fun projects at work - but all that is a matter of another story. Today I want to share with you a long-overdue update for unpackers.

Enigma Virtual Box unpacker

  • Added support for Enigma Virtual Box v8.10, v8.20, v9.00 and v9.10.
  • Unpacker now restores file attributes and date/time. Be careful, unpacked files might have attributes "read only", "hidden", etc.!
  • Added validation of extracted folder/file names to prevent directory traversal attacks. It was on my todo list for a long time and all the media-craziness around Zip Slip finally forced me to do something about it.
  • Fixed warning message about TLS directory. Mea culpa.

Molebox Virtualization Studio unpacker

  • Fixed error "VFSDecrypt: failed to find STELPACK signature" on some data files;
  • Fixed error "SPack catalog not found or invalid. vfsrootsize=00000000" on some EXE files;
  • Fixed out-of-memory error when unpacking huge data files;
  • Loads possible filenames from mole_dictionary.txt;

How to use mole_dictionary.txt

If you have a file which uses "hide files" feature of Molebox VS, it only stores hash of the filename - original filenames are not stored anywhere. But if you have a good idea what the filename might be, you can add it to mole_dictionary.txt and my unpacker will use that for intelligent guessing.

You must enter path relative to where the main executable is, for example: data\magic.dat. DO NOT enter full paths like C:\Program Files\My Program\data\magic.dat, they will not work.

You can also add comments for your convenience - any line starting with "//" is treated as a comment and ignored.

If your paths contain non-English characters, make sure you save mole_dictionary.txt in UTF-8 encoding with BOM.

Real-life example of mole_dictionary.txt

There are lots of different "editions" of Tantra Online game. They all need specific files like HTSound.dll, HTWeb.dll or system\MobInfo.tan to run properly. However, this specific version called Tantra Surya has packed all files inside HTLauncher.exe and .sps files

and enabled "hide files" feature:

My unpacker does the job but original filenames are lost:

To improve unpacking results, you can add list of files normally used by Tantra into mole_dictionary.txt. Let's start with something simple, files that normally are in Tantra root folder:

After that, unpacker works much better. It has recovered most of the DLL names and just 5 filenames are unknown:

Of course, the more possibilities you add, the better are chances that the filename will be recovered. smile So, let's look into some subfolders..

Take, for example, this map folder:

Compare it to the same map folder in some different Tantra edition, in my case - Prime:

Now we know what filenames to add to mole_dictionary.txt:

Run the unpacker again on the packed HTLauncher.exe and the result is much better:

You can keep on building your dictionary until all the unknown filenames are resolved. But that's your task, I will not do that for you.. smile

Have fun and as always - please let me know if you notice any issues!

26 Jun

x64dbg – 2 years later..

Almost 2 years ago I wrote a post about x64dbg and why I don't use it in my work. People still comment on the article, so I decided to revisit x64dbg and see if anything has changed in past two years.

Improvements

Some menus are slightly cleaned up. Not by much, though.

Now you can customize the context menus and hide all the crap you don't need or want. I'd preferred to have the crud removed altogether but it is a really nice feature:

Feature bloat

It's getting slightly better. Instead of three different assembler engines we have "just" two. However, other useless features like "Help on mnemonic" are still there. What for?

And some of the big bloat is still there (eg. Snowman and Yara). Those are standalone tools, not core features. In my opinion, it would make much more sense to have them as plugins so the user can choose whether to have them or not.

But it's still buggy

I tried to use x64dbg for one day - for doing actual work. And during that day, I encountered several serious bugs which seriously affected my work.

Assembler is buggy

Have you ever tried to assemble a simple instruction using x64dbg? For example, mov rax,1 ? You might get a different instruction instead..

As of time of writing, this is the latest x64dbg build available for download. The bug is reproducible on older builds as well.


Why is that? I'd say it's because of the feature bloat. There are 2 assembler engines and apparently at least one of them is not tested properly.

Can I work around it? Yes. Once I know that AsmJit is broken, I can use XEDParse all the time. But it shouldn't be like that in the first place!

Ignored exceptions are not ignored.

Ever tried ignoring exceptions? It kinda works. Sometimes. But not always. From what I see, it's totally random - but 100% reproducible.

Again - using the latest build, x32dbg this time:

Sounds like a minor annoyance to you? Try debugging executable that uses "int 3" as an anti-debug measure everywhere. It's basically impossible with x32dbg.

Conclusion

Some things have improved. But overall, it's still the same product it was 2 years ago - good for some simple tasks, unreliable for an actual work.

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

24 Apr

About City of Atlanta and ransomware

I just read the article on ZDNet: "Atlanta projected to spend at least $2.6 million on ransomware recovery". Yes, you read it right - $2'600'000 to clean up the Atlanta city network from ransomware. And, of course, taxpayers will pay the bill. smile

Dear City of Atlanta, this situation will not magically resolve itself. Your IT guys must take the responsibility for this failure. Fire your CIO. Fire your entire IT staff. Sue them all for the damages. And let them rot in prison for a few years for gross negligence.

You hold an architect accountable for making your house blueprints right. You hold the builders accountable for building your house right and your doctor for taking a proper care of you.

IT guys are not special snowflakes, they don't do magic, and they must be held accountable for their (in-)actions just like everyone else. Only then we'll see some improvements in security.

 
But I'm sure City of Atlanta knows better. After all, they decided $600'000 on advisory services from Ernst & Young on how to handle security incidents. That's a money well spent! </irony>

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
10 Jan

F00F bug or why morons shouldn’t be writing about security (again)

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?

  1. 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.
  2. 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.

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.

02 Nov 2017

Complicated state machines – or how Unit42 “discovered” .NET Reactor

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:

So, apparently, the latest versions of de4dot are buggy. Let's use an older version:

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:

Lessons learned

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.

Further reading

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