An Introduction To .NET Reversing

The first time I saw a .NET application, I was scared. I was scared of the unknown and this fear was only heightened after looking closer with OllyDbg, IDA and LordPE. I imagine that every seasoned reverser out there felt the same way. Well if that’s you, and you’re anything like me, then you’ll have avoided the .NET paradigm-shift for as long as possible. But after seeing new .NET articles and tools popping up left, right and centre, I decided it was time to face my demons and get comfortable with the inevitable future. This post is aimed at those familiar with native RCE but not with .NET, and forms a distillation of the essential facts you’ll need to get started.

You probably already know that .NET is a semi-compiled language - that is, a .NET binary (called an ‘assembly’) exists as bytecode that is compiled into native code just before execution. The bytecode is called Common Intermediate Language, or CIL, (formerly known as Microsoft Intermediate Language - MSIL) and it is the product of any C#, VB.NET or J# compilation. These exe and DLL assemblies are wrapped up inside regular PE files having only one import - mscoree.dll - which acts as the assembly’s just-in-time (JIT) compiler and its gateway to the .NET Framework and its platform API, the Common Language Runtime (CLR). The PE header’s data directory contains a .NET directory entry, which points to a new header in the file containing everything the operating system needs to run it.

There are a lot of changes from the familiar native situation, some of which work for us and some against. From a hacker’s perspective, there are some pros:

• CIL is reflective, meaning that the structure of the code can be deterministically inferred from its assembly.
• For JIT compilation, linking and introspection to work, a considerable amount of type information must remain in the assembly.
• .NET assemblies are a few levels of abstraction away from the user-mode platform, so there is far less scope for obfuscation, and anti-debug tricks.
• The CLR provides standardised interfaces for a tremendous amount of functionality for standard operations, and this is typically embraced by .NET programmers. The result is short, concise code that can reveal even very complex algorithms at a glance.

and, of course, some cons:

• The assembly effectively runs in a virtual machine, meaning the operations-to-clock-cycles ratio is a few orders of magnitude higher. This is of immediate consequence if you are tracing through the program natively (i.e. debugging the JIT compiler).
• The abstracted nature of the program’s entities means that old friends like Olly’s ‘registers’ and ’stack’ windows are of very little use. In fact, the applicability of a low-level debugger is altogether questionable.
• While the relatively small community is making tremendous efforts, the science of .NET RCE is still quite young and so the tools available are correspondingly immature and thin on the ground.

So put OllyDbg, LordPE and your hex-editor aside (you may want to keep IDA within reach) and meet your new arsenal:

• Lutz Roeder’s .NET Reflector is perhaps the best-known and most advanced .NET reversing tool. It’s also an invaluable asset for every .NET job, giving you in-depth at-a-glance information about any assembly.
• ILDAsm - This is Microsoft’s CIL disassembler and is far more useful than any native equivalent. You can download it from MSDN if necessary, but it comes as a part of Visual Studio (all versions) and can be found either at ($ProgramFiles)\Microsoft SDKs\Windows\[Version]\bin or ($VisualStudioDir)\SDK\2.0\… depending on your version. Be sure to check your non-x86 Program Files directory if you’re running Windows x64.
• ILAsm - As you guessed, this is the CIL assembler. The great thing about this is that in many circumstances, you can pipe ILDAsm’s output into ILAsm and end up with a fully working assembly.
• Explorer Suite - A Swiss Army Knife of .NET-aware tools. This will be your new PE editor for all things .NET.

  (I recommend you take a look around Dan Pistelli’s site once you’re comfortable with the terrain as he’s produced a lot of marvellous tools that can cut your workload down considerably.)

If you were wondering where the debugger is, then my answer is that you’re probably better off without one, at least for the moment. It would of course be a very handy addition, but I haven’t found any .NET debuggers that work too well. DILE is promising, but it’s very unstable on my 64-bit Windows, and WinDbg puts in a good effort with the SoS extension running, but you won’t find anything that’s a joy to use.

So with all the framework in place it’s remarkably easy to get going. The first step is to take a look at your target assembly in Reflector and get a feel for the program. If it isn’t obfuscated then you’ll probably be surprised how easy this is (in the many cases it’s just like having the source code). If it is obfuscated then you may need to work a little harder, or perhaps skip straight ahead to the next step:

ildasm Target.exe /out=Target.il

The resulting file contains a complete CIL listing of the assembly, which you can edit at your leisure. You may want to Google ‘MSIL’ to get an idea of what all those alien-looking opcodes do, but it’s really quite straightforward to do the basics:

• ‘Push’ instructions start with ld (load), ‘Pop’s with st (store).
• There is no MOV instruction. In order to copy from one place to another, push then pop.
• Most manipulation involves arguments and locals, which are referenced by index using a dot, e.g.
  ldarg.1 // Push the second argument
  stloc.0 // Pop it into the first local
• Constants are pushed using ldc. The size and type of constant must also be specified e.g.
  ldc.i4 12 // Push a 4-byte integer (of value 12)
  ldc.r4 33.33 // Push a 32-bit float
• The values are returned by pushing them onto the stack prior to a return (ret)

Far more complete references exist on the web if you’re willing to search, but this is enough to short-circuit a function or two. Once you’re done playing with the CIL, compile it back up, being sure to specify any resource files that were created by the disassembler:

ilasm [/dll] Target.il [/res=Target.res] /out=TargetNew.dll

And you’re all ready to go. This is sufficient for the most basic cases, but it will only be a matter of time before you encounter an obfuscated assembly (which will cause you problems in Reflector) or one that’s signed using strong-names (which will refuse to run after compilation). I’ll discuss both of these situations and any relevant workarounds another day.

Posted in RCE | 3 Comments »

Tracing Over System Calls In OllyDbg

Things have been quiet over here since installing Life 2.0, so to start warming things up again I present a simple trick to counter a frustrating problem. This isn’t particularly clever, but it didn’t occur to me first few times ’round so maybe it will save some newbies a little time.

How many times have you attempted a run-trace in Olly with a break-condition set, only to find that the break never occurs and you have to start over? It happens to me all the time, and it’s usually my fault. But sometimes the cause isn’t a poorly thought-out condition, but the presence of a system call during the trace. Being a lowly ring3 process, OllyDbg doesn’t have permission to follow the CPU’s execution of your program into kernel space, so when it encounters a SYSCALL, SYSENTER, or CALL/JMP FAR out of the debuggee’s address-space, no choice remains other than to let the process run away and hope it comes back. As we’ve established, this doesn’t always happen.

Now, the most commonly encountered system calls are those in ntdll, but these pose no problem to us. Set ‘Always trace over system DLLs’ in Olly’s ‘Trace’ options and you’ll never need to trace over such an instruction directly. (If this still isn’t working for you, be sure to ‘Mark [ntdll] as system DLL’ in the ‘Executable modules’ dialog). But if you play with some nastier targets, such kernel transitions will occur in modules you need the trace data for.

Olly intrinsically supports three modes of tracing (although it doesn’t give you much control over which it uses): hardware breakpoints, software breakpoints and execution trapping (using the EFlags ‘trap bit’). Unfortunately, given the way Windows implements its kernel transitions, we can’t use any of these to our advantage. Arguments are passed to these system calls via the general-purpose registers, rather than by the stack-frame system we’re all used to, and moreover the return address isn’t always that of the instruction following the system call. Hence without complete knowledge of these ‘fastcall’ specifications, there’s no way to be sure where user-mode execution will resume, and so we’re at a loss when it comes to placing the next breakpoint. For this reason, there is no one-size-fits-all solution that I’m aware of, but it is possible to clean up this little mess on a per-case basis with only minimal effort.

Take a look at the run trace produced by your failed run. It’s probably a lot shorter than you expected, with its dying instructions indicating an upcoming transition to ring0. Scroll up a little and work out a location where execution is very likely to pass through shortly after ring3 execution resumes. This doesn’t need to be the actual return address, but ideally something that follows soon after. Usually, the saved return-address belonging to the function at the top of the call stack does a good job. Our goal is to trap execution at this point and resume the trace. Of course, we could do this manually by placing a breakpoint and keeping our fingers on ctrl-F11, but that’s the dumb way. The last piece of the puzzle is to make OllyDbg automate this for us: employ a conditional breakpoint, with an impossible condition (say, 1 == 2). Now our trace executes over the system call flawlessly without the need for us to lift a finger.

Posted in RCE | No Comments »

Run-time determination of VC++ virtual member function addresses: Take II

I wrote about this tricky little problem a while ago and wasn’t too happy with the desperate methods that seemed necessary. Since then, I’ve been shown a much cleaner way to do the same thing, by manipulating the vTable manually. It seems that Microsoft haven’t changed their vTable implementation since Visual Studio 6 (at least) and so with a little modification, the following piece of inline-assembly will do the trick: no muss, no fuss.

__declspec(naked) void* ResolveVirtualFunction(IDirect3DDevice9* pDevice, ...) {
    __asm {
        mov eax, dword ptr ss:[esp+0x08]
        add eax, 0x8
        cmp byte ptr ds:[eax-1], 0xA0
        mov eax, dword ptr ds:[eax]
        je normal_index
        and eax, 0xFF
normal_index:
        mov ecx, eax
        mov eax, dword ptr ss:[esp+0x4]
        mov eax, dword ptr ds:[eax]
        mov eax, dword ptr ds:[eax+ecx]
        retn
    }
}
 
