Dongle-Protected MS-DOS!

[fargo]

Someone sent me a link for MS-DOS 3.30 that is protected by dongle! Here is the link: https://archive.org/details/msdos-330-ar

I tried booting the first disk using an emulator and got "Security Device failure" error message!

Is this really protected by a dongle or just a corrupted copy?

 

[kc8eyt]

Hold down the LEFT SHIFT key while booting. This will bypass CONFIG.SYS and AUTOEXEC.BAT. One of these files may be loading some security software, if so you can bypass it.

 

[fargo]

That didn't work. I even deleted config.sys and auroexec.bat from the disk and got the same error message.

 

[Agent Orange]

That didn't work. I even deleted config.sys and auroexec.bat from the disk and got the same error message.

I think you're beating a dead horse with that one. I believe the problem is in IO.SYS and/or MSDOS.SYS or a combination of both. You can laboriously copy all the useful 3.30 files off and maybe find MSDOS 3.30 SYS.COM elsewhere which will generate those 2 systems file for you when invoked. This is what I know about it from years gone by and there may be other ways. I haven't encountered a software dongle since back in the 90's when I worked for the feds.

 

[Eudimorphodon]

Just out of curiosity I was able to trick it into installing on a hard disk image in QEMU by booting from a "normal" MS-DOS disk and then launching the installer from disk 2 of those from the archive, but trying to boot the resulting hard disk also produces the same "Security Device failure". If you then try to "sys c:" from the normal MS-DOS disk and reboot you get a bunch of warnings about incorrect DOS versions when it tires to run config.sys so, yeah, it sure looks like it depends on some kind of system check to run. It looks like Microsoft farmed the arabic localization off to a third party but there's very little documentation to be found about it.

Interestingly if you look at the disk with a binary editor that error isn't visible, at least in plain english. The boot sector has more code in it than the vanilla MS-DOS disk so I'm guessing the tripwire is cleverly hidden in there with the error message encoded in some alternative way.

 

[fargo]

I think you're beating a dead horse with that one. I believe the problem is in IO.SYS and/or MSDOS.SYS or a combination of both. You can laboriously copy all the useful 3.30 files off and maybe find MSDOS 3.30 SYS.COM elsewhere which will generate those 2 systems file for you when invoked. This is what I know about it from years gone by and there may be other ways. I haven't encountered a software dongle since back in the 90's when I worked for the feds.

I booted with a different version of MS DOS 3.30. Programs inside config.sys and autoexec.bat refused to run and complained about "wrong dos version"!

 

[Timo W.]

I'd guess "Microsoft MS-DOS 3.30 with Arabic support" gives a hint. Just like versions of DOS with support for e.g. Japanese, Chinese, etc., Arabic most likely needs an additional character ROM to be present in the PC - or even only runs on certain PCs made for it. The absence of that is probably what causes the message.

Also, I'd assume the internal version is not 3.30 to prevent compatibility issues.

 

[fargo]

I found an article from 1988 talking about this DOS. The "security device" is required for running this version!

 

[ldkraemer]

Why don't you download the MSDOS 3.3 Version from https://www.allbootdisks.com/download/dos.html

The EXE file will write a floppy when run from a PC, or you can write the IMG file directly to Floppy.

Larry

 

[fargo]

Why don't you download the MSDOS 3.3 Version from https://www.allbootdisks.com/download/dos.html

The EXE file will write a floppy when run from a PC, or you can write the IMG file directly to Floppy.

Larry

I'm not interested in this because I specifically need DOS 3.30, but because it's a rare version with hardware protection from Microsoft.

 

[Eudimorphodon]

Also, I'd assume the internal version is not 3.30 to prevent compatibility issues.

The boot sector has the same 3.30 string as a generic MS-DOS but, yes, there are sub-version numbers that are different to make sure the binaries fail.

Re: "font rom" or whatever, according to the sketchy docs that are out there (and also visible in the display selection part of the installer, which you can run after booting from plain DOS) the major requirement for running this version of DOS, other than the security device, is you need to have display hardware with software definable fonts. That means plain MDA/Hercules and CGA are out, but in addition to EGA/VGA it supported a range of other oddball code-page-capable cards.

