Hello,

I have a problem with reversing an OS-loader / kernel:
It is the evaluation version of the ROM-DOS by Datalight,
which has a small 'bug'. When booting it displays a message
("You are using the eval version blabla..." und waits for
the user to press ESC. This is what I would like to fix.

But I don't have a clue where to start... The IDA-deadlisting
doesn't give me any hints (too much asm and too little
Interupt-calls ;-) and I don't know how to use a debugger
in this...

So it would be really great if someone could help me with this or
give me a hint on how to proceed with this...

Thanks very much in advance.

Decide the working of the same first:

1. Is this in the ROM ?
2. Is this loaded by ROM, but the first in the line of drivers?
3. Is it a .SYS file loaded by DOS?

1) If it is the ROM, you will have to search the message board and find out my tips on hacking ROMS. You will require softwares OTHER than simple IDA. Debuggers (current stock) are not sufficent.

2) If it is loaded as the first driver by ROM, then you will have to bring it down on the chain of drivers(suggest you look that up first).

3) Simple. IDA is best here (remember, UNPACK and DECRYPT, if necessary) before doing the same.

The reason you are not seeing many interrupts is because an interrupt is used by DOS. If this thing is capable of existing without DOS, then it will have its own methods of communicating with the hardwares. Find that out and you will know what to do. You can also use ROM-DUMPERS to dump the rom, disassemble it, mark the checks and remove them. Remember though, it will NOT be a jump/jne/jnz...etc at all. Instead it will be a loop of keyboard scan where it waits for the user to press ESC. Your best bet is to:

1. Dump the ROM
2. Understand the hex equivalent of the ASCII value of ESC key (or check SCANCODE value in hex)
3. Search for the same in the dump (you'll get a LOTTA hits)
4. Filter them. You know that its in a loop. Check for the same
5. The loop would be executed by some jump/jne/jnz....etc. but reversing them would prolly throw the whole system out. So instead, check for the values in the register and change them.

Have Phun

Thanks for your reply!

The protection sits in the part of the OS, which is written
to the bootsector of the HD or FD, so its first loaded
when starting the OS.

My first idea was to look for the loop and for the ESC-scancode, too,
but I didn't get any result with this.

About the scancode: For DOS the ascii-code for ESC would be 0x1b (27).
Is this DOS-specific or is it valid for any OS ?

Maybe, is there a way to use a program like VMWare to start
the OS an then using a debugger on it?

cu

Hello thenite !

If it is like you say and the "nag" is written to the boot sector of the HD or FD, then there is not much code which could contain the "nag", especially on FDs.

The ASCII code for ESC is 27 (=1Bh), but at deep OS level it's not likely that anything is done with the help of ASCII codes, but with the help of SCAN codes.

The SCAN code for ESC is 01h. You can get these code for other keys with help of INT 16. Just set AX = 0, execute and INT 16, press any key and after that AL will contain the ASCII code and AH the SCAN code of the key.

If you don't find it with help of INT 16, you should look for something like IN AL, 60. After this AL contains the SCAN code of the pressed key (but it doesn't wait for a key to be pressed).

So you might find something like this somewhere:

Hi, thanks for the hints!
I didn't thought about the difference between scancode and ascii code.
But unfortunately this didn't get me any further. I couldn't find
any occurence of the int 16h and no in al,60 or similar....
I even dusted off the old sourcer, for trying it istead of IDA, but
this didn't help, too. So I give up *g*

If there's someone who wants to take a look at it, drop me line
and I'll send it to you (~200Kb).

Many thanks for your tipps,
cu