# Virtualization Challenge IV – QNX 1.2

(This is a guest post by Antoni Sawicki aka Tenox)

This is a Virtualization Challenge. A competition to virtualize an OS inside emulator/hypervisor. (Previously 1 / 2 / 3)

This time the object of the competition is QNX version 1.2. A demo disk is covered here. This is the set of floppy disks:

As you can see the boot disk is copy-protected. As such I have imaged these disks using both KryoFlux and SuperCard Pro. The magnetic flux stream images are available here. For verification I have converted the raw stream of the demo disk in to a sector image using HFE tool. The converted disk boots and works correctly in an emulator. The demo disk can also help with analyzing the boot process since it’s known to work.

The contest is to virtualize the OS, install it and provide a fully working hard disk image with the OS installed. Any emulator of your choice or method is acceptable as long as anyone can download and run it. The prize is $100 via PayPal and of course the fame! 🙂 The winner will be whoever comments the article first with a verifiable working solution. A bonus$50 prize will be awarded if you can patch the boot floppy disk so that it can be installed as if the copy protection was never there.

Good luck!!!

UPDATE: The competition has ben won: QNX 1.2 Virtualized

UPDATE 2 : QNX 1.2 challenge Act II – HDD Boot

## 58 thoughts on “Virtualization Challenge IV – QNX 1.2”

1. It looks like the copy protection is on track 39 side 1 which is just garbage according to hxc in your kyroflux dump. I wonder was the track was formatted as part of the install to hide the protection or is there some really something there that hxc can’t understand. Anyway the boot process tries to read sector 0x51 from that track.

• https://imgur.com/6yb1Ei1
Just had to convert qnx12_boot.img to imd and set track 39 head 1 sector 9 to sector number to 0x51. Maybe there’s more but at least it boots (in mame but I’m sure it’ll get that far with anything).

• Wow thas big! Awesome work. Thats practically winning the contest. Can you send me the patched boot image? I will try to install it fully on something like PCem or 86box.

• Sorry, total newbie here. What machine did you use on MAME to boot the .imd file? I tried Toshiba 1000 and IBM 5170 and they just don’t boot, the screen just waits for some kind of input.

And how can I get the imd back to raw? I tried samdisk and libdsk on Windows and they don’t seem to do the trick.

• /chdman createhd –compression none –output xt-qnx12.chd -chs 306,4,17

Will create an Empty XT Type 3 hard disk.

TYpe of drive will have to be set to 3 in the dip switches menu.

• Hey I sent you an email but you never replied. Whats the best way to contact u?

• hey how can I get in touch with you, I sent you emails, do you have discord by any chance?

• hey how can I get in touch with you, I sent you emails, do you have discord by any chance?

2. The protection can be bypassed by modifying qnx12_boot.img in a hex editor.

Patch byte at 0x004a5a9, change from 0x74 to 0xEB

0x74 is a JZ instruction
0xEB is an unconditional JMP.

This worked for me in pcjs. I used the debugger there to come up with the patch.

3. Doesn’t look like there is a boot loader for hard disks, so someone will have to write their own. Probably they could patch the floppy boot loader.

It is possible to mount a 10MB XT Hard disk and backup the files.

• Probably part of their insane copy protection

• Running mount shows 1:/ is only using 528 blocks. Typically 360KB floppy is 720 512k blocks.

The “kernel” appears to start at CHS 29:0:1 (522 LBA, 0x41400) and end at CHS 39:1:1, (711 LBA, 0x58E00)

• test

It is possible to mount a 10MB XT Hard disk and backup the files. mount disk 3 /config/xt fdisk 3 Search 3

4. It is possible to mount a 10MB XT Hard disk and backup the files.
mount disk 3 /config/xt
fdisk 3

• Make a partition in slot 1. Change, set OS of type 7 (QNX), start cylinder 0, end cylinder 305. Mark boot if you want. Save. Quit.

5. Then for the rest of the disks, put them in B:, and run
backup 2:/ 3:/

Tell QNX to use the search path of the HD, instead of floppies.
Search 3

6. Made a little progress, was able to dump the kernel off the floppy to a file.

Was then able to use a slightly newer version to write the loader to the hard drive.

I can now boot the kernel off the hard drive. Unfortunately it busy loops until a floppy is installed and loads the root file system from there.

The boot file is not just the kernel. It also has imaged into it a few QNX tasks. This includes the file system task, the device task, and in later version the network task. The file system task will either use (mount) the floppy driver if it was booted off of a floppy or a hard disk driver if it was booted off of a hard drive and the driver image is found in /config/hd???. After the kernel starts up and gets these tasks running, there is some mechanism that trys to execute the shell “sh” on a file in /config with the prefix like “sysinit”. I could look it up but I forget the exact name. The prefix can end with nothing, a .0 or .# indicating a node number, not something you need to worry about without a network card installed.

If the system doesn’t have an accessible drive, or the drive doesn’t have login, you can type CTRL-Z into the console and the device task will search for /cmds/login. If you are booting off of a real floppy and the boot diskette doesn’t have /cmds/login, you can see the floppy light come on looking for it. You could replace the floppy with a diskette with /cmds/login and try again and it will work. When you put in a login userid or userid/password if needed, the program /cmds/sh will be started and you will have a shell.

I’m not sure, but you might be able to put /cmds/sh at the end of the startup shell.

8. Hi,
Are the raw files a complete dump using Kryoflux? I can only seem to write back to floppy these disks:

dosfsys
qdos
utils

The rest give an error “The image contains invalid or incompatible data”
Any ideas?
Regards,

• I’ve tried loads of different ways of writing the KF dumps to floppy disk but does not seem possible. Have the Kryoflux dumps been modified in anyway?