There might be someone smart enough on this forum to disassemble the boot code and figure out a way to neuter the security device requirement, but that person isn't me. How hard it might be may well depend on whether there is just the one check in the DOS initialization code or if checks against that device are peppered all over the code.

 

[Agent Orange]

The boot sector has the same 3.30 string as a generic MS-DOS but, yes, there are sub-version numbers that are different to make sure the binaries fail.

Re: "font rom" or whatever, according to the sketchy docs that are out there (and also visible in the display selection part of the installer, which you can run after booting from plain DOS) the major requirement for running this version of DOS, other than the security device, is you need to have display hardware with software definable fonts. That means plain MDA/Hercules and CGA are out, but in addition to EGA/VGA it supported a range of other oddball code-page-capable cards.

There might be someone smart enough on this forum to disassemble the boot code and figure out a way to neuter the security device requirement, but that person isn't me. How hard it might be may well depend on whether there is just the one check in the DOS initialization code or if checks against that device are peppered all over the code.

On top of all that's been said, there may be something in the board's ROM that shakes hands with MSDOS 3.30. It may be worth taking a peek at the ROM.

 

[Eudimorphodon]

On top of all that's been said, there may be something in the board's ROM that shakes hands with MSDOS 3.30. It may be worth taking a peek at the ROM.

According to the doc fragment Fargo found it's explicitly stated that the security device is a parallel port dongle, which they don't have. How hard it is to break those dongles can vary a lot; sometimes they're extremely rudimentary dinguses that just return a static value when triggered, or do a simple bit-rotation on an input or other trivial task, while others can have ROM or NVRAM with encryption keys, full embedded CPUs, whatever. It doesn't really *look* like from a binary editor that "much" of the code of that disk is encrypted, but without disassembling it it's impossible to tell how often it bangs on the security dongle and what it expects to get back. It may be a simple couple-byte patch to fix it, or it might be a lot more involved.

 

[fargo]

I'm sure this is a retail DOS version that requires no specific hardware other than an IBM compatible with EGA or VGA video card, and a parallel port of course.

I compared the three main files in this version with a regular 3.30 version.

COMMAND.COM:
Identical files.

MSDOS.SYS:
Identical file sizes, with one byte difference: "DB" byte at offset 0x6d31 replaced with "CB" byte

IO.SYS:
Lots of differences.
Arabic ver size: 57,516 bytes
Regular ver size: 22,357 bytes



So, it seems all changes were implemented in IO.SYS file.

 

[Eudimorphodon]

It might be an interesting challenge to see if you can find encoded in that file (since that's probably where it is) the "Security Device failure" error message. It doesn't appear anywhere in the disk image as a naked string, I'm curious if it's in there with just a high bit set (or something similarly trivial to change it from ASCII) or if there's something more sophisticated happening.

 

[krebizfan]

Or examine a disassembly of the the IO.SYS looking for every call to the parallel port checking for to see what is sent and returned. Patching every dongle call to return success should result in an operational OS unless the dongle also stored ROM fonts or something.

 

[fargo]

Ok, I was able to debug the IO.SYS using QEMU and GDB. I couldn't figure out where the dongle check occurs. For anyone who wants to try, here are commands to run the emulator and the debugger:

% qemu-system-i386 -boot order=a -no-acpi -no-hpet -parallel file:lpt.log -s -S -fda DOS330_AR_01.vfd
% gdb -ex 'target remote localhost:1234' \
-ex 'set architecture i8086' \
-ex 'break *0x7c00' \
-ex 'continue'

 

[krebizfan]

I must be confused. It looks like the highlighted line involves EAX 32-bit register which should not used by 8086 code.

 

[Krille]

Not only is it disassembled in 32-bit mode, it's also in AT&T syntax. Yuck!

 

[fargo]

There is a bug in gdp preventing it from disassembling 16-bit code correctly. The workaround for that bug does not seem to be working with the latest gdp version.

Edit: maybe it's working! I have to start gdb with "-ex 'target remote localhost:1234'" only. Then from inside the gdp, issue the commands:
(gdb) set tdesc filename target.xml
(gdb) break *0x7c00
(gdb) c