V3 Password Experimentation

Help Support TamaTalk:

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
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:

Eggiweg

Well-known member
Joined
May 17, 2018
Messages
707
Reaction score
1,024
Location
Australia
How many values of d_user_item should I be cycling through?

I've tried d_user_item values up to 26 with the item codes 75 (plant) and 129 (Key 1) with the username LUCKY with no success.

 
Last edited by a moderator:

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
How many values of d_user_item should I be cycling through?

I've tried d_user_item values up to 26 with the item codes 75 (plant) and 129 (Key 1) with the username LUCKY with no success.
d_item_user can be anywhere from 0 to 255 unfortunately. It's a lot of trial and error at the moment, and I've still not been successful in finding any semblance of a pattern in these numbers.

 

Eggiweg

Well-known member
Joined
May 17, 2018
Messages
707
Reaction score
1,024
Location
Australia
I found that a d_item_value of 71 works with the username LUCKY and the item_code 129 (key1), however I tried setting Byte 4 to the values 1, 55 and 166, and the password didn't work on all three occasions.

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
I found that a d_item_value of 71 works with the username LUCKY and the item_code 129 (key1), however I tried setting Byte 4 to the values 1, 55 and 166, and the password didn't work on all three occasions.
Huh. And Byte_5 was 0 when you changed Byte_4? That's interesting because it potentially shows some addition a structure I wasn't aware of.

 

SilverRibbon

Member
Joined
Sep 9, 2019
Messages
6
Reaction score
14
Quick questions from someone who is both really bad at math and really impressed by your research so far--

If a Tamagotchi is technically such a simple and small device, why does the password generation have to be so complex? I understand that the developers didn't want people being able to cheat to get easy codes for everything and ruin the fun, but is it REALLY that difficult of an algorithm, or is it just really difficult to narrow it down to what they chose to do with it?

I'm having a ton of fun reading through these posts

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
Quick questions from someone who is both really bad at math and really impressed by your research so far--

If a Tamagotchi is technically such a simple and small device, why does the password generation have to be so complex? I understand that the developers didn't want people being able to cheat to get easy codes for everything and ruin the fun, but is it REALLY that difficult of an algorithm, or is it just really difficult to narrow it down to what they chose to do with it?

I'm having a ton of fun reading through these posts
Although it can be difficult for a human to get their head around, the operations used in decoding a password are actually really simple for a computer written in an assembly language (like the one Tamagotchis are written in) to perform. In some senses it's kind of the simplest way they could do it while still maintaining some level of username encryption!

 
Last edited by a moderator:

Eggiweg

Well-known member
Joined
May 17, 2018
Messages
707
Reaction score
1,024
Location
Australia
Found some more working codes

Also bought some airplane tickets which gave me the following codes

Australia code (Username:LUCKY): 67864 34388
Switzerland code (LUCKY): 12472 35059





Item code


d_item_user


byte_04 (working)


byte_04 (non-working)




130


70


1


56, 87, 148





131


69


2


1, 4, 126, 244




132


68


1, 2


126, 244




 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
Found some more working codes

Also bought some airplane tickets which gave me the following codes

Australia code (Username:LUCKY): 67864 34388
Switzerland code (LUCKY): 12472 35059





Item code


d_item_user


byte_04 (working)


byte_04 (non-working)




130


70


1


56, 87, 148





131


69


2


1, 4, 126, 244




132


68


1, 2


126, 244
I'm wondering if the reason some of the passwords aren't working is to do with the Y at the end of the username? This puts a 1 at the start of the username constant which I'm not sure how to deal with yet - it could be having adverse effects on the rest of the password.

The ticket passwords are helpful! I'm not yet sure what I'm going to do with them or if they'll help with getting the remaining items, but I'm definitely curious about them, so any passwords you have to donate would be helpful. That includes Parent / Grandparent passwords, which have been known to regularly change.

If these passwords use a similar structure to item passwords it's possible that generating a bunch of them will help crack that third byte! I'll be generating as many as I can with the V3 I'm currently running.

 
Last edited by a moderator:

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
It turns out that parent and grandparent passwords are calculated in a similar way to item passwords! Essentially, there's four components to a parent / grandparent password: U, the username; C, a constant; D, the data; and S, an optional constant.

Let's go over each one. I'm on mobile, so forgive the lack of lovely formatting ;)

