Can WinDbg do this?

WINDBG
1

Greetings to list members.

I have a binary driver (that is, no source code to it available) for an old ISA device that I need to debug. This is an Interface device used to communicate with an DSP Board via mapped IO on the ISA bus.
The Hardware is mostly similar to this reference implementation from freescale:
http://www.freescale.com/files/dsp/doc/inactive/APR10.pdf?fsrch=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

My job is to redesign this device to use the USB bus instead. A Prototype is working, but has some problems. Thus I want to compare it to the original driver regarding to how it accesses the device, and for that I need to find out the exact order of reads/writes, the addresses and the data that was passed.
There will only be a handful of accesses, so manual step-through would be possible.

I assume setting a Breakpoint on HAL.dll!WRITE_PORT_UCHAR and HAL.dll!READ_PORT_UCHAR should do the trick. But before I go into the troubles of setting up a debug target system (having only a single development machine right now, debugging the local Kernel wouldn’t let me set mentioned breakpoint) I wanted to ask experts if this is sound.

Also, when capturing such event with a breakpoint, will I be able to see what is passed to the called function (port and address in this case)?

Are there any better/easier alternatives? I have searched for an ISA bus sniffer tool, but wasn’t lucky.

You answers will be greatly appreciated.

Best regardsm

Fabian Cordes

2

Hello Fabian,

* On Tue, Dec 15, 2009 at 06:35:37AM -0500 xxxxx@web.de wrote:

I assume setting a Breakpoint on HAL.dll!WRITE_PORT_UCHAR and
HAL.dll!READ_PORT_UCHAR should do the trick.

Most probably: NO! Just grep through the WDK include headers and you
will find out that WRITE_PORT_UCHAR and READ_PORT_UCHAR (and the other
WRITE_PORT_XXX and READ_PORT_XXX functions) are #define’d to inp(),
outp(), and the like on x86 machines.

Thus, the compiler will replace the calls with intrinsics, resulting in
IN or OUT asm instructions in the code. Thus, no function calls are
generated.

Of course, some calls might be generated, but you cannot be sure that
you caught every one.

Also, when capturing such event with a breakpoint, will I be able to
see what is passed to the called function (port and address in this
case)?

If your breakpoint stops in the function: Yes.

Are there any better/easier alternatives?

Don’t you have a possibility to get the sources of the driver?

Beste Grüße
Spiro.

–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

3

Thank you very much for your response.

Unfortunately no, the sources have been lost (one of the reasons I am doing the work).
So no function calls are generated. That is a good point, i was not aware of that.
But I could use another known function also, such as the driver dispatch routine (while I have no source code, i know the structure of the driver, because I have all schematics etc. on the device).
As a last question, allows WinDbg for single-step execution after a breakpoint? Or does it only give a snapshot of the time when the breakpoint triggered?

4

Yes Windbg allows single stepping. Also, there is a data access breakpoint
ba that can break on port or memory access which should help you track what
is going on with the driver.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@windbg…
> Thank you very much for your response.
>
> Unfortunately no, the sources have been lost (one of the reasons I am
> doing the work).
> So no function calls are generated. That is a good point, i was not aware
> of that.
> But I could use another known function also, such as the driver dispatch
> routine (while I have no source code, i know the structure of the driver,
> because I have all schematics etc. on the device).
> As a last question, allows WinDbg for single-step execution after a
> breakpoint? Or does it only give a snapshot of the time when the
> breakpoint triggered?
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4689 (20091215)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4689 (20091215)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

5

Hallo Fabian,

* On Tue, Dec 15, 2009 at 07:45:23AM -0500 xxxxx@web.de wrote:

Unfortunately no, the sources have been lost (one of the reasons I am
doing the work). So no function calls are generated. That is a good
point, i was not aware of that. But I could use another known
function also, such as the driver dispatch routine

Ja, allerdings gibt es da keine Gewißheit, dass man alle Aufrufe
“erwischt” hat.

Eine Möglichkeit wäre natürlich auch, im Treiber nach den ASM-Befehlen
IN und OUT zu suchen und überall dort Breakpoints zu setzen. Die
Register DX und AX sagen einem dann, welcher Port (DX) zugegriffen wurde
und den Wert, der geschrieben (AL bei OUTB, AX bei OUTW, EAX bei OUTD)
oder gelesen (AL bei INB, AX bei INW, EAX bei IND) wurde.

