(Offtopic?) Dos device driver modifcation query

Silver · 04 February 2007, 03:00

Apologies if this should be in Offtopic, as it does not relate to Amiga programming, but thought it might be better suited to the Coders forum...

I'm hoping there might be some people skilled in dissasembly/assembly language who can help me out.

I have an (old) real-mode DOS device driver (runs on FreeDos,Dr-Dos,CalderaDos - anything MS-dos compatible basically) that attaches IDE drives to the system without the bios.
i.e. the PC's bios can have the IDE devices set to "none", you can boot to dos from floppy, no "C" drive is present. Then you can run the driver, and it attaches all drives/partitions it finds and gives the letters (so the "C" drive appears).

Might sound pointless, but immensely useful on some SBC devices which run a tiny fast-booting bios that does not have HD's setup, and can not be configured/modified.

Unfortunately, it appears that this device driver rejects any hard disks that answer as "removable" to the ATA command query "Identify device". Which is exactly what compact flash IDE devices do... which is obviously what I'm trying to get to work. (It's not returning a 0 at a certain bit, basically).

What I want is to either modify the driver to ignore this bit/response, or run a TSR program to catch this query and patch it. I have dissassembled the file (and re-compiled) but my ability to find what I need in the code is sorely lacking.

Can anyone give me some pointers/lend a hand/tell me I'm wasting my time with this?

Not an obvious place to post, but all the people I knew who were good at assembly were busy patching bits to crack protections on the Miggy...

musashi5150 · 04 February 2007, 12:09

Sounds like a fun little exercise

Unfortunately I'm not versed in x86 assembler - but someone here might well be...

Silver · 04 February 2007, 19:01

I hope so. I was thinking that a driver/TSR to patch ram before I load the IDE driver would be easiest approach, although I could be wrong.

Silver · 05 February 2007, 13:57

Well I've been trying to look at this myself. Found an old DOS dissasembler and dissasembled the driver.

I've also found that that "Identify device" command (what is sent to the drive by the driver at the start) is "EC0h" or "0xEC".

I get a bit lost trying to track whats going on though. It must analyse the data returned by the drive ('word ptr' functions?) It's this bit I need to change what it is checking....

Anyone interested is seeing the disassembled file?

Photon · 05 February 2007, 14:41

Sure, put it in The Zone. Probably just a conditional branch that should be patched. It's the code after the return from the call (should be a regular DOS interrupt call?) that is of interest.

Silver · 05 February 2007, 15:44

Much appreciated, I'll stick it in the Zone shortly.

Been using this to (try) and teach myself a little bit of assembly. I'll upload the orginal driver (internal.sys) and an dump of dissaembler view.

Let me know if you need any of the ASM files - I am not that familiar with dissassemblers.

More info: This is a real mode DOs driver from Onspec, several years old. It's is going to query the standard DOS IDE ports for ATA devices.

The ATA "Identify Device" command is EC0h, which will make the device return a bunch of data. I'll look into the ATA spec and see exactly what it will return.

Thanks

Silver · 05 February 2007, 19:17

As a bit more info:

When the IDE device is sent the 0xEC command (Identify Drive) it will return
256 words/512 bytes.

This contains a pile of data (CHS info, serial number etc...) but specifically Word Address 0, Byte address 0 is the Configuration word consisting of 16 single-bit flags.

The flags should be:

Configuration/ID word bit flags:
15 Non-magnetic drive
14 Format speed tolerance gap required
13 Track offset option available
12 Data strobe offset option available
11 Rotational frequency tolerance > 0.5%
10 Data transfer rate > 10 MB/s
9 Data transfer rate > 5 MB/s, <= 10 MB/s
8 Data transfer rate <= 5 MB/s
7 Removable disk
6 Non-removable disk
5 Spindle motor can be switched off
4 Head switching time > 15 us
3 Not MFM encoded
2 Soft sectored
1 Hard sectored
0 reserved
The driver - I suspect - is checking for bits 6, 7 and 15 being appropriate. And they are potentially incorrect on a Compact Flash in IDE mode. So I need an ability to patch these bits in the response the drive sends/make the driver ignore these bits.

Silver · 08 February 2007, 12:07

This is proving taxing so far...

I am struggling to track down exactly where the driver is sending 0ECh to the drives. It pushes 0ECh to the stack at one stage, but then goes for a mile of subroutines and conditional jumps, and alters the stack offset, before I can get to a useful "out al,dx".

