Reverse-engineering QNX 1.2 to boot from HDD

This is a guest post from Mihai Gaitos, hawk.ro. A winning entry for Virtualization Challenge IV – Act II – QNX 1.2 HDD Boot ($2000 prize).


Since a lot of people (especially Zir Blazer) tried to use the available QNX 1.2 / QNX 2 tools to install a HDD boot loader and load the existing kernel, I decided to take a different approach and build a new loader. At first I was under the impression that maybe a BIOS disk driver was already present in the kernel. After realizing that there was no HDD driver included, I decided to try reverse-engineering the relevant parts of QNX.

Starting from the start (boot sector) helped me extract the kernel from the boot diskette and analyze it just enough to validate that it’s the right thing and the assumed entry point is correct.

In order to make things easier (and because it was a fun project per se) I wrote a somewhat simple QNX filesystem access tool that enabled me to extract files from the diskette and HDD images.

Going for mount

Afterwards, my main activity was centered on mount. As opposed to typical Linux/Unix mount, here it also loads the HDD driver. After finding out the executable file format (ftp.qnx.com/usr/free2/technotes/qnx_load) I wrote another small tool to extract the code and data segments of QNX executables. Analyzing the disassembly, I have determined what operations mount performs in order to install the driver and mount a QNX partition. The main steps are:

  • load the driver file contents into malloc-ed buffer (inside the data segment of mount)
  • send a TA_ALLOC_SEG message to task in order to allocate a separate segment and copy driver there
  • build a DEFINE_DRIVER message using data from driver file and the allocated segment address and send the message to fsys (part of kernel, but separate task)
  • send a SET_ATTR message to fsys that has the side-effect of initializing the driver
  • use the driver to read first HDD sector (partition table)
  • send another SET_ATTR message to adjust disk size and offset to values read from partition

Knowing this gave me an idea to what my loader would need to do beside simply loading the kernel from HDD. However, this still depended on having an already running kernel to send messages to.

Back to kernel

The kernel is split into 5 parts:

  • task (task and memory management)
  • fsys (disk and filesystem)
  • dev (terminal devices)
  • idle (CPU arbiter)
  • shared (int 72 handler, mostly libc and other shared functions)

Description in parenthesis are my assumptions.

The copy protection routine (tries to read the last sector from diskette and if the read succeeds resets the computer) provides a good entry-point into the fsys part of the kernel. I assumed it can be replaced with some code to emulate what mount does. However, trying to allocate a segment (via TA_ALLOC_SEG message) hangs. I think this is causing a deadlock, since fsys initialization is called from task before it finished its initialization. Fortunatelly, while digging into this I noticed the header structure of the kernel, thus enabling me to increase its size in order to fit the xt driver at the end of fsys (it would have been slightly easier to put it at the end of shared, but that didn’t occur to me at the time).

Failing to use syscalls (DEFINE_DRIVER and SET_ATTR) meant I had to determine what those messages actually did. I disassembled fsys separately and proceeded to manually follow the code path in order to determine the effect each of those messages should have in the context of mounting a disk. Eventually it emerged that almost all of the data structures can be prefilled in the kernel image, leaving only the call to driver initializaion function.

I modified the kernel to add the xt driver at the end of fsys (modifying the header by hand), replaced the copy-protection routine with code to call its initialization, and indeed the harddrive was available from the start, without the need to run mount. I was still booting from diskette at this time but I was past the most difficult hurdle.

Finishing touches

Loading the kernel proved somewhat simple (I still have some knowledge about 16-bit assembly and real-mode BIOS) but the kernel “insisted” in trying to run /cmds/sh from floppy. At first I solved this by an ugly hack, modifying the command line string in kernel image from “/cmds/sh” to “3:/xi/sh” and “/config/sys.init” to “3:/xi/sys.init” (3: being the HDD identifier, similar to C: from DOS). The xi was needed in order to keep the same string length, or at least not making it larger since there was some other importand data just past this.

This mostly solved the challenge (there were some other minor mistakes and fixes), except I disliked that hack and went on to analyzing that first start of /cmds/sh, disassembling fopen (in shared) and finally finding the memory location where of the search system variable (somewhat similar to PATH). Modifying that variable eliminated the need for starting the first shell with “3:”.

Room for improvement

At present some parameters are hardcoded and the kernel is just placed at the end of the HDD, outside of QNX parition and its position and size is written in the boot sector (somewhat similar to the original QNX diskette approach). The partition size itself is hardcoded (by hand) in the kernel data structures instead of being read from the partition table on boot. Still, for something that is unlikely to ever run outside an emulator, I deem it good enough (for now).

Thanks

  • to Zir Blazer for putting a lot of effort into his approach and documenting each step
  • to Mitchell Schoenbrun for providing insight into QNX system philosophy
  • to forty for beating the first challenge and identifying the copy-protection routine address
  • and of course, to Tenox, Neozeed and Dan Dodge for the challenge. And for providing me with a great prize for 3 weeks of hard-working fun!

To access files, tools, bootable image and ready to run in your browser PCjs with QNX 1.2 go to Mihai’s site hawk.ro post.

QNX 1.2 Virtualized

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

A few week ago we ran a Virtualization Challenge to virtualize QNX 1.2. The difficult part of this one was that the boot disk was copy protected. Thanks to Kryoflux and SuperCard Pro I was able to image the disks and convert them to usable images using HxC software tool HFE.

Technically the competition has been won by Crazyc who was the first to submit disk images with copy protection worked around. He however waived his monetary prize and did not do any further work on making whole system bootable from hard disk.

