V3 Password Experimentation

TamaTalk

Help Support TamaTalk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
666
Reaction score
549
Location
England, United Kingdom
In early 2013, Tamatown was permanently shut down, completely locking players out of the password-only features on the V3, V4, V4.5 and Music Star.

Upon logging into Tamatown, the V3 version of the site would request the user name you'd typed into your V3. Any passwords you received on the site would be generated using your username, so they only worked on Tamagotchis using the same password.

On the V4, logging into Tamatown requires a login password, too. This password gives Tamatown details of what character you're currently using, as well as your parent and grandparent characters, how much you've donated to the Tamagotchi King, and any travel tickets you might have used recently. A logout password is generated which gives players the points they gained while using Tamatown, and individual items obtained in Tamatown are obtained by typing in their passwords like on the V3.

Additionally, for both of these versions there existed passwords which only worked under specific conditions, like whether a plane ticket had been used that generation or what the parent characters were. It's not yet clear whether these passwords are generated by the same means as every other password but only work when the right conditions are set on the Tamagotchi, or if they are generated with a different algorithm using the login password or the password obtained on the device (e.g. like the passwords given after using a ticket or donating enough to the King).

The Music Star worked a little differently. In this version, item codes are entered before logging out, and they're only six digits long now. As such, it's much easier to scroll through all the different passwords until you find a working one. Unlike previous versions, all item codes depend on the login code now, as they're entered before logging out.

If you've been around a while you might remember previous password generators for these versions, and you might also be wondering why we can't just use those generators. Aside from the fact that all those generators were taken down over time, they didn't actually use the password algorithms directly - instead, after typing in the required login details it requests the password from the Tamatown servers (which, as it turned out, was surprisingly easy to do). All the generation was still done behind the scenes. When the Tamatown servers died, so did generators.

Not all password generators have been this unsuccessful, though. Binary's EnWarehouse uses an algorithm which consistently gives the correct passwords for the Entama - there's a thread about the initial discovery of password generation for the Entama here.

The Entama was a little different from the English releases in that it didn't use a user name to generate passwords. Passwords were instead only generated using the login password. After figuring out some of the patterns in these passwords, Binary was able to construct an algorithm to obtain any password you want. Here's how it goes:

This cheat does not work on V3 nor V4 Tamagotchis. This cheat is for the EnTama. EnTamas use 14-digit Login and Logout Codes for e-tamago, which is the Japanese Tamatown.
 
Step 1. Write down your e-tamago login password.
 
Step 2. Look at the 6th digit of the login password. This digit determines the location of the item codes, and the checksum digit. I've shown the item codes as "ABCD" and the checksum as "S". Don't change the digits marked "x".
 
Bxxxx0x
SAxxDxC
 
Bxxxx1x
SAxxDxC
 
xABxx2x
SCxxxxD
 
xABxx3x
SCxxxxD
 
xxxDS4x
CxxABxx
 
xxxDS5x
CxxABxx
 
xDCxx6x
xxxxSBA
 
xDCxx7x
xxxxSBA
 
xSDxC8x
xBxAxxx
 
xSDxC9x
xBxAxxx
 
Step 3. Choose the item you want.
 
Some Free Items
ABCD
4014 900 $G$
5108 Pre-school Grade Magazine by Shogakukan
5122 drum
5196 JAL airplane
5197 EcoPanda doll by KIRIN Beverage
5198 hamburger
6090 10 intelligence points
6091 10 fashion points
6092 10 kindness points
5201 CA4LA hat
5202 T block

5203 M block intelligence
5208 G block fashion
5209 C block kindness
 
Step 4. Replace the login password ABCD digits with the item code.
 
Step 5. Replace the checksum digit with 0 (zero).
 
Step 6. Add all 14 digits together.
 
Step 7. Replace the checksum with the last digit of the sum from step 6.
 
