The bogus file header was causing them to be interpreted as a different kind of file when opened by the viewer-editor (what we might consider an IDE today). The code wasn't encrypted at all and nothing prevented the author from reading it:
> In the editor, I could also clearly see the text of the BASIC source code for all the programs. It was there, not encrypted.
Incidentally, I find the various copy/read protection schemes of yesteryear absolutely fascinating. It seems like it always comes down to some brand of cleverness, and gives credence to the idea that there is always someone smarter than you.
Also “Never underestimate a time-rich, money poor kid”
The fact that it's a single bit confuses me. If it was a full null byte (0x00) it would be easier to explain. C strings are null terminated, so you could assume the editor stopped reading when it hit "the end of a string" but BASIC still executed it?
Or if it was some unreadable ASCII character, maybe it worked like an EOF in the editor? But the fact that he switched it from an F to an E gives me no clues. This stuff is unfortunately before my time, I'm sad I never got to play around with stuff like this in my youth.
Some older filesystems, like ADFS[1] which I'm familiar with, have a "type" attribute, along with the read/write/execute (etc.) bits, as part of the directory node [2].
On RISC OS, as that page says, a BASIC file has type FFB. I remember a plain text file had type FFF.
The byte apparently was not part of the file contents but part of a file header that was interpreted by the editor; probably encoding some kind of "file type" that was displayed differently when opened.
However, technically, switching an 'E' for an 'F' is flipping *two* bits :/
The RDOS file system provided means for protecting files by setting attributes. Because RDOS, not being a multi-user system, had no notion of file ownership, attributes applied to all programs that accessed a file. The sense of the attribute bits was, in most cases, the opposite of that in Unix; if the bit was set, the operation was prohibited. Files were by default created with all attribute bits cleared, permitting all operations. The attribute bits, as identified by the letters used to identify them in a file listing, were:
'R': prohibited reading
'W': prohibited writing
'P': "permanent file"; prohibited renaming or deleting the file
'S': identified a "save" file, that is, one that contains an executable program.
'N': prohibited symbolic links from linking to this file
'A': attributed protected; prohibited any further changes to the file's attributes. (A file that had both P and A set became un-deletable, except by reformatting the disk.)
'I': Prohibited reading or writing by means other than direct block I/O. (This was removed from later versions of RDOS.)
'?' and '&': User-defined attributes, ignored by RDOS
thanks for this! I've always wondered what the deal was, and teen me did not do any research on why the hack worked- once I got the files visible I just moved on. It was almost certainly this RDOS attribute stuff you show here I was playing with (also I took some artistic license in the post, not really sure it was 'F' vs. 'E'.)