// ...
 
// The function should be invoked like this:
void* address_device_present = ResolveVirtualFunction(device, &IDirect3DDevice9::Present);

Thanks go to Vuurvlieg for this function. The beauty (or horror), here, is the use of a variadic parameter-list to overcome C++’s strong-typing that would otherwise make this operation very difficult. Obviously, this implementation will only work for objects of type IDirect3DDevice9, but the method extends to any other class by simply replacing the class name in the function declaration. Don’t be tempted to generalise this function to IUnknown or some other common base-class, as you’ll quickly run into problems with object-slicing. A final warning to those still using Visual C++ 6 (not that you deserve any help for such a crime): you’ll need to drop the ampersand from the second argument in the function call, as VC++6 handles function pointers slightly differently.

Posted in Game Programming, RCE | 13 Comments »

Shellcoding on Windows: Part I

If you were wondering why things have been so quiet for the past month, it’s because I’ve been spending my every waking hour learning to hack. This explains the presence of a new category here on the site, and the motivation behind some of the upcoming topics. It would be a shame to let January pass us by, so here comes an introductory post on the exciting science of shellcoding. First, some formalities:

Shellcode (shĕl’kōd)
n.

A relocatable piece of executable code used as the payload in a software exploit, typically having the purpose of providing the attacker with unauthorised access to the system at which it is directed.

v. [shellcod•ing, shellcod•er]

The process of developing shellcode and tailoring it to a particular target.

A piece of software is said to be vulnerable (to exploitation) if it contains a bug which allows a user to cause it to behave in a way unintended by the developers, by supplying appropriately crafted data to one of its normal input mechanisms. The faulty processing of this input is the vulnerability, and any operation that takes advantage of this is an exploit. The data used in such an exploit is the payload, and the executable component of this payload is the shellcode. While a distinction exists between an exploit’s payload and its shellcode, the two terms are often used interchangeably. The name ’shellcode’ derives from the fact that many Unix exploits would work toward the goal of delivering a shell to the attacker, but this is not a necessary criterion under today’s usage.

Not all exploits will require shellcode, as certain goals may be achieved without it, but we’ll primarily concern ourselves with vulnerabilities that lead to execution of arbitrary code (i.e. the shellcode), as that’s the holy grail of the hacker. While vulnerabilities can fall into many categories, there are a few of particular interest, and these are the ones I’ll concentrate on. Putting the theory into practice is the real stumbling-block, and so along the way I’ll discuss common problems the average Windows shellcoder will run into. Here’s the battle-plan:

• Stack overflows
• Heap overflows
• Format-string vulnerabilities
• String filters, shellcode-location and other technical problems
• Non-executable stacks and stack-canaries

I appreciate that this is a lot of material to cover, and that you may be best off buying a book (The Shellcoder’s Handbook handles this vast subject magnificently), but I aim to spend as little time as possible on the bread-and-butter material that can be found just about everywhere, while putting far more focus on the practical side of things. See you next week.

Posted in Hacking, RCE | No Comments »

A framework to take the tedium out of code-injection in C++

I know I’ve been banging on about injection a lot recently, but I figured a good way to pinch off would be to present some code. After searching and failing, I took it upon myself to write a reusable C++ class to do most of the leg-work for Windows XP/2000/Vista32 DLL injection and hooking. The source is available on the project page.

The process of remote function hooking via a DLL is notoriously messy, so I’ve tried to encapsulate as much of the mess as possible into a C++ class. Here’s an example of some client code that injects a DLL into Windows Calculator, then installs two hooks (one by name and another by address):

// Create the injection object
DLLInjection injection("E:/Temp/HookDLL.dll");
 
// Find Calc.exe by its window
DWORD process_id = injection.GetProcessIDFromWindow("SciCalc", "Calculator");
 
// Inject the DLL
HMODULE remote_module = injection.InjectDLL(process_id);
 
// Hook a DLL function (User32!SetWindowTextW)
HDLLHOOK swtw_hook = injection.InstallDLLHook("C:/Windows/System32/User32.dll", "SetWindowTextW", "SetWindowTextHookW");
 
// Hook a function manually (Calc!0100F3CF)
HDLLHOOK manual_hook = injection.InstallCodeHook(reinterpret_cast <void*> (0x0100F3CF), "SomeOtherHook");
 
// Remove the hooks
injection.RemoveHook(swtw_hook);
injection.RemoveHook(manual_hook);

Testing has been limited so don’t be surprised to find bugs. If you do find any, please report them via email or comment.

Posted in Game Programming, RCE | 11 Comments »