Updated Enigma VirtualBox unpacker again

kao

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

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! 🙂

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

Updated Molebox unpacker

kao

During last year, the most common complaint on this blog was "your Molebox unpacker cannot unpack this crazy big EXE of MMORPG game X, Y or Z."

Sounds like an easy problem to fix, right? Well, that's not true - but I finally did it!

TL;DR:

In the rest of the post I'll describe the obstacles I had to overcome while solving this seemingly simple problem.

Delphi TMemoryStream limitation

First, unpacker is written using classic (non-.NET) Delphi and compiled as x86 executable. And standard Delphi streams are retarded. TMemoryStream uses GetMem - which ends up somewhere in Delphi memory manager and VirtualAlloc. That doesn't work well with 800+MB files.

I ended up with implementing custom stream backed by temporary file (CreateFile with FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE).

Pointer magic

Since the original unpacker was using TMemoryStream, the whole file was loaded in memory as a continuous memory block and I could easily read/write each byte of file using pointers. Something like this:

function Decode_Stage2(p: pdword; size: dword; key: dword): dword;
var
   d: dword;
begin
   result := 0;
   d := 0;
   while d < size do begin
      key := key * $19660D + $3C6EF35F;
      p^ := p^ xor key;
      inc(p);
      inc(d, 4);
   end;
end;

...

Decode_Stage2(pointer(dword(f.fImage.Memory) + f.RVAToOffset(startAddress - f.NtHeader.OptionalHeader.ImageBase)), endAddress - startAddress, decryptionKey);

Guess what? Files don't work that way.. 🙁 I had to do a full and complete rewrite of all those methods.

Zlib conflicts

Original unpacker was compiled with Delphi 3. Delphi 3 didn't have Zlib library, so you had to supply your own Zlib implementation. But it won't compile with new versions of Delphi, giving error message

Unit Graphutil was compiled with a different version of zlib.TZDecompressionStream.

The solution was to get rid of my Zlib implementation and rewrite all methods that deal with decompression.

ANSI strings

In Delphi 3 all strings were ANSI. Starting from Delphi 20072009, strings are Unicode. Since Molebox internally uses ANSI, it required changing quite a few structure definitions and rewriting several string manipulation routines. It's a lot of fun (and source of the most obscure bugs), trust me!

Conclusion

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!

MoleBox goes out of business

kao

Molebox as it used to be

A bit of history

MoleBox 2 was released in year 2003 and it was one of the first file virtualization solutions in the market. It bundled executable with the DLL and data files into a single EXE file. At that time that was something new and innovative.

They had quite a success and released another product (MoleBox Ultra, later renamed to MoleBox Virtualization Solution) in year 2009. Apparently it was very hard to fight in the increasingly more competitive market of application virtualization solutions and the last version of MoleBox Virtualization Solution was released in 2013.

Game over

In February 2016 domain molebox.com was sold for $1526. Yesterday their web server started serving generic WordPress page with dating-related spam. And that is just sad. 🙁
MoleBox dating advice

Release of static unpacker

However, both editions of MoleBox are still very popular with private game server owners, as they allow to bundle patched EXE files together with their custom data files. It's not a bullet-proof security but stops newbies from stealing their valuable data.

Since the MoleBox company is officially out of business now, I have no more reasons to keep my static Molebox unpacker private. It supports most versions of MoleBox 2.x including the external box files.

Have fun guys!

Download link: see October update to Molebox unpacker for an updated version.

P.S. This post was made just because I noticed changes in MoleBox web, I wasn't planning to release the unpacker today. So, please keep in mind this code was written in year 2009 and has had only one small fix applied in 2015. It's likely that you'll encounter some bugs and quirks - please send me the problematic file and I'll fix the bug. 🙂

P.P.S. I have static unpacker for MoleBox Virtualization Solution as well. But it doesn't have a nice UI yet, so it will be released on a later day.

About .NET, googling and lazy programmers.

kao

Delphi fail. .NET win.