While the copy protection turned out to be quite easy to circumvent and several people did it independently, installation on a hard disk proved to be quite impossible. You can fdisk, create partitions, lay out file system, mount and copy files to hard disk. However there is no way to install a boot loader and the kernel. QNX 2.x and above provide a way of doing it but unfortunately not version 1.x. Many people including various QNX gurus looked at it and we all gave up at this point.

Probably the only reasonable way of using hard disk with QNX 1.x is to copy all files from all the floppies to the hdd. Then use the boot floppy disk for booting and the rest from hard disk. This is likely why the disk set came with a backup copy of boot disk. This is what Forty eventually did in effect winning the competition. Forty supplied a 86Box ready to run configuration with patched and modified boot floppy to mount and use the hard disk image. I have buffed it up a bit to a faster XT and EGA video for better resolution. This is how it looks like during boot:

You can safely ignore date/time prompt with enter. To login to the system just enter slash ‘/‘ as the user name:

You can find all the binaries in /cmds directory. The system does have some sort of networking facility but I have not figured it out yet. Probably a good candidate to explore in another post.

QNX has a super cool editor which is basically ed on steroids. Documentation for it can be found in 2.x manuals.

Also working C compiler:

Finally QNX has some sort of a DOS emulator or hypervisor called QDOS:

Unfortunately I don’t know how to exit that. There is a little bit information about QDOX in expl inform section about other QNX products:

Congratulations to Forty for winning the competition and gettin $100 via PayPal. Thanks to his time and work you can boot and play the system yourself. 86Box files are here.

You may also be interested in QNX 2.x, QNX Windows and QNX 4.x posts.

Finally QNX 1.2 also works under PCjs emulator and you can try it online here.

Have fun with virtualization!

UPDATE : QNX 1.2 challenge Act II – HDD Boot

UPDATEReverse-engineering QNX 1.2 to boot from HDD

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

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

QNX 1.1 Demo Disk

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

Fresh from the oven, or rather Kryoflux dump – a QNX version 1.1 Demo Disk:

QNX 1.1 Demo Disk

I managed to boot it on 86Box:

QNX 1.1 booted on 86Box Emulator

For the readers with more curiosity and time at their hands please could you try it on different emulators and comment what works and what doesn’t.

For the less curious this how the demo actually looks like once you log in as demo user:

QNX 1.1 Demo Menu

As the authors demand to make as many copies of this disk as possible here it is. Please download and spread!

I also managed to dump the rest of QNX 1.2 including boot disk, utils and even c compiler. Unfortunately the boot disk is copy protected:

I have raw stream dump made with Kryoflux as well as regular disk images. If you are interested in circumventing checking the copy protection so the system could be run in an emulator let me know in a comment. Perhaps time for another Virtualization Challenge?

Previously:

Virtualizing QNX 2

QNX Windows – First Look

QNX 2.21 Arrived Today

OS Archive dot org

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

Dear lazyweb. I have been collecting operating systems and system software since 1991. My archive was always intended to be eventually made publicly available. A few years ago I began researching various hosting options. In the end I decided to settle on archive.org. Nothing beats free and maintained by someone else.

The whole hoard is ver very large and it will probably take a long time to upload. Due to a popular demand I started with smaller items mostly sought after. Enjoy.

QNX including your all time favorite QNX 2.x

Microsoft XENIX and OEMs such as Altos, Apple, IBM, Intel, Olivetti, Sperry, Tandy and of course our all time favorite SCO. Plus all these juicy apps.

ISC / Kodak / SunSoft Interactive UNIX

Microport

…and others.

Check back in future for more uploads.

QNX Windows – First Look

qnx-windows2

OLWM info:

qnx-olwm1

qnx-olwm2

Also managed to get 800×600 resolution under QEMU. To do so run with -vga cirrus and run the QW video driver with qw.vga_bios video7,1

800x600-2

Unfortunately the mouse doesn’t work under QEMU. Either in PS/2 or serial mode the cursor randomly jumps around with a tendency to hang around top line of the screen.

Virtualizing QNX 2.15

(Note this is a guest post by Antoni Sawicki aka Tenox)

Enter 1988… around that time Microsoft just released MS-DOS 4.01 and IBM shipped OS/2 1.1. Compare to the other two, this QNX was years ahead of its time. Pretty much on every aspect. Now, some 25 years later QNX2 is still found running industrial machinery, clean rooms, avionics and military hardware. Some people report systems up and running non-stop for 15 years and longer!

It took me similar amount of time to acquire usable media set. QNX is an embedded system and never really seen life on a desktop machine, so finding these floppies was rather hard and expensive adventure. Fortunately I can finally let it see some daylight. Let’s examine how the system will install on a modern hardware under VMware Workstation.

qnx2-disks

The install is rather straight forward. Floppy boot comes with a login prompt.

qnx2-vmware-floppyboot

After you log in as qnx you need to swap the floppy disk to Boot Utilities and run install. The script guides you through setup steps.

qnx2-vmware-install

First you need to select the disk controller. For compatibility mode QNX 2 provides access via int 13 (real mode).

qnx2-vmware-disk

Then you partition the disk. QNX partition type is either 7, 8 or 9. You will be asked to mark it bootable later on.qnx2-vmware-part

Then you have to select the kernel. QNX can operate in real mode and protected mode on AT286. qnx2-vmware-kernel

The install script copies all the data from distribution floppy disks, asks about boot loader and active partition. Finally you get to choose some video options.

qnx2-vmware-video

The system also asks about networking options. Unfortunately it only works with custom Arcnet cards so I skipped this. Once complete you are asked to remove the boot floppy disk and reboot the machine. This is what comes up after first hard disk boot.

qnx2-vmware-firstboot

I guess what is in the system will be the a topic of another post.

QNX 2.x files are here, a ready to run VMware image is here. Virtual Box here.

Updates:
You may also be be interested in QNX Windows and Fun with QNX 4 Networking posts.