Recommended Posts

2 hours ago, hwd45 said:

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. 

  • Like 1

Share this post


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

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!

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

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

Edited by hwd45
  • Like 1

Share this post


Link to post
Share on other sites

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!!)

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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