Recently, several people sent me bug reports where my EnigmaVB unpacker failed to extract files. In all cases, the problem was caused by really large files, like 3.5GB in size. So, what's causing the problem?

EnigmaVB unpacker is a 32bit application written in Delphi. And Delphi streams are retarded. They look like they've been written in 1990s and were never updated. TMemoryStream uses a continuous memory range, so it can never support anything larger than 2GB. TFileStream internally uses longint, so it doesn't properly support files larger than 2GB. WTF?

So, I have two choices. I can either make a custom stream class in Delphi, or I can pick another framework and rewrite my tool to use that.

I'm not a programmer, I'm a reverser. I don't want to spend my time developing custom stream classes. I'd very much rather use this time breaking some code. So, say hello to .NET framework - my next version of EnigmaVB unpacker will be made in C#.. 🙂

Am I a programmer or a googler?

While researching all the Delphi limitations and possible workarounds, I ran into this great article by Scott Hanselman. Reading both the post and the comments made me think a lot.

Does using Google to solve your programming tasks makes you less of a programmer? I don't think so.

In fact, I'm just lazy. Most people are. Why should I spend 30 minutes remembering basic algorithms for converting string to hex, if Google query can solve it in 10 seconds? Why reinvent the wheel and write CRC calculation from scratch? I'll just open StackOverflow and have a solution that's already tried and tested. It doesn't mean I can't do those boring tasks - I just don't want to.

How about you? Would you be able to write some tools without using Google and StackOverflow?

Static unpacker for AutoPlay Media Studio files

kao

tl;dr version - it unpacks stuff. Feel free to leech and reupload. Report bugs here.

Unpacker for AutoPlay Media Studio

Introduction

It all started with a topic on BlackStorm forums where whoknows posted a link to Reverzor - The first cloud based software that decompiles everything!.

Wow, a magic tool that does everything! Sounds too good to be true.. 🙂 Soon enough, li0n posted a link to the trial executable and I started looking into it. I quickly found out that it's written in AutoPlay Media Studio, and that there is no working unpacker for that.

I should fix that - and have some fun in process!

Existing tools and research

First, I found a great blogpost by Xiaopang - I wholeheartedly recommend that you read it.

And then there's a AmsDec.exe by mohsen.
amsdec
Unfortunately, it only works for some files (supposedly - v8.1, v8.2) and shows weird messages in Persian language. And it's not really a decompiler, it just extracts _proj.dat file from the cdd file. And, of course, it didn't work for Reverzor.

How AutoPlay Media Studio works

So, let's see what we need to do to unpack it all properly. As the authors of AutoPlay Media Studio wrote in changelog:

As we all know, anyone determined enough can break any protection system given enough time and resources, but the use of rolling codes renders generic attacks ineffective. You can now sleep a little easier!

Right... They are using ZIP files protected with randomly generated passwords and obviously have no clue how generic attacks work..

Unpacker needs to analyze EXE file, generate correct password and unzip files. If there's a cdd file, unzip that one too. And since it's that simple, I will use AutoPlay Media Studio as a target for a separate blogpost explaining how to write a static unpacker from scratch. 🙂

Since there are several options how you can distribute files built by AutoPlay Media Studio, here's a quick reference:

  1. you have just a single application.exe;
  2. Such files can be generated using "Publish -> Web/Email executable" feature in AutoPlay Media Studio. Example file would be CardRecovery v
    6.10 Build 1210 AIO Installer -nelly-.exe

    Drop the exe file on unpacker, it will unpack everything automatically. Then check the appropriate folder for extracted data files and _proj.dat for the installation script.

  3. you have a folder with application.exe and application.cdd in a subfolder AutoPlay;
  4. These files are created using "Publish -> Hard drive folder" in AutoPlay Media Studio. An example file can be, for example, Russian software (malware?) claiming to be a Photoshop installer.

    There is not much to unpack, as data files are in plain sight in folder AutoPlay and subfolders. Drop the exe file on unpacker, it will find cdd file automatically and unpack everything, including _proj.dat.

  5. you have application.exe and application.cdd files in the same folder;
  6. This happens when "Rename resource files" feature is enabled in AutoPlay Media Studio. It's one of those features that add fake security to the product:

    This option is designed to obscure the filenames of your resource files during publishing.

    This is a case of Users Sniffer. Similar to previous case, there's not much to unpack. Drop the exe file on unpacker, it will find cdd file automatically and unpack everything, including _proj.dat.

