Re: reverse engineering windows driver for linux

g.wall wrote:

> if i can find out how the memory mappings are working
> cant i just watch values written to/read from a certain set of addresses
> to determine what command and control values are being used
>
>
>
> Iwo Mergler wrote:
>> g.wall wrote:
>>
>>
>>>I am trying to reverse engineer another windows driver for a new PCI
>>>fpga board. I am trying to figure out how to catch signals being sent
>>>out over the pci bus, or maybe through the windows kernel in order to
>>>see what commands
>>>are being sent to the device (ie DMA transfer, reset, reconfigure, etc)
>>>(the device API has all these things well hidden in the code i have been
>>>given).
>>>I have been able to get a software package
>>>that shows what windows API function calls are being made for a given
>>>executable, and i have some other
>>>reverse engineering tools, but i was wondering if you knew of something
>>>easier, or could make a suggestion on my approach.
>>>
>>>what i have:
>>>1. C API libraries for configuring, IO, various device specific
>>>functions for the pci board
>>>2. A .sys windows driver file (this is binary but can be opened and
>>>parsed with some reverse engineering tools i have)
>>>3. debuggers, dissassemblers which show the windows API function being
>>>called for a given process, and the values passed to these API functions
>>>
>>>what i need
>>>1. device specific command and control values
>>>2. information about memory mappings on the device, ie what address maps
>>>to what fpga, sdram, etc
>>>
>>>
>>>ideally i would like to catch values sent to the PCI board as i step
>>>through the devices API function calls in my test code(writeword,
>>>readword, etc)
>>>in order to match a certain command bit sequence to an API function call.
>>>
>>>
>>>if you have any thoughts at all on this, they would be most appreciated.
>>
>>
>> The PCI transactions are the result of memory/IO access to addresses
>> within a specific address range. The base address of this block is
>> normally set once, at system start time.
>>
>> What I'm trying to say is that your question has the same answer as
>> the question about intercepting memory accesses - you need hardware
>> support.
>>
>> The hardware may be already present in the processor. If you can create
>> a debugger breakpoint on memory data read/write of a specific address,
>> you could use the same method to intercept the PCI transactions.
>>
>> The hardware may be emulated. If you can get the thing to run inside
>> a PC emulator like QEMU, you may be able to record the transactions.
>> You'll have to modify QEMU for this.
>>
>> If the transactions are time critical, the only feasible solution is
>> to get another FPGA PCI card which you configure as a PCI transaction
>> logger. If you're not terribly unlucky, it should see the transactions
>> on a neighboring slot.
>>
>> Some very expensive logic analyzers have PCI support.
>>
>> Kind regards,
>>
>> Iwo
>>
Iwo is right, you need dedicated hardware analyzers. Fortunately they can
be rented. On the other hand you should take a course in their use at the
beginning of your rental.
--
JosephKK

.

Relevant Pages