Recommended Posts

I've made sufficient progress that I think it's time for an update - let's once more go over how the passwords are generated.

Passwords can be thought of as a five-byte number. Using zero as an example we have:

00000000 00000000 00000000 00000000 00000000

Each byte does something different. The rightmost two bytes seem to be the simplest to understand - they're essentially just random numbers that determine the rest of the password. The leftmost byte (which we will call B_5) may only be 0 or 1, while the other byte (B_4) can be any number from 0 to 255 (00000000 to 11111111 in binary).

The other three bytes are in part determined by the username. Let's consider an example username: "TMGC!". Each letter of this username can be represented by a five-bit integer corresponding to its place in the alphabet... except, it's not quite that easy.

If you've ever connected a Japanese device to an English one before, you'll know that they don't always handle eachothers' character sets perfectly. Here's a summary of the character set used by the Japanese devices:

Characters 0 - 80: Hiragana
Characters 81-90: Punctuation
Characters 91-92: ! and ?
Characters 93-105: Punctuation and symbols

I distinguished ! and ? here for a reason - they're also in the English character set. The English characters - as they appear on the device - cycle through each of the letters before cycling through the symbols. However, connecting an English device to a Japanese device hints that, internally, the ! and ? characters may be stored in the middle of the alphabet instead of at the end.

You see, the alphabet replaces the punctuation from the Japanese devices. All the hiragana characters remain in English devices, but from character 81 onward the letters begin replacing the symbols. Characters 81-90 get replaced with A through to J, but that's when something different happens. The ! and ? characters on the Japanese devices are actually the same as the ones on the English devices, so connections between devices with these characters in the name will result in them remaining when viewing the names in the friends list.

Then, characters 93-105 get replaced by K through to W. The Japanese devices have no characters for 106-108 so X, Y and Z in an English name will appear blank on a Japanese device.

What this all means is that the naive approach of assigning A to 1, B to 2 and so on is not necessarily the right approach. Instead, we should assign numbers to each of the letters as follows:

Blank character - 0
A - J: 1 - 10
!, ? - 11, 12
K - Z - 13 - 28

Converting each of these numbers into a 5-bit binary integer and concatenating them in a certain way gives us our username constant - returning to our example of TMGC!:

T = 22, 10110 in binary
M = 15, 01111
G = 7, 00111
C = 3, 00011
! = 11, 01011

We concatenate them in reverse order:

01011 00011 00111 01111 10110

Splitting this up into bytes:

0 10110001 10011101 11110110

As I understand, this constant is probably XOR'd with the password at some point in the encoding / decoding process. However, I'm not really very confident in what the leftmost 9 bits do, so we're going to ignore them for now (they probably still play a predictable role in the passwords though). With the two bytes we have left, let's XOR the first with 70 and the second with 199. This gives us:

11011011 00110001

In decimal, these are 219 and 49 respectively. You may recognise the 49 as being the C_user constant for TMGC! that I mentioned in an earlier post. XORing 219 and 49 gives the D_user constant I also mentioned before.

Next, we XOR the left byte by the ID of the item we're producing a password for, and after that we XOR both of these bytes by 106*B_5 - if B_5 is zero this has no effect on the password. The two bytes we have left after all this are the rightmost bytes of the password, B_2 and B_1.

So, using item ID 128 as an example and setting the left bytes to zero we've been able to produce the following password:

00000000 00000000 ???????? 01011011 00110001

(If you're wondering what happened to B_2, that's the result of XORing with the item ID 128).

The only bit left to figure out is the middle byte, but sadly this is where it all gets a bit unclear. Here's what is known about B_3:

  • When B_5 = 0, B_3 XOR B_4 is a variable which depends only on the username and item ID - changing either of these will change the value of B_3 XOR B_4, but equivalent passwords will always give the same result of B_3 XOR B_4.
  • When B_5 = 1, B_3 XOR B_4 fluctuates slightly and these fluctuations depend on B_4 and the item ID.
  • B_3 XOR B_4 will either be:
    • Always the same parity as the item ID
    • Always the opposite parity to the item ID

I haven't really figured out what's going on with Byte 3 yet but this information means that, at the very least, we can narrow down the number of potentially valid passwords from the 10,000,000,000 figure we had prior to finding any of this out to only 128 potential passwords. As it turns out, for the above username / item ID / B_5 trio, B_3 XOR B_4 = 78. Since B_4 is zero here, B_3 is 78:

00000000 00000000 01001110 01011011 00110001

After B_3 is generated, the entire string is converted into a decimal integer - in this case, it's 5135153. This is padded with zeroes to make a ten digit integer - 0005135153 - and then the first five digits and the last five digits are switched to give the following:

35153
00051

I've tested this password and can confirm that it works :)

So that's (most of) how the passwords work! Next I'm going to brute force a bunch of passwords to see how the B_3 XOR B_4 value changes. It nearly correlates with the item ID (XORing with the ID results in something which generally remains constant) but after a while it starts acting completely unpredictably, so more research is needed. Once this one variable is understood, the V3 password system will be entirely cracked (apart from travel, king and parent related passwords because there's not enough information to crack those).

I've produced a sort-of-working password generator for people to copy and use (I think you can copy this entire document to your own google drive but I'm not certain?) but it still requires finding the value of a mystery constant and it generally doesn't work when B_5 = 1. If you're willing to brute force up to 128 different passwords to get what you want, then this spreadsheet should help you do that. I can't guarantee that I haven't made a mistake in the formula somewhere though!

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

That is some amazing sleuthing you've done, and I'm sure generations of V3 fans will be grateful for this development!

Just some questions for interest:

  1. How did you figure out where the letters are stored by connecting japanese and english devices?
  2. You said that the alphabet replaced punctation starting at 81 (A), but why is A assigned to the number 1?
  3. Where do the values 70 and 199 come from?

Is there any way we can help by generating and testing passwords?

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Eggiweg said:

That is some amazing sleuthing you've done, and I'm sure generations of V3 fans will be grateful for this development!

Just some questions for interest:

  1. How did you figure out where the letters are stored by connecting japanese and english devices?
  2. You said that the alphabet replaced punctation starting at 81 (A), but why is A assigned to the number 1?
  3. Where do the values 70 and 199 come from?

Is there any way we can help by generating and testing passwords?

Hopefully these will answer your queries:

How did you figure out where the letters are stored by connecting japanese and english devices?
Maybe I didn't explain well enough in the previous post - basically, I worked under the assumption that the index that's used matches the order the characters appear on Japanese devices, and the English characters are placed in such a way to fit around that.

When you connect a Japanese device and an English device, sometimes the name in the friends list will appear incorrect on the other device. Hiragana are present on both devices and so they always show correctly, but most of the punctuation symbols are replaced with letters on the English devices. Connecting Japanese and English devices together and seeing how the names change reveal the correspondence between letters and symbols - ー is replaced by A, ~ is replaced by B, … is replaced by C and so on up to .being replaced by J. Then, on the Japanese devices, you have ! and ? which don't change during the connection process. Afterwards you have & which is replaced by K and so on.

You said that the alphabet replaced punctation starting at 81 (A), but why is A assigned to the number 1?
I'm not sure, but I assume it was convenience on the part of the programmer. Adding 80 to every value just results in a sort of redundant couple of bits, and it means that 7 bits have to be used to store each character instead of 5. Choosing the 5-bit option means they can get the most use out of the username - using all 7 bits could result in them being unable to use the same method to produce a username constant which actually uses all five of the characters in the username.

Where do the values 70 and 199 come from?
I'm not sure! They were basically what just popped out of my calculations, but they work for all usernames and items so I guess they were just chosen to add some additional "encryption". It also means that they could use the same password algorithm on later versions and all they'd need to do is change these two numbers to guarantee that passwords that work on the V3 won't work on, say, the V4 (I'm expecting to tackle this version's passwords next so this'll be the first thing I try).

Is there any way we can help by generating and testing passwords?
Yes! Though it will be somewhat time consuming, so if you'd like to give it a go I'd recommend doing something else at the same time so you don't get bored out of your mind. Let's recall what the two unknowns are - the item-user variable d and the fluctuation variable E:

Calculating d
One thing I'd like help with is calculating some values of d for different items and usernames. Here's the process:

  • Copy the generator spreadsheet
  • Set Byte 5 to zero
  • Set Byte 4 to zero
  • Choose a working ID number (there's an item ID list in the spreadsheet) and set the ID field to that number
  • Cycle through different vaules of d_item_user to generate different passwords, trying each one until one works
    • If none work then either an invalid ID has been chosen or the spreadsheet doesn't work as intended. Either way, it'd be good to inform me of the issue!
  • Eventually you should find a value of d that works. Note down the value of d somewhere along with the item ID and username and try a few different values of Byte 4 to check that it always works.
    • If it doesn't, inform me of this too!
  • Assuming that it always works, this value of d will either be of opposite parity to the item ID (i.e. one is odd and one is even) or the same parity (both odd or both even). All values of d will follow this rule for your username, so you can limit your search for other values of d for other item IDs in the same manner. For example, if my item ID is 128 and the value of d associated with it is 78, I know that for item ID 129 I only need to try values of d that are odd.

Calculating d
E is related to the values of the ID, the username and the value of Byte 4. Here's how to calculate it:

  • First, set Byte 4 to zero and Byte 5 to one. Try using the same item ID and the value of d that was calculated in the previous part and check that the output password works
    • If it does work, change Byte 4 to a few different values to check that it always works. If it does then note that down.
  • If it doesn't work, or if it only works for some values of Byte 4, then duplicate the generator sheet and in the copied version edit the "E" and "e" values on the right to 0, as well as Byte 4. This means deleting the formulae that are in those cells, even if they currently appear to equal zero!
  • Now change the value of d by adding or taking a way an odd number and trying the result until a password works.
    • You will usually only need to add or take away a number less than or equal to 15, so try these first.
  • What I had written here before is not a good idea. Instead, keep d the same as it was before - and definitely set e to zero - but edit E to be one of the following integers until a password works:
    • 1, 3, 7, 15, 31, 63, 127, 255
  • Jot down the working d E value, change Byte 4 to something else (increment it by 1, for example) and try to calculate a working value of d E again. Keep a record of all the working values of d E, the value of Byte 4 that they correspond to, the item ID and the username.

If this all sounds a bit much then no worries! It's what I'll be trying myself, but of course I can only try it on one username currently.

Edited by hwd45
Edited some mistakes in the last section
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I would love to help out when I get access to my V3 again. Thankyou for all the hard work you've done ^^

  • Like 2

Share this post


Link to post
Share on other sites

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.

Edited by Eggiweg
  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, Eggiweg said:

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.

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Eggiweg said:

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.

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.

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, hwd45 said:

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.

Yeah, byte_5 was left as 0.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Eggiweg said:

Yeah, byte_5 was left as 0.

Interesting! Either I've forgotten to add a BIN2DEC somewhere in the generator or there's something I've totally not accounted for.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, SilverRibbon said:

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

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!

Edited by hwd45
  • Like 2

Share this post


Link to post
Share on other sites

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
  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, Eggiweg said:

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

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.

Edited by hwd45
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

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.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Item code

d_item_user

byte_04 (working)

byte_04 (non-working)

128

72

1, 2, 126, 244, 255

 

129

71

 

1, 2, 126, 244

130

70

1

56, 87, 148


131

69

2

1, 4, 126, 244

132

68

1, 2

126, 244

133

67

244

1, 2, 126

134

66

1, 244

2, 56

135

65

2, 244

1, 56, 126

136

64

1, 2, 244

126

 

 

 

 

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

Item code

d_item_user

Tile

127

73

TIE

126

74

P

125

75

SG CK

124

76

TS

123

77

W

122

78

AR2 (The A was cut in half)

121

79

·OY(First dot looked like part of a ‘T’)

Also managed to snag another ticket code.

China (LUCKY): 20690 70397

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, Eggiweg said:

Item code

 

d_item_user

 

byte_04 (working)

 

byte_04 (non-working)

 

128

 

72

 

1, 2, 126, 244, 255

 

 

 

129

 

71

 

 

 

1, 2, 126, 244

 

130

 

70

 

1

 

56, 87, 148

 


131

 

69

 

2

 

1, 4, 126, 244

 

132

 

68

 

1, 2

 

126, 244

 

133

 

67

 

244

 

1, 2, 126

 

134

 

66

 

1, 244

 

2, 56

 

135

 

65

 

2, 244

 

1, 56, 126

 

136

 

64

 

1, 2, 244

 

126

 

 

 

 

 

 

 

 

 

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

Item code

 

d_item_user

 

Tile

 

127

 

73

 

TIE

 

126

 

74

 

P

 

125

 

75

 

SG CK

 

124

 

76

 

TS

 

123

 

77

 

W

 

122

 

78

 

AR2 (The A was cut in half)

 

121

 

79

 

·OY(First dot looked like part of a ‘T’)

 

Also managed to snag another ticket code.

 

China (LUCKY): 20690 70397

 

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?

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.