The Username U is exactly what it says on the tin - as before, you take the five characters of the username, reverse them and convert each letter into binary via the following correspondence:

A - J: 00001 - 01010

! - ?: 01011 - 01100

K - Z: 01101 - 11100

Blank space: 11101

I actually only just discovered the ID of the blank space character - I'd assumed it was 0, but apparently not!

So, as an example, the username ABCDE becomes 0010100100000110001000001.

The Constant C is independent of the username and data. A similar constant is used in the item password encryption - using | pipes | to split up bytes (so that I can represent them in decimal instead of binary), the constants for parent passwords and grandparent passwords are as follows:

Parent: 0 | ??? | 70 | 62 | 6

Grandparent: 0 | ??? | 134 | 62 | 6

The Data Value D basically just contains all the information corresponding to the password in question.

Parent: 0 | ??? | PID | 0 | CID

Grandparent: 0 | ??? | GID | 0 | CID

Here, the CID is the ID of the character in use and the PID and GID are the IDs of the parent and grandparent characters respectively. Helpfully, the IDs can be found in some of the archived Tamatown .xml files, though the IDs also match up with the order the characters appear in the debug mode character list.

The Optional Constant S is an additional constant which can be applied to the password in order to generate a second password - that's why there's two different passwords that can be received from each parent. This also mimics item passwords:

S = 1 | ??? | 106 | 106 | 106

The password can be obtained by one of the following two calculations - this gives a ten digit number which is once again rearranged such that the first five digits are on the bottom row of the password:

P = U XOR C XOR D

P = U XOR C XOR D XOR S

You might notice that I've left question marks in the second byte for each of them. Once again, there's a single byte which just doesn't want to behave! In particular, the ??? in the (not-so-constant) constant S seems to fluctuate slightly - sometimes it's 107 (that is, 106 XOR 1) and other times it's 117 (106 XOR 31). There's probably other values it takes on too, but if you've been following along with my other posts you might be getting Déjà Vu. It's like there's another variable - say E - which is applied to the second byte along with the rest of S.

Hopefully this insight will help what's going on with the middle byte in the item passwords - perhaps it's the middle byte which takes on a random value and the second byte that is having the same fluctuating variables applied to it as we see in the parent passwords? Who knows.

Also, the presence of those repeated 106s and the general structure of these passwords make me wonder... perhaps the patterns will begin looking clearer if we XOR out the username and 106s before trying to make out patterns in the second and third bytes? That'll be something to try.

 

Eggiweg

Well-known member
Joined
May 17, 2018
Messages
707
Reaction score
1,024
Location
Australia
[SIZE=12pt]Item code [/SIZE]







[SIZE=12pt]d_item_user [/SIZE]







[SIZE=12pt]byte_04 (working) [/SIZE]







[SIZE=12pt]byte_04 (non-working) [/SIZE]









[SIZE=12pt]128[/SIZE]



[SIZE=12pt]72[/SIZE]



[SIZE=12pt]1, 2, 126, 244, 255[/SIZE]



[SIZE=12pt][/SIZE]





[SIZE=12pt]129[/SIZE]



[SIZE=12pt]71[/SIZE]



[SIZE=12pt][/SIZE]



[SIZE=12pt]1, 2, 126, 244[/SIZE]





[SIZE=12pt]130 [/SIZE]



[SIZE=12pt]70 [/SIZE]



[SIZE=12pt]1 [/SIZE]



[SIZE=12pt]56, 87, 148 [/SIZE]





[SIZE=12pt]131 [/SIZE]



[SIZE=12pt]69 [/SIZE]



[SIZE=12pt]2 [/SIZE]



[SIZE=12pt]1, 4, 126, 244 [/SIZE]





[SIZE=12pt]132 [/SIZE]



[SIZE=12pt]68 [/SIZE]



[SIZE=12pt]1, 2 [/SIZE]



[SIZE=12pt]126, 244 [/SIZE]





[SIZE=12pt]133[/SIZE]



[SIZE=12pt]67[/SIZE]



[SIZE=12pt]244[/SIZE]



[SIZE=12pt]1, 2, 126[/SIZE]





[SIZE=12pt]134[/SIZE]



[SIZE=12pt]66[/SIZE]



[SIZE=12pt]1, 244[/SIZE]



[SIZE=12pt]2, 56[/SIZE]





[SIZE=12pt]135[/SIZE]



[SIZE=12pt]65[/SIZE]



[SIZE=12pt]2, 244[/SIZE]



[SIZE=12pt]1, 56, 126[/SIZE]





[SIZE=12pt]136[/SIZE]



[SIZE=12pt]64[/SIZE]



[SIZE=12pt]1, 2, 244[/SIZE]



[SIZE=12pt]126[/SIZE]





[SIZE=12pt][/SIZE]



[SIZE=12pt][/SIZE]



[SIZE=12pt][/SIZE]



[SIZE=12pt][/SIZE]






I’ve also generated some passwords for the ‘undefined’ item codes from 127-113 after finding that d_item user increased sequentially.  This worked from item_code 127-120, and I was getting text in ‘map tile’ format blocks from these codes.  I’ve included a photo of item_code 125 as an example.

https://i.imgur.com/U60xLb1.jpg





[SIZE=12pt]Item code [/SIZE]







[SIZE=12pt]d_item_user [/SIZE]







[SIZE=12pt]Tile[/SIZE]









[SIZE=12pt]127[/SIZE]



[SIZE=12pt]73[/SIZE]



[SIZE=12pt]TIE[/SIZE]





[SIZE=12pt]126[/SIZE]



[SIZE=12pt]74[/SIZE]



[SIZE=12pt]P[/SIZE]





[SIZE=12pt]125[/SIZE]



[SIZE=12pt]75[/SIZE]



[SIZE=12pt]SG CK[/SIZE]





[SIZE=12pt]124[/SIZE]



[SIZE=12pt]76[/SIZE]



[SIZE=12pt]TS[/SIZE]





[SIZE=12pt]123[/SIZE]



[SIZE=12pt]77[/SIZE]



[SIZE=12pt]W[/SIZE]





[SIZE=12pt]122[/SIZE]



[SIZE=12pt]78[/SIZE]



[SIZE=12pt]AR2 (The A was cut in half)[/SIZE]





[SIZE=12pt]121[/SIZE]



[SIZE=12pt]79[/SIZE]



·[SIZE=12pt]OY(First dot looked like part of a ‘T’)[/SIZE]






Also managed to snag another ticket code.

China (LUCKY): 20690 70397

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
[SIZE=12pt]Item code [/SIZE]



[SIZE=12pt]d_item_user [/SIZE]



[SIZE=12pt]byte_04 (working) [/SIZE]



[SIZE=12pt]byte_04 (non-working) [/SIZE]





[SIZE=12pt]128[/SIZE]



[SIZE=12pt]72[/SIZE]



[SIZE=12pt]1, 2, 126, 244, 255[/SIZE]










[SIZE=12pt]129[/SIZE]



[SIZE=12pt]71[/SIZE]








[SIZE=12pt]1, 2, 126, 244[/SIZE]





[SIZE=12pt]130 [/SIZE]



[SIZE=12pt]70 [/SIZE]



[SIZE=12pt]1 [/SIZE]



[SIZE=12pt]56, 87, 148 [/SIZE]





[SIZE=12pt]131 [/SIZE]



[SIZE=12pt]69 [/SIZE]



[SIZE=12pt]2 [/SIZE]



[SIZE=12pt]1, 4, 126, 244 [/SIZE]





[SIZE=12pt]132 [/SIZE]



[SIZE=12pt]68 [/SIZE]



[SIZE=12pt]1, 2 [/SIZE]



[SIZE=12pt]126, 244 [/SIZE]





[SIZE=12pt]133[/SIZE]



[SIZE=12pt]67[/SIZE]



[SIZE=12pt]244[/SIZE]



[SIZE=12pt]1, 2, 126[/SIZE]





[SIZE=12pt]134[/SIZE]



[SIZE=12pt]66[/SIZE]



[SIZE=12pt]1, 244[/SIZE]



[SIZE=12pt]2, 56[/SIZE]





[SIZE=12pt]135[/SIZE]



[SIZE=12pt]65[/SIZE]



[SIZE=12pt]2, 244[/SIZE]



[SIZE=12pt]1, 56, 126[/SIZE]





[SIZE=12pt]136[/SIZE]



[SIZE=12pt]64[/SIZE]



[SIZE=12pt]1, 2, 244[/SIZE]



[SIZE=12pt]126[/SIZE]




























I’ve also generated some passwords for the ‘undefined’ item codes from 127-113 after finding that d_item user increased sequentially.  This worked from item_code 127-120, and I was getting text in ‘map tile’ format blocks from these codes.  I’ve included a photo of item_code 125 as an example.

https://i.imgur.com/U60xLb1.jpg





[SIZE=12pt]Item code [/SIZE]



[SIZE=12pt]d_item_user [/SIZE]



[SIZE=12pt]Tile[/SIZE]





[SIZE=12pt]127[/SIZE]



[SIZE=12pt]73[/SIZE]



[SIZE=12pt]TIE[/SIZE]





[SIZE=12pt]126[/SIZE]



[SIZE=12pt]74[/SIZE]



[SIZE=12pt]P[/SIZE]





[SIZE=12pt]125[/SIZE]



[SIZE=12pt]75[/SIZE]



[SIZE=12pt]SG CK[/SIZE]





[SIZE=12pt]124[/SIZE]



[SIZE=12pt]76[/SIZE]



[SIZE=12pt]TS[/SIZE]





[SIZE=12pt]123[/SIZE]



[SIZE=12pt]77[/SIZE]



[SIZE=12pt]W[/SIZE]





[SIZE=12pt]122[/SIZE]



[SIZE=12pt]78[/SIZE]



[SIZE=12pt]AR2 (The A was cut in half)[/SIZE]





[SIZE=12pt]121[/SIZE]



[SIZE=12pt]79[/SIZE]



·[SIZE=12pt]OY(First dot looked like part of a ‘T’)[/SIZE]






Also managed to snag another ticket code.

China (LUCKY): 20690 70397
Oh wow. I had speculated that Passwords might be able to be used to obtain unused items or unoccupied item IDs, but my personal testing had led to finding no such working passwords. I'm honestly kind of surprised that these "items" do exist, after all!

Can any of them be bought or used?

 

Eggiweg

Well-known member
Joined
May 17, 2018
Messages
707
Reaction score
1,024
Location
Australia
Oh wow. I had speculated that Passwords might be able to be used to obtain unused items or unoccupied item IDs, but my personal testing had led to finding no such working passwords. I'm honestly kind of surprised that these "items" do exist, after all!

Can any of them be bought or used?
They don't appear in your inventory or souvenir list and can't be bought. 

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
They don't appear in your inventory or souvenir list and can't be bought. 
Ahh, so presumably you just receive them as you would with a souvenir and it presents the garbage data it's received as though it's a souvenir but there's no menu option for it or anything. Interesting!

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
Since I've had some success with the V3 passwords, I figured I might as well take on a new task: V4 login passwords.

In some ways this would be easier than the V3 item passwords to decode - I can generate as many as I want, just like parent and grandparent passwords. However, this time I've got 14 hexadecimal digits to work with - instead of there being 10,000,000,000 different potential passwords, this time it's more like 72,057,594,037,927,936. It's taken some extensive work, but I've actually made some reasonable progress. I'm going to need to do more work to determine where all the data goes in the password - and also the role that usernames play - but I've got part of the general structure down.

V4 login passwords take the following form:

ABCDEFG
HIJKLMN


As per usual, we'll rearrange the top and bottom rows as follows:

HIJKLMN ABCDEFG


This isn't totally necessary since the digits are hexadecimal this time, so there's no significant structure changes when we convert to binary. However, it still might be useful to arrange the password this way.

In fact, I'll be representing this password as follows from now on - you'll see why soon:

H I JK L MNABCDEFG


H and I are interesting because they actually seem to be independent of the username. They're structure determining variables that determine the iteration of the password.

Essentially, for each set of input data and username, there's 32 different passwords which can be generated. Let's take two example passwords:

22F8055
30F025B

15CF326
E18396C


These represent the same data, so I'll call them equivalent passwords.

Rearranging:

3 0 F0 2 5B22F8055

E 1 83 9 6C15CF326


Let's XOR the two passwords and look at the result:

D 1 73 B 373737373


Isn't that suspicious? The numbers 3 and 7 appear over and over. Further observations lead us to the following conclusion:

- First, a "base" password is generated from the data. This password is 9 hexadecimal digits long but can be thought of as 10 digits if we add a leading zero. We'll call this the data, D.
- A random digit from 0 to F is chosen to determine the iteration. This is the leftmost digit of the password, which we'll call the structure variable. The third and forth digits from the left record the value of the iteration, with each value corresponding to the structure variable:

Struct Varb Iteration
0 46
1 75
2 24
3 13
4 02
5 31
6 6F
7 50
8 FE
9 88
A 99
B EA
C BB
D CC
E DD
F D8


- A random digit from 0 to 1 is then chosen - another structure variable. This is the second digit from the left. If it's 0, leave the rest of the password unchanged. Otherwise, XOR the iteration value (digits 3 and 4) by 6C.
- Next, each pair of digits (except the two leftmost digits) are XOR'd by what is left in digits 3 and 4 (the iteration value or the iteration value XOR 6C depending on the value of the second digit). Using the data "123456789" and structure constant 0 as an example:

If digit 2 is 0,
0 0 46 0 123456789 -> 0 0 46 4 7650321CF

If digit 2 is 1,
0 1 2A 0 123456789 -> 0 1 2A 2 B096F4DA3


We're not quite done yet. Next we XOR the password by a constant generated via the username - I'm not sure how this is calculated yet though. It seems to be similar to the way it was done with V3 passwords but potentially with more zeroes. For example, if the username has the binary expansion 1110100001011110000110110 (I explain how I calculate this in a previous post but it's essentially a concatenation with of the 5-bit representations of the IDs of each of the letters with the leftmost character of the username being rightmost in the concatenation and so on) then I take digits 2-7 to get 110100, I add two zeroes after the first four digits to get 11010000 and then I XOR this binary value with digits 3 and 4 of the password. A similar thing is done with each other pair of digits, except for the leftmost pair.

We also probably XOR the password by some other constant which I haven't determined yet (this should be easy to figure out once I'm more confident with the username impact).

This almost gives us the password. There's one digit left to handle - digit 5. So far I've been treating it as though it's any other digit, but in fact, it doesn't really behave quite as well as the rest (there's always something!). As far as I can tell, it's a sort of checksum, but I'm not sure at which point the checksum is performed or how. It probably XORs the digits together or something before applying the username and iteration variables, but I'm not 100% certain.

Now let's have a moment to think about the data contained in a password. Referring to the outputs of D-Best's old generator, we can use an example output to infer which information was used in the decoding process:

decodeResult=OK&characterCode=09&gender=MALE&job=03&cCharacter=NO&cGender=MALE&pCharacterCode=00&pHouse=NO&gCharacterCode=00&gHouse=NO&passport=YES&travel=0&donationRank=1&donationGift=0&version=0&oPasswordUp=614DF99&oPasswordDown=A18C96F&data=1080&passwordUp=34719&passwordDown=75576


Let's go over each of these:

characterCode
ID value of the character

gender
Either male or female

job
ID value of the career that your Tamagotchi has - includes pre-school, school and post-preschool pre-school stages, too

cCharacter
Either "Yes" or "No" - probably child character, as the presence of a baby alongside your character has been noticed to affect the login password

cGender
Baby's gender, probably

pCharacterCode
Parent character ID

pHouse
???

gCharacterCode
Grandparent character ID

gHouse
???

passport
Whether or not you have the passport souvenir (this is to stop it from appearing every time you log in)

travel
Whether a ticket has been used during that generation, and the ID value of the location

donationRank
How many King donation milestones have been passed

donationGift
How many of the King souvenirs have been obtained - presumably this is to stop the player passing stage 1 and 2 and only receiving one souvenir as a result

version
Probably whether it's V4 or V4.5

oPasswordUp
Upper half of the logout password

oPasswordDown
Lower half of the logout password

data
Item ID

passwordUp
Upper half of the item password generated from the input data

passwordDown
Lower half of the item password generated from the input data


Where do each of these appear in the data? Expanding the 9 digits out to a 36 digit decimal number:

TTTB????????????????B??KJJJJ?GCCCCCC

T - Travel information.
B - Child character and child's gender. Not sure which is which though.
J - Career variables. K is probably included under this too?
G - Character's gender
C - Character ID


Clearly, there's a lot more to figure out, still. I'm making progress, though! I think solving the username mystery will require passwords from two different usernames representing almost exactly the same data - the fact that I can't figure out what all those question marks are means that I can't really see where changes in the data correspond to usernames unless I obtain a bunch of passwords of like, freshly started V4s to ensure they have almost identical input data. As such I'm probably going to end up buying a new V4 for password experimentation  :p

 
Last edited by a moderator:

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
New update: I've begun dissecting V4 item passwords, too, and they seem to work in a similar (though slightly different) way to V3 item passwords. Whilst looking for some I found the output of D-Best's password generator that someone had used, and the password list output by Tamatown at the end of someone's play session. I noticed something interesting appearing in the middle byte of the password: all of them took on the same value for each set of passwords.

Let's quickly remind ourselves of the five-byte structure of a V3 password - we'll label the leftmost byte "B_5" and the rightmost "B_1", etc.

B_5 can either be 0 or 1 and represents additional encryption on the password - if it's 1, you XOR every other byte by 106
B_2 holds the item ID data
B_1 holds no data unless the item relates to the travel tickets, the King or to the parent or grandparent characters
All five bytes are XOR'd by a variable relating to the username on the device, and there's a constant which is XOR'd onto the whole thing to give the final result

B_4 and B_3 are somewhat enigmatic - it is known that one of them may be any value and serves to increase the number of password combinations, and the other is a sort of checksum. Up until this point I had assumed B_3 was the checksum, but the parent / grandparent passwords lacked a byte corresponding to increasing the number of password combinations 256-fold, so it became clearer that at least in that scenario the checksum byte was B_4. Maybe this carried over to other passwords too?

When the old V4 password generators produced passwords - or when Tamatown did it at the end of your play session - all the passwords are generated simultaneously and so they all use the same random input variables. Comparing the V4 passwords I had found to eachother, it was clear that the middle byte was once again the random byte, not B_4.

Perhaps this is the real reason some of the values of d_item_user don't work - because the formula assumes that B_4 can take any value when really it's B_3 that should be able to take any value. If the checksum was generated with XORing alone this probably wouldn't be an issue due to the surjective nature of the XOR function. However, if the checksum is generated in a more obscure manner, then it's possible that there are some checksum values which are never attained by any of the input (B_3) values.

What does this all mean? It means that B_4 is still a total mystery, but perhaps somewhat less so now than it was before.

---

So... V4 login passwords, let's talk about them again.

After searching for a little while online I managed to find a login and logout password pair. Both of the passwords use different iteration values, so I XOR'd out the iteration before XORing the two passwords together to see what had changed. To my surprise, only two things had:
- The iteration byte was XOR'd by 3.
- The rightmost byte was XOR'd by 128.
The bit which changes in the latter case was always observed to be 0 in the login passwords, so perhaps this is a "login / logout" variable. Unusually, even the checksum remained unchanged between the passwords despite the iteration value changing - assuming it's not a coincidence, then perhaps the logout is simply obtained by switching the iteration of the login password - and a few other bits of data - without recalculating the checksum.

And what about that 3? The logout code actually corresponded to logging out with 300p, so I suspect that variable just determines how many hundreds of Gotchi points you'll be receiving. Pretty simple, really!

If I get further confirmation that this all works as intended then I'll be making a V4 logout password generator very soon. Not only could it be used to generate free points, but future versions of fan-made Tamatowns could incorporate the generators to create a more authentic experience. Funnily enough, I didn't really need any info on the actual data structure of the login passwords to figure this out, only the iteration variables.

That hasn't stopped me from gaining a further understanding of the password structure, though. Since my last post I've managed to crack the username component as well as most of the data variables:

Recall that each character of the username can be represented by five bits. Suppose the nth character of the username has the bit structure "abcde". Define f(n) to be the concatenation 00abcdebcde, and g(n) to be the concatenation bcde. Then the username variable equals the concatenation g(5)f(4)f(3)f(2)f(1).

That might sound complicated, but I couldn't really find an easier way of explaining it, hahaha. Maybe an example would help illustrate? The characters in the username "ABCDE" have the following bit structures:

A = 00001
B = 00010
C = 00011
D = 00100
E = 00101


Then - in binary - the username variable is:

0000101010100001000100000001100110000010001000000010001
EEEEEEEEEEEDDDDDDDDDDDCCCCCCCCCCCBBBBBBBBBBBAAAAAAAAAAA
From E From D From C From B From A




XORing the password by the username variable, as well as the iteration variables, leaves only the data. So far I've observed the data to take the following structure:

(PPPP000A IIIIIIII) SSSSTTTB 100GGGGG 000PPPPP ?0VJJJJJ LGCCCCCC


P - Iteration type
(In brackets because this structure is removed once the iteration variables are XOR'd out - after removing all the iteration data these bits will end up being zero, but I kept them there to indicate where that information is stored) Basically just indirectly tells you what value the iteration value I takes.

A - Alternator
(In brackets for the same reasons as above) If it's zero, then the password is unchanged. If it's 1, XOR each of the other bytes by 108.

I - Iteration
(In brackets once again) The value by which each other byte (all but the leftmost byte) is XOR'd by to increase the number of passwords representing the same data.

S - Checksum
Unsure of how this is calculated, but it definitely depends on the rest of the data and the iteration type. I'm not sure if the checksum depends on the username (one way to check would be to generate passwords from a freshly started V4 for multiple usernames until you've obtained two with identical iterations - then, XOR out the username and see what's left)

T - Travel
Has a ticket been used? Which one?

B - Baby
Seems to change when the adult character has a baby. Not sure if it relates to the presence of the baby or its gender.

G - Grandparent character
ID of the grandparent.

P - Parent character
ID of the parent.

V - Version
0 for V4, 1 for V4.5.

J - Job
ID of the job the character has. Preschool, school and the stages between schools and between school and work are also included as their own ID values.

L - Login / logout
0 for login passwords, 1 for logout passwords.

G - Gender
0 for male, 1 for female

C - Character
Character ID.

? - No idea
?????? I've seen it take on the values 0 and 1 but haven't detected a correlation between those values and the input data.

I expect some of the 1s and 0s will end up representing other bits of data that I've not accounted for, like the King rank, the King gifts and the Passport souvenir.

It should also be noted that parent and grandparent IDs are stored slightly differently to character IDs on the V4 - since only adult characters can be parents or grandparents, most of the ID values would be unused. To resolve this issue, the IDs used by these characters are like what you'd get if you took the normal ID list, removed all non-adult characters and renumbered each character according to its placement. So for example, Mametchi normally has ID 9, but in this new system he has ID 1. This means the character is represented with only 5 bits of data instead of 6.

Okay, so V4 login / logout passwords are mostly done now, I guess. I should really try and decipher the various check digits that are left but I'm becoming increasingly curious about the system that was used by the Music Star... so any login password donations for the Music Star will be appreciated as always, as will any item passwords found to be working with those login codes (it turns out it's actually fairly easy to trial-and-error item passwords on the Music Star!)

All this password cracking is making me miss Tamatown more and I'm lamenting the fact that so little was done to archive all the swf files that the website hosted. As time goes on it seems less and less likely that somebody is going to come out of the blue and say "oh, it turns out I saved a bunch of the files on my pc back in the day", so perhaps a future project could be to reproduce the art and flash files used by the site in a manner faithful to the original content alongside (fingers crossed) a working password generator. Even if that doesn't happen, I want to preserve any information on generating passwords that I manage to figure out, so I'll continue posting updates here whenever I make breakthroughs, and I intend on producing some documentation which is hopefully a little more accessible than some of my posts have been. Who knows, maybe I'll produce an EnWarehouse-like application for the passwords too - only time will tell (it really depends on how complicated these check digits are!!)

 

hwd45

Well-known member
Joined
Aug 7, 2007
Messages
653
Reaction score
509
Location
Abingdon, Oxfordshire, England, United Kingdom
Just to update, I haven't managed to make much password progress for a while. I think at this point generating more passwords and throwing things at the generator until something sticks will have to be the way forwards. Here's the current status of the password types I've been working on cracking:










Ver


Password Type


Status




3


Item


Checksum uncracked




3


Parent


Checksum uncracked




3


Grandparent


Checksum uncracked




3


Travel


Uncracked




3


King


Uncracked




4


Login


Some data uncracked (including checksum)




4


Logout


Partially cracked




4


Item


Uncracked




6


Login


Uncracked




6


Logout


Uncracked




6


Item


Uncracked





I think the passwords I'd like to focus on most are the Music Star login passwords and the V3 Travel passwords, so as always password donations would be greatly appreciated. The information I'm most likely to need in addition to these passwords are the current character, any parent / grandparent characters and the username (and, of course, which ticket was used). One of the roadblocks to figuring this all out is the addition of a pattern variable - something that causes multiple valid passwords to generate from the same input data. As such, multiple passwords representing the same (or similar) input data, if possible, will be most helpful.

 
Top