• Content Count

  • Joined

  • Last visited

  • Days Won


hwd45 last won the day on October 13

hwd45 had the most liked content!

Community Reputation

291 Excellent

About hwd45

  • Rank

  • Birthday 12/11/1995

Profile Information

  • Gender
  • Location
    Abingdon, Oxfordshire, England, United Kingdom

My Tamagotchis

  • My Collection
    V1 x 3
    V3 x 2
    Music Star
    Eevee × Tamagotchi
    Tamagotchi On
  • Favorite Tamagotchi
    Version 3
  • Favorite Tamagotchi Character

Contact Methods

  • Website URL

Recent Profile Visitors

855 profile views
  1. It's been a while since I gave an update, and I don't really have all that much to add. It seems like there's not really that many versions left to document, so I'm pretty chuffed that we've managed to make it this far and discover this much. ROM versions are an interesting piece of history worth preserving! But... there has been something on my mind lately regarding some of the really unusual devices I've encountered in my time researching. Every unusual device I've encountered has revealed something new about Tamagotchi's history. Let's briefly talk about a couple of these unusual Tamagotchis. So a few months ago, a user in the Tamagotchi Collectors Discord received two wave 1 US V1s. We were expecting at least one of the devices to use ROM Version 4.0, but they instead used 4.1 and 4.2. As I recall, this was the first time a wave 1 shell had been observed to use 4.2. Closer analysis of the 4.1 revealed something else unusual - the hardware was akin to that of a European device instead of an American one. The sound effects, the jumpers on the board, the screen - none of it matched what would be expected of a US device. Later on it was noted that the paint job on the device was also slightly different to other US devices - the logo was the wrong size and placed slightly differently. This wasn't the first time we'd seen this though - if you've ever compared one of the Spanish language devices to the English ones, you might have noticed the exact same differences in the logo printing. We still don't fully know why the V1 in question features these differences, but the similarities to the Spanish devices are undeniable - they also use similar hardware to the European devices. It's possible that this V1 was an early South American device, before the implementation of the Spanish language version, but who knows. At the very least, it's an indication that each region had its own unique and interesting history of Tamagotchi releases. Speaking of which... A while back I mentioned that one particularly rare ROM version for the V4 had been found - A4.7 E. This has so far only been observed once, and its manufacture date was a particularly late 31st March 2008, over a year after the initial release of the V4. This is not the only unusually late date that has been observed. Some V1s released in Europe and Australia were manufactured in late 2004 to early 2005, resulting in a relatively rare ROM version, 2.4; some European V2 shells weren't released until early 2006; and we've also found a V3 with a manufacture date of 20th August 2007, an extremely late date for a V3. While I'm not sure that all of these devices have anything particular in common, it has been observed that the extremely late V3 and V4 were actually released in Greece and featured Greek packaging. I'm used to thinking of Europe as being one whole collective when it comes to Tamagotchi releases, but apparently some regions received new versions much later than other regions. Not only that, but evidently, there were some ROM versions which seemed to only make themselves public through these unusual releases. The V3 had a standard A3 3 ROM, but that hasn't deterred me from hoping that other Greek devices are found in the future (some of the super late ones might have been released in other countries too, I'm not sure - Greece is just a common denominator right now). Could there be a V1 VER 2.5? A V2 VER A.7? Perhaps a late V4.5 or V5? If I do manage to encounter another extremely late release, I'll make sure to find out. The fact that after all this time we're still encountering new things to learn about Tamagotchis is fascinating to me, and I think that's one of the biggest appeals of this sort of research - you never know what else you have to learn.
  2. 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!!)
  3. It should be noted that sometimes different versions have the same secret screens - for example there are two different versions of the P's which have the same secret screen. If two secret screens are different then they're definitely different versions, but if they're the same then they could be the same but they might still be different. Here's the secret screens I know of so far - some information missing though: iD - VER 43, 10-02-25 - Chamametchi, "My birthstone is Amethyst!" iDL - VER 50, 11-01-14 - Chamametchi, "My birthstone is Amethyst!" iDL English Version - VER 53, 12-04-30 - Chamametchi, "My birthstone is Amethyst!" iDL 15th Anniversary - VER 54, 11-09-05 - Lovelitchi, "My birthstone is Sapphire!" iDL Princess Spacy - VER 55, 11-12-22 - Spacytchi "My birthstone is Ruby!" P's - VER 56, 12-10-11 - Yumemitchi "My dream is to become an idol!" P's - VER 56, 12-11-03 - Yumemitchi "My dream is to become an idol!" P's - VER 56, 13-01-06 - Kiraritchi Melody M!x - VER 012, 16-05-03 - Kuchipatchi, "My Birthday is the 18th of May!" Fairytale Meets - VER 030, 18-10-19 - Mametchi Pastel Meets - VER 055, 19-03-10 - Watawatatchi Sanrio Meets - VER 056, 19-04-24 - Kuchipatchi Fantasy Meets - VER 047 - Prince Mametchi Fairytale On - VER 057, 19-05-05 - Kuchipatchi, Taurus Magical On - VER 058, 19-05-13 - Kuchipatchi, Taurus I think the star signs usually match up with the intended release dates of the device. Fantasy is a bit of an outlier in this respect (I think it's Sagittarius?), but funnily enough its version number is also lower than any of the other versions released in 2019. Maybe it really was intended to be released last year?
  4. Judging by the packaging you've got a wave 1 shell design. I've heard there were relatively frequent issues with the battery on early releases of the first wave (not sure if it's a hardware issue or a software issue), and its age might contribute to some of those issues, too. Hopefully the problems aren't consistent and now that your V1 seems to have survived a few days it continues to last longer
  5. 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
  6. 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!
  7. 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?
  8. 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.
  9. 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.
  10. 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!
  11. Interesting! Either I've forgotten to add a BIN2DEC somewhere in the generator or there's something I've totally not accounted for.
  12. 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.
  13. 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.
  14. Unfortunately due to the nature of the generators in that topic, they stopped working when the Tamatown servers went down in 2013, and there's no way to fix them. Until someone creates a working generator, it's impossible to generate new passwords for the V3 (give me a couple weeks and maybe that'll change ). I don't think that's really relevant to this topic, did you mean to post somewhere else?
  15. 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.