V3 Password Experimentation
- Thread starter hwd45
- Start date
Help Support TamaTalk:
How many values of d_user_item should I be cycling through?
I've tried d_user_item values up to 26 with the item codes 75 (plant) and 129 (Key 1) with the username LUCKY with no success.
I've tried d_user_item values up to 26 with the item codes 75 (plant) and 129 (Key 1) with the username LUCKY with no success.
Last edited by a moderator:
hwd45
Well-known member
d_item_user can be anywhere from 0 to 255 unfortunately. It's a lot of trial and error at the moment, and I've still not been successful in finding any semblance of a pattern in these numbers.
I found that a d_item_value of 71 works with the username LUCKY and the item_code 129 (key1), however I tried setting Byte 4 to the values 1, 55 and 166, and the password didn't work on all three occasions.
hwd45
Well-known member
Huh. And Byte_5 was 0 when you changed Byte_4? That's interesting because it potentially shows some addition a structure I wasn't aware of.
![Vaxson 3-Pack Screen Protector, compatible with Tamagotchi Connection Version 5 Celebrity /V5C/V5.5/Dream Royal Family Plus TPU Film Protectors Sticker [ Not Tempered Glass ]](https://m.media-amazon.com/images/I/51ipUKPjAWL._SL500_.jpg)
![Tznzxm [10-PACK] Screen Protector Compatible with tamagotchi connection Clear Soft TPU Film](https://m.media-amazon.com/images/I/41usSfxgBUL._SL500_.jpg)
![Vaxson 3-Pack Screen Protector, compatible with Tamagotchi Connection Version 3 V3 TPU Film Protectors Sticker [ Not Tempered Glass ]](https://m.media-amazon.com/images/I/41zSjSBo1mL._SL500_.jpg)
hwd45
Well-known member
Interesting! Either I've forgotten to add a BIN2DEC somewhere in the generator or there's something I've totally not accounted for.
SilverRibbon
Member
- Joined
- Sep 9, 2019
- Messages
- 6
- Reaction score
- 14
Quick questions from someone who is both really bad at math and really impressed by your research so far--
If a Tamagotchi is technically such a simple and small device, why does the password generation have to be so complex? I understand that the developers didn't want people being able to cheat to get easy codes for everything and ruin the fun, but is it REALLY that difficult of an algorithm, or is it just really difficult to narrow it down to what they chose to do with it?
I'm having a ton of fun reading through these posts
If a Tamagotchi is technically such a simple and small device, why does the password generation have to be so complex? I understand that the developers didn't want people being able to cheat to get easy codes for everything and ruin the fun, but is it REALLY that difficult of an algorithm, or is it just really difficult to narrow it down to what they chose to do with it?
I'm having a ton of fun reading through these posts
hwd45
Well-known member
Although it can be difficult for a human to get their head around, the operations used in decoding a password are actually really simple for a computer written in an assembly language (like the one Tamagotchis are written in) to perform. In some senses it's kind of the simplest way they could do it while still maintaining some level of username encryption!
Last edited by a moderator:
Found some more working codes
Also bought some airplane tickets which gave me the following codes
Australia code (Username:LUCKY): 67864 34388
Switzerland code (LUCKY): 12472 35059
Item code
d_item_user
byte_04 (working)
byte_04 (non-working)
130
70
1
56, 87, 148
131
69
2
1, 4, 126, 244
132
68
1, 2
126, 244
Also bought some airplane tickets which gave me the following codes
Australia code (Username:LUCKY): 67864 34388
Switzerland code (LUCKY): 12472 35059
Item code
d_item_user
byte_04 (working)
byte_04 (non-working)
130
70
1
56, 87, 148
131
69
2
1, 4, 126, 244
132
68
1, 2
126, 244
hwd45
Well-known member
I'm wondering if the reason some of the passwords aren't working is to do with the Y at the end of the username? This puts a 1 at the start of the username constant which I'm not sure how to deal with yet - it could be having adverse effects on the rest of the password.
The ticket passwords are helpful! I'm not yet sure what I'm going to do with them or if they'll help with getting the remaining items, but I'm definitely curious about them, so any passwords you have to donate would be helpful. That includes Parent / Grandparent passwords, which have been known to regularly change.
If these passwords use a similar structure to item passwords it's possible that generating a bunch of them will help crack that third byte! I'll be generating as many as I can with the V3 I'm currently running.
Last edited by a moderator:
hwd45
Well-known member
It turns out that parent and grandparent passwords are calculated in a similar way to item passwords! Essentially, there's four components to a parent / grandparent password: U, the username; C, a constant; D, the data; and S, an optional constant.
Let's go over each one. I'm on mobile, so forgive the lack of lovely formatting
The Username U is exactly what it says on the tin - as before, you take the five characters of the username, reverse them and convert each letter into binary via the following correspondence:
A - J: 00001 - 01010
! - ?: 01011 - 01100
K - Z: 01101 - 11100
Blank space: 11101
I actually only just discovered the ID of the blank space character - I'd assumed it was 0, but apparently not!
So, as an example, the username ABCDE becomes 0010100100000110001000001.
The Constant C is independent of the username and data. A similar constant is used in the item password encryption - using | pipes | to split up bytes (so that I can represent them in decimal instead of binary), the constants for parent passwords and grandparent passwords are as follows:
Parent: 0 | ??? | 70 | 62 | 6
Grandparent: 0 | ??? | 134 | 62 | 6
The Data Value D basically just contains all the information corresponding to the password in question.
Parent: 0 | ??? | PID | 0 | CID
Grandparent: 0 | ??? | GID | 0 | CID
Here, the CID is the ID of the character in use and the PID and GID are the IDs of the parent and grandparent characters respectively. Helpfully, the IDs can be found in some of the archived Tamatown .xml files, though the IDs also match up with the order the characters appear in the debug mode character list.
The Optional Constant S is an additional constant which can be applied to the password in order to generate a second password - that's why there's two different passwords that can be received from each parent. This also mimics item passwords:
S = 1 | ??? | 106 | 106 | 106
The password can be obtained by one of the following two calculations - this gives a ten digit number which is once again rearranged such that the first five digits are on the bottom row of the password:
P = U XOR C XOR D
P = U XOR C XOR D XOR S
You might notice that I've left question marks in the second byte for each of them. Once again, there's a single byte which just doesn't want to behave! In particular, the ??? in the (not-so-constant) constant S seems to fluctuate slightly - sometimes it's 107 (that is, 106 XOR 1) and other times it's 117 (106 XOR 31). There's probably other values it takes on too, but if you've been following along with my other posts you might be getting Déjà Vu. It's like there's another variable - say E - which is applied to the second byte along with the rest of S.
Hopefully this insight will help what's going on with the middle byte in the item passwords - perhaps it's the middle byte which takes on a random value and the second byte that is having the same fluctuating variables applied to it as we see in the parent passwords? Who knows.
Also, the presence of those repeated 106s and the general structure of these passwords make me wonder... perhaps the patterns will begin looking clearer if we XOR out the username and 106s before trying to make out patterns in the second and third bytes? That'll be something to try.
Let's go over each one. I'm on mobile, so forgive the lack of lovely formatting
The Username U is exactly what it says on the tin - as before, you take the five characters of the username, reverse them and convert each letter into binary via the following correspondence:
A - J: 00001 - 01010
! - ?: 01011 - 01100
K - Z: 01101 - 11100
Blank space: 11101
I actually only just discovered the ID of the blank space character - I'd assumed it was 0, but apparently not!
So, as an example, the username ABCDE becomes 0010100100000110001000001.
The Constant C is independent of the username and data. A similar constant is used in the item password encryption - using | pipes | to split up bytes (so that I can represent them in decimal instead of binary), the constants for parent passwords and grandparent passwords are as follows:
Parent: 0 | ??? | 70 | 62 | 6
Grandparent: 0 | ??? | 134 | 62 | 6
The Data Value D basically just contains all the information corresponding to the password in question.
Parent: 0 | ??? | PID | 0 | CID
Grandparent: 0 | ??? | GID | 0 | CID
Here, the CID is the ID of the character in use and the PID and GID are the IDs of the parent and grandparent characters respectively. Helpfully, the IDs can be found in some of the archived Tamatown .xml files, though the IDs also match up with the order the characters appear in the debug mode character list.
The Optional Constant S is an additional constant which can be applied to the password in order to generate a second password - that's why there's two different passwords that can be received from each parent. This also mimics item passwords:
S = 1 | ??? | 106 | 106 | 106
The password can be obtained by one of the following two calculations - this gives a ten digit number which is once again rearranged such that the first five digits are on the bottom row of the password:
P = U XOR C XOR D
P = U XOR C XOR D XOR S
You might notice that I've left question marks in the second byte for each of them. Once again, there's a single byte which just doesn't want to behave! In particular, the ??? in the (not-so-constant) constant S seems to fluctuate slightly - sometimes it's 107 (that is, 106 XOR 1) and other times it's 117 (106 XOR 31). There's probably other values it takes on too, but if you've been following along with my other posts you might be getting Déjà Vu. It's like there's another variable - say E - which is applied to the second byte along with the rest of S.
Hopefully this insight will help what's going on with the middle byte in the item passwords - perhaps it's the middle byte which takes on a random value and the second byte that is having the same fluctuating variables applied to it as we see in the parent passwords? Who knows.
Also, the presence of those repeated 106s and the general structure of these passwords make me wonder... perhaps the patterns will begin looking clearer if we XOR out the username and 106s before trying to make out patterns in the second and third bytes? That'll be something to try.
[SIZE=12pt]Item code [/SIZE]
[SIZE=12pt]d_item_user [/SIZE]
[SIZE=12pt]byte_04 (working) [/SIZE]
[SIZE=12pt]byte_04 (non-working) [/SIZE]
[SIZE=12pt]128[/SIZE]
[SIZE=12pt]72[/SIZE]
[SIZE=12pt]1, 2, 126, 244, 255[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt]129[/SIZE]
[SIZE=12pt]71[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt]1, 2, 126, 244[/SIZE]
[SIZE=12pt]130 [/SIZE]
[SIZE=12pt]70 [/SIZE]
[SIZE=12pt]1 [/SIZE]
[SIZE=12pt]56, 87, 148 [/SIZE]
[SIZE=12pt]131 [/SIZE]
[SIZE=12pt]69 [/SIZE]
[SIZE=12pt]2 [/SIZE]
[SIZE=12pt]1, 4, 126, 244 [/SIZE]
[SIZE=12pt]132 [/SIZE]
[SIZE=12pt]68 [/SIZE]
[SIZE=12pt]1, 2 [/SIZE]
[SIZE=12pt]126, 244 [/SIZE]
[SIZE=12pt]133[/SIZE]
[SIZE=12pt]67[/SIZE]
[SIZE=12pt]244[/SIZE]
[SIZE=12pt]1, 2, 126[/SIZE]
[SIZE=12pt]134[/SIZE]
[SIZE=12pt]66[/SIZE]
[SIZE=12pt]1, 244[/SIZE]
[SIZE=12pt]2, 56[/SIZE]
[SIZE=12pt]135[/SIZE]
[SIZE=12pt]65[/SIZE]
[SIZE=12pt]2, 244[/SIZE]
[SIZE=12pt]1, 56, 126[/SIZE]
[SIZE=12pt]136[/SIZE]
[SIZE=12pt]64[/SIZE]
[SIZE=12pt]1, 2, 244[/SIZE]
[SIZE=12pt]126[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
I’ve also generated some passwords for the ‘undefined’ item codes from 127-113 after finding that d_item user increased sequentially. This worked from item_code 127-120, and I was getting text in ‘map tile’ format blocks from these codes. I’ve included a photo of item_code 125 as an example.
https://i.imgur.com/U60xLb1.jpg
[SIZE=12pt]Item code [/SIZE]
[SIZE=12pt]d_item_user [/SIZE]
[SIZE=12pt]Tile[/SIZE]
[SIZE=12pt]127[/SIZE]
[SIZE=12pt]73[/SIZE]
[SIZE=12pt]TIE[/SIZE]
[SIZE=12pt]126[/SIZE]
[SIZE=12pt]74[/SIZE]
[SIZE=12pt]P[/SIZE]
[SIZE=12pt]125[/SIZE]
[SIZE=12pt]75[/SIZE]
[SIZE=12pt]SG CK[/SIZE]
[SIZE=12pt]124[/SIZE]
[SIZE=12pt]76[/SIZE]
[SIZE=12pt]TS[/SIZE]
[SIZE=12pt]123[/SIZE]
[SIZE=12pt]77[/SIZE]
[SIZE=12pt]W[/SIZE]
[SIZE=12pt]122[/SIZE]
[SIZE=12pt]78[/SIZE]
[SIZE=12pt]AR2 (The A was cut in half)[/SIZE]
[SIZE=12pt]121[/SIZE]
[SIZE=12pt]79[/SIZE]
·[SIZE=12pt]OY(First dot looked like part of a ‘T’)[/SIZE]
Also managed to snag another ticket code.
China (LUCKY): 20690 70397
[SIZE=12pt]d_item_user [/SIZE]
[SIZE=12pt]byte_04 (working) [/SIZE]
[SIZE=12pt]byte_04 (non-working) [/SIZE]
[SIZE=12pt]128[/SIZE]
[SIZE=12pt]72[/SIZE]
[SIZE=12pt]1, 2, 126, 244, 255[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt]129[/SIZE]
[SIZE=12pt]71[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt]1, 2, 126, 244[/SIZE]
[SIZE=12pt]130 [/SIZE]
[SIZE=12pt]70 [/SIZE]
[SIZE=12pt]1 [/SIZE]
[SIZE=12pt]56, 87, 148 [/SIZE]
[SIZE=12pt]131 [/SIZE]
[SIZE=12pt]69 [/SIZE]
[SIZE=12pt]2 [/SIZE]
[SIZE=12pt]1, 4, 126, 244 [/SIZE]
[SIZE=12pt]132 [/SIZE]
[SIZE=12pt]68 [/SIZE]
[SIZE=12pt]1, 2 [/SIZE]
[SIZE=12pt]126, 244 [/SIZE]
[SIZE=12pt]133[/SIZE]
[SIZE=12pt]67[/SIZE]
[SIZE=12pt]244[/SIZE]
[SIZE=12pt]1, 2, 126[/SIZE]
[SIZE=12pt]134[/SIZE]
[SIZE=12pt]66[/SIZE]
[SIZE=12pt]1, 244[/SIZE]
[SIZE=12pt]2, 56[/SIZE]
[SIZE=12pt]135[/SIZE]
[SIZE=12pt]65[/SIZE]
[SIZE=12pt]2, 244[/SIZE]
[SIZE=12pt]1, 56, 126[/SIZE]
[SIZE=12pt]136[/SIZE]
[SIZE=12pt]64[/SIZE]
[SIZE=12pt]1, 2, 244[/SIZE]
[SIZE=12pt]126[/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
[SIZE=12pt][/SIZE]
I’ve also generated some passwords for the ‘undefined’ item codes from 127-113 after finding that d_item user increased sequentially. This worked from item_code 127-120, and I was getting text in ‘map tile’ format blocks from these codes. I’ve included a photo of item_code 125 as an example.
https://i.imgur.com/U60xLb1.jpg
[SIZE=12pt]Item code [/SIZE]
[SIZE=12pt]d_item_user [/SIZE]
[SIZE=12pt]Tile[/SIZE]
[SIZE=12pt]127[/SIZE]
[SIZE=12pt]73[/SIZE]
[SIZE=12pt]TIE[/SIZE]
[SIZE=12pt]126[/SIZE]
[SIZE=12pt]74[/SIZE]
[SIZE=12pt]P[/SIZE]
[SIZE=12pt]125[/SIZE]
[SIZE=12pt]75[/SIZE]
[SIZE=12pt]SG CK[/SIZE]
[SIZE=12pt]124[/SIZE]
[SIZE=12pt]76[/SIZE]
[SIZE=12pt]TS[/SIZE]
[SIZE=12pt]123[/SIZE]
[SIZE=12pt]77[/SIZE]
[SIZE=12pt]W[/SIZE]
[SIZE=12pt]122[/SIZE]
[SIZE=12pt]78[/SIZE]
[SIZE=12pt]AR2 (The A was cut in half)[/SIZE]
[SIZE=12pt]121[/SIZE]
[SIZE=12pt]79[/SIZE]
·[SIZE=12pt]OY(First dot looked like part of a ‘T’)[/SIZE]
Also managed to snag another ticket code.
China (LUCKY): 20690 70397
hwd45
Well-known member
Oh wow. I had speculated that Passwords might be able to be used to obtain unused items or unoccupied item IDs, but my personal testing had led to finding no such working passwords. I'm honestly kind of surprised that these "items" do exist, after all!
Can any of them be bought or used?
hwd45
Well-known member
Ahh, so presumably you just receive them as you would with a souvenir and it presents the garbage data it's received as though it's a souvenir but there's no menu option for it or anything. Interesting!
hwd45
Well-known member
Since I've had some success with the V3 passwords, I figured I might as well take on a new task: V4 login passwords.
In some ways this would be easier than the V3 item passwords to decode - I can generate as many as I want, just like parent and grandparent passwords. However, this time I've got 14 hexadecimal digits to work with - instead of there being 10,000,000,000 different potential passwords, this time it's more like 72,057,594,037,927,936. It's taken some extensive work, but I've actually made some reasonable progress. I'm going to need to do more work to determine where all the data goes in the password - and also the role that usernames play - but I've got part of the general structure down.
V4 login passwords take the following form:
ABCDEFG
HIJKLMN
As per usual, we'll rearrange the top and bottom rows as follows:
HIJKLMN ABCDEFG
This isn't totally necessary since the digits are hexadecimal this time, so there's no significant structure changes when we convert to binary. However, it still might be useful to arrange the password this way.
In fact, I'll be representing this password as follows from now on - you'll see why soon:
H I JK L MNABCDEFG
H and I are interesting because they actually seem to be independent of the username. They're structure determining variables that determine the iteration of the password.
Essentially, for each set of input data and username, there's 32 different passwords which can be generated. Let's take two example passwords:
22F8055
30F025B
15CF326
E18396C
These represent the same data, so I'll call them equivalent passwords.
Rearranging:
3 0 F0 2 5B22F8055
E 1 83 9 6C15CF326
Let's XOR the two passwords and look at the result:
D 1 73 B 373737373
Isn't that suspicious? The numbers 3 and 7 appear over and over. Further observations lead us to the following conclusion:
- First, a "base" password is generated from the data. This password is 9 hexadecimal digits long but can be thought of as 10 digits if we add a leading zero. We'll call this the data, D.
- A random digit from 0 to F is chosen to determine the iteration. This is the leftmost digit of the password, which we'll call the structure variable. The third and forth digits from the left record the value of the iteration, with each value corresponding to the structure variable:
Struct Varb Iteration
0 46
1 75
2 24
3 13
4 02
5 31
6 6F
7 50
8 FE
9 88
A 99
B EA
C BB
D CC
E DD
F D8
- A random digit from 0 to 1 is then chosen - another structure variable. This is the second digit from the left. If it's 0, leave the rest of the password unchanged. Otherwise, XOR the iteration value (digits 3 and 4) by 6C.
- Next, each pair of digits (except the two leftmost digits) are XOR'd by what is left in digits 3 and 4 (the iteration value or the iteration value XOR 6C depending on the value of the second digit). Using the data "123456789" and structure constant 0 as an example:
If digit 2 is 0,
0 0 46 0 123456789 -> 0 0 46 4 7650321CF
If digit 2 is 1,
0 1 2A 0 123456789 -> 0 1 2A 2 B096F4DA3
We're not quite done yet. Next we XOR the password by a constant generated via the username - I'm not sure how this is calculated yet though. It seems to be similar to the way it was done with V3 passwords but potentially with more zeroes. For example, if the username has the binary expansion 1110100001011110000110110 (I explain how I calculate this in a previous post but it's essentially a concatenation with of the 5-bit representations of the IDs of each of the letters with the leftmost character of the username being rightmost in the concatenation and so on) then I take digits 2-7 to get 110100, I add two zeroes after the first four digits to get 11010000 and then I XOR this binary value with digits 3 and 4 of the password. A similar thing is done with each other pair of digits, except for the leftmost pair.
We also probably XOR the password by some other constant which I haven't determined yet (this should be easy to figure out once I'm more confident with the username impact).
This almost gives us the password. There's one digit left to handle - digit 5. So far I've been treating it as though it's any other digit, but in fact, it doesn't really behave quite as well as the rest (there's always something!). As far as I can tell, it's a sort of checksum, but I'm not sure at which point the checksum is performed or how. It probably XORs the digits together or something before applying the username and iteration variables, but I'm not 100% certain.
Now let's have a moment to think about the data contained in a password. Referring to the outputs of D-Best's old generator, we can use an example output to infer which information was used in the decoding process:
decodeResult=OK&characterCode=09&gender=MALE&job=03&cCharacter=NO&cGender=MALE&pCharacterCode=00&pHouse=NO&gCharacterCode=00&gHouse=NO&passport=YES&travel=0&donationRank=1&donationGift=0&version=0&oPasswordUp=614DF99&oPasswordDown=A18C96F&data=1080&passwordUp=34719&passwordDown=75576
Let's go over each of these:
characterCode
ID value of the character
gender
Either male or female
job
ID value of the career that your Tamagotchi has - includes pre-school, school and post-preschool pre-school stages, too
cCharacter
Either "Yes" or "No" - probably child character, as the presence of a baby alongside your character has been noticed to affect the login password
cGender
Baby's gender, probably
pCharacterCode
Parent character ID
pHouse
???
gCharacterCode
Grandparent character ID
gHouse
???
passport
Whether or not you have the passport souvenir (this is to stop it from appearing every time you log in)
travel
Whether a ticket has been used during that generation, and the ID value of the location
donationRank
How many King donation milestones have been passed
donationGift
How many of the King souvenirs have been obtained - presumably this is to stop the player passing stage 1 and 2 and only receiving one souvenir as a result
version
Probably whether it's V4 or V4.5
oPasswordUp
Upper half of the logout password
oPasswordDown
Lower half of the logout password
data
Item ID
passwordUp
Upper half of the item password generated from the input data
passwordDown
Lower half of the item password generated from the input data
Where do each of these appear in the data? Expanding the 9 digits out to a 36 digit decimal number:
TTTB????????????????B??KJJJJ?GCCCCCC
T - Travel information.
B - Child character and child's gender. Not sure which is which though.
J - Career variables. K is probably included under this too?
G - Character's gender
C - Character ID
Clearly, there's a lot more to figure out, still. I'm making progress, though! I think solving the username mystery will require passwords from two different usernames representing almost exactly the same data - the fact that I can't figure out what all those question marks are means that I can't really see where changes in the data correspond to usernames unless I obtain a bunch of passwords of like, freshly started V4s to ensure they have almost identical input data. As such I'm probably going to end up buying a new V4 for password experimentation
In some ways this would be easier than the V3 item passwords to decode - I can generate as many as I want, just like parent and grandparent passwords. However, this time I've got 14 hexadecimal digits to work with - instead of there being 10,000,000,000 different potential passwords, this time it's more like 72,057,594,037,927,936. It's taken some extensive work, but I've actually made some reasonable progress. I'm going to need to do more work to determine where all the data goes in the password - and also the role that usernames play - but I've got part of the general structure down.
V4 login passwords take the following form:
ABCDEFG
HIJKLMN
As per usual, we'll rearrange the top and bottom rows as follows:
HIJKLMN ABCDEFG
This isn't totally necessary since the digits are hexadecimal this time, so there's no significant structure changes when we convert to binary. However, it still might be useful to arrange the password this way.
In fact, I'll be representing this password as follows from now on - you'll see why soon:
H I JK L MNABCDEFG
H and I are interesting because they actually seem to be independent of the username. They're structure determining variables that determine the iteration of the password.
Essentially, for each set of input data and username, there's 32 different passwords which can be generated. Let's take two example passwords:
22F8055
30F025B
15CF326
E18396C
These represent the same data, so I'll call them equivalent passwords.
Rearranging:
3 0 F0 2 5B22F8055
E 1 83 9 6C15CF326
Let's XOR the two passwords and look at the result:
D 1 73 B 373737373
Isn't that suspicious? The numbers 3 and 7 appear over and over. Further observations lead us to the following conclusion:
- First, a "base" password is generated from the data. This password is 9 hexadecimal digits long but can be thought of as 10 digits if we add a leading zero. We'll call this the data, D.
- A random digit from 0 to F is chosen to determine the iteration. This is the leftmost digit of the password, which we'll call the structure variable. The third and forth digits from the left record the value of the iteration, with each value corresponding to the structure variable:
Struct Varb Iteration
0 46
1 75
2 24
3 13
4 02
5 31
6 6F
7 50
8 FE
9 88
A 99
B EA
C BB
D CC
E DD
F D8
- A random digit from 0 to 1 is then chosen - another structure variable. This is the second digit from the left. If it's 0, leave the rest of the password unchanged. Otherwise, XOR the iteration value (digits 3 and 4) by 6C.
- Next, each pair of digits (except the two leftmost digits) are XOR'd by what is left in digits 3 and 4 (the iteration value or the iteration value XOR 6C depending on the value of the second digit). Using the data "123456789" and structure constant 0 as an example:
If digit 2 is 0,
0 0 46 0 123456789 -> 0 0 46 4 7650321CF
If digit 2 is 1,
0 1 2A 0 123456789 -> 0 1 2A 2 B096F4DA3
We're not quite done yet. Next we XOR the password by a constant generated via the username - I'm not sure how this is calculated yet though. It seems to be similar to the way it was done with V3 passwords but potentially with more zeroes. For example, if the username has the binary expansion 1110100001011110000110110 (I explain how I calculate this in a previous post but it's essentially a concatenation with of the 5-bit representations of the IDs of each of the letters with the leftmost character of the username being rightmost in the concatenation and so on) then I take digits 2-7 to get 110100, I add two zeroes after the first four digits to get 11010000 and then I XOR this binary value with digits 3 and 4 of the password. A similar thing is done with each other pair of digits, except for the leftmost pair.
We also probably XOR the password by some other constant which I haven't determined yet (this should be easy to figure out once I'm more confident with the username impact).
This almost gives us the password. There's one digit left to handle - digit 5. So far I've been treating it as though it's any other digit, but in fact, it doesn't really behave quite as well as the rest (there's always something!). As far as I can tell, it's a sort of checksum, but I'm not sure at which point the checksum is performed or how. It probably XORs the digits together or something before applying the username and iteration variables, but I'm not 100% certain.
Now let's have a moment to think about the data contained in a password. Referring to the outputs of D-Best's old generator, we can use an example output to infer which information was used in the decoding process:
decodeResult=OK&characterCode=09&gender=MALE&job=03&cCharacter=NO&cGender=MALE&pCharacterCode=00&pHouse=NO&gCharacterCode=00&gHouse=NO&passport=YES&travel=0&donationRank=1&donationGift=0&version=0&oPasswordUp=614DF99&oPasswordDown=A18C96F&data=1080&passwordUp=34719&passwordDown=75576
Let's go over each of these:
characterCode
ID value of the character
gender
Either male or female
job
ID value of the career that your Tamagotchi has - includes pre-school, school and post-preschool pre-school stages, too
cCharacter
Either "Yes" or "No" - probably child character, as the presence of a baby alongside your character has been noticed to affect the login password
cGender
Baby's gender, probably
pCharacterCode
Parent character ID
pHouse
???
gCharacterCode
Grandparent character ID
gHouse
???
passport
Whether or not you have the passport souvenir (this is to stop it from appearing every time you log in)
travel
Whether a ticket has been used during that generation, and the ID value of the location
donationRank
How many King donation milestones have been passed
donationGift
How many of the King souvenirs have been obtained - presumably this is to stop the player passing stage 1 and 2 and only receiving one souvenir as a result
version
Probably whether it's V4 or V4.5
oPasswordUp
Upper half of the logout password
oPasswordDown
Lower half of the logout password
data
Item ID
passwordUp
Upper half of the item password generated from the input data
passwordDown
Lower half of the item password generated from the input data
Where do each of these appear in the data? Expanding the 9 digits out to a 36 digit decimal number:
TTTB????????????????B??KJJJJ?GCCCCCC
T - Travel information.
B - Child character and child's gender. Not sure which is which though.
J - Career variables. K is probably included under this too?
G - Character's gender
C - Character ID
Clearly, there's a lot more to figure out, still. I'm making progress, though! I think solving the username mystery will require passwords from two different usernames representing almost exactly the same data - the fact that I can't figure out what all those question marks are means that I can't really see where changes in the data correspond to usernames unless I obtain a bunch of passwords of like, freshly started V4s to ensure they have almost identical input data. As such I'm probably going to end up buying a new V4 for password experimentation
Last edited by a moderator:
hwd45
Well-known member
New update: I've begun dissecting V4 item passwords, too, and they seem to work in a similar (though slightly different) way to V3 item passwords. Whilst looking for some I found the output of D-Best's password generator that someone had used, and the password list output by Tamatown at the end of someone's play session. I noticed something interesting appearing in the middle byte of the password: all of them took on the same value for each set of passwords.
Let's quickly remind ourselves of the five-byte structure of a V3 password - we'll label the leftmost byte "B_5" and the rightmost "B_1", etc.
B_5 can either be 0 or 1 and represents additional encryption on the password - if it's 1, you XOR every other byte by 106
B_2 holds the item ID data
B_1 holds no data unless the item relates to the travel tickets, the King or to the parent or grandparent characters
All five bytes are XOR'd by a variable relating to the username on the device, and there's a constant which is XOR'd onto the whole thing to give the final result
B_4 and B_3 are somewhat enigmatic - it is known that one of them may be any value and serves to increase the number of password combinations, and the other is a sort of checksum. Up until this point I had assumed B_3 was the checksum, but the parent / grandparent passwords lacked a byte corresponding to increasing the number of password combinations 256-fold, so it became clearer that at least in that scenario the checksum byte was B_4. Maybe this carried over to other passwords too?
When the old V4 password generators produced passwords - or when Tamatown did it at the end of your play session - all the passwords are generated simultaneously and so they all use the same random input variables. Comparing the V4 passwords I had found to eachother, it was clear that the middle byte was once again the random byte, not B_4.
Perhaps this is the real reason some of the values of d_item_user don't work - because the formula assumes that B_4 can take any value when really it's B_3 that should be able to take any value. If the checksum was generated with XORing alone this probably wouldn't be an issue due to the surjective nature of the XOR function. However, if the checksum is generated in a more obscure manner, then it's possible that there are some checksum values which are never attained by any of the input (B_3) values.
What does this all mean? It means that B_4 is still a total mystery, but perhaps somewhat less so now than it was before.
---
So... V4 login passwords, let's talk about them again.
After searching for a little while online I managed to find a login and logout password pair. Both of the passwords use different iteration values, so I XOR'd out the iteration before XORing the two passwords together to see what had changed. To my surprise, only two things had:
- The iteration byte was XOR'd by 3.
- The rightmost byte was XOR'd by 128.
The bit which changes in the latter case was always observed to be 0 in the login passwords, so perhaps this is a "login / logout" variable. Unusually, even the checksum remained unchanged between the passwords despite the iteration value changing - assuming it's not a coincidence, then perhaps the logout is simply obtained by switching the iteration of the login password - and a few other bits of data - without recalculating the checksum.
And what about that 3? The logout code actually corresponded to logging out with 300p, so I suspect that variable just determines how many hundreds of Gotchi points you'll be receiving. Pretty simple, really!
If I get further confirmation that this all works as intended then I'll be making a V4 logout password generator very soon. Not only could it be used to generate free points, but future versions of fan-made Tamatowns could incorporate the generators to create a more authentic experience. Funnily enough, I didn't really need any info on the actual data structure of the login passwords to figure this out, only the iteration variables.
That hasn't stopped me from gaining a further understanding of the password structure, though. Since my last post I've managed to crack the username component as well as most of the data variables:
Recall that each character of the username can be represented by five bits. Suppose the nth character of the username has the bit structure "abcde". Define f to be the concatenation 00abcdebcde, and g to be the concatenation bcde. Then the username variable equals the concatenation g(5)f(4)f(3)f(2)f(1).
That might sound complicated, but I couldn't really find an easier way of explaining it, hahaha. Maybe an example would help illustrate? The characters in the username "ABCDE" have the following bit structures:
A = 00001
B = 00010
C = 00011
D = 00100
E = 00101
Then - in binary - the username variable is:
0000101010100001000100000001100110000010001000000010001
EEEEEEEEEEEDDDDDDDDDDDCCCCCCCCCCCBBBBBBBBBBBAAAAAAAAAAA
From E From D From C From B From A
XORing the password by the username variable, as well as the iteration variables, leaves only the data. So far I've observed the data to take the following structure:
(PPPP000A IIIIIIII) SSSSTTTB 100GGGGG 000PPPPP ?0VJJJJJ LGCCCCCC
P - Iteration type
(In brackets because this structure is removed once the iteration variables are XOR'd out - after removing all the iteration data these bits will end up being zero, but I kept them there to indicate where that information is stored) Basically just indirectly tells you what value the iteration value I takes.
A - Alternator
(In brackets for the same reasons as above) If it's zero, then the password is unchanged. If it's 1, XOR each of the other bytes by 108.
I - Iteration
(In brackets once again) The value by which each other byte (all but the leftmost byte) is XOR'd by to increase the number of passwords representing the same data.
S - Checksum
Unsure of how this is calculated, but it definitely depends on the rest of the data and the iteration type. I'm not sure if the checksum depends on the username (one way to check would be to generate passwords from a freshly started V4 for multiple usernames until you've obtained two with identical iterations - then, XOR out the username and see what's left)
T - Travel
Has a ticket been used? Which one?
B - Baby
Seems to change when the adult character has a baby. Not sure if it relates to the presence of the baby or its gender.
G - Grandparent character
ID of the grandparent.
P - Parent character
ID of the parent.
V - Version
0 for V4, 1 for V4.5.
J - Job
ID of the job the character has. Preschool, school and the stages between schools and between school and work are also included as their own ID values.
L - Login / logout
0 for login passwords, 1 for logout passwords.
G - Gender
0 for male, 1 for female
C - Character
Character ID.
? - No idea
?????? I've seen it take on the values 0 and 1 but haven't detected a correlation between those values and the input data.
I expect some of the 1s and 0s will end up representing other bits of data that I've not accounted for, like the King rank, the King gifts and the Passport souvenir.
It should also be noted that parent and grandparent IDs are stored slightly differently to character IDs on the V4 - since only adult characters can be parents or grandparents, most of the ID values would be unused. To resolve this issue, the IDs used by these characters are like what you'd get if you took the normal ID list, removed all non-adult characters and renumbered each character according to its placement. So for example, Mametchi normally has ID 9, but in this new system he has ID 1. This means the character is represented with only 5 bits of data instead of 6.
Okay, so V4 login / logout passwords are mostly done now, I guess. I should really try and decipher the various check digits that are left but I'm becoming increasingly curious about the system that was used by the Music Star... so any login password donations for the Music Star will be appreciated as always, as will any item passwords found to be working with those login codes (it turns out it's actually fairly easy to trial-and-error item passwords on the Music Star!)
All this password cracking is making me miss Tamatown more and I'm lamenting the fact that so little was done to archive all the swf files that the website hosted. As time goes on it seems less and less likely that somebody is going to come out of the blue and say "oh, it turns out I saved a bunch of the files on my pc back in the day", so perhaps a future project could be to reproduce the art and flash files used by the site in a manner faithful to the original content alongside (fingers crossed) a working password generator. Even if that doesn't happen, I want to preserve any information on generating passwords that I manage to figure out, so I'll continue posting updates here whenever I make breakthroughs, and I intend on producing some documentation which is hopefully a little more accessible than some of my posts have been. Who knows, maybe I'll produce an EnWarehouse-like application for the passwords too - only time will tell (it really depends on how complicated these check digits are!!)
Let's quickly remind ourselves of the five-byte structure of a V3 password - we'll label the leftmost byte "B_5" and the rightmost "B_1", etc.
B_5 can either be 0 or 1 and represents additional encryption on the password - if it's 1, you XOR every other byte by 106
B_2 holds the item ID data
B_1 holds no data unless the item relates to the travel tickets, the King or to the parent or grandparent characters
All five bytes are XOR'd by a variable relating to the username on the device, and there's a constant which is XOR'd onto the whole thing to give the final result
B_4 and B_3 are somewhat enigmatic - it is known that one of them may be any value and serves to increase the number of password combinations, and the other is a sort of checksum. Up until this point I had assumed B_3 was the checksum, but the parent / grandparent passwords lacked a byte corresponding to increasing the number of password combinations 256-fold, so it became clearer that at least in that scenario the checksum byte was B_4. Maybe this carried over to other passwords too?
When the old V4 password generators produced passwords - or when Tamatown did it at the end of your play session - all the passwords are generated simultaneously and so they all use the same random input variables. Comparing the V4 passwords I had found to eachother, it was clear that the middle byte was once again the random byte, not B_4.
Perhaps this is the real reason some of the values of d_item_user don't work - because the formula assumes that B_4 can take any value when really it's B_3 that should be able to take any value. If the checksum was generated with XORing alone this probably wouldn't be an issue due to the surjective nature of the XOR function. However, if the checksum is generated in a more obscure manner, then it's possible that there are some checksum values which are never attained by any of the input (B_3) values.
What does this all mean? It means that B_4 is still a total mystery, but perhaps somewhat less so now than it was before.
---
So... V4 login passwords, let's talk about them again.
After searching for a little while online I managed to find a login and logout password pair. Both of the passwords use different iteration values, so I XOR'd out the iteration before XORing the two passwords together to see what had changed. To my surprise, only two things had:
- The iteration byte was XOR'd by 3.
- The rightmost byte was XOR'd by 128.
The bit which changes in the latter case was always observed to be 0 in the login passwords, so perhaps this is a "login / logout" variable. Unusually, even the checksum remained unchanged between the passwords despite the iteration value changing - assuming it's not a coincidence, then perhaps the logout is simply obtained by switching the iteration of the login password - and a few other bits of data - without recalculating the checksum.
And what about that 3? The logout code actually corresponded to logging out with 300p, so I suspect that variable just determines how many hundreds of Gotchi points you'll be receiving. Pretty simple, really!
If I get further confirmation that this all works as intended then I'll be making a V4 logout password generator very soon. Not only could it be used to generate free points, but future versions of fan-made Tamatowns could incorporate the generators to create a more authentic experience. Funnily enough, I didn't really need any info on the actual data structure of the login passwords to figure this out, only the iteration variables.
That hasn't stopped me from gaining a further understanding of the password structure, though. Since my last post I've managed to crack the username component as well as most of the data variables:
Recall that each character of the username can be represented by five bits. Suppose the nth character of the username has the bit structure "abcde". Define f
to be the concatenation 00abcdebcde, and g to be the concatenation bcde. Then the username variable equals the concatenation g(5)f(4)f(3)f(2)f(1).That might sound complicated, but I couldn't really find an easier way of explaining it, hahaha. Maybe an example would help illustrate? The characters in the username "ABCDE" have the following bit structures:
A = 00001
B = 00010
C = 00011
D = 00100
E = 00101
Then - in binary - the username variable is:
0000101010100001000100000001100110000010001000000010001
EEEEEEEEEEEDDDDDDDDDDDCCCCCCCCCCCBBBBBBBBBBBAAAAAAAAAAA
From E From D From C From B From A
XORing the password by the username variable, as well as the iteration variables, leaves only the data. So far I've observed the data to take the following structure:
(PPPP000A IIIIIIII) SSSSTTTB 100GGGGG 000PPPPP ?0VJJJJJ LGCCCCCC
P - Iteration type
(In brackets because this structure is removed once the iteration variables are XOR'd out - after removing all the iteration data these bits will end up being zero, but I kept them there to indicate where that information is stored) Basically just indirectly tells you what value the iteration value I takes.
A - Alternator
(In brackets for the same reasons as above) If it's zero, then the password is unchanged. If it's 1, XOR each of the other bytes by 108.
I - Iteration
(In brackets once again) The value by which each other byte (all but the leftmost byte) is XOR'd by to increase the number of passwords representing the same data.
S - Checksum
Unsure of how this is calculated, but it definitely depends on the rest of the data and the iteration type. I'm not sure if the checksum depends on the username (one way to check would be to generate passwords from a freshly started V4 for multiple usernames until you've obtained two with identical iterations - then, XOR out the username and see what's left)
T - Travel
Has a ticket been used? Which one?
B - Baby
Seems to change when the adult character has a baby. Not sure if it relates to the presence of the baby or its gender.
G - Grandparent character
ID of the grandparent.
P - Parent character
ID of the parent.
V - Version
0 for V4, 1 for V4.5.
J - Job
ID of the job the character has. Preschool, school and the stages between schools and between school and work are also included as their own ID values.
L - Login / logout
0 for login passwords, 1 for logout passwords.
G - Gender
0 for male, 1 for female
C - Character
Character ID.
? - No idea
?????? I've seen it take on the values 0 and 1 but haven't detected a correlation between those values and the input data.
I expect some of the 1s and 0s will end up representing other bits of data that I've not accounted for, like the King rank, the King gifts and the Passport souvenir.
It should also be noted that parent and grandparent IDs are stored slightly differently to character IDs on the V4 - since only adult characters can be parents or grandparents, most of the ID values would be unused. To resolve this issue, the IDs used by these characters are like what you'd get if you took the normal ID list, removed all non-adult characters and renumbered each character according to its placement. So for example, Mametchi normally has ID 9, but in this new system he has ID 1. This means the character is represented with only 5 bits of data instead of 6.
Okay, so V4 login / logout passwords are mostly done now, I guess. I should really try and decipher the various check digits that are left but I'm becoming increasingly curious about the system that was used by the Music Star... so any login password donations for the Music Star will be appreciated as always, as will any item passwords found to be working with those login codes (it turns out it's actually fairly easy to trial-and-error item passwords on the Music Star!)
All this password cracking is making me miss Tamatown more and I'm lamenting the fact that so little was done to archive all the swf files that the website hosted. As time goes on it seems less and less likely that somebody is going to come out of the blue and say "oh, it turns out I saved a bunch of the files on my pc back in the day", so perhaps a future project could be to reproduce the art and flash files used by the site in a manner faithful to the original content alongside (fingers crossed) a working password generator. Even if that doesn't happen, I want to preserve any information on generating passwords that I manage to figure out, so I'll continue posting updates here whenever I make breakthroughs, and I intend on producing some documentation which is hopefully a little more accessible than some of my posts have been. Who knows, maybe I'll produce an EnWarehouse-like application for the passwords too - only time will tell (it really depends on how complicated these check digits are!!)
hwd45
Well-known member
Just to update, I haven't managed to make much password progress for a while. I think at this point generating more passwords and throwing things at the generator until something sticks will have to be the way forwards. Here's the current status of the password types I've been working on cracking:
Ver
Password Type
Status
3
Item
Checksum uncracked
3
Parent
Checksum uncracked
3
Grandparent
Checksum uncracked
3
Travel
Uncracked
3
King
Uncracked
4
Login
Some data uncracked (including checksum)
4
Logout
Partially cracked
4
Item
Uncracked
6
Login
Uncracked
6
Logout
Uncracked
6
Item
Uncracked
I think the passwords I'd like to focus on most are the Music Star login passwords and the V3 Travel passwords, so as always password donations would be greatly appreciated. The information I'm most likely to need in addition to these passwords are the current character, any parent / grandparent characters and the username (and, of course, which ticket was used). One of the roadblocks to figuring this all out is the addition of a pattern variable - something that causes multiple valid passwords to generate from the same input data. As such, multiple passwords representing the same (or similar) input data, if possible, will be most helpful.
Ver
Password Type
Status
3
Item
Checksum uncracked
3
Parent
Checksum uncracked
3
Grandparent
Checksum uncracked
3
Travel
Uncracked
3
King
Uncracked
4
Login
Some data uncracked (including checksum)
4
Logout
Partially cracked
4
Item
Uncracked
6
Login
Uncracked
6
Logout
Uncracked
6
Item
Uncracked
I think the passwords I'd like to focus on most are the Music Star login passwords and the V3 Travel passwords, so as always password donations would be greatly appreciated. The information I'm most likely to need in addition to these passwords are the current character, any parent / grandparent characters and the username (and, of course, which ticket was used). One of the roadblocks to figuring this all out is the addition of a pattern variable - something that causes multiple valid passwords to generate from the same input data. As such, multiple passwords representing the same (or similar) input data, if possible, will be most helpful.
hwd45
Well-known member
It's been less than a day since my last update - normally I'd just edit my last post but I feel like it might be worth bumping the thread for this update.
Unless I'm mistaken... I've figured out how the checksum works in the V3 passwords, thus cracking the algorithm.
There's still more to understand - with this I'm only capable of generating half the allowed password combinations (which is still obviously more than is necessary, so it's not really a big deal) due to that one variable which, when turned on, seems to make everything more difficult. I think, after this most recent revelation, it should be easier to figure out, though.
Recall that there's a five-byte structure to the passwords, which we'll represent as follows:
BYTE_5 | BYTE_4 | BYTE_3 | BYTE_2 | BYTE_1
For now we'll set BYTE_5 to zero to make things a bit easier. Recall also that a username constant is XOR'd onto this structure - for now we'll pretend we've already XOR'd out this username factor so the username is no longer affecting the password. Since BYTE_5 is zero, we get the following password structure, just by the nature of how these passwords work:
0 | BYTE_4 | BYTE_3 | BYTE_2 | 199
BYTE_2 = ITEM_ID XOR 70
BYTE_3 may be any integer from 0 to 255
BYTE_4 may be the checksum?
That random 70 was definitely raising my eyebrows and when adding together all of the bytes I noticed that the result I got most of the time was exactly 140 away from 256, a power of two. So I tried XORing out a couple 70s here and there:
0 | BYTE_4 | BYTE_3 | BYTE_2 | 199
XOR
0 | 70 | 70 | 70 | 70
=
0 | BYTE_4 XOR 70 | BYTE_3 XOR 70 | ITEM_ID | 129
This seems like it's in a format that would make more sense for the password decoder to read - the item ID can now just be read out instead of needing to apply a random 70 to it. It should also be noted that BYTE_3 XOR 70 is once again just another integer from 0 to 255 so we can consider this the random element (if you'd like a more technical definition, the XOR 70 operator is a bijective function on the set of integers from 0 to 255 to itself). We'll notate BYTE_3 XOR 70 as just "RAND" and BYTE_4 XOR 70 as "CHECK". Here's the breakthrough:
129 + ITEM_ID + RAND + CHECK = 0 mod 256
Hence,
CHECK = 127 - ITEM_ID - RAND mod 256
A slightly unusual checksum, but it makes a certain amount of sense. To verify the checksum, all the device would need to do is add the four bytes together and check that they equal zero (mod 256).
I have a generator spreadsheet ready for those who want to generate passwords using this now, but I'd prefer to get it into a more accessible state, so I'm writing up some javascript for this purpose instead. I'm also considering creating a sort of EnWarehouse-like program for this purpose too, once I figure out some of the other password systems as well.
I'll get the script out as soon as possible. Thanks to all those who have helped me on this journey!
---
EDIT: I've embedded the script into this page: https://hazzabobbo.wixsite.com/mamemamelabs/password-generator
The presentation is a bit sloppy for now but it's something I'm working on! There'll probably be some item IDs which don't work so any feedback is helpful.
Unless I'm mistaken... I've figured out how the checksum works in the V3 passwords, thus cracking the algorithm.
There's still more to understand - with this I'm only capable of generating half the allowed password combinations (which is still obviously more than is necessary, so it's not really a big deal) due to that one variable which, when turned on, seems to make everything more difficult. I think, after this most recent revelation, it should be easier to figure out, though.
Recall that there's a five-byte structure to the passwords, which we'll represent as follows:
BYTE_5 | BYTE_4 | BYTE_3 | BYTE_2 | BYTE_1
For now we'll set BYTE_5 to zero to make things a bit easier. Recall also that a username constant is XOR'd onto this structure - for now we'll pretend we've already XOR'd out this username factor so the username is no longer affecting the password. Since BYTE_5 is zero, we get the following password structure, just by the nature of how these passwords work:
0 | BYTE_4 | BYTE_3 | BYTE_2 | 199
BYTE_2 = ITEM_ID XOR 70
BYTE_3 may be any integer from 0 to 255
BYTE_4 may be the checksum?
That random 70 was definitely raising my eyebrows and when adding together all of the bytes I noticed that the result I got most of the time was exactly 140 away from 256, a power of two. So I tried XORing out a couple 70s here and there:
0 | BYTE_4 | BYTE_3 | BYTE_2 | 199
XOR
0 | 70 | 70 | 70 | 70
=
0 | BYTE_4 XOR 70 | BYTE_3 XOR 70 | ITEM_ID | 129
This seems like it's in a format that would make more sense for the password decoder to read - the item ID can now just be read out instead of needing to apply a random 70 to it. It should also be noted that BYTE_3 XOR 70 is once again just another integer from 0 to 255 so we can consider this the random element (if you'd like a more technical definition, the XOR 70 operator is a bijective function on the set of integers from 0 to 255 to itself). We'll notate BYTE_3 XOR 70 as just "RAND" and BYTE_4 XOR 70 as "CHECK". Here's the breakthrough:
129 + ITEM_ID + RAND + CHECK = 0 mod 256
Hence,
CHECK = 127 - ITEM_ID - RAND mod 256
A slightly unusual checksum, but it makes a certain amount of sense. To verify the checksum, all the device would need to do is add the four bytes together and check that they equal zero (mod 256).
I have a generator spreadsheet ready for those who want to generate passwords using this now, but I'd prefer to get it into a more accessible state, so I'm writing up some javascript for this purpose instead. I'm also considering creating a sort of EnWarehouse-like program for this purpose too, once I figure out some of the other password systems as well.
I'll get the script out as soon as possible. Thanks to all those who have helped me on this journey!
---
EDIT: I've embedded the script into this page: https://hazzabobbo.wixsite.com/mamemamelabs/password-generator
The presentation is a bit sloppy for now but it's something I'm working on! There'll probably be some item IDs which don't work so any feedback is helpful.
Last edited by a moderator:
