IceProbe is a utility that allows live tracing and analysis of SoftIce commands using the full capability of SoftIce itself. It is a tool strictly for code exploration, designed to be able to trace running Softice code in order to augment IDA analysis. It is debugging a debugger, in order to answer the question "How does Softice work?"
There is much that can be learned about system internals by studying Softice code. This utility will give a live hands-on method of tracing and exploring the code for the first time. It can also act as a GUI front-end for Softice, as bizarre as that might sound.
Concept:
Any SoftIce command typed into the command line window is stored in a global string buffer. The command string consists of the command name and any arguments. The buffer is passed to the individual function where it is parsed, and the command is executed.
We can selectively replace instances of this global buffer pointer with one of our own and call Softice commands directly from a GUI interface. An (optional) embedded breakpoint which will pop-up Softice is written into our driver code immediately before calling the command, which allows us to start tracing the Softice command.
While live tracing you have full use of all other Softice commands at your disposal, including the ability to set breakpoints in Softice code itself. There is an additional modification which will force the "Idt" command to expose the addresses of the Softice IDT hooks so you can also locate and analyse those various handlers as well.
Usage:
Iceprobe is simple to use, select Initialize/Reinitialize from the menu and the driver will return a listview listing of all the Softice commands and their addresses. A log window will monitor the driver. Double click on one of the entries and you will be presented with a dialog box to add any usual arguments to the command. When you select OK, Softice will popup at the start of the command, and you're ready to start tracing with F8.
Options:
Disable Manual Tracing Mode We embed an INT 3 in our code and programatically enable "I3HERE DRV" in order to make Softice popup at the start of each command. Set this option if you don't want Softice to popup. The command will still be executed and output to the Softice window as normal.
Make "Idt" show real addresses Expose the addresses of the Softice IDT hooks in the listing from the "Idt" command.
Disable extra Softice self address space checks These are somewhat experimental patching of locations where Softice tests if an offset is within its own address space. Specifically, they occur in the "Search" command, in a portion of breakpoint handling code where MSR LastBranch and MSR LastException information is printed, and in the Int0D handler. You may or may not see any effect.
Include Undocumented Commands There is only one command here, BPTE - Breakpoint on Thread Execution was its probable purpose. Code exists to be traced, but the command appears non-functional and was never documented. If selected, the BPTE command will be added to the listview where you can run it with test arguments.
Increase Recursive Disassembly Level (Calls nested 4 deep) We must find every occurence of the Softice global command buffer used in each command, in order to replace them with a pointer to our own buffer. A recursive disassembly is therefore needed in order to trace through all nested subcalls within a command.
A simple recursive method is used - trace each call until a RET/RETN is reached. It was found that this was sufficient with a default value of 3 nested levels of disassembly to find all instances of the global buffer for each command. A value of 4 will find further instances, but most seem to be false positives and not part of the command execution path. This is due to how Softice code is laid out (code chunks, use of jmps, etc), and the simplified method of recursive disassembly.
Output Recursive Call Pattern for Xref with IDA (DbgPrint) - Shows the nested recursive disassembly of all Calls and SubCalls for a command, as determined by the Increase Recursive Disassembly Level option. The pattern can be matched to what you find during the IDA analysis. It makes it easier to keep track of where you are while jumping back and forth between IDA and the Softice/Softice tracing of a command.
Output Developmental Notes (DbgPrint) Prints a bunch of output about the Softice driver and internal offsets, mostly used during development.
All these options can be "toggled" on or off by setting them and selecting Initialize/Reinitialize from the menu again.
IDA Analysis:
This tool is meant to work side by side with an IDA analysis of the ntice.sys driver. Iceprobe should run without problem with Driver Studio 2.7, 3.1 or 3.2. It is designed to work with the final official DS3.2.1 patch version of the Softice driver which was publically available on their ftp site. This offical patch is available here:
This would be incomplete without an explanation of how to set up IDA properly, which fortunately I discussed previously:
Setting up IDA for analysing Softice functions http://www.woodmann.com/forum/showthread.php?t=6529
Briefly, Softice keeps its command names and offsets in indexed tables. The very first step is to run the following idc script. The CmdTable offsets are for the DS3.2.1 patch version. If you happen to be using a different version change the offsets accordingly, the above thread describes how to find them.
Your IDA disassembly will now identify all of the Softice commands by name. I would then strongly suggest to look at the IDB analysis and Softice headers produced by The Owl while developing Icedump, and use them to start naming some of the internal variables already defined. The article by +Spath is old but indispensable as well.
NTICE and WINICE IDB Files by the_owl (IDB) http://woodmann.net/yates/ida/softice_idb.zip
SOFTICE INTERNALS revision 2 by +Spath http://www.woodmann.com/crackz/Tutorials/Siceints.txt
Now you can start filling in the blanks in your IDA analysis with live tracing of any command using Iceprobe. The ideal situation is to have Softice running under VMWare and have IDA on your desktop. Iceprobe is stable, but you ARE live tracing Softice, so running under VMWare, etc. is desirable.
To further enhance the experience, you can create progressive NMS symbol files of your IDA analysis and have Softice load its own symbol file into itself using its Symbol Loader. Produce the symbol file with Mostek's Ida2Sice
Any command can be traced, while at the same time being able to issue any other Softice command. However, if you execute the same command as you are tracing it will only rerun it with the same parameters that were initially set in the GUI, since we've overwritten the global buffer for that command with our own pointer.
For tracing the BPX command, you can set a breakpoint with a double click, or use BPM. You can even trace the HBOOT command and watch your VM reboot! (I put a protection in the GUI so you can't inadvertently click the HBOOT command).
WTF is this?:
I wrote this a few years back, partly as a way of tracing Softice code, but mostly as a way of exploring system internals and how Softice made use of various system structures, variables, hardware and registers. Sort of kernel spelunking through the eyes of a ring 0 debugger.
IceProbe was first integrated as a KDExtension driver to take advantage of the internal Softice disassembly engine available through the WINDBG_EXTENSION_APIS interface. Further Softice internal details can be found in the thread
Guide to creating a Softice Kernel Debugger Extension (KDExtension) http://www.woodmann.com/forum/showthread.php?t=7097
This version uses a standalone driver and the disassembler is an integration of a module I created from the Ndisasm NASM disassembler for use in drivers. The disasm module is also available separately here:
Sysdasm: Full-Text Disassembler DLL Export Module for Kernel Mode http://www.woodmann.com/collaborative/tools/index.php/SysDasm
Full VC6++ source is included for those interested in looking at an old friend with new eyes. ;)