• What ways of writing KF dumps to floppy have you tried? Also what the issue actual issue with writing?

9. Hi, I’m using a KF and DTC to write the raw files back to a floppy disk. This is the command im using: dtc -w -w0 -f”qnx12_boot00.0.raw” -d1

This fails with this error: The image contains invalid or incompatible data” Does not even get to the writing stage. I’m using a 5 1/4″ drive and DS,DD floppy disks. I can write back other raw files to floppy without problems.

Have you managed to write back to floppy?
Thanks,

• Well it’s true that the disk images contain “invalid data” because of disk protection. I would try to use the modified (hacked/fixed) raw (non KF) disk images and write these to disk.

10. How did you dump them from the original disks? What commands did you use? KF should not be bothered about the disk protection and should at least try and write back some of the tracks to disk??? From what I’ve seen above the protection is on track 39 and most probably has the typical sector size changed etc.

11. Any chance you could re-dump the boot disk with your Kryoflux? The raw files are really strange.

12. So it does seem there are issues with the dump. Couple of guys over at KF Forum mentioned that it could be a possible USB error (loosing packets while dumping) and other issues on other tracks which render this dump corrupt. Did you dump on a 48tpi drive or 96tpi?

• Would you be able to elaborate more about whats wrong with the dump? Many people have used it to successfully boot it in an emulator so for me it means it worked just fine. Also there is a secondary “backup” floppy disk. There also is a dump made by SCP (Super Card Pro) http://tenox.pdp-11.ru/qnx/qnx1/qnx11-supercard-raw.rar

13. “This dump is severely damaged : For example have a look to the track 32 side 0 in stream view : You can see twice time the sector 1 & 2 back to back… Which is impossible regarding the previous revolutions.

i suspect that the machine used to dump this disk has dropped a lot of usb packets (had a lot of usb buffers underrun/overrun… ?)

Even without any analyser you can see that there is something wrong : have a look to the tracks file size qnx12_boot37.0.raw, qnx12_boot32.0.raw, qnx12_boot34.1.raw versus the others files.

also : qnx12_boot25.1.raw and qnx12_boot26.0.raw are missing…”

• Could be to do with copy protection? Damaged floppy disk? Have you tried boot_backup floppy disk? How does it compare to other disks in the set? Is it only on the boot disks or other disks too? Also SCP disk images? How do they compare to KF images?

14. “If you simply run the stream files through DTC (e.g. dtc -m1 -fdump/q* -k2 -i) you will see plenty of messages like these…:

62.0 : The streaming device reported a buffering error

The USB connection was poor or the drive electronics generated way too much noise. In the latter case you should really set the density line for dumping to DD mode, e.g. -dd1 In the first case, make sure that you are not using a USB hub etc.
…”

I’ll see if anything can be done with the SCP dump. I dont have one so I have to rely on format conversion which is never good. The best would be to get the disks dumped again using the KF and making sure the USB connection is good. Maybe trying another port, making sure its not connected via a HUB etc.

• Okay thats bit better. Thank you. Is this specific to one disk image or all disk images?

15. I’ve quickly checked the others and they have simular USB errors. I would recommend dumping again all 5 floppy disks (these images are bad), piping the output to a log file, checking the USB does not go through a hub and using a 48tpi drive if possible. Also set the density line for dumping to DD mode, e.g. -dd1.

• Okay here is something that I don’t get. USB is a digital protocol. Packets either go through or don’t. USB itself has error checking and correction. It can’t damage data unless the data sent was already “bad”. I would rather assume that either the floppy disk medium, floppy drive or fdd cable has an issue, not USB. Finally these images were used to boot in an emulator so digitally they are correct. If the images were “bad” you won’t be able to boot and use them would you?

16. From what we’ve seen with the guys over at KF is the dumps are bad. There is no doubt here. Emulation works differently to real hardware. Its probable (as we have seen) that it allows you to boot and “apparently works” but when you do something that needs the area of the image/disk that is damaged then QNX will bomb out because its missing data there. There is data missing from the tracks due to the dumping problem with the USB.

If you have access to the original floppuies test it. Clean gently the floppies with a lint free cloth and with a mixture of Isopropyl alcohol/ distilled water. Clean floppy drive heads with alcohol and Q-tips. Use a different USB port or remove the USB hub and redump. Let’s see the outcome.

• I still don’t understand how USB transfer could affect data. Is Kryoflux sending analog audio signal over it? But even then USB is a digital protocol with error correction. If there were issues with data transfer why wouldn’t KF software tell right away that there was an issue, instead of writing incorrect data to an image. This doesn’t make any sense.

17. I’m sorry I don’t know enough about the internals of the KF device to answer that question . The Kryoflux Team mentioned the following:

“Each USB packet is serialised and DTC will complain when a packet is missing and mark the read as bad. So this dump must have taken ages with a dozen error messages per track.”

• I had no errors when dumping it.

• If you inspect the raw files they have errors. Depends what log level you have setup for dumping you will see things or not.
Try writing the boot disk back to a blank floppy with your KF and you will see 🙂

• You previously said “DTC will complain when a packet is missing” now I need a flag to turn it on?

I think maybe send me the exact command for DTC I should try?

• You can try this command on the re-dump if your using a 1.2MB drive:

dtc -f”qnx_boot” -i0 -k2 -i4 -d1

And to test write it back to a new floppy disk with:
dtc -w -wi0 -f”qnx_boot.00.0.raw” -d1

You can also output the log to a file with >
path\to\output.log and use -l8 for a format log view and output

This site uses Akismet to reduce spam. Learn how your comment data is processed.