Can anyone recommend a program that will let me debug/step through a sys file? a lot of programs seem restricted to exe/com files, which a device driver.sys file is not. Or any ideas to make the code more legigble?

musashi5150 · 08 February 2007, 12:09

I think SoftICE for DOS is probably your holy grail

Silver · 08 February 2007, 14:25

Ok thanks... Not the easiest program in the world, it seems to do the job...

But anyway, I've set a breakpoint for port io access 1F0h (one of the normal primary master port access) which seems to work as I hit the breakpoint when the driver tries to load. I can then step through the program, all the way to the end, but without seeing what I am looking for.

I can see it kicking out instructions to the port (out dx,al etc..) and then reading stuff back (in ax,dx) after checking for the drive being busy (80h). But can't really see what I'm looking for.

Very fustrating - so near yet so far....!

Silver · 09 February 2007, 15:09

Argh. Thought I had it. Worded out when the driver was sending the "EC" command to the drive, found where it was storing the result in memory, set a break point there and patched it - but the driver just bugged out (at least with a different error).

It appears to read the config word multiple times off the drive, and store it all over the place in memory.

On top of all that, it seems that the driver will not install smoothly on a known good normal drive when I've set any breakpoints in SoftIce, which makes actually testing this close to impossible....

The joys of debugging in a new language. And if only I'd know at the start that Intel x86 stores in memory backwards....

musashi5150 · 09 February 2007, 15:12

Quote:

Originally Posted by Silver

And if only I'd know at the start that Intel x86 stores in memory backwards....

Indeed - beautiful processors, no?

Still, at least it sounds like you are making some kind of progress compared to the start of this thread anyway.

Silver · 09 February 2007, 16:04

Yes cheers... progress of a sort!

Ceratinly been on a steep x86 assembly learning curve the past 48 hours which is a good thing I guess.

