Author:  David Zimmer <david@idefense.com, dzzie@yahoo.com>
License: GPL
Download:Source
Copyright:   iDefense.com, a Verisign Company.
  olly.dll and portions of hooker.lib Copyright (C) 2001
Oleh Yuschuk and used under GPL License.


COMRaider Introduction
COMRaider is an application designed to help you fuzz COM object interfaces.

COMRaider has been built with the following design considerations:
  • target scriptable objects which may be creatable from IE

  • integrated debugger to:
    • capture extended details of exception environment
    • identify possibly exploitable exceptions which may be masked by seh

  • targeted api hooking framework built in to record file/registry access

  • distributed auditing framework so teams can:
    • track and download/display audited clsid's
    • share notes on audit ideas or findings
    • ability to upload interesting fuzz files to central server w/error environment
    • search, sort, generate stats on audit logs

  • interface that includes tools to easily:
    • load objects by GUID, file path, parent directory
    • scan the local machine for control marked as Safe for Scripting or implementing IObjectSafety
    • built in type library viewer capable of fuzzing
      • entire library, specific classes, or individual functions





Background/Implementation
COMRaider is a mix of a VB6 interface and some VC6 dlls. All of the main interface code and database access is done in VB for simplicity. Disassembly engine (olly.dll), debugger core (crashmon.dll) and api logger (logger.dll) have been done in VC6.

Since COMRaiders main focus is on scriptable components which can loaded in IE, the fuzzing implementation is based off of dynamically created Windows Script Files (*.wsf) that it creates. This design has some drawbacks, in that target objects will have to support the IDispatch or IDispatchEx interfaces in order to be scriptable, and that scripting clients can only access the default interface of a COM object. While this fits fine into COMRaiders design intent, it may make the tool unusable for certain audit targets.

COMRaider uses Microsoft's tlbinf32.dll to load and parse type library files (*.tlb) that may be included with, or compiled into ActiveX servers. If a COM Object does not include a type library resource, COMRaider can also create a live instance of the object which it can then query to load the interface info for fuzzing. The type library viewer form will examine each function and determine which functions are fuzzable. COMRaider supports 5 basic variable types for fuzzing: ints, longs, doubles, strings, and variants. Some variable types such as singles, bytes, bools were decided to have to small of a range to make for interesting targets and will instead be set to a default value. Argument variations used in fuzzing are controlled by the user and are defined in the external buildargs.vbs script.

All fuzz files are generated from the type library viewer form using right click menus. Once this has been completed you can click next to goto the debugging form. The wsf files are launched and run through wscript.exe which is monitored by the debugger. The debugger records all exceptions and saves the exception environment for each error.

A window monitor is also run at the same time to record and close any script error dialogs that may be displayed as the script runs. A timeout timer, monitors progress and will terminate wscript after 8 seconds if it the script has not finished processing in the allotted time.

The API Logger was stolen from the iDefense Labs SysAnalyzer project and only hooks a handful of functions relating to file and registry access. This is to help you determine if the ActiveX control allows for unsafe system modifications.

For simplicity, COMRaider's distributed auditing features are based off of a system DSN connection which can be pointed to any database server your system has drivers for. If you are working out of the lab, you can also point your DSN to aim to your local access database and then latter upload your individual audit logs to the central server at a latter date. More details on setting up your system for distributed auditing can be found in the section of the manual dedicated to it.

Finally, it is also worth mentioning that this is a research tool and not a full commercial application. While ideas and feature requests are always welcomed, not every idea will be able to be included. This tool has been designed for a specific purpose, there is no shortage for wish list features, however this is the base feature set for initial release. If you see room for improvement code it! Thatís why its open source.



Dependencies:
Source is included for all of the core components for COMRaider consisting of:
  • COMRaider.exe - main UI - vb6
  • Crashmon.dll - debugger and misc C functions - vc6
  • olly.dll - disasm engine using Olehs GPL code - vc6
  • logger.dll - detours style api logger - vc6
  • buildDB.exe - Queries live objects for IObjectSafety Settings and builds database


COMRaider depends on the following 3rd party dlls which are installed during initial setup: spSubclass.dll, vbDevKit.dll, TLBINF32.DLL, msscript.ocx, mscomctl.ocx, MSWINSCK.OCX.

If you are running an early Win2k or Win98 machine, you may have to additionally install the VB 6 Runtimes (1 mb)

Changelog
7.12.06 - added form to list killbitted controls, display this attribute w/ other forms.
7.19.06 - new option to set browser path (was hardcoded to US-EN path)
8.01.06 - added form to search for controls by progid
8.08.06 - ability to set ApiLog alert triggers and search all ApiLogs added
8.08.06 - minor change to default object argument val
8.08.06 - added error handling and more warnings around buildargs.vbs in case of script errs
8.08.06 - fixed display bug: not logging exceptions if next script had same crash as previous
8.10.06 - added symbol support for disasm, seh chain, and call stack
8.10.06 - added support for debug string messages

Bugs:
• Scan directory for registered COM Objects will not find controls set w/ DOS path