Advanced use cases

But sometimes things are not that easy. So, here are few possible scenarios how to deal with modified AutoPlay Studio:

  1. application.exe is packed and there is application.cdd file present.
  2. This is a case of official AMS studio challenge that Xiaopang mentioned on the blog. Good news - you don't need to be an unpacking wizard and properly unpack PCGuard to break their protection. It's enough to run the EXE in VMWare, dump process memory and drop dumped exe on my tool. As long as PE header and section table is correct, it should be fine.

    Step-by-step:
    1) Run and dump:
    challenge1
    2) When saving dump, keep the original filename. Otherwise my unpacker won't be able to find cdd file:
    challenge2
    3) Process dump with unpacker:
    challenge3

  3. application.exe is packed and there is no cdd file.
  4. This is the case of Reverzor. First you would need to unpack Enigma Virtual Box - for that you can use my other unpacker.. 😉 Now you have both exe and cdd files but exe file is still packed with ASPack. Again, you don't need to unpack ASPack properly, just run & dump process memory. Then process dumped exe with my unpacker.

  5. application.exe is hacked and the cdd file is renamed to something else;
  6. This is a case of Idler. Author hacked AutoPlay engine and replaced file extension cdd with dll.
    idler
    There is no way for my unpacker to cover all such scenarios automatically, sorry. Just rename idler.dll to idler.cdd and drop idler.exe on unpacker.

Conclusion

This was a small weekend project for me. If it also helps you in some adventures, I'm happy. If it doesn't help you at all, I don't care. 🙂

Download the unpacker from:


Note - due to technical reasons it's compiled against .NET 3.5, if you wish to run it on computer with only .NET 4.0 installed, create amsunpacker.exe.config with the following lines:


<?xml version="1.0"?>
<configuration>
 <startup>
  <supportedRuntime version="v4.0"/>
 </startup>
</configuration>


And stay tuned for the upcoming post, where I'll explain how to write such unpacker from scratch!

Static Enigma Virtual Box unpacker, part 3

kao

Here comes a new version. Again. 🙂

EnigmaVB_Unpacker_v033

I added support for Enigma Virtual Box 7.30, (hopefully) fixed all issues with very long filenames and fixed an issue with processing command-line.

Thanks to ManOfWar for constantly supplying new challenges and parrot for bringing my attention to a bug with command-line.

Download link: Please get latest version from this post

Static Enigma Virtual Box unpacker, part 2

kao

Here comes a new version. 🙂 This time I added support for unpacking external packages. "External packages" are data files that can be loaded by Enigma Virtual Box and can contain both embedded files and registry entries.

I also made my unpacker 100% Unicode-aware - there should not be any more problems with non-english filenames. But I had to switch to Delphi 2009 compiler to do this, so there might be some unexpected bugs lurking around.

And, of course, lots of internal bugs had to be fixed. My code is not perfect, you know! 😉

EnigmaVB Unpacker v0.30

Download link: Please get latest version from this post

P.S. Thanks to Manofwar for giving me few example files for development & testing!

Improved static Enigma Virtual Box unpacker

kao

Last few weeks have been really hectic. I moved to a new apartment, so lots of time was spent on packing, unpacking, cleaning, and other non-computer related chores. Finally it's done, I got a great new place to live and I'm happy. 🙂

To relax and get back into shape, I spent an evening with one of my old projects - Enigma Virtual Box unpacker. I fixed few little bugs and added support for x64 executables.

EnigmaVB unpacker

Get it here: Please get latest version from this post