socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=1024 SO_SNDBUF=1024

Alas, I found no obvious way to modify these values in the enclosure’s web interface. Furthermore, extracting the hard-drive and mounting it locally proved that it is used for content storage only – the OS sits on a ROM, away from the user’s grubby fingers. And so I was out of luck and was at the point of giving up, until curiosity got the better of me. Taking a look at the ’shares’ page of the admin interface it was pretty clear that this thing was running a Unix-based OS (disclosing local paths such as ‘/mnt/C/Media/Music’), and if their implementation was as flaky as their design there may be another way in.

So I tried what any hacker would have done faced with this input field, and tried to traverse the device-local path using some ‘../’s.

Now I won’t pretend that it was big, clever or original, but to my surprise it worked. Browsing to ‘\\nas\Root’ from my computer landed me right in the device’s root, with admin read/write privileges. For those wondering, the OS is BusyBox.

And the rest is history. A couple of words of warning to anybody planning on doing the same:

• In order to access this root share, the device obviously needs to boot and mount successfully. As such I wouldn’t be the slightest bit surprised if any undue alterations to the OS or its configuration result in the device being rendered permanently unusable. I never did brick mine and so haven’t confirmed this, but be very careful what you touch.
• /config/smb.conf is presumably kept open at all times, and so you’ll likely have trouble saving to it. I found that saving as a different file and then renaming them around works fine. Be aware that there is very little excess space to play with (I suspect it’s mounted as a ramdrive).
• The smb.conf, at least, seems quite volatile, in that any changes via the web interface result in the [global] parameters being reset to their defaults. I have observed the alterations to persist across reboots but couldn’t offer a comprehensive list of actions that result in it being wiped clean, so don’t be surprised if you find that your fixes disappear when you’re not looking.

It has taken a little while, but the application of asymmetric cryptography to binary signing is becoming popular. This is reflected in the intrinsic DSA signing mechanism offered by the .NET framework. If you aren’t familiar with strong name signing, the idea is fairly simple: The creator of a .NET assembly has their own RSA key pair, which they use to encrypt a combination of hashes of the file. The resulting strong-name signature is included in the binary along with the public key and the whole lot is distributed as normal. Now, whenever a user tries to load this assembly, the public key and signature are used to verify the integrity of the file, thus thwarting the attempts of any bad guys to patch the assembly. And of course, because the private key is never published, it is virtually impossible for the file to be re-signed with the same key after its release.

The method of digital signing is remarkably effective at preventing patching and without the use of a hypercomputer, the chances of anyone cracking the key is as good as zero. Also of note is that the code responsible for verifying the signature is part of the system’s .NET assembly loader, and therein lies both a strength and the weakness of the technique. While this makes it easy for developers to sign their assemblies (very easy indeed using Visual Studio), it also unifies the implementation allowing for automated removal of such signatures. The weak point in the protection is obviously the DSA signature-checking algorithm, but it lies in system code and so for many reverse-engineers, bypassing it is undesirable or impossible. So we target the next best thing – the metadata in the assembly itself. If the assembly looks like it isn’t signed then that is exactly how it will be treated.

The exact structure of the relevant metadata is described in the .NET specification, and the steps necessary to remove the signing have been concisely detailed here. Even more generously, Andrea provides us in that article us with a tool to remove the signatures from a single file. Similar programs can be found elsewhere on the web but nowhere did I see a tool that’s capable of handling complex projects with nested binary dependencies. The problem here is that the public key is stored both in a binary itself and each assembly that references it, so if you’re patching a DLL deep in a dependency structure, it is nontrivial to isolate and execute all the necessary patches. That’s why I created AdmiralDebilitate.

If you load up any number of PE files, AdmiralDebilitate will enumerate all .NET dependencies and provide you with a tree, much like the Dependency Walker. From here, you can ‘mark’ any and all assemblies that you intend to patch, and all the work of identifying dependants and patching out the headers will be done for you. I provide no further instructions but it should be self-explanatory. As usual, this is a one-man project and the code is correspondingly immature so please report any bugs.

Get the source and binary here.

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.

The topic of debugging full-screen Direct3D applications came up a little while ago. If you’ve ever tried it on a single-monitor setup (or even multi-monitor if the app wasn’t designed to handle it) then you’ll know how much of a pain it is. Windows just can’t handle focus being stolen from a suspended exclusive-mode program. The solution’s exactly what you’d expect – to intercept the relevant window- and device-creation calls and coax the debuggee into running in a window. This works, but fiddling with the calls manually each time you restart the process quickly gets boring. So here’s my first attempt at a generic solution.

D3DLookingGlass is a DLL which, if injected into a Direct3D process early enough, will make sure that all video devices are created in windowed mode, allowing the hosting process to coexist with a debugger without any bother. If you can inject this DLL into the target process before the first call to CreateWindow, then everything should go smoothly. I think. Any later than this and your mileage may vary.

