If you're on at all recent firmware you're going to need to use version 3 of the serial protocol. See here for my implementation of that, which supports basically all the operations you can do over serial with the Jr: https://gitlab.com/anthem/py-threedub
Unfortunately, v3 of the protocol supports basically no interesting operations. You can start a print, attempt a firmware upgrade (and no, even with this I had no luck downgrading from 2.2.7), and get printer status, and that's about it.
I also had no luck using v1 (DAV- commands) or v2 (XYZ_@3D- commands) with the Jr. It just doesn't respond to them.
Now, here's an interesting thing -- I think there are some kind of password "salt" values that *might* be used to generate the chip passwords. There is a command, XYZv3/config=, which is used at the beginning of a print job to push what appears to be four 16-bit integer values:
XYZv3/config=pda:[1591]
XYZv3/config=pdb:[4387]
XYZv3/config=pdc:[7264]
XYZv3/config=pde:[8046]
I don't know what exactly these do, or what happens if you push different values, or in a different order. You can definitely start print jobs over serial without pushing these first, so if they are used for chip passwords then the firmware stores and re-uses the last values.
The reason I *suspect* these have something to do with the password algorithm is that, using the "0x0" chip ID and password that greatone76 generated a while back you can actually zero out the 12 least significant bits of the password for chip ID 0x0 by incrementally XORing the four values in the order (pdb, pde, pdc, pda) while shifting 4 bits left.
E.g.,
chip ID 0x0 password = 0x5ADBF8F3
Original password:
0x5ADBF8F3 = 1011010110110111111100011110011b
p = p ^ (pdb)
0x5ADBE9D0 = 1011010110110111110100111010000b
p = p ^ ((pdb ^ pde) << 4)
0x5ADB0D00 = 1011010110110110000110100000000b
p = p ^ ((pdb ^ pde ^ pdc) << 8)
0x5AC92000 = 1011010110010010010000000000000b
p = p ^ ((pdb ^ pde ^ pdc ^ pda) << 12)
0x5B888000 = 1011011100010001000000000000000b
So this is starting to look like some sort of checksum algorithm based on these four values. However, this simple sequence falls apart after the 12th bit and the rule no longer applies.
There's also some other aspect to this algorithm that ends up factoring higher bits of the ID (at least when non-zero) into the least significant bits of the password, since as you can see the password for chip id 0x1 is far different from that for chip id 0x0.
Also interesting is the fact that there are certain chip IDs that reproduce the same password. There are a few examples of this in greatone76's generated passwords:
(0x00000100000000, 0x44F5BB33)
(0x00010000000000, 0x44F5BB33)
(0x00000000010000, 0x9C18EBFF)
(0x00000001000000, 0x9C18EBFF)
(0x00000000000001, 0xABAA7D46)
(0x00000000000100, 0xABAA7D46)
So there's some sort of symmetry or omission that occurs between bits 1 and 3, 5 and 7, and 9 and 11 that makes them either factor the same into the password, or the algorithm ends up ignoring them in some cases.
In any case, I never got much further than that. Long story short I ended up upgrading to 2.2.7 just after learning how to use my logic analyzer, then I fried my stock firmware and ended up converting to RAMPS 1.4 anyway.