Ghosting an Operating System for Privacy
by Diana
Upon wondering how to return privacy to home and hobbyist computing, I thought of an idea I applied on another system as a patch when track zero of the hard drive was damaged. I feel this idea could aid in providing a ghost portion of an operating system to prevent snooping or spyware or unauthorized data gathering.
The way to think of it is that surgically removing parts of an operating system can take vast amounts of time, especially if you do not have an interrupt map or operating system jump table. The method I'm describing relates to a solution I performed in the 1980s with a Xerox 820 that ran CP/M, and it is still applicable today.
When I received the Xerox 820, I rushed the startup sequence for the 20MB hard drive that came with it. As a result, track 0 was damaged. So, when a program ran and a warm boot was needed, a disk error would appear.
I wanted to fix the disk error because the hard drive contained other programs added when I bought the Xerox 820. I realized my Osborne 1 and Xerox 820 both ran CP/M and, as a new graduate in computer science from University of Wisconsin, my studies included computer science, computer engineering, and operating systems.
So, to fix the program, I studied how CP/M on the Osborne acted when a program ran for a cold boot. The primary mechanism was that rather than have a program end with a HALT statement in assembly, the programs actually ended with:
Since the WarmBoot constant related to a certain index in the BIOS jump table and the BIOS jump table was loaded into RAM, this meant the table could be modified. So, the code for WarmBoot is 0.
When you look at the jump table for $e000, you will see the code "jmp WarmBootMain".
Looking at the "WarmBootMain" code, I thought that maybe I could ghost the original warm boot routine with a ghosted routine that would remap track 0 on the hard drive and use track 0 on the "A:" floppy drive. When I looked at the code, my ghosted OS for "WarmBootMain" was the same except for one line of assembly. The assembly to specify the drive:
And was changed to:
As a result, when I used the Xerox 820, part of the start-up process was to put a special setup CP/M disk in "A:" drive with a submit script to link to the hard drive and add the modified ghost code. This was done by writing a small loader assembly program and then block moving an area open in RAM above the BIOS.
Very reliable and it always worked. When my dad was alive, he would show friends as he was proud about how I worked out a neat hack to get the full system to work.
On current computers, the biggest issues regarding privacy are communications ports and Wi-Fi drivers. As many of us know, when you bought a laptop circa 2005 and re-installed the OS, you had a special CD that included installing the Wi-Fi driver. If the Wi-Fi CD was not used, even with the Wi-Fi part of chip on the CPU, there was no code to use it, so it was shut off.
In areas where the Wi-Fi driver code is located, if one could devise ghosted code which would feign talking to the Wi-Fi device but, actually send the data to port NULL, then one could control their privacy better than an air-locked computer.
The reason I say one could control their privacy better than an air-locked computer is because an air-locked computer uses a patch that sets a gate as to which data can go to the Wi-Fi part of the chip - which mean it still uses the BIOS software part of the OS. So, a ghosted BIOS would act better because most people would see the same BIOS code when looking at the machine code, not realizing the ghosting.