Howdy!
I started walking the dark path of (at least for me) 'Winnie' understanding and reversing.
The first obstacle i found was that Winice would not let me put bpx's on its own code.
This was rapidly 'fixed' with a byte patch.
But the problem kinda goes on, because now i can place breakpoints on Winice but they wont 'work'.
By 'won't work' i mean that Winice won't break on its own memory addresses.
Maybe the reason why is obvious for the 'congnoscenti' :P but not for me!
Let me give you an example:
By reading icedump's sources (thanks very much icedump team!) i found out that Winice's pPrintChar function (at least that's how its called in the sources) is at C0047043h in Winice version 4.0.5 Build 334. I do BPM C0047043 x and Winice accepts it due to the patch. But it will never break!
If i do 'u C0047043' i see that memory address line in blue.
As per usual, every tip is very much appreciated.
Thanks very much.

Latigo.

Frog's Print has a tool called BreakIce to allow you do set BPXs inside WinIce. Get it here:

{ http://www.playtools.cjb.net | breakice.zip ("http://156.17.4.4/~player/playtools/debuggers/softice/tools/breakice.zip") }

hmm, icedump sources won't give the offset in memory, but rather an RVA inside the winice VxD image. where it will end up in memory depends on some factors, most notably the size of the VxDs that load before winice, eg. VMM (which changes in each windows version). so how did you arrive at that VA? i'd also try out a plain BPX, ie. not the DRx type, i don't recall right now if winice enforces some memory range limits for DRx or not.



if you do a disassembly there, will winice display something like 'winice + xxxxx' where xxxxx is the RVA that you can find in the icedump include files?

Hi The Owl! and thanks for replying..
What i did was the following.
First i got Winice's base in memory by issuing a 'vxd winice' inside Winice.
Once i got the base address i added the RVA of the pPrintChar function found in the icedump's inc files for my Winice version.
pPrintChar's RVA is 0x0001879F. If i add this to COOOOOOO (base for a IDA disassembled winice) i get to the same place as in memory.
And yes when i disassemble memory at 0C0047043h i get a WINICE + 1879F which is the same RVA that w9xice4.05.334g.inc displays.
I also tried BPX 0C0047043h (actually i tried all the flavors of breakpoints) and no luck.
I also replaced the first instruction at 0C0047043h with a CC..but i won't do it again .
Would it be possible to debug a winice (with winice) running on a vmware virtual machine on the same computer??
Like i don't know how im gonna learn how it works if i can't debug it . (remote debugging??)
Again thanks for your help.

Latigo.

Hi Latigo,

I tried that kind of masochistic approach
some time ago, but since that project took me a lot more than the expected time, I threw it in the big list of my waiting projects. It was anyway a big fun. Here is what I did and what I learned.

You cannot debug Winice with Winice itself. You must use another kernel debugger. The only kernel debugger I am aware of, besides Softice (never tried with TRW2000, because at that time my platform was WindowsNT) is Microsoft WINDBG (take it for free at http://www.microsoft.com/ddk/debugging/).
Tip: I think TRW2000 could be a good solution for Win9x platforms, but I am not sure of...

Unfortunately WINDBG cannot debug the kernel on the same machine where it runs but it requires a remote computer.
The target machine will run the kernel with the /DEBUG option. In this way the serial port (COM1 or COM2) will be used by the kernel to send and receive information for the remote debugger, with a simple protocol nearly undocumented by Microsoft.
It seems that Windows Whistler could be debugged by WINDBG on the same machine...
So you have two chances:
(a) buy another PC and connect it to the target one with a null-modem cable
(b) put your hands on VMWARE

I followed the second chance, and after some troubles installing Softice on the VMWARE virtual machine (you must set a standard VGA driver on it, selecting only 16 colours in order to have a not-garbled screen when softice pops-up), another problem arose: how can the virtual machine dialogate with WINDBG? You have again two chances:
(a) use a null-modem cable to connect COM1 with COM2. Configure the virtual machine kernel in order to use one of them, and instruct WINDBG to use the other one. I did not try this solution: on the paper it should work... who knows?
(b) thanks to VMWARE facility of redirecting all the COMx flow to a named pipe, another way to connect the two machines would be via pipes. But this requires an NT driver (VMWARE runs only on Windows NT) in order to redirect the COM to a pipe, since WINDBG can use only a COM port to connect to the target machine.

Well, I wrote a filter NT driver on the top of the standard serial one, which simply redirects all the WINDBG I/O to a named pipe and gets there the answers from the VMWARE redirected kernel I/O. I was in the stage of debugging this one when I realized that VMWARE was yet full of bugs: a lot of times it crashed. I lost my patience and I decided to stop the project and to spend my time with some more interesting, waiting for some new releases of VMWARE.

In the following weeks I found another way to manage the problem. You could use Bochs (the Intel emulator with full source code) with its debugger built-in, in order to step inside Winice. Could it work? I would have the time to try... Grab a Windows version of Bochs with the debugger enabled at
http://www.reactos.com/tools/bochsget.html

Ok, please let me know if you have the time and the skillness to make some progress...
I would be very interested at it.
My best regards.

DinDon!!
Thanks very much!!
I really appreciate your info and i'll try all this stuff out as soon as i got some time.
Thanks again very very much

Bye now!

Latigo

i forgot to mention that TRW2000 can debug winice indeed (provided it works fine otherwise on your machine). on a more general note, you can understand (most of) the SoftICE code by looking at the disassembly only (and reading lots of docs, like Intel IA-32 manuals, DDK help + include files, books on VxDs/KMDs, etc). except for the symbol subsystem and some of the newer commands everything else was written in assembly, so it is less of a challenge to decipher; you'll find that you spend more time on reading docs then the actual code itself.