Hier muss man natürlich beachten, dass OUTB, OUTW und OUTD sowie INB,
INW und IND jeweils eigene Opcodes haben. Man müßte also nach 6
Byte-Mustern suchen.

As a last question, allows WinDbg for single-step execution after a
breakpoint?

Bei Remote-Debugging: Ja.

Local wohl nicht (habe ich nie benutzt: Gehen da Breakpoints überhaupt?)

Du arbeitest nicht zufällig bei der Firma Goldammer in Wolfsburg? :wink:

Beste Grüße
Spiro.

–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

6

Hello,

* On Tue, Dec 15, 2009 at 02:11:01PM +0100 I wrote:

Hallo Fabian,

[…]

I am sorry, this was not meant for the list. (I was too lazy to write in
English…)

To come back to OnT: Of course, Don’s suggestion with ba is a good one.
I do not know why I did not think about it.

Regards
Spiro.

–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

7

Also consider ida pro, it does a rather remarkable job of disassembling and giving you “source”. For the amount of time it is going to cost you to reverse engineer your own driver, ida pro is going to be cheaper

d

-----Original Message-----
From: xxxxx@web.de
Sent: Tuesday, December 15, 2009 3:34 AM
To: Kernel Debugging Interest List
Subject: [windbg] Can WinDbg do this?

Greetings to list members.

I have a binary driver (that is, no source code to it available) for an old ISA device that I need to debug. This is an Interface device used to communicate with an DSP Board via mapped IO on the ISA bus.
The Hardware is mostly similar to this reference implementation from freescale:
http://www.freescale.com/files/dsp/doc/inactive/APR10.pdf?fsrch=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

My job is to redesign this device to use the USB bus instead. A Prototype is working, but has some problems. Thus I want to compare it to the original driver regarding to how it accesses the device, and for that I need to find out the exact order of reads/writes, the addresses and the data that was passed.
There will only be a handful of accesses, so manual step-through would be possible.

I assume setting a Breakpoint on HAL.dll!WRITE_PORT_UCHAR and HAL.dll!READ_PORT_UCHAR should do the trick. But before I go into the troubles of setting up a debug target system (having only a single development machine right now, debugging the local Kernel wouldn’t let me set mentioned breakpoint) I wanted to ask experts if this is sound.

Also, when capturing such event with a breakpoint, will I be able to see what is passed to the called function (port and address in this case)?

Are there any better/easier alternatives? I have searched for an ISA bus sniffer tool, but wasn’t lucky.

You answers will be greatly appreciated.

Best regardsm

Fabian Cordes

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

+1

Excellent advice.

If you do go that route, be advised that the ‘Basic’ version doesn’t support x86_64/x64/amd64, which really blows, as the ‘Advanced’ version is (last I looked) about twice the cost and unless you do embedded work, you’ll never use any of the many additional architectures it supports.

http://www.hex-rays.com

Good luck,

mm

9

Let me thank you again for the many inputs to this question.

I will definitly go on and set up a secondary computer to give those suggestions a try. Thank god I dont need to do full fledged reverse engineering, I looked at the disassembly more out of curiosity, hoping that they did hardcode the addresses, but they didn’t, at least not in an obvious way.
Basically all I want to know is which address and maybe data drives the reset line. Since there is a distinct IOCTL to do that, my Idea is (now) to break on the dispatch routine, send the IOCTL and see what happens :slight_smile:

Goodbye for now,

Fabian

10

Don’s I/O port breakpoint suggestion is a good one to consider if the device is not using memory-mapped I/O and the port numbers are well-known and few (less than or equal to 4).

The debugger command to use here is “ba”. Look up the documentation in the debugger docs for more details.

  • S

-----Original Message-----
From: Don Burn
Sent: Tuesday, December 15, 2009 4:55
To: Kernel Debugging Interest List
Subject: Re:[windbg] Can WinDbg do this?

Yes Windbg allows single stepping. Also, there is a data access breakpoint
ba that can break on port or memory access which should help you track what
is going on with the driver.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@windbg…
> Thank you very much for your response.
>
> Unfortunately no, the sources have been lost (one of the reasons I am
> doing the work).
> So no function calls are generated. That is a good point, i was not aware
> of that.
> But I could use another known function also, such as the driver dispatch
> routine (while I have no source code, i know the structure of the driver,
> because I have all schematics etc. on the device).
> As a last question, allows WinDbg for single-step execution after a
> breakpoint? Or does it only give a snapshot of the time when the
> breakpoint triggered?
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4689 (20091215)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4689 (20091215)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer