Recommended Posts

Posted (edited)

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:

Quote

 

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.

Edited by hwd45
Fixing broken quote tag
  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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. :( 

Edited by kuchikid
  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


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

Thanks! I've actually encountered these before, but I'm sure they'll come in handy. I'm not quite sure how I'll use them just yet since I only have one password for each item and username instead of a collection of passwords, but we'll see!

  • Like 2

Share this post


Link to post
Share on other sites

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

V3 codes.xlsx

  • Like 2

Share this post


Link to post
Share on other sites
21 minutes ago, Eggiweg said:

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

V3 codes.xlsx 13.49 kB · 1 download

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
11 minutes ago, kuchikid said:

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.

Share this post


Link to post
Share on other sites
13 minutes ago, hwd45 said:

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!

Share this post


Link to post
Share on other sites
On 3/31/2019 at 6:29 PM, hwd45 said:

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.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, MasterPengo said:

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!

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.