OSDev.org

Hi All,

I am trying to test the windows loader(NTLDR) to find out how many interrups it using before windows is fully loader.

Problem:
I changed my MBR to hook a particular interrupt(BIOS) lets say 15h. place my ISR some where in the memory. Then loaded the windows bootloader at address 0x7c00 and passed control to it. The problem is that while booting windows it overides my ISR thus hanging itself up. I tried various memory location to put my ISR at, but failed.

Is there a location where i can fool windows so that my ISR is never overwritten. ???

Any help will be appreciated.
Thanks
Inder.

Hi,

inderpreetb wrote:I changed my MBR to hook a particular interrupt(BIOS) lets say 15h. place my ISR some where in the memory. Then loaded the windows bootloader at address 0x7c00 and passed control to it. The problem is that while booting windows it overides my ISR thus hanging itself up. I tried various memory location to put my ISR at, but failed.

You could try putting your code just below the EBDA and then adjusting the size of conventional memory by updating the value at 0040h:0013h (see http://www.ctyme.com/intr/rb-0598.htm).

It's not guaranteed to work, but it might.

I won't ask why your doing this (not sure I want to know)...


Cheers,

Brendan

Try overriding INT 12h (Get Conventional Memory Size) and just subtract X KB from the return value as it passes through (obviously the code for both need to be position independant so that you can put it just below the EBDA [the value returned before you override it]).

Since this is in the OS Dev forum I'll assume you either want to know what Windows does so that you can copy the process or you're trying to modify Windows. For the former, that may not be a good idea as Microsoft's way is rarely the best way (athough this can be more to do with the implementation rather than design in a lot of cases). For the latter, can't help you there, and probably don't want to either.

Oh, and i should mention that Windows NT could perfectly be refusing to boot because it detects that INT 15h (or worse, INT 13h) is no longer pointing to the ROM BIOS code, which is typical from boot virus behaviour ...

Make sure you read the CLUF about reverse-engineering before you start anything based on the knowledge you gathered with those experiments ...

hi

Thanks for the pointers.
I don't think that windows does any such detection
as i was able to reach half way of the loading process
and it did'nt display any such warning or messages.

Still, i am working on the new methods, lets see what happens.

Thanks
Inder.