I’ve also written a ‘loader’ program that installs the DLL as a system-wide CBT hook, so that you don’t need to inject it manually. This kind of worked for my limited set of test-cases, but there seems to be no Windows-hooks method of injecting a DLL globally and beating the call to CreateWindow. Windows installs the DLL containing the hook at the latest possible moment for its function, and I can find no type of hook that needs to be around before a window is created. I’d love for somebody to prove me wrong (or suggest another way to install the DLL system-wide), but by the looks of things, my loader is of limited use.

In particular, I recall a situation where the game (Call Of Duty 4 Demo, I think) creates a non-overlapped window, which works fine for full-screen mode, but causes problems when you try force the device to bind as windowed. This will still be a problem unless the call to CreateWindow can be intercepted (and a well-formed window induced), which means that D3DLookingGlassLoader will struggle. Confirmation would be nice.

Here’s the source: D3DLookingGlass_Source.zip

Here’s the binary: D3DLookingGlass_Binary.zip

Here’s the small-print:

• The DLL hooks CreateWindowExW and ShowWindow in its DLLMain. I think this is kosher in terms of loader-lock, but it’s obviously not too cool with regard to system stability. Especially if it’s being installed in every running process. If d3d9.dll isn’t found in the address-space then the hooks fall straight through, so that shouldn’t be too much of a problem. But if it is found then all attempts to create or show (or hide) a window will be overridden – possibly to the demise of the process if it’s doing anything but the basic behaviour. So in all cases, watch out, and make sure you aren’t running anything important in the background (in particular, I’ve noticed that it doesn’t play nice with Firefox).
• The loader uses a system-wide hook, and you hate system-wide hooks. I trust that anybody who needs this tool has some degree of technical expertise and is aware of the stability concerns inherent in installing somebody else’s barely-tested system-wide hook.
• This was harder to put together than I anticipated, and that’s probably evident from the slightly shabby code. Again, I intend for this only to be used for debugging purposes, so you’ll have to forgive me for the sub-production-quality code.
• Despite the focus on Direct3D of this blog, I’m not really a gamer and I don’t actually have any commercial games installed on this machine. So I only got a chance to test this against my own programs. Obviously, there are several ways to skin the metaphorical Direct3D-initialisation cat, so please leave a comment when you find a game that this chokes on.

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.

• A user-modifiable stack buffer is usually designed to hold string data, but even when this isn’t the case, it’s rare to find a situation where arbitrary input is accepted and blindly copied to the stack. It’s not infeasible that your shellcode will be restricted to null-terminated printable ASCII (that’s 0×20-0×7E inclusive), and if you’ve ever tried to write code that assembles into this range you’ll realise that it’s no mean feat. Furthermore, not all strings are ASCII and even a seasoned hacker can have trouble crafting an executable Unicode string.
• If you’re able to provide an arbitrary amount of data then overflowing a return-address is easy. But what’s not so straightforward is ensuring that the function actually gets a chance to return – after all, you have just corrupted every stack variable between the buffer and the return-address.
• Suppose that your shellcode compiles okay, passes the input filters; no crashes occur and that you now own EIP after the vulnerable function returns. Just where should you make the target return to? Understand that the address from which to commence execution must be known at the time the shellcode is provided, and moreover that – in the paradigm case – your shellcode lies ’somewhere’ on the stack. Inherent in the nature of stack-based function architecture is the fact that the same function can execute many times without ever taking the same value of ESP. This problem of locating your shellcode after injection is one that never seems to go away and has become the bane of many hackers’ lives.
• If we weren’t already struggling enough, the recent shift in focus towards security has prompted the Windows kernel developers to take more and more precautions regarding the execution of data buffers. Windows XP SP2 introduced DEP (data-execution prevention) for Windows Services, and Vista/Server 2003 extended this to protect all processes by default. This means that as of Windows Vista, any attempts to execute code on the stack will fail with a warning dialog from the OS, provided the system’s processor supports the NX/XD bit (Intel and AMD couldn’t agree on nomenclature, apparently).
• Because the OS can only do so much, many compilers now ship with support for automatic security code-generation. In particular, Visual Studio 2005 introduced the GS flag, which creates what Microsoft are calling a Security Cookie (but to everyone else, a stack canary) within each function’s stack frame. With this option enabled, each function will push a pseudo-random dword onto the stack in its prologue, and check that it hasn’t been modified by the time the epilogue is reached. This way, any attempts to overflow into the return-address will corrupt the canary and alert the program before the RETN occurs.

All of these problems can be appeased to a degree through a variety of techniques. Notably, the use of structured exception handling in the target application can make our job as an attacker considerably easier as we may be able to abuse the SEH records and sidestep several of these problems in one go. Details next time.

__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.

By popular demand, I’ve updated the Direct3D 9 Hooking Sample to accommodate Windows Vista. The same binary should work on both Vista and XP. I’ve only tested it on Vista 64-bit, so it’d be nice to know if it works with Vista 32 or not. Other than this, most of the same caveats apply as last time.

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.

The Collaborative RCE Tool Library

It’s already rather complete, but if you feel anything is missing then it needn’t be for very long. Take a look, download what you need, learn what you can and maybe give something back.

See you in the new year.