OpenRCE: Blog

IOCTL-Proxy

Sun, 21 Dec 2008 12:03:22 -0600

This is a POC of IOCTL fuzzer. It gave surprisingly good results.

IOCTL-Proxy works by hooking NtDeviceIoControlFile, manipulating its' parameters and feeding them to the real function.

Load the driver and simply click around in application you want to test.

You will get a lot of BSODS, be careful.

PreviousMode==KernelMode is ignored, since we are only interested in calls from UserMode to KernelMode, not Kernel->Kernel.

Get it here:
http://www.orange-bat.com

Command line version of OSR's DeviceTree

Tue, 16 Dec 2008 10:10:14 -0600

Get it here: http://orange-bat.com/code/device.tree.cmd.rar

Sample output:



Unloading ObjInfo driver

Loading driver: D:\tools\devicetree\i386\OBJINFO.SYS

No service, creating...

Service not running, starting...

Service started.

Driver object: 0x89c98a08

Service name: nvata

Device name: \Device\00000138, type: 0x00000007

Device name: \Device\NvAta2, type: 0x00000001

Device name: \Device\NvAta1, type: 0x00000001

Device name: \Device\NvAta0, type: 0x00000001



Driver object: 0x89c8a8d0

Service name: NDIS

Device name: \Device\Ndis, type: 0x00000012



Driver object: 0x89cdad28

Service name: KSecDD

Device name: \Device\KsecDD, type: 0x00000039



Driver object: 0x8897b218

Service name: Beep

Device name: \Device\Beep, type: 0x00000001



Driver object: 0x899e7418

Service name: Raspti

Device name: \Device\{AA56C973-4F1C-4D19-8BAC-4FA6F14D80CB}, type: 0x00000017



Driver object: 0x89aab928

Service name: Mouclass

Device name: \Device\PointerClass1, type: 0x0000000f

Device name: \Device\PointerClass0, type: 0x00000000

.

.

.

Fighting Oreans' VM (code virtualizer flavour)

Tue, 19 Aug 2008 12:27:29 -0500

If you don't know what code virtualizer is, or how it works, you should read this first:
http://rapidshare.com/files/16968098/Inside_Code_Virtualizer.rar
(Inside Code Virtualizer by scherzo)

Now, as you probably already know from paper by scherzo ;), one possible way recover virtualized code is to identify each mutated handler (find corresponding non-mutated version). After this done, we can trace virtual opcodes and "decompile" them to VM instructions. Having "clean" decompiled output, we can translate it to x86 assembly. I consider the last step, to be simple "find and replace" job with flex/yacc.

The problem is, oreans' vm engine can be a bitch. Consider this piece of code:

continued at:

http://www.woodmann.com/forum/showthread.php?t=12015