Bit annoyed that the problem is more complicated than I suspected (if patching the config word had worked as I had hoped, then I probably could have worked out how to change the dissasembled source.

I think it compares the config word by ANDing it with a set value "8000", although in binary it doesn't make a huge amount of sense (based on what the bits mean in the IDE spec) so I could be wrong.

Its strange as technically apart from the config word a CF card in TrueIDE mode should be electrically indistinguishable from an ATA drive.

Silver · 10 February 2007, 05:09

Got it! Woohoo... (cough ahem, sorry).

Well it works (so far).

B*astards read and checked the config word TWICE for some unknown reason.

I was completely off on my original guesses of it checking for the "fixed disk" status - it doesn't at all. It checks on some arcane config bit (I was right about the 8000h comparision after all) that seems irrelevant nowadays.

The good news is that 'cheating' and getting a utility from Sandisk (via signing an NDA) which lets you change the 'Fixed disk' bit, or buying an expensive 'industrial' compact flash which come with the bit set, would have been an expensive mistake, as they would not work either.

A HUGE thanks to musashi5150 for the SoftICE mention - never would have hacked this without it (despite that fact the driver won't install correctly with any breakpoints in softince - I think the drive times out?).

EDIT: Does this make me a hacker?

musashi5150 · 10 February 2007, 11:04

Congrats Silver, that's excellent work! You should feel rightly proud for getting this working against the odds of x86 assembly

Quote:

Originally Posted by Silver

EDIT: Does this make me a hacker?

Yes, I guess it does

Good work... is there another program on your list or are you going to rest on your achievements now?

Silver · 10 February 2007, 11:18

Well there is always FAT32 support to look at. This driver will detect FAT32 partitions, and notify you of them, but won't assign them a drive letter as it assumes it would never work in Dos. But if you are using Dr-dos enhanced.....

(I have a feeling this might be a slightly bigger hack...)

Doc Mindie · 14 February 2007, 18:05

Sorry, Silver, it doesn't make you a hacker.

Ahacker is a person who breaks into a system, leaves a msg for the sysop saying "I got in this and such way" and then quietly goes out again without doing any harm, not changing anything, or snooping around in the system.

The good old hackers had a sense of pride...... the lamers nowadays has no pride, only a sense of destructiveness.

04 February 2007, 03:00	#1
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	(Offtopic?) Dos device driver modification/patch/hack query - files in Zone Apologies if this should be in Offtopic, as it does not relate to Amiga programming, but thought it might be better suited to the Coders forum... I'm hoping there might be some people skilled in dissasembly/assembly language who can help me out. I have an (old) real-mode DOS device driver (runs on FreeDos,Dr-Dos,CalderaDos - anything MS-dos compatible basically) that attaches IDE drives to the system without the bios. i.e. the PC's bios can have the IDE devices set to "none", you can boot to dos from floppy, no "C" drive is present. Then you can run the driver, and it attaches all drives/partitions it finds and gives the letters (so the "C" drive appears). Might sound pointless, but immensely useful on some SBC devices which run a tiny fast-booting bios that does not have HD's setup, and can not be configured/modified. Unfortunately, it appears that this device driver rejects any hard disks that answer as "removable" to the ATA command query "Identify device". Which is exactly what compact flash IDE devices do... which is obviously what I'm trying to get to work. (It's not returning a 0 at a certain bit, basically). What I want is to either modify the driver to ignore this bit/response, or run a TSR program to catch this query and patch it. I have dissassembled the file (and re-compiled) but my ability to find what I need in the code is sorely lacking. Can anyone give me some pointers/lend a hand/tell me I'm wasting my time with this? Not an obvious place to post, but all the people I knew who were good at assembly were busy patching bits to crack protections on the Miggy... Last edited by Silver; 05 February 2007 at 17:05.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Creating network device driver: multiple units?	tnt23	Coders. System	1	26 July 2013 09:18
Error: Not a DOS disk in device df0 -- Help, please?	jenxbunni	support.WinUAE	6	11 February 2013 20:10
device driver C tutorial/skeleton ?	watz	Coders. General	2	04 September 2012 23:12
Not a DOS disk in device DF0:	MoreGrog	New to Emulation or Amiga scene	10	23 July 2010 19:46
Is it possible to unload a device driver without rebooting?	dabone	support.Hardware	4	01 February 2010 18:13

04 February 2007, 12:09	#2
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 42 Posts: 2,351	Sounds like a fun little exercise Unfortunately I'm not versed in x86 assembler - but someone here might well be...

04 February 2007, 19:01	#3
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	I hope so. I was thinking that a driver/TSR to patch ram before I load the IDE driver would be easiest approach, although I could be wrong.

05 February 2007, 13:57	#4
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Well I've been trying to look at this myself. Found an old DOS dissasembler and dissasembled the driver. I've also found that that "Identify device" command (what is sent to the drive by the driver at the start) is "EC0h" or "0xEC". I get a bit lost trying to track whats going on though. It must analyse the data returned by the drive ('word ptr' functions?) It's this bit I need to change what it is checking.... Anyone interested is seeing the disassembled file?

05 February 2007, 14:41	#5
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,628	Sure, put it in The Zone. Probably just a conditional branch that should be patched. It's the code after the return from the call (should be a regular DOS interrupt call?) that is of interest.

05 February 2007, 15:44	#6
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Much appreciated, I'll stick it in the Zone shortly. Been using this to (try) and teach myself a little bit of assembly. I'll upload the orginal driver (internal.sys) and an dump of dissaembler view. Let me know if you need any of the ASM files - I am not that familiar with dissassemblers. More info: This is a real mode DOs driver from Onspec, several years old. It's is going to query the standard DOS IDE ports for ATA devices. The ATA "Identify Device" command is EC0h, which will make the device return a bunch of data. I'll look into the ATA spec and see exactly what it will return. Thanks

05 February 2007, 19:17	#7
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	As a bit more info: When the IDE device is sent the 0xEC command (Identify Drive) it will return 256 words/512 bytes. This contains a pile of data (CHS info, serial number etc...) but specifically Word Address 0, Byte address 0 is the Configuration word consisting of 16 single-bit flags. The flags should be: Configuration/ID word bit flags: 15 Non-magnetic drive 14 Format speed tolerance gap required 13 Track offset option available 12 Data strobe offset option available 11 Rotational frequency tolerance > 0.5% 10 Data transfer rate > 10 MB/s 9 Data transfer rate > 5 MB/s, <= 10 MB/s 8 Data transfer rate <= 5 MB/s 7 Removable disk 6 Non-removable disk 5 Spindle motor can be switched off 4 Head switching time > 15 us 3 Not MFM encoded 2 Soft sectored 1 Hard sectored 0 reserved The driver - I suspect - is checking for bits 6, 7 and 15 being appropriate. And they are potentially incorrect on a Compact Flash in IDE mode. So I need an ability to patch these bits in the response the drive sends/make the driver ignore these bits.

08 February 2007, 12:07	#8
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	This is proving taxing so far... I am struggling to track down exactly where the driver is sending 0ECh to the drives. It pushes 0ECh to the stack at one stage, but then goes for a mile of subroutines and conditional jumps, and alters the stack offset, before I can get to a useful "out al,dx". Can anyone recommend a program that will let me debug/step through a sys file? a lot of programs seem restricted to exe/com files, which a device driver.sys file is not. Or any ideas to make the code more legigble?

08 February 2007, 12:09	#9
musashi5150 move.w #$4489,$dff07e Join Date: Sep 2005 Location: Norfolk, UK Age: 42 Posts: 2,351	I think SoftICE for DOS is probably your holy grail

08 February 2007, 14:25	#10
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Ok thanks... Not the easiest program in the world, it seems to do the job... But anyway, I've set a breakpoint for port io access 1F0h (one of the normal primary master port access) which seems to work as I hit the breakpoint when the driver tries to load. I can then step through the program, all the way to the end, but without seeing what I am looking for. I can see it kicking out instructions to the port (out dx,al etc..) and then reading stuff back (in ax,dx) after checking for the drive being busy (80h). But can't really see what I'm looking for. Very fustrating - so near yet so far....!

09 February 2007, 15:09	#11
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Argh. Thought I had it. Worded out when the driver was sending the "EC" command to the drive, found where it was storing the result in memory, set a break point there and patched it - but the driver just bugged out (at least with a different error). It appears to read the config word multiple times off the drive, and store it all over the place in memory. On top of all that, it seems that the driver will not install smoothly on a known good normal drive when I've set any breakpoints in SoftIce, which makes actually testing this close to impossible.... The joys of debugging in a new language. And if only I'd know at the start that Intel x86 stores in memory backwards....

09 February 2007, 16:04	#13
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Yes cheers... progress of a sort! Ceratinly been on a steep x86 assembly learning curve the past 48 hours which is a good thing I guess. Bit annoyed that the problem is more complicated than I suspected (if patching the config word had worked as I had hoped, then I probably could have worked out how to change the dissasembled source. I think it compares the config word by ANDing it with a set value "8000", although in binary it doesn't make a huge amount of sense (based on what the bits mean in the IDE spec) so I could be wrong. Its strange as technically apart from the config word a CF card in TrueIDE mode should be electrically indistinguishable from an ATA drive.

10 February 2007, 05:09	#14
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Got it! Woohoo... (cough ahem, sorry). Well it works (so far). B*astards read and checked the config word TWICE for some unknown reason. I was completely off on my original guesses of it checking for the "fixed disk" status - it doesn't at all. It checks on some arcane config bit (I was right about the 8000h comparision after all) that seems irrelevant nowadays. The good news is that 'cheating' and getting a utility from Sandisk (via signing an NDA) which lets you change the 'Fixed disk' bit, or buying an expensive 'industrial' compact flash which come with the bit set, would have been an expensive mistake, as they would not work either. A HUGE thanks to musashi5150 for the SoftICE mention - never would have hacked this without it (despite that fact the driver won't install correctly with any breakpoints in softince - I think the drive times out?). EDIT: Does this make me a hacker?

10 February 2007, 11:18	#16
Silver Registered User Join Date: Jan 2005 Location: London Age: 46 Posts: 118	Well there is always FAT32 support to look at. This driver will detect FAT32 partitions, and notify you of them, but won't assign them a drive letter as it assumes it would never work in Dos. But if you are using Dr-dos enhanced..... (I have a feeling this might be a slightly bigger hack...)

14 February 2007, 18:05	#17
Doc Mindie In deep Trouble Join Date: Sep 2004 Location: Manchester, Made in Norway Age: 51 Posts: 841	Sorry, Silver, it doesn't make you a hacker. Ahacker is a person who breaks into a system, leaves a msg for the sysop saying "I got in this and such way" and then quietly goes out again without doing any harm, not changing anything, or snooping around in the system. The good old hackers had a sense of pride...... the lamers nowadays has no pride, only a sense of destructiveness.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)