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 2

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

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!

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

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!

  • Like 2
  • Thanks 1

Share this post


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

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

  • Like 2

Share this post


Link to post
Share on other sites
On 9/8/2019 at 3:57 PM, hwd45 said:

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.

  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, MasterPengo said:

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

  • Like 1
  • Thanks 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.