Virtualization Challenge IV – QNX 1.2

Posted on by

(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

UPDATE 3: Reverse-engineering QNX 1.2 to boot from HDD

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.

  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.

  4. 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.

  9. 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.

  10. A couple comments.
    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.

  11. 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,

  12. 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.

  13. 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.

  15. 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?

  16. “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?

  17. “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…:

    00.0 : Bad stream position
    00.0 : Read operation failed
    …
    62.0 : The streaming device reported a buffering error
    62.0 : Read operation failed

    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.

  18. 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?

  19. 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.

  20. 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.”

      • 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

Leave a Reply to crazyc Cancel reply