Print

[fri0701]

Hi everyone,
I've been working with LisaEm and BLU a bit over the last few days, and wanted to note down some findings I had about the Lisa's serial number in one place. Hopefully this will be of help to others.

Through BLU, you can read the serial number of a Lisa off of its Video ROM. This is the serial number used for application serialization. Here's an example screenshot (with colors added, which I'll explain in a second):



The sections in green are standard - they seem to never change across Lisas, except in some prototype cases.
Notably, the 3 bytes in blue aren't "unused/unknown" - they're the checksum of the bytes in red. To calculate it, sum up all the decimal numbers in red, one by one. The resulting sum is the 3-digit decimal number in blue.

This is interesting for a couple reasons:
1. Many of the bytes labeled as "unused/unknown" are now known. The most interesting one to me is the byte to the right of the checksum - it's the only byte included in the checksum that has an unknown meaning.

2. Knowing how to calculate this checksum allows us to use any AppleNet number we want in LisaEm, or (in theory) in custom Lisa Video ROM chips. This is another method around serialization, if the AppleNet number the applications are serialized against are known.
For example, if I want to emulate Lisa AppleNet #00100001 (pretty early), I could use:
FF000000000000FF0010000100205D2C
(the checked bytes that aren't part of the AppleNet number aren't validated in any other way, and can be set however you like)
I could even generate a completely nonsensical AppleNet number like #99999999:
FF999999999999FF9999999918995D2C
...and it still works!

Perhaps in future versions of LisaEm, the serial number field in the Settings dialog could support setting an AppleNet number by itself, and do this math internally to produce a valid serial number.

_____________________________________

Another observation:

I was playing around with application deserialization, using David T. Craig's paper here:
https://lisaem.sunder.net/cgi-bin/bookview2.cgi?zoom=-3?page=5?book=7?Go=Go

In it, he mentions "My Lisa has the serial number 70,935 which is equivalent to $00011517.", which is the hex value encoded into the application for serialization.

This serial number didn't look to be in any format I recognized. It turns out that if you separate the hex value into 0x0001 and 0x1517, the 0x0001 is unrelated, or at least standard across all serialized applications. The second half, 0x1517, when converted into decimal, is 5399. I noticed when testing with my own disks on a Lisa with a known AppleNet number that this number *is* the AppleNet number. In other words, I believe David T. Craig's Lisa used for this paper is AppleNet 00105399.

This is intriguing - through examining Lisa ProFile disks or floppy disks that contain serialized applications, we can now tell which AppleNet number these applications are tied to. This could be useful to establish provenance, or even reunite Lisa systems with their original disks or drives.


Feel free to send any questions or comments my way. I hope this is useful to the community!

[blusnowkitty]

Feel free to send any questions or comments my way. I hope this is useful to the community!

This is quite interesting! And should prove very helpful in my own project to estimate how many Lisas were produced/remain in existence.

[rayarachelian]

Eh, I'm against the whole DRM/serial number thing. In 1982 it might have had some use for Apple, Inc. Today it's just an annoyance to be avoided.

LisaEm will let you set anything you want on purpose. This is to allow you to get whatever values are used off a real Lisa via use of the service mode, and make it available to LisaEm, so that way if you use BLU to copy an installed system you can still get the tools to run.

By default newer LisaEms will set the serial number to all zeros (with some sync bytes), this is the "magic serial number" that will prevent the DRM from working even if it does serialize a tool (since all zeros indicates unserialized).

AppleNet isn't used by any software in LOS AFAIK, while cards exist, there doesn't seem to be any software in LOS to make use of it in any way. Hopefully in the future when/if LOS source code is released, perhaps it might include some info/code about AppleNet proper.

Right now we don't think serial numbers are necessarily sequential, and can't be used to estimate the total number of Lisas made directly, so we'd have to use the "Tank" algo and a spreadsheet to do that..

I did add a small tool to decode the actual VSROM which might be of interest to you: https://github.com/rayarachelian/lisaem/blob/master/src/tools/src/decode-vsrom.c if you wish to pursue this further. You might be able to use some of this code as an example to generate valid serial/AppleNet IDs. The purpose of this tool is to allow you to use an EEPROM burner to read the VSROM and get at the serial number info without having to install it on a CPU board, power up the Lisa, and use BLU or Service Mode to get at it, etc.

It's possible that the AppleNet card boot ROM may have some more hidden details about the AppleNet ID number in some form, though it does seem to have rudimentary boot code. Tom might have done some work on this, not sure.

The deserialize tool ( https://github.com/rayarachelian/lisaem/blob/master/src/tools/src/los-deserialize.c ) will now work on hard drives as well and will remove not only the serial number but the copy inhibition flag (I call it bozo-bit which is in line with the original Mac System bozo-bit that was later removed.) There's also a tool that will let you enable the bozo bit ( https://github.com/rayarachelian/lisaem/blob/master/src/tools/src/los-bozo-on.c ), but this just sets a flag that prevents LOS from allowing you to freely copy a tool.

So, since AppleNet IDs don't seem to be used for anything on LOS, I didn't bother with any of that. The source code to the "H" Boot ROM is available and does some checking of the serial/applenet checksum data as it comes off the VSROM (see the code around 0BF6, and checksum routine at 0CB2 - note that this is different from VFYCHKSM which is used to checksum the boot ROM itself). You might look at that code as well. Perhaps if it was important, I might add a button to fix the checksum bytes of the serial # based on the "H" ROM code at 0CB2, but... doesn't seem to matter.

In an unrelated vein, there's something even more interesting to me. LOS documents are checksummed and this checksum is somehow changed if there's a password set.

The data in the document itself remains in plain text - so this is not encryption in any sense of the word and you can see the whole text of the document with lisafsh-tool, but you just can't mess with it in any way, if you do, LOS will refuse to open the document no matter what, saying it's damaged. I think this is what John Couch referred to as "The Lisa has document data protection but the Mac does not" (paraphrased) in his new book.

I've not been able to reverse engineer this, but I've noticed that when you take a document that's unprotected and set a password, the Desktop Manager will create a new inode for it with a new checksum, and destroy the original one. For example if you have a LisaWrite document and it lives at inode 123, once you set a password on it, the document itself will remain the same, but the new inode will have a new checksum (and possibly a flag that indicates this).

I tried to mess around with simple passwords like a single char like "a" and then "b" and see if there's some pattern, one did show up, but it behaves differently based on the size of the password and spaces, etc. Seems to be adding characters, but I'm unsure of the full algo.

So effectively what this means is that if you have a plain text document, you can't just feed it to the Lisa and make it look like a LisaWrite document, it won't be accepted by the Desktop Manager. Best we can do right now is copy & paste from the host machine to the keyboard into a document. i.e. it breaks modern day data transfer of a document to LOS from, say your macbook pro.

[stepleton]

It's possible that the AppleNet card boot ROM may have some more hidden details about the AppleNet ID number in some form, though it does seem to have rudimentary boot code. Tom might have done some work on this, not sure.

This is possible, but if it's happening, it's still a mystery to me. My boot ROM disassembly notes are here: https://github.com/stepleton/applenet/blob/master/applenet_boot_rom.txt . There are a few more adventurers here since the last time I shared this --- maybe their fresh eyes could find something?

[fri0701]

So, since AppleNet IDs don't seem to be used for anything on LOS, I didn't bother with any of that. The source code to the "H" Boot ROM is available and does some checking of the serial/applenet checksum data as it comes off the VSROM (see the code around 0BF6, and checksum routine at 0CB2 - note that this is different from VFYCHKSM which is used to checksum the boot ROM itself). You might look at that code as well. Perhaps if it was important, I might add a button to fix the checksum bytes of the serial # based on the "H" ROM code at 0CB2, but... doesn't seem to matter.

I actually referenced this code earlier when trying to figure out the pattern to the checksum. I noticed a pattern in LisaEm and went to the ROM code to double-check. Importantly, if the above checksum isn't correct, the Lisa will refuse to boot with a "CPU 42" error.

What we now know is that while the AppleNet number doesn't seem to be fully sequential across the Lisa's production span (only partially so in "batches" of machines), it does seem to be unique, and it's this unique identifier that's used in application serialization.

Your document password problem is interesting... I'll have to take a look at that next 

[compu_85]

So effectively what this means is that if you have a plain text document, you can't just feed it to the Lisa and make it look like a LisaWrite document, it won't be accepted by the Desktop Manager. Best we can do right now is copy & paste from the host machine to the keyboard into a document. i.e. it breaks modern day data transfer of a document to LOS from, say your macbook pro.

Something you can do is use the Text Reader app from the Toolkit Examples. You can then copy / paste the text into LisaWrite.

-J

[rayarachelian]

Something you can do is use the Text Reader app from the Toolkit Examples. You can then copy / paste the text into LisaWrite.

Nah, no need for the extra step, I can paste directly to the "keyboard" via LisaEm's Edit/Paste to Keyboard menu item directly into LisaWrite, but would have been better if we could directly convert and upload a document from, say, .rtf or whatever to LisaWrite. (And ofc, there's always the graphics/draw data to consider.)