Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

new HACKWRAP fix for MS-DOS7+, aka smashing the bug (Miscellaneous)

posted by Ninho(R) E-mail, 15.12.2009, 19:08

> I incline to think that if you go with your method, you may as well leave
> it to the user's responsibility to repeat the loading of your driver as
> the last DEVICE entry. It is just a workaround, after all. If the user is
> unhappy, let him rewrite WRAPPER.SYS.

Couldn't agree more. After all, a user savvy enough to play with WRAPPER.SYS must be capable of RTFMing.

>> Magic_test: TEST Win386flags, MS_mask OR Ninho_bit
>> JNZ skip_unwanted ; jmp if any mask bit(s) is (are) set

> At any time that your bit is set, you make DOS take the jump, and at any
> time your bit is clear, you leave DOS to decide whether to take the jump.
> Since you're going to make DOS take the jump, why not just change the
> jump? The bit is redundant. At any time that you would set your bit, just
> change the JNZ to a JMP SHORT, and at any time that you would clear your
> bit, just change the JMP SHORT back to a JNZ.

> Leave the TEST alone. Change the 0x75 to 0xEB.

Yeah, there's more than one way to skin this cat. I still see advantages to having a separate switching bit in the DOS data segment : undoing the fix is then as simple as switching this bit off, no need to replay the code chasing game. Also, I certainly wouldn't /modify system files/ on anonymous clients' disks, but you and me and all the members here, could easily patch the one bit of code in /our/ copies of IO.SYS, once and for all, and then the FIXWRAP becomes as simple as flipping one data bit without all the heuristic work nor magics, black or otherwise. Oh well...

>> and black magic

> I think you'll end up with quite a lot of the latter. What the "exact
> science" points to, over and over, is that the DOS code segment is not
> meant to be found - well, not by anyone but DOS itself.
> Besides, what good is it to you to know what segment DOS uses for
> accessing its code? It's just an addressing base. It doesn't tell you
> where the DOS code starts, let alone where it ends. You're going to be
> involved in some heuristics, come what may.

It's not not exact science perhaps, but not too far. I combine the exact CS value that DOS uses (from the yet unmodified SHARE hooks) with the offset of Int27_entry (found at DOSDATA:F8E), and I bet you the "magic test" is fourteen bytes ahead of that! However I do not have to rely on the distance being 14 bytes - in practice though the code from the MTI to int27entry was unchanged in all samples I have examined, from Windows 95 Gold to Windows ME.
(Apart from the magic byte itself being 01 in 95A and 03 later).

>> DOS CS is kept near the start of IO.SYS data area @ 0070:0003.
> It holds the DOS data segment, as far as I ever knew. It was always a
> handy thing to know when debugging.

Yeah sorry. I already noted in another message, it was just brain fart :-(



Complete thread:

Back to the forum
Board view  Mix view
15347 Postings in 1387 Threads, 254 registered users, 12 users online (0 registered, 12 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum