Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

{smartassembly} protection analysis + unpacker (with source)

This forum focuses on analyzing malware and any aspects of dealing with packer protections.
User avatar
arc_
Member
Posts: 90
Joined: Tue May 13, 2008 2:24 am

{smartassembly} protection analysis + unpacker (with source)

Post by arc_ »

A while ago I decided to get my hands dirty on .NET protections, and {smartassembly} by redgate seemed like a nice start. There already exist unpackers for this, but they seem to be mostly out of date (don't support the newer protections), and more importantly I was unable to find an explanation on how the protection actually works.

So I set out and explored it by myself. It turns out there is really not that much to this "first-rate obfuscator" as redgate calls it. The protection consists of these layers:
  • The names of non-public namespaces, classes, methods and fields are removed and replaced by junk. Not much to do against that.
  • All the string constants are encrypted. ldstr instructions get replaced by a call to a method that fetches the string by index.
  • All calls to imported methods (methods from externally referenced types) are obfuscated. They get replaced by a call to a delegate that passes control to the original imported method. This delegate is set up at runtime.
  • Some weak control flow obfuscation is performed. It's a bit like the strategic code splicing as seen in Armadillo: small code sequences of one or two instructions get moved to the end of the function, and a branch is placed at their original location.
  • Finally, all the resources are encrypted as well (but their names are left alone, e.g. in instantiations of ResourceManager).
That's it. Now let's look at these in a bit more detail.

String encryption
Every string literal is encoded as UTF-8 and then base64. It also gets a length prefix (which is variable-length encoded). All these length-prefixed base64 strings are then concatenated - the resulting block is then compressed using regular deflate(), and encrypted using regular DES.

The encrypted block is stored in the binary as a resource stream (with a GUID as name) and is decrypted and decompressed at runtime. This process consists of a loop which performs a deobfuscation pass on every iteration, passing the output of each pass as input to the next. It identifies the next layer to remove by a 4-byte header that is prepended to the data:
  • "{z}\0x02": decrypt the data using DES (key and IV are in plaintext in the binary)
  • "{z}\0x01": decompress the data using raw, headerless inflate
Every class that uses the ldstr instruction somewhere has a static field added which contains a delegate. Every ldstr instruction gets replaced by a call to this delegate. It accepts an int and returns the corresponding string through the following algorithm:
  • Subtracts its own metadata field index from the given number (i.e. the lower 24 bits of the metadata token)
  • Subtracts a fixed constant, which is stored as plaintext in the #US stream
  • The resulting number is an offset into the base64 block. It goes to that offset, reads the variable-length encoded string length, extracts the base64 string, decodes from base64, and decodes from UTF-8. Optionally the int -> string mapping is cached.
Imported methods
The actual imports (MemberRef metatable) are left completely intact, only the calls to them are obfuscated.

For every import method signature, a new delegate class is added to the binary (with no namespace). For every imported method, a static field is added to its corresponding delegate class, containing an instance of that class. Every call to an imported method is replaced with a call to that static delegate instance.

The delegate instances are initialized at runtime in the delegate class's static constructor. They get assigned a method body that is generated using reflection, which does nothing more but pass through the parameters to the original imported method. The index of the imported method to call (in the MemberRef table) is calculated from the name of the delegate instance field. The name also indicates whether the call is virtual or not.

Code flow obfuscation
Not much more to say about this than has already been said. The chosen code sequences get moved to the end of the innermost exception handler, or, if there isn't one, to the end of the method. This is not done very often in each method (most of the code is left unmodified) and no further junk code is added.

I solved this by building a basic block tree of the method and from there searching for "redundant" branches: unconditional branches to a basic block that is not reachable from anywhere else. I then remove the branch and "pull in" the target basic block to after the basic block that jumps to it.

Resources
All resource streams are moved out of the main file into a separate, new assembly that has a GUID as name. This assembly is then compressed and encrypted in exactly the same way and with the same keys as the strings block, and is also added as a resource stream with a GUID name (the same as the assembly name).

The <Method> .cctor is extended with code that registers two event handlers: ResourceResolve and AssemblyResolve.

Since the original resources were removed, any attempt to access them will result in the ResourceResolve event being triggered. The handler for this will do Assembly.Load with the name of the resource assembly (the GUID), and checks if this can serve the resource request. If so, it returns the assembly.

Of course, the resource assembly can't be loaded just like that since it doesn't actually exist as a .dll on disk. This is where the AssemblyResolve handler comes in. It compares the name of the requested assembly to the name of the resource assembly, and if this matches, it decrypts, decompresses, loads, and returns the resource assembly, all in-memory.

The unpacker
I couldn't come up with a clever name for my {smartassembly} unpacking tool so I just called it dumbassembly :p . It removes all code protections mentioned here except the destroyed names. It also decrypts and extracts the resources. I do not claim that it will work on all {smartassembly} protected applications. In fact, I only tested it on one (another redgate product). In the end this project was more about analyzing the protection and demonstrating how it works.

The unpacker is completely free and open source and also comes with the description of the different protection layers. So if you find a binary which the unpacker doesn't work on, you have the possibility of analysing and fixing the problem yourself.

Since I generally can't stand .NET applications because of their typical sluggishness, it's written in (optimized) C++ :D . A Windows binary is included with the download. If you want to compile it yourself, be aware that 1) it is Windows-only and 2) will only compile with VS2010 as it uses some C++0x features.

Download: http://www.mediafire.com/?m6mlrdj3xp56af7

RebelDotNET
The unpacker comes with RebelDotNET by Daniel Pistelli (http://ntcore.com/), an excellent .NET PE rebuilder. It uses it for replacing the #US stream with a new one containing all the decrypted strings.
User avatar
Kurapica
Posts: 102
Joined: Wed Jun 11, 2008 5:14 pm
Location: JIT compiler

WoW

Post by Kurapica »

this is the best work on this protector since version 2.0 !!

really impressive analysis and code.

Edit :

I have a little question, does it only support assemblies protected with version 5.0 and above ?

please specify version.
Life can only be understood backwards but It must be read forwards

http://board.b-at-s.info
http://portal.b-at-s.info/news.php
User avatar
arc_
Member
Posts: 90
Joined: Tue May 13, 2008 2:24 am

Post by arc_ »

To be frank I have no idea what version of SmartAssembly the program I reversed was protected with... But since it's from redgate itself and quite recent (2010), I guess it's safe to assume it's the latest.

Will it work on previous versions? Probably not, I'm e.g. using hardcoded method offsets to find the string decryption keys, which will not be the same in older versions. Also, in the string decryption routine I saw code for zip decompression (with a check for a PK header) which is probably for backwards compatibility with older versions, but since it's not used anymore I didn't add support for it.
User avatar
Kurapica
Posts: 102
Joined: Wed Jun 11, 2008 5:14 pm
Location: JIT compiler

Post by Kurapica »

I've tried this Project against a simple exe protected by version 5.0

It looks like it's not supported or maybe I'm doing everything wrong :-/

I've attached the file if you want to have a look.
Attachments
Hello.rar
(73.4 KiB) Downloaded 528 times
Life can only be understood backwards but It must be read forwards

http://board.b-at-s.info
http://portal.b-at-s.info/news.php
User avatar
arc_
Member
Posts: 90
Joined: Tue May 13, 2008 2:24 am

Post by arc_ »

There were two reasons why it was going wrong on that file:
  • The smartassembly meta stream is not called "{smartassembly}" but "SmartAssembly", so the unpacker thought there was no SA protection at all. I added this second name as well.
  • As feared, the code offsets in the methods for retrieving the subtraction constant and the string decryption keys were all different. (In fact, your string decryption function contained a whole new feature: it verifies that the assembly calling it is signed by RedGate :D .) So I put some more effort into it and made the parameter retrieval code much more generic.
With these changes the tool can now successfully unpack your binary. Updated download link is in the main post.
User avatar
Kurapica
Posts: 102
Joined: Wed Jun 11, 2008 5:14 pm
Location: JIT compiler

Post by Kurapica »

very nice, now it can deal with ver 5.x assemblies.

all that is left, is to have a running fixed file, your fixed files seem ok but maybe the

some type initialization is messed up and causes a crash :\

I used my tracer to find this error.

Respect :yay:
Life can only be understood backwards but It must be read forwards

http://board.b-at-s.info
http://portal.b-at-s.info/news.php
User avatar
arc_
Member
Posts: 90
Joined: Tue May 13, 2008 2:24 am

Post by arc_ »

Yes, I noticed that the unpacked files don't actually run. It's probably down to the resources, a quick glance shows that these are also decrypted at runtime, on-demand on the "AssemblyResolve" event. This might be failing due to the strong name signature no longer being valid after the unpack.

I'll have to look into it. At least you can already properly decompile and analyze targets now.

Edit: looks like it isn't due to the resources, the obfuscation process is way too simple to cause damage. The resource assembly doesn't contain any kind of code. I added information about the resource obfuscation process anyway in the main post, and also updated the unpacker to support it. Still can't run unpacked files.
yfki

Post by yfki »

_arc Any suggestions here?


C:\Documents and Settings\Vmware\Desktop\dumbassembly-0.3>dumbassembly.exe Comma
nds.exe Commands_Out.exe
{smartassembly} unpacking tool by arc_
--------------------------------------

Loading input file...
Stripping 1009 methods...
Scanning for indirect imports...
Assertion failed: index >= 0 && index < m_Data.size (), file d:\vs2010\projects\
dumbassembly\shared\lazyvector.h, line 17
toyzruz

Post by toyzruz »

hey all (:

i hope you can help and say me what protection this file use i think this smartassembly but i cannot unpack this.
Scanning -> ...\Protected.exe
File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 3929088 (03BF400h) Byte(s)
[File Heuristics] -> Flag : 00000000000001001101000000110001 (0x0004D031)
[!] {smartassembly} DotNet Obfuscator detected !
[CompilerDetect] -> .NET
- Scan Took : 0.673 Second(s)
Image

http://filebeam.com/aaff2280cd5c051e920ac855f3588519

you have any tips?

sry for my bad english :-/

best regards
maci2

Post by maci2 »

those 2 guys before are right. The tool just crashes and unpacks nothing. Pity I don't know C++ and cannot repair it...
hanz

Post by hanz »

Yes! The tool crashes!
Kurapica can you help us?

I've this error:
"Assertion failed: index >= 0 && index < m_Data.size (), file d:\vs2010\projects\ dumbassembly\shared\lazyvector.h, line 17"
I don't undestand C++ too....i'm a .NET programmer! :(
yfki

Post by yfki »

This would really be incredible if we could get a a fully working SA unpacker.

DeSmart is amazing, but it leaves you with an inoperable executable, so any desired changes still need to be cone to the obfuscated version -- not a pleasant task

_arc or Kurapica - Can you guys help here?
__H

Post by __H »

Trying dumbassembly 0.3 against two files which are definitely protected with a recent version of smartassembly I get:

Code: Select all

Loading input file...
Input file is not protected with {smartassembly}.
desmart crashes / runs out of memory on these. Seems smartassembly tweak things in every update...

Is any update for dumbassembly (which looked like the most hopeful tool I found) forthcoming, or can anyone recommend any other tools that might work?
__H

Post by __H »

I have patched out the return in main.cpp which causes dumbassembly to quit on my file, just to see where it fails:

Code: Select all

C:\tools\dumbassembly>dumbassembly-patch.exe input.dll output.dll
{smartassembly} unpacking tool by arc_
--------------------------------------

Loading input file...
Input file is not protected with {smartassembly}.
Stripping 19426 methods...
Assertion failed: outputInfo.m_iOffset >= 0 && iBBEndOffset <= iSize, file c:\tools\dumbassembly\dotnetpe\basicblockpool.cpp, line 679
Seems that the PE file parsing is failing on this file for some reason.
The lines above the failing assert are:

Code: Select all

BasicBlock::OutputInfo& outputInfo = pBB->GetOutputInfo ();
int iBBEndOffset = outputInfo.m_iOffset + pBB->GetLength () + outputInfo.m_iBranchLength;
assert ( outputInfo.m_iOffset >= 0 && iBBEndOffset <= iSize );
The files I have are definitely {smartassembly} protected, I'm guessing with the latest version... Any help would be appreciated.
MadCoder

Post by MadCoder »

Hi

Here I have another sample where unpacker fails. See the attached files.

See if you can solve this.

Thx
Attachments
asm.zip
(849.29 KiB) Downloaded 429 times
Locked