You now have a valid logout password. Enter it into your En-Tama to claim your item. Items are stored in different places on the En-Tama, depending on the item type.
This gives us a glimpse into how to generate passwords for the V3 - it's likely a similar algorithm was used. But what algorithm was used, how do we find it, and how to usernames come into play?
Some useful materials I encountered when researching this information was the original xml files that Tamatown used to store all the item and character IDs. I'm not sure if these xml files were the ones used in unfinished versions of Tamatown (the site was under construction for months after it first released) but the V3 xml doesn't seem to contain all the souvenirs. Furthermore, two of the souvenirs seem to have been accidentally marked with the same ID number, which I can only imagine causing problems for players. Nevertheless, the remaining gaps can be filled in.
These IDs might serve useful when figuring out password generation. The ID number has to appear somewhere in the generation algorithm so that the device can decode the password and decide which item is being requested.
To start analysing passwords I began with the V3 password list on Tamenagerie. Of course, these passwords are only valid for one specific username, but I had to start somewhere. Almost immediately I noticed one potential lead: the surf board password, 37139 06723. Digits 3, 4 and 5 form the number "139" which, perhaps coincidentally, is the decimal ID code for the surf board souvenir.

I noticed another thing strange about this password when followed by the panda bear and maracas souvenir passwords which immediately follow it:

37139 06723
56851 07059
76563 07395

Can you see the pattern?

These three numbers form an arithmetic progression. That is, the difference between the first two is the same as the difference between the last two. This is no coincidence, but I still don't fully understand how or why it happened.

It wasn't long before I realised that some numbers were appearing more often than others. For example, a lot of the passwords - for some reason - ended with a 7. I tallied up how many of each number appeared in each position of the passwords and found the following:

- The first digit had a roughly uniform distribution but 5 and 7 appeared more frequently than other digits, perhaps coincidentally
- The second digit was more likely to be 7 than any other number
- The third digit was most frequently 1 by a relatively wide margin
- The fourth digit had a roughly uniform distribution with 9 appearing the most
- The fifth digit was odd in all but two passwords with the remaining passwords having a 4 in the place of the fifth digit - of the odd digits, 1 appeared most frequently
- The sixth digit had 0 and 5 appearing the most
- The seventh digit was mostly uniform with 7 appearing the most
- The eighth digit was most frequently 1, 3 or 7 with the remaining digits appearing less frequently
- The ninth digit was mostly uniform with 8 and 9 appearing the most
- The tenth digit was most frequently 7 by a relatively wide margin

I don't think there's all that much I can do with this information, but it might gesture in the right direction. The fact that the fifth number was (almost) always odd was of particular interest - there's no way that's a coincidence. Passwords associated with other usernames were similar - for some usernames, the number in the fifth position was always odd. For others, it was always even.

It might be worth noting that the only passwords bucking this trend were passwords for the cellphone and bicycle souvenirs - these were given out by the parents / grandparents, which seem to have handled passwords differently (in particular, the passwords for those items only work under specific conditions). I haven't been able to examine the distribution of the other digits with other usernames just yet, but I'm not sure the results would be all that helpful.

One thing that hasn't been considered up until this point was that one item can be obtained with multiple different passwords. Finding patterns is a lot more difficult to pin down when there's also a random component involved which could influence how the password is decoded - some passwords might follow completely different patterns to others, so spotting a common pattern between them is impossible. To attempt to get around this, I'd need a list of all the passwords for a given item and username in order to see how different passwords can give out the same item.

Fortunately for me, I found this thread where Binary dedicated what I can only imagine to be at least an hour generating hundreds of passwords for the Passport souvenir under the username "TMGC!". As it turns out, this list alone provides some vital clues to understanding how passwords are generated. But before we can figure out the passwords, we need to go a couple layers deeper:

I arranged these passwords in numerical order and took the difference between consecutive passwords. According to Binary, they estimate that there's around 500 passwords per item, so it was very likely that there'd be entries missing from my list. Despite that, I immediately started to notice that many of the differences between consecutive passwords would appear multiple times - for example, there were a total of 11 times where the difference between consecutive passwords was found to be 23440258.

This actually complicates things a little. The patterns and generation techniques used on the Entama were to do with the individual digits in the password. Numerical patterns, on the other hand, indicate that the generation algorithm may actually rely on the numerical properties of the password as treated as a number, rather than treating all the numbers separately. This could mean the V3 uses a generation algorithm far too dissimilar to the Entama's algorithm for us to even hope one could be used to get an idea of how the other works. How could it be the case that patterns were starting to emerge in the differences between the passwords when we'd just figured out that the fifth digit can only ever be always odd or always even depending on the username?

And then it got weirder. Assorting these differences in numerical order once more and finding the differences between the differences, we find that these differences between differences are either 0, 48, 329, 589 or a sum of these four numbers modulo 2048. In other words, they're either a multiple of 2048, or, when divided by 2048, the remainder they give is 48, 329, 589, or some sum of these numbers (like 329+589). There's also one case of the difference being 145; I'm not really sure how this one happened. When it's a sum of some of these numbers I'm guessing there's gaps in the list of differences - for example if our list has A and B as consecutive differences with B-A=329+589, then maybe there's a C between A and B such that C-A=329 and B-C=589, or vice versa. There's a very clear pattern emerging here, but what it means and whether any information can be extracted from it is unclear.

Actually, whilst writing this I found that 48=329+3*589 mod 2048 and 145=10*329+19*589 mod 2048, so I guess that solves that mystery.

Upon closer inspection, I also noticed that there was a pattern emerging amongst these numbers - the order with which a 329 or a 589 would appear took the following pattern:

589, 329, 589, 589, 329, 589, 589, 329, 589, ...

Even when taking the differences which were sums of 329 and 589 into account, the number of times each of these numbers appear in each sum exactly corresponds to what we'd expect if the pattern above were to continue.

There's some patterns in the amount the multiple of 2048 increases too but I haven't been able to pin it down just yet.

This all has the effect that the difference between two passwords on this list takes the following form:

2048n + 329a +529(2a+d)

Where n is a "large" integer (usually well over ten thousand), a is a "small" integer and d is either -1, 0 or 1. In case you're wondering where the 2a+d came from, it's due to the fact that 529 appears twice for every time 329 appears in the sequence I noted above.

In fact, the values for n seem quite restricted too. If I've got a password and I wanted to use these numbers to take a guess at what the "next" password giving the same item is, I only really need to check the values of n that I've observed already in the passport list, since there's not that many of them at all relatively speaking, yet still enough to make the list seem comprehensive.

There's quite a few variables to consider when trying to understand the password system, especially when we take the variables used by the Entama into account:

- Is there an initially generated password, like the login password?
- How does the username come into play?
- Where do the item IDs appear?
- Where do randomly generated numbers appear?
- Is there a pattern controlling variable like on the Entama?
- Is there a checksum variable?
- What order does are all these variables applied?

I think understanding the order in which each of them appear might be the trickiest part. Maybe there's some specific algorithm that's applied to passwords to transform them into a password which contains the ID and a checksum and the pattern variable like the Entama passwords, but it could also be the case that some of the controlling variables appear earlier on in the decoding process, which would create some wildly different results. Even if we start noticing patterns in what we already have available to us, it's really only the tip of the iceberg.

You might be wondering what the point of making such a generator is. Souvenirs never really did anything, and making a generator wouldn't bring Tamatown back. Plus, without Tamatown, using passwords taken from a generator takes some of the challenge and reward out of the items. Despite that, I think it's still important to be able to preserve this feature of a Tamagotchi, particularly as it provides a view into content that can no longer be obtained. It's also a convenience for players looking to buy a specific item without having to wait until it appears in the shop.

Aside from the souvenirs, there's also a few food items which go unused because they're only available through the password system. Unlike the other food items, they're given directly to the player instead of acting as an opportunity to purchase the item.

There's also a chance that some of the items on the V3 or V4 are completely unused, can only be obtained using passwords, but were never made accessible through Tamatown. It's actually already known that sprites for some of the ticket items on the V3 are present on the V2 (they can be occasionally seen using obscure glitches, though it's not known if these items are obtainable or if they'd do anything when used) and the Music Star had a few unused ticket items too (which can be obtained by guessing the right item passwords). With a generator, we could see items we've never seen before.

On top of all this, I think it's just interesting to be able to learn more about how Tamagotchis work, and it's a good idea to take the opportunity to document these findings, even if nothing comes of it. Even if we don't get working passwords, we'll have an opportunity to learn something new.

The next step will probably be to more closely examine the Passport passwords once again. I'm considering trying to use the patterns to limit which passwords have the potential to be valid, and then once I've limited the number of potential passwords to a more palatable number I can try them out until I start to create a more comprehensive list of passwords. This'll help me pin down the patterns more easily. I hope.

Once the passwords for one item are understood we can move to looking at other items - we may want to investigate the following:

- If we've got two passwords giving the same item, is it guaranteed that there exist passwords for every other item between these two passwords? In other words, is the password distribution uniform with respect to the items they give?
- If, say, we shift a passport password by a value k to get a password for the second souvenir. If we do the same thing to another passport password, will we get another working password for the other souvenir?

It may well be the case that neither of these points are proven to be the case, but the more structure the passwords have, the easier they'll be to understand.

Ideally, more passwords would be helpful to figuring this all out. Though given how long it's been since Tamatown stopped working, I doubt there's all that many "complete" password lists, and certainly not that many lists of passwords which all give the same item. The impact of usernames will be interesting to see though, and at the very least, more passwords will mean we can take a closer look into how the number distribution in the password changes with the username (if that turns out to be at all useful or necessary).

For people more experienced with Tamagotchi hacking, perhaps it'll be time to dump the Tamagotchi's ROM. Doing so won't be particularly easy, and it won't be guaranteed to give us any results, but it might be the best bet we have at understanding how passwords work.

I know this post has already been pretty wordy, but if anything else comes of my research I'll be sure to continue to document it here.

 
Last edited by a moderator:
I don't really have the time to dedicate to helping you much, but I have a little bit of input.

I have a feeling you'd find more success looking at the bit/base-2 level instead of trying to figure out the corresponding base-10 arithmetic. If I recall correctly, the Connections were coded in some sort of assembly language, so it is very likely the programmers were considering bits -and not decimals- while they made the code generation algorithm.

It's also unlikely that the codes were hard-coded into the devices, considering the amount of memory that would require. It's probably just using an encryption/decryption algorithm of some sort.

Considering the codes work regardless of the device, we know that there is no device-dependent key, so somehow the username and login code combination contains enough information to encrypt/decrypt item codes. My guess would be that the user name is converted into some byte-stream and XORd with some other code somewhere during the encryption and decryption process to make the codes appear different when they're really not. Unfortunately, because the log-in code is also used somewhere, this makes figuring out HOW the username is used more complicated.

Because security really isn't much of a concern, it wouldn't surprise me if they had just done something as simple as the following:
1. Have some x-bit sequence for every item, C.
2. Generate a random x-bit login sequence, L.
3. Repeat the user name twice to make an x-bit sequence, U.
4. C xor L xor U = the output code, O.

Then getting back C would just be a matter of taking O xor L xor U.

I... really can't offer much more aside from saying that the fact that usernames are 5 characters long and logout sequences are 10 characters long probably isn't a coincidence. What confuses me is the fact that, if the logout code is ONE 32-bit unsigned integer, its maximum value should be 4,294,967,295, which isn't true. If it's being stored as two 16-bit unsigned shorts, the maximum value of each should be 65,535, which also isn't true. Maybe it's being stored as two 5 character strings, so each character can be XORd with a character from the username?

I don't know how they would then convert that into a [0, 9] number, mind you. If they were to truncate any of the bits, then the decryption to get the item code would turn out wrong. Perhaps the item codes were selected in such a way that removing these bits wouldn't influence the decryption.

At any rate, I would suggest you try repeating Binary's input-output experiment with a different username before you look into the math patterns too much. The patterns you saw are likely unique to the username "TMGC!" and are just a byproduct of that specific encryption. It's very likely that Binary's results cannot be generalized to other usernames before we determine how the username influences the encryption/decryption process.

Now I honestly wish I could see the code. :(  

 
Last edited by a moderator:
I hadn't actually thought about converting the codes to base-2, but given how often multiples of 2048 were appearing in my experimentation, it certainly seems like some of the generation is done on the base-2 level. Luckily for us, there's no login code on the V3, so we don't have to worry about that being a factor. Simply xoring the username and an item code aren't enough though, since it doesn't take into account how multiple passwords can arise from one item, so there must be some third factor which is applied to the password too, to add an extra degree of freedom.

The problem with repeating Binary's experiment - aside from the fact the V3 doesn't have any login codes - is that there aren't any means to generate logout codes. The reason I'm focusing on one username right now is because, should any of the patterns generalise to other usernames, if I were to gain an understanding of what patterns arise with the username "TMGC!" then potentially I would already have a starting point to work with when looking at other usernames. Unfortunately, no other usernames are as well documented as this hefty list of passwords, so regardless I'm pretty much stuck using this one username for now.

 
Don't think it'll be of much help, but I complied the codes into a spreadsheet for easy viewing.

View attachment 261
This is very helpful! Saves me having to type them into my spreadsheets ;)

i see you've encountered the same xml files I did - I'm not sure why there's so many gaps but I assume an unfinished version of the xml was what was archived. Interestingly enough if you compare the ID numbers with the V4's corresponding xml, you find that items that were carried over between versions have the same ID number. This actually gives a pretty solid way of matching up the remaining items with ID numbers and only leaves a few food items ambiguous. It also leaves a lot of gaps in the ID list that have the potential to contain unused content.

 
I honestly doubt this can be of much use without the login code, too. As I mentioned, if the login changes the logout code, it's certainly part of the encryption algorithm.

 
I honestly doubt this can be of much use without the login code, too. As I mentioned, if the login changes the logout code, it's certainly part of the encryption algorithm.
And as I mentioned, the V3 doesn't have a login code. All the passwords corresponding to a given item will work every time, except for the items corresponding to parents and grandparents, travel tickets and the Tamagotchi king.

 
And as I mentioned, the V3 doesn't have a login code. All the passwords corresponding to a given item will work every time, except for the items corresponding to parents and grandparents, travel tickets and the Tamagotchi king.
OH! I misread that. Sorry!

 
For people more experienced with Tamagotchi hacking, perhaps it'll be time to dump the Tamagotchi's ROM. Doing so won't be particularly easy, and it won't be guaranteed to give us any results, but it might be the best bet we have at understanding how passwords work.
You're doing a fantastic job, I've been hoping for something like this for a while. I just wanted to know, have you tried contacting the people who have experience with Tamagotchi ROM dumping? I recently tried to contact someone via email without success. The reason was because I've been planning on starting a spriting project on the V3 and for a number of reasons I was hoping to do it with a ROM instead of the physical device.

 
You're doing a fantastic job, I've been hoping for something like this for a while. I just wanted to know, have you tried contacting the people who have experience with Tamagotchi ROM dumping? I recently tried to contact someone via email without success. The reason was because I've been planning on starting a spriting project on the V3 and for a number of reasons I was hoping to do it with a ROM instead of the physical device.
I've spoken to Natashenka a few times in the past, but not since I started examining passwords. It's definitely something I'm considering for the future, though it'd be a project that requires a lot of preparation and the right equipment. Rewarding, though!

 
So after some fiddling around with passwords I've decided... it's time for another update.

After looking over the old password generators and the information that was sent to the servers using the .cgi file upon login, I noticed that the login password, which is seen on the device in the form:

ABCDEFG
HIJKLMN

Is formatted in the login information as:

HIJKLMNABCDEFG

I thought about this for a moment and noticed that, this entire time, I've been working with passwords assuming the top row to be the first five digits of a ten-digit number. What happens if I swap the two rows? In other words, what happens if I treat a password like "01234 56789" as the number "5678901234"?

I went back to my large list of Passport passwords for the username "TMGC!", reordered them as above, arranged the rearranged passwords into numerical order, found the differences between consecutive passwords and arranged these differences into a list in numerical order.

When I did this before - with the top row as the first five digits - I found 92 unique differences between passwords with some differences appearing multiple times. When I did this with the reversed passwords? There was only 37 unique differences. Not only that, but certain differences appeared significantly more frequently than others - I started with 218 passwords, generated 217 differences and of those 217 differences 100 were one of three specific differences. In essence, there's a hell of a lot more structure here than there was when we used passwords in the more intuitive way.

Not only that, but the awkward multiples of 329 and 589 that we had before entirely disappear here. Instead of being slightly awkward sums of slightly awkward numbers, this time all the differences are whole multiples of 65536 = 2^16. Awesome!

Okay, so there's one small catch. One of the differences wasn't a perfect multiple of 65536. In fact, it's not even close, being off by over 10,000. So what happened here? Was there a typo? Well, the thing is, if there was a typo, we'd expect to see the next difference be off by the same amount as the previous one, but it's not. It's alone in being totally, totally wrong. This will come up again later, as you'll see.

As a result, if we instead take each of the edited passwords modulo 65536, we find that the first half are 23345, and the second half (appearing after the one difference which wasn't equal to 0 mod 65536) are 12635. This is a level of structure that's never been seen in the V3 passwords before! This also explains why all the passwords have digits of the same parity in position 5 - after rearranging, this digit becomes the final digit of the number, and because the difference between any two passwords is an even number, either all passwords are odd or all passwords are even, and hence the same is true of the final digit.

I realised that looking into the values of these rearranged passwords modulo 65536 doesn't require having lots of passwords for the same item and username, so I went back to my database of passwords from other usernames and for other items and performed the same operations on those passwords.

Passwords corresponding to the same username and item pair showed the same thing again - after using the modulo 65536 operator, they would always come out with one of two numbers. As a few examples:

TMGC!, Passport - 12635, 23345
ICHI, Passport - 3268, 26286
TINK, Shoes - 11240, 16770

When I did the same thing to different items for the same username, the pattern wasn't immediately obvious, as every item had its own number (presumably, every item had its own pair of numbers as before, but I wasn't able to confirm this). So, I did what I always do - copied them, arranged them into numerical order and found their differences. I was surprised to find that, once again, the differences are almost always a power of two (2^8 this time), with some minor exceptions, resulting in two different values coming out as a result (I actually didn't need to arrange them into another list and perform the operator on them too - I could've just taken each of the modified passwords mod 2^16 and I would've got the same result). One value corresponded to lower password numbers, the other corresponding to higher numbers.

So basically, this is what we know up to this point:

  • All passwords for a given username, after rearranging the top and bottom rows, take on the values A and B upon applying the mod 256 operator. The values of A and B depend on the username, so different usernames may result in different values for these constants.
  • For each username and each item, there are a pair of numbers C_item and D_item such that C_item = A mod 256 and D_item = B mod 256 and, for any (rearranged) password for this item and username pair, either P = C_item mod 65536, or P = D_item mod 65536. There seems to be a point Q such that, for P < Q, P = C_item mod 65536; and for P > Q, P = D_item mod 65536 (perhaps after switching the definitions of C and D).
  • Each different item has a different pair of C_item and D_item.
  • By the looks of it, the information from C_item and D_item is used to not only determine what item to give the player, but also to check that the password is compatible with the username.

This is information that might allow us to predict passwords given passwords we already know, but generation is still a way off. Basically, this just proves there's a lot more structure than we thought there was! Now let's look at a few of the values of A and B for a few different usernames:

TMGC! - 49, 91
TINK - 155, 241
ICHI - 174, 196
MAUDE - 130, 232
GRACE - 42, 64
TAMA - 155, 241
WHALE - 180, 222
SANTA - 152, 242
RAPHA - 153, 243

Eagle-eyed readers may have noticed that TINK and TAMA have the same numbers. Perhaps that's related to the fact that the first and last characters are the same in both (the last character being a space)? There's also something going on with RAPHA and SANTA, perhaps it's the As? Or, if we look at only the first and last characters again, we might notice that R and S also only differ by one. More passwords and usernames are needed!

If you're wondering what happens to them at greater powers of 2, it becomes less interesting - some of the values we were looking at differed by exactly 256, so once we start looking at 512 instead, more values start to emerge. If we look at modulo 64 instead, the values from TMGC! also match those of TINK and TAMA - maybe that's a T-thing?

So yeah, basically... we're getting somewhere, but I still don't know if we're anywhere near to cracking anything. Only time will tell!

 
Previously I mentioned that I don't think we're close to cracking anything. Less than a day later... I've changed my mind :)

I'm still playing around with things, but I've noticed some really solid patterns beginning to emerge.

Let's establish some variables to begin with: we begin with a password consisting of two 5-decimal strings, (P_1, P_2). By concatenating P_2||P_1 we receive a 10-digit decimal number P.

Now convert P into a five-byte binary number, and we'll call these bytes B_1 through to B_5 with B_5 being the leftmost byte.

Let's use an example: 70545 42729 is a Passport password for the username "TMGC!". This makes up our (P_1, P_2). Next, we produce P by concatenating: P = 4272970545.

In binary, this decimal is represented as 11111110101100000101101100110001. We'll add a few leading zeros to make it 40 digits long: 0000000011111110101100000101101100110001. This gives us our five bytes:

B_5 = 00000000
B_4 = 11111110
B_3 = 10110000
B_2 = 01011011
B_1 = 00110001

As mentioned last time, applying the modulo 256 operator to the password gives us a pair of numbers which we called A and B. This is essentially equivalent to the value of B_1 - it only ever takes on two possible values for a given username. As it turns out, the value of one can be obtained from the other by applying the XOR 106 operator to it - this is true of all usernames!

Hence, we have a constant C_user which relates to the username, but I'm not sure in what way it relates just yet. But some things have been observed:

If B_5 = 0, B_1 = C_user
If B_5 = 1, B_1 = C_user XOR 106

I'm not sure what happens if B_5 is 2, but I'm willing to guess it just loops back round to being C_user again. If I had to guess, I'd say B_5 can only take on the values of 0 or 1 and it takes them on randomly. For user="TMGC!", C_user = 49.

So that's two bytes down, but it depends on a constant C_user which we're not currently sure how to calculate without obtaining passwords first. Now let's look at B_2:

B_2 = ID XOR B_1 XOR D_user

There's two new variables here. ID is the item ID variable - for example, Passport is 128. These IDs can be found in some of the archived Tamatown XML files. D_user is another variable that relates to the username in a way I've not quite figured out yet.

I'm not sure what B_3 or B_4 do just yet, or if they even matter! But given how so far this seems to really strongly depend on the byte structure I'm willing to guess they've got their own roles too.

In other words... I'm so close, I can almost taste it. I think at this point I just need lots of username and password data to calculate lots of values of C_user and D_user, so any information would be strongly appreciated!

One thing that should be said about all this is that it's all slightly wrong for passwords that depend on a parent or grandparent character or travel tickets. These ones seem to be character independent but it doesn't seem to change the algorithm enough to make it unusable; but without data about what character people were using when they used the travel ticket and so on there's not much I can do to crack them. There's plenty of hope for the rest of the items though!

Until next time!

 
Previously I mentioned that I don't think we're close to cracking anything. Less than a day later... I've changed my mind :)
Normally in a case like this, I would merge the two posts, but due to amount of information and the high quality of these posts, for readability's sake I'm leaving these ones separate!

I'm seriously impressed by how much has happened on this front, and on the TamaTown front, over the last couple of days. I guess that waiting for events like this is like waiting for a bus - you wait for ages and then a bunch of them come along at once. :lol:

Fantastic work - please keep it up. :D

 
One thing that should be said about all this is that it's all slightly wrong for passwords that depend on a parent or grandparent character or travel tickets. These ones seem to be character independent but it doesn't seem to change the algorithm enough to make it unusable; but without data about what character people were using when they used the travel ticket and so on there's not much I can do to crack them. There's plenty of hope for the rest of the items though!
Is it possible that a V3 in debug mode could help with this? I know there's the issue of the username/password system not working when the device is debugged, but I have a faint memory of getting around the issue by choosing a username when debug mode is off, then activating it once it got to the egg hatching.

 
Is it possible that a V3 in debug mode could help with this? I know there's the issue of the username/password system not working when the device is debugged, but I have a faint memory of getting around the issue by choosing a username when debug mode is off, then activating it once it got to the egg hatching.
As far as I know debug mode doesn't really provide any additional tools for checking the password system. You'd think this would be a pretty important thing to debug though!

Right now I've hit a bit of a wall in the research - I've figured out a few more bits of information that narrow down some of the constants a bit further but it's not really enough to use as of yet. A single working password for a given username is now enough to narrow down the number of password possibilities for each item to 128, which is obviously a lot better than the 10 billion we started with. I'm gonna try and experiment with my device to get a password for every item ID for my username and see if that helps me pin down the algorithm any further.

Naturally, though, since you have to retype the entire password if it's wrong and there's a few seconds of delay due to there being an "ERROR" screen, trying lots of passwords can be kind of time consuming. Part of me wonders if the debug mode also has the same way of handling errors or if the "no" sound would play similar to the Music Star's item passwords. I guess if anything would help debug the password system, it would be to make it nicer to use.

Thinking about it, there's two different firmware versions of the V3 in America, too. Since you rarely had to type in passwords from the device into Tamatown, I doubt the password system has any versioning aspect which alters the way it works... though I do wonder if perhaps the earlier version had a glitch in the decoding algorithm or something that they needed to fix.

---

Since I've made so much progress on these passwords I'd like to take a crack at other passwords too. V5 and the Japanese releases seem to be well-understood at this point, so there's a few other passwords I'd like to attempt to understand instead - V3 King passwords, V3 Travel passwords, V3 Parent and Grandparent passwords, V4 login and logout codes and all its other passwords and the Music Star item codes. I have a feeling most of these are going to be a lot more difficult to crack but they might be fun to attempt if I can't make any more progress on V3 passwords :D

 
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!

 
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?

 
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.

 
Last edited by a moderator:

Latest posts

Back
Top