Print

[rayarachelian]

Fun times! Was working on lisafsh-tool and wanted to add a los-depassword.c tool, but no luck.

Note that the password will only keep you from opening the document, it does not encrypt it. You can still extract it with lisafsh-tool, which is fine if it's text, but you won't be able to do much with say LisaDraw documents.

So each extent (inode) at hex offset 63 to around 6b (9 bytes) contains some kind of checksum for the document.

At offset 0x62 is the length field for the password. this goes from 0-8.
If you pick a password longer than 8 chars, say the max: 20 chars, the password length bytet will still stay at 8 chars.

If you touch chars 0x63-0x6b you'll no longer be able to open the file at all.

When you set a password that's all the same char, like 000000 and then switch to another that's all 11111111's, you can see the values there increment by 1. So it's a most likely just a summing routine. If your password is longer than 8, say you go from 7 zeros to 8, it rolls over and updates the first byte at 0x63 and the low nibble goes up by one more.

If you set the password length to zero, it will still ask for a password, but you won't be able to open the document (or drag it to the trash).
So the password length is not the only thing it uses as a flag.

When you have a plain file and convert it to password protected it will delete the extent (inode) and create a new protected one.
If you try to copy the values at 0x62-0x6b over those on the new extent, it will still ask for a password.

Even more fun, if you create a new blank LisaWrite doc and try to replace its contents with the contents of an encrypted one, because this checksum field won't match, it won't let you open it and put up a message saying "LisaWrite is unable to display this document. The document may be damaged."

But if you duplicate a file, you'll now have two files that have the same exact checksum.

[fri0701]

(I realize this is a pretty old thread, but I have some new discoveries that could be relevant)

Looking at disk images from LisaEm before and after setting passwords, and using Ray's notes above, I wrote a Python program for what I believe the algorithm for creating the password string is: https://github.com/tfrikker/lisa_utils/blob/master/lisa_password_generator.py

I also noticed that (at least on my setup), at the location where the password is stored, the string is set to a static value whenever a password is removed. That string (in my case) is "00004A6FEFA64E56FFA6". It seems to be true across documents, across document types, and across disks.

I tested this by creating a floppy image with a password-protected file, then ejecting it. I modified the password string for that file to the above value, saved the file, and re-inserted it into LisaEm. Both LisaEm and the Lisa OS itself complained that the disk was damaged (it looks like there's a more general checksum for the whole disk that I'm sure I broke), but after dismissing the warnings, the disk loaded just fine. Sure enough, the password for that file was gone, and it opened without a hitch.

If someone else wants to try this out and see if it works on their end, that'd be great!

[rayarachelian]

So dc42 has two checksums within it, one for the data and another for the tags. (That's unrelated to the LOS Desktop Manager checksums ofc.)

That's what you're seeing there when LisaEm complains of a disk checksum error. There's a routine in libdc42 that recalculates those here: https://github.com/rayarachelian/lisaem/blob/master/src/lib/libdc42/src/libdc42.c#L349

If you've solved the LOS document password issue, that's fantastic and thank you!

[rayarachelian]

... and the Lisa OS itself complained that the disk was damaged (it looks like there's a more general checksum for the whole disk that I'm sure I broke), but after dismissing the warnings, the disk loaded just fine. Sure enough, the password for that file was gone, and it opened without a hitch.

If someone else wants to try this out and see if it works on their end, that'd be great!

I had missed this bit you've mentioned about LOS itself by reading too fast; that warning usually happens when it detects the disk wasn't closed by LOS, i.e. power loss. It does this by looking at the tags and the file system and then prompts you to insert the LOS Install Disk #1 to repair, say the ProFile by running the scavenger tool.

Likely there's some flag on the tag of the inode as well that didn't get updated - since you've mentioned you've modified these floppy images yourself, (likely with python I presume?)

I'll take a look when I get a chance (and the applenet checksum thing from the other thread too, likely for that I'll put up a dialog box saying the checksum is wrong, would you like it fixed? that way the user can say "no" if they wish.)

In terms of the dc42 checksum and LisaEm complaining, there's an easy way to fix it, you can just do

Code: [Select]

echo quit | lisafsh-tool disk-image.dc42 - lisafsh-tool will then open disk-image.dc42 and close it, and as it closes it it will redo the checksums.