• Content Count

  • Joined

  • Last visited

  • Days Won


hwd45 last won the day on February 18

hwd45 had the most liked content!

Community Reputation

341 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

1,024 profile views
  1. So here's the interesting thing about the ball glitch: the items I get seem to be more or less the same every time I try it... and furthermore, doing things on the device seems to affect what items are currently present in the treats menu. For the purposes of this post I'll focus on the ball glitch's effects on the treats menu. The ball glitch can effect the items menu too but you can trigger the glitch without affecting this menu. Let's examine the contents of this menu upon first triggering the glitch. They're not always identical, but one of the most common configurations is as follows: 1-32: Ball 33-36: Random(?) items 37-83: Ball 84: Pencil 85: Usually ball, sometimes another item 86: Usually ball, sometimes another item 87: Ball 88: Glitch item "AIT" 89-90: Ball 91: Can be many different items 92: Usually hair gel, sometimes another item 93: Can be many different items 94: Usually ball, sometimes another item 95: Can be many different items 96: Usually ball, sometimes another item 97 onwards: Tools Whenever one of the items is eaten it turns into a ball. The fact that these specific items seem to appear so often suggests that this outcome isn't really "random", but rather, it's reading some information stored on the device and displaying that information as items. The first hint into what some of this data means is by looking at items 33-36. I quickly noticed that these items are always the same as what's in the shop at any given time - hence, eating one of them (and thus turning it into a ball) will cause a ball to appear in the shop! Which is why I kept noticing items in the shop changing into balls whilst eating some of the seemingly random items I'd encountered. What about if you buy something from the shop? What item appears in the treat list to take its place? Turns out it's a new glitch item, a bit different to what we've seen before: Unlike the glitch items we had encountered before, this one's sprite is not made from fragments of another item's name. Instead, the sprite is made from garbage data and the name consists partially of graphical data - namely the small-font numerals. Whilst on the topic of glitch items, let's briefly look at another glitch item I've encountered whilst the ball glitch was active. This one was encountered during a different instance of the glitch so I think the data that was present in the treats list was totally different, and thus I'm not sure what this item corresponds to. This one's eating animation once again shows us sprites that are normally only seen on the V1. Back to the ball glitch now - I had noticed that the items in the 85-96 range would change every now and then. In particular, I noticed they would change every time I connected to another device or pressed the reset button - pressing the reset button these would all turn back into being balls, so we can press the reset button to sort of "reset" the initial conditions in testing the results of connecting to different devices. It was by resetting these initial conditions that I realised that even unsuccessful connections would have an effect on these items, as though it takes in the IR data, stores it and checks over it to see if it's valid. 91-94 seem to behave very unusually and apparently depend on what device you're connecting to - perhaps it's related to the internal ID of the device, which is used to identify if two connections to characters with the name same name are really from the same device. Resetting the other device seemed to change what items appeared here as a result. The only real thing of note that I can tell from this is that it seems to be the case that #91 + #93 = #92 + #94, and these sums are usually 15 or 0. 95 and 96 are fun - they represent the number of friends in your friends list. For whatever reason, it seems the variables being presented here are 4-bit variables, so the items displayed are (with the exception of the AIT glitch?) all items with IDs 0-15. This means that, to display numbers larger than 15, a second item slot is used as overflow - 95 represents the lower part of the number and 96 the higher part. Setting one of these to zero by eating it makes part of the friends list disappear, but the actual friend data held on the device still remains. Hence, increasing your friend count again will reset what was stopping it before by recovering all your friends. Though weirdly this seems to be able to overwrite one of the friends in your friends list, as if the variable representing the number of friends is also used to determine which slot to write the information about the next friend into. By far the most interesting is 86 (and presumably this is a 4-bit variable so 87 may also be part of this variable). If you've read my ROM Versions thread, you may remember when I looked over a V1 patent document detailing many of the different variables handled by the device. One of these variables - specifically one sent during connection - is the "recognition code", a variant of the device's version number. From the small table offered in the document, it seemed like the recognition codes were in fact just the integer part of the device's ROM version. This does still leave the recognition codes of some of the English language devices unclear though, as these ROM versions are not simple numbers. For example, the V2 I was using for these experiments uses ROM version A.3 - how can we assign an integral value to this number if it's not a real number? The ball glitch may have the answer for us. Here are a few ROM versions and their respective effect on item 85 when connecting to the V2: Ver ROM Ver Connect Mode Item 85 1 0.0 - ID 0 (Ball) 1 2.1 - ID 2 (Wig) 1 4.1 - ID 4 (Tools) 2 A2 H Ver 1 ID 10 (Darts) 2 A2 H Ver 2 ID 10 (Darts) 4 A4.5 E Others ID 0 (Ball) 4 A4.5 E Jinsei ID 10 (Darts) I can't be certain this is the recognition code - perhaps it's another similar version variable - but it's still very intriguing. Not only are the IDs a perfect match for all three major versions of the V1, but later versions seem to change the item to ID 10 - looking at the version numbers of other devices reveals that there's a gap in version 10 where no known device goes. This version falls somewhere between the Keitai and the Akai implying a 2005 release date - exactly matching the V2. As such, I think it's possible that version 10 was deliberately avoided to reserve the spot for releases outside of Japan. I've not tested the V3 or the V4.5 but I assume they return similar results. I tried a V7 too but this seemed to have no effect on the items - presumably because the IR protocol had changed significantly by this point. Strangely the V4 seems to behave differently to the V2 when in "Others" mode - the V2 seems to continue transmitting the same version data whereas the V4 seems to attempt to mimic the Plus by setting the value to 0. Alright, I think that's about as much as I want to cover about the ball glitch for one post. One last interesting glitch: A user in the Tamagotchi Collectors Discord called Mr Incubator joined me in my experiments using a V4. One of the most interesting glitches involved a spontaneous change to the contents of the meal and snack menus. After the four permanent food items the following items were listed in the following order: # Item ID 5 Choco Bar 112 6 Waffle 111 7 Fried Chicken 110 8 Crepe 109 9 Candy 108 10 Lollipop 107 11 !! ? 12 Yogurt ? 13 Noodles 104 14 Turkey 103 15 Cake ? 16 Cookie 101 17 Chocolate 100 18 Grapes 99 19 Orange ? 20 Scone ? 21 Melon 96 22 Corn 95 23 Royal Costume ? 24 Pasta 93 25 Pineapple 92 26 Pear 91 27 Popcorn 90 28 Cereal ? 29+ Lots of balls - All the food items showed one of their partially eaten sprites for some reason. So there's a very clear pattern here - weirdly, a group of items appeared which appear to perfectly match the order the items appear in the item ID list, albeit backwards. Assuming the unknowns also fit the pattern, this allows us to fill in a whole bunch of ID list blanks! I'm hoping similar things can be done with the V2. Until next time!
  2. What makes you say the characters are Bill variants? They're humans, sure, but they're not really related to Bill in any way. Bandai Japan seems to have always been reasonably fond of Tamagotchi crossovers - even during the 90s there were a number of crossover devices (the Mothra, Genjintch and TamaOtch immediately come to mind). Nowadays those crossovers still exist but tend to make a bit more "sense" like the multiple Sanrio crossovers or the Eevee Tamagotchi though there's definitely some unusual and unexpected crossovers like the Pac-Man Nano and a certain leaked Tamagotchi supposedly planned for release this year. But back in the connection era the crossovers seem to have been that extra bit unusual - I'm sure that as westerners there's a level of cultural context that we're missing, perhaps Haneru No Tobira and Oden-Kun and GLAY were really popular in Japan at the time - but all the crossovers they did are utterly bizarre, looking back. As such I don't think the Hanerutchi is particularly exclusive in being a bit of a weird concept, I think that was just how Bandai operated back then - I don't think there was any specific "reason" the Hanerutchi was a thing aside from it being a profitable endeavour. Historical and cultural context are probably the main things getting in the way of our understanding of why they ever thought the Hanerutchi or even the GLAY Plus were ever considered.
  3. Following on from the previous post, sending the items to another device just seemed to convert them into generic gift items like cakes. Not that exciting. In other news, I've been finding that the Ball Glitch seems to be one of the bizarrest glitches attainable, with some of the most wide-reaching effects. The most recent round of Ball Glitch effects I've experienced have revealed some things I hadn't even considered about glitch items. Remember how glitch items have strange effects when used in the items menu? And remember how the Ball Glitch can make food items appear in the items menu and items appear in the food menu? Well, as it turns out, if your character is an adult you can use the food items that end up in your items menu and they act in similar ways to glitch items. CRACKER - The Tamagotchi instantly crashed and the screen turned off TEA - Like AB, the screen continues showing the item as if that screen is the item animation CREAMY CAKE - A LOT like TEA and AB, but it momentarily hangs and then registers two button presses instead of one, causing it to instantly go onto the clock screen. While it's transferring to the clock screen you can see the "CREAMY CAKE" item screen but for some reason the character sprite is underneath the text too creating a bit of a mess. I'd create an image if I could but it was difficult to get a photo of because of how quickly it happened. I suppose the inverse of food behaving like glitch items is glitch items behaving as food. As it turns out, by some bizarre coincidence (perhaps it wasn't a coincidence and there's some item data even when you think it's all gone?) the Ball Glitch placed one of our glitch item friends in my treats menu. Specifically, "AIT", which as an item caused the device to crash. What happens when you eat it? A LOT HAPPENS, APPARENTLY - It's almost like getting a glimpse into a sprite sheet that the Tamagotchi draws its images from. Except, those sprites in the last frame... they don't look familiar to me. This'll need more investigation. One more interesting thing I found using this glitch? If your items list is more than 100 long, things get a bit weird. Like many fairly primitive programs, there's no "100s" place in the number - instead, the 10s place just keeps changing to symbols beyond 9. These were the first few characters I noticed in the 10s column after 9: A blank space, as if the number of the item was less than 10, A zero, something you definitely wouldn't normally see in this column, 1, 2, E, h, 5, 9, L, 8, 6, Another blank space. Notice a pattern in the symbols above? The 6 and the 9 might give it away - the E, h and L aren't actually letters, they're just the digits 3, 4 and 7 rotated by 180 degrees. For some reason that's the case of all the digits in this run of characters. As always I'll continue to give more updates as more unusual things happen. I feel like, since I'm starting to get items I wouldn't normally be able to, that I'm getting closer to one of those unused items I've been looking for.
  4. A small update - my V2 just evolved into an adult (after some very heavy abuse of the pause button, apparently) and I became able to use the glitch items. What did I find? To my surprise, the two items I was able to test had entirely different effects. Neither of the effects were very interesting in their own right, but the fact that each glitch item seems to behave differently is itself somewhat fascinating. I guess logging the effects of all the glitch items will have to be part of this project. The item with the "AB" sprite behaved as though it was playing an item animation, but nothing particularly interesting happened on screen - it just looked like it had stayed on the item screen but any button press would change it back to normal. "AIT" was slightly less usable - selecting the item caused the device to immediately freeze, without even making the "select" sound. Once again the screen hung on the image of the item. When I get home from work I'll try and see if sending the items to another device does anything interesting. I'm getting the impression that these items aren't particularly stable (who'd'a thunk it?) so my fingers are crossed for some wacky outcomes.
  5. A few months back, in my password experimentation topic, user Eggiweg noted that whilst using an unfinished version of my password generator they'd managed to obtain "glitch souvenirs" - item IDs 114 - 127 would give the player a "souvenir" of sorts that looked like a small section of text taken from somewhere else. The souvenir is only briefly seen and doesn't appear in the souvenirs list, but is an interesting example of "glitch items" on the V3 nonetheless: ID SOUVENIR ID ITEM 114 Untested 0 BALL 115 CIL 1 PENCIL 116 Untested 2 WIG 117 Untested 3 SUNGLASSES 118 Untested 4 RC CAR 119 N 5 (Unknown) 120 HTS I 6 WEIGHTS 121 OY 7 RC TOY 122 AR2 8 (Unknown) 123 W 9 BOW 124 TS 10 DARTS 125 G CK 11 BLDG BLOCK 126 P 12 CAP 127 TIE 13 BOW TIE The items listed above are all the glitch souvenirs I've recorded so far. I don't currently have a V3 running so I've basically just had to go off what others using the password generator have found. In the left two columns you'll the the item ID of the souvenir in question and how that souvenir appears to look on-screen. On the right I've listed the first 14 items by their ID number. Clearly, there's a correspondence here like some of the items we saw on the V2. From this, we can conclude that RC CAR2 is probably item ID 8 and item ID 5 is probably PEN. You can see the items I've obtained images of so far below: I've left 15 slots here instead of 14 because I've actually not seen item ID 113 tested yet and I'm not sure if it'll be rejected as an unused item ID or if it'll contain yet another glitch souvenir. Ideally I'd like to fill in all the empty slots as part of an effort to document all the absurd glitch-items Tamagotchis have to offer, so any experimentation with and photographs of the glitch souvenirs using the password generator would be helpful
  6. Nobody really knows what was planned for the WTE but by the sounds of it it was going to be like a 6.5. All we ever heard about it was a press release confirming its existence, but later on in the year emails to Bandai customer support confirmed they never made production. It's a shame, I really enjoyed the Music Star and would've loved to have seen more Music Star versions. Actually speaking of battery glitches and the Music Star, I do remember one time my Music Star absolutely flipped out when I changed the batteries. Amongst a series of other unusual effects, one of the most bizarre things that happened was that one of the trophies in my trophies list was replaced by the "happy birthday" sprite until I obtained that trophy again.
  7. I've gone over a few pieces of unused content on my ROM Versions thread, it's actually a fairly common feature of Tamagotchis! And a really fascinating feature, too. Strangely enough the Music Star also has a bunch of unused ticket items like the V2, though these tickets can be obtained using passwords (if you get lucky and happen to type in a working one!). They don't really do that much sadly, but I figure they were planned to have a use on the cancelled World Tour Edition.
  8. I doubt I'll experiment with the Friends. The battery type is entirely different so it doesn't really lend itself to the same effects that the CR batteries do - I'd think it'd be much harder to fiddle with the batteries in the same way you can on earlier models. The Friends ROM has been dumped anyway so I doubt there'd be much in the way of new content to find using these glitches. I'll instead be focusing on the V2 and maybe a little bit on the V1, too, if I can get it to do anything fun. The V1 had a bunch of cut features which, if they still exist in any form on the device, would make for some seriously interesting findings.
  9. It seems to be, yeah! It's definitely not the first time I've encountered battery-related glitches either, as I'm sure my devices have acted unusually after switching batteries before (I remember my Music Star actually dying as a result of one of these glitches - I swear, I didn't kill it!) One thing I forgot to mention in the post was that Tamagotchis actually accept several different battery sizes (CR2016 and CR2025 on top of the intended CR2032 - the only difference is the battery width), and so I've even been experimenting with different battery sizes in case they're slightly easier to "tilt", as it were. In the past I've encountered some very unusual behaviour from devices using the incorrect battery sizes, so initially I thought that was how the glitches in the videos were performed. But as it turns out, the battery doesn't need to be fully in for the device to stay on, it just needs to be able to make contact with the circuit. When I'm messing around with the battery I'm usually constantly holding it against the Tamagotchi and trying not to let it slip - the video briefly demonstrates what I mean at around 4:24. If the battery had to be all the way in for it to function, I doubt these glitches would be attainable, due to how long it would take to remove and replace the battery - the trick is to tilt the battery quickly (but not too quickly).
  10. Hey look, it's hwd45 again. I wonder what weird topic he's starting this time? I think I'll have to start this with a bit of a disclaimer - I do not know the full extent of the procedure I'm showing off. As such, I cannot guarantee that this will not cause permanent damage to your device, though I do think it's likely that permanent damage is not something that can be attained via these glitches. Regardless, if you do choose to experiment with these glitches, be aware that at the very least you will likely lose your save data. I'm performing these glitches on a pre-owned device that I bought purely for experimental purposes. A few years back someone uploaded a video simply titled "Tamagotchi Glitches" showing some utterly bizarre behaviour that I've never seen from a Tamagotchi before. Another user uploaded a similar video using a Spanish V2. According to the first video, the following process was used in obtaining these glitches: I was not entirely sure what this meant at first, but it turns out that the "slide the battery in and out" is the most important part - the rest seems to be entirely irrelevant. From my own personal experiments it seems like it's harder to get exciting things to happen on screens with a low refresh rate - screens which aren't constantly updating - but pretty much any screen can be used to interesting results. Screens like the idle screen and the health menu have low refresh rates and the battery can actually be taken out for several seconds before the screen fades and it shuts down, whereas the shop screens and the transition to and from the clock screen have an incredibly high refresh rate and the device runs out of battery almost immediately when the battery is removed on these screens. Some screens seem to include more of a danger factor - attempting these glitches on the shopkeeper screen oddly seems to fully reset my device most of the time. What's so exciting about these glitches? Well, what appealed most about them to me was their ability to present the player with content you wouldn't see under normal conditions. Unused items? Unused games? Some utterly bizarre pseudo-characters that emerge from the device using the wrong sprite offset for your character? It's all here. Let's go over some of the exciting things seen in the videos, as well as some of the glitches I've been able to personally replicate. The Character -> Item Glitch One of the glitches I've not managed to reproduce is a glitch which replaces each sprite of your character's animation with an item. Since most of the items shown are V1 items (and hence items with a low item ID value) it stands to reason that the item that's shown seems to represent the ID value of the sprite that's shown. Here's a table: Sprite Item ID Idle 1 BALL 0 Idle 2 PENCIL 1 Happy WIG 2 Mouth closed SUNGLASSES 3 Mouth open TOOLS 4 Eyes closed SKATEBOARD 5 Back turned WEIGHTS 6 No RACQUETS 7 Angry CAPE 8 Sad BOW 9 Running 1 BOOTS 11 Running 2 CAP 12 Fallen over BOW TIE 13 Sitting mouth closed WINGS 14 Sitting mouth open HAIR GEL 15 Close-up close 1 SUNDAE 22 Close-up close 2 MILK 23 Favourite food ENERGY DRINK 52 Close-up mid Poo ?? Tooth brushing (1?/2?) Present Ice Cream ?? I'd like to continue gathering information on these sprites so I can work towards a more complete list of item IDs and sprite IDs. The Character -> Egg Glitch Similar to above - the sprites used for the character are now egg sprites. There's only four egg sprites, though, so after a certain point Petitchi sprites are used instead, but all offset by four. These can be used in conjunction with the item glitch above to figure out item IDs, since we know the difference between the ID of the sprite that is supposed to be shown and the ID of the sprite that is actually shown is four. Here's a table: Sprite Egg / Petitchi Sprite ID Idle 1 Egg 1 0 Idle 2 Egg 2 1 Happy Egg hatch M 2 Mouth closed Egg hatch F 3 Mouth open Idle 1 4 Eyes closed Idle 2 5 No Mouth closed 7 Angry Mouth open 8 The Egg -> Violetchi Glitch One glitch I've successfully performed that wasn't shown in the video was a similar glitch to the above, but instead of a character changing to an egg, the egg changed to have a character's sprite. That's about it, haha. Unused sprites? A few images of the V2 show content which is either never seen under normal conditions or only seen later on the V3. Could they have swapped the shells half way through the video? Perhaps. But it's certainly interesting and worth investigating. And I really have no idea what that "TRY?" menu might do, but I have been able to glitch into random menus using these glitches a few times, so it's possible that this could reveal some hidden functionality or something. The Rebirth Glitch This was a glitch I definitely wasn't expecting. Sometimes, messing with the battery will cause your Tamagotchi to revert back to an egg - this isn't quite the same as a full restart since it doesn't ask you to re-enter the time and date, but bizarrely, it seems to totally randomise the time and date, even to the extent of changing the clock to impossible dates like the 64th of April. The name of your character is also sometimes preserved, but it's usually randomised - this can even mean some of the characters changing to hiragana, like what was seen in the video. Several times I've also encountered glitch characters which will eventually change back to a hiragana character if you scroll far enough, and doing so seems to also change the character to the right of it, too. Very weird. Sometimes, after hatching, another glitch will have taken hold too: The Ball Glitch It's somewhat infamous at this point, but the ball glitch is a glitch which absolutely floods your item and food lists with balls. Occasionally other items end up in there too, but balls are the common denominator. This can go way beyond the 32 item limit and even go over 100, causing the number in the corner of the screen to behave strangely. What happens if you eat one of the non-food items? I wasn't really expecting this to happen, but weirdly, the animation for the standard meal that babies and children eat on the V1 (versions 0.0 - 2.4; or in other words, all the non-American devices) is shown instead. This item isn't seen anywhere else on the V2! My shop also filled with balls. Speaking of the shop, Glitch Items I'm not sure how I pulled it off but I managed to get all the shop items to change to glitch items. And they *stayed* that way, even after changing the battery. I tried buying a couple to see what they did but I couldn't use them as my character was still a baby. The sprites consisted of segments of text taken from the names of other items. Here are the items, and some interesting data to go with them: No. Sprite Price Notes 1 AB 800p Matches price of item ID 3, sprite resembles CRAB (ID ??) 2 K 1000p Matches price of item ID 2, sprite resembles MILK (ID 23) 3 AIT 110p Matches price of item ID 1, sprite resembles PARFAIT (ID 22) 4 ET 200p Matches price of item ID 0, sprite resembles OMELET (ID 21) One interesting side-effect of these sprites being based on the names of other items is that in later variants of the V2 the item names changed and so some of these sprites would change, too. I sent one of the items over to another V2 but curiously it just arrived as one of the standard gift ice creams. I've no idea why. So far the items have been otherwise unusable but it's possible that they'll be usable once my character reaches adulthood. There's definitely some sort of pattern in the data for each of the glitch items. Not only do the item prices match four consecutive items, but the names for each of the items seem to be the same glitchy mess, but shifted along by three pixels to the left for each consecutive item. Three of the small text fragments in the icons seem to match three items known to have consecutive ID numbers, too (as seen above, OMELET, PARFAIT and MILK have consecutive IDs). It stands to reason that CRAB might have an ID of 24 - the only other item ending in "AB" is KEBAB (which was called BBQ on later devices) but this one already has a known ID of 33. This actually aligns with some other known information about the V2 - the food items that are given by Deka characters. Here are the IDs of the Deka characters: ID Character 23 Omuratchi 24 Capsuletchi 25 Tamagotchi 26 Tsutatchi 27 Burgertchi 28 Denpatchi 29 Maikutchi And here are the food items given by each, as well as the ID of that item: Char ID Character Item Item ID 23 Omuratchi OMELET 21 SUNDAE 22 24 Capsuletchi MILK 23 CRAB 24? 25 Tamagotchi FRIED EGGS ?? BANANAS 26 26 Tsutatchi CHERRIES 27 PEANUT ?? 27 Burgertchi BURGER 29 FRIES 30 This can be used as further proof of several item's ID numbers - FRIED EGGS goes in slot 25 and PEANUT in 28. Denpatchi and Maikutchi's items can probably be used to determine more item IDs too, but I'm not sure what items they send to the V2. If you're wondering why the Deka characters give such a strange array of items, it's because the items they give on the V1 actually make some sort of sense, but the IDs used by these items were overwritten by different items on the V2. Anyway, that's enough of that small tangent. This is all I've got for now, but I'll continue to update as I find more interesting glitches! It's fascinating that using glitches like these can give us such an insight into how Tamagotchis work, and I've still got my fingers crossed that I'll eventually obtain a more interesting unused item via these methods.
  11. Has it not already been proven by this point that the MyMeets panic was largely fuelled by misinformation? As I recall, there were two ways in which the MyMeets application was incompatible with the main app: * Using MyMeets to obtain as-of-yet unreleased characters would cause the app to prevent the player from accessing the Plaza, the "banning" people often talked about. As such, the creator of the application no longer releases new character genes until they're officially released. * Using MyMeets to force a non-adult character to marry an adult would supposedly cause some level of data corruption which may be passable through the app - as I understand this is the corruption people spoke of, but the issue wasn't "MyMeets genes" as many put it. The extent of this corruption seems to have simply been a bizarre visual glitch on the family photo screen but not much else - many people have falsely attributed glitches such as the Peter Pan glitch to "MyMeets genes" but as of yet there's zero evidence for a connection. The creator of the application has since released a patch which disallows non-adults from marrying, circumventing any potential corruption.
  12. It's probably something I've done wrong - I think there might be extra information encoded into the password that I haven't accounted for. I think the character ID is supposed to go in there somewhere - probably in place of the random byte. As for the parent password, it's curious that you had to type several passwords in before it worked. I guess, as you say, that this is to do with the fact that you hadn't viewed the "Password for PC!!" thing first, but it definitely requires some investigation. --- So I've been continuing to experiment with various password types and it seems as though the V4 login and logout passwords use a similar checksum to the item passwords, but instead of adding each byte of the "base" password it adds each hexidecimal character of the "base" password (obtained after removing the pattern information and the username). Logout passwords seem to change one digit according to how much money you are to take back from Tamatown, and one binary digit is flipped, too, before recalculating the checksum and reapplying the pattern and username variables. However, in practice, logout passwords I've attempted to generate have not worked so far. Either the pattern of the logout needs to be something very specific with relation to the login password, or my calculator has a mistake in it, or these passwords have more information I've not yet accounted for. I'm hoping it's not the latter due to how infrequently valid pairs of login and logout passwords appear online (I've only managed to find one pair so far, so any old logout passwords you might have would be appreciated, though I understand many people won't still own these passwords because they're basically useless). --- EDIT: Okay, I think I've found the problem with travel passwords. And possibly parent passwords too? It seems like the random component of the travel items are instead replaced with the numbers 129, 130, 131, 132 or 133 depending on the item. Not really sure why, but it's simple enough. As for parent / grandparent items, these ones I've observed to use either 1 or 65, which might just be a coincidence. Interestingly the fact that the travel passwords require the numbers I listed above - an arithmetic progression - is part of the reason why some of the passwords I observed in my very first post on this topic formed an arithmetic progression!
  13. The codes for these passwords are slightly different from other passwords in that the underlying "base" password has a 130 or a 131 instead of a 129, but otherwise they're basically the same as other passwords. You're correct in guessing, though, that the reason they don't work is that your character doesn't have a parent or hasn't travelled. If you fulfil the correct conditions it should make those souvenirs obtainable. As I recall, though, the travel and parent passwords used on Tamatown actually do contain information about what character your Tamagotchi currently is - I don't know if this information is used at all, though. The V4 seems to act a little bit differently though - I think it requires a specific successful logout password before you're allowed to get these items.
  14. One more update: I've figured out that one strange 0 / 1 (the leftmost byte) that seems to mess everything up - it turns out that after XORing out those extra 106's the checksum is calculated in basically the same way - after removing the username, the 106's and the 70's, the sum of the bytes (now including the extra "1") is once again a multiple of 256, all the time. Analysing Parent / Grandparent / Travel passwords, too, it seems as though once all the encryption is stripped as before, the only difference from other passwords is that the rightmost byte is 130 or 131 instead of 129 (130 for parents and grandparents, 131 for travel items - I think these passwords only work when you've actually got parent characters or when you've actually travelled, though!). I do not know if the Famous Picture souvenir also acts this way, but if it does, I will need to make a very minor modification to my script. So basically... V3 item passwords are cracked. V4 passwords seem to act identically, except that instead of a 106 it's a 109 and instead of a 70 it's an 87. I have not been able to confirm if they still treat parent / grandparent passwords the same, however. Either way, I've added a V4 option to the generator. Okay... which passwords to tackle next? Since the V3 and V4 passwords were so similar, I expect that other passwords covered by the V3 (login passwords) also use similar checksum calculation techniques. Perhaps V4 login passwords do too! Music Star passwords are still a mystery, though.
  15. It's been less than a day since my last update - normally I'd just edit my last post but I feel like it might be worth bumping the thread for this update. Unless I'm mistaken... I've figured out how the checksum works in the V3 passwords, thus cracking the algorithm. There's still more to understand - with this I'm only capable of generating half the allowed password combinations (which is still obviously more than is necessary, so it's not really a big deal) due to that one variable which, when turned on, seems to make everything more difficult. I think, after this most recent revelation, it should be easier to figure out, though. Recall that there's a five-byte structure to the passwords, which we'll represent as follows: BYTE_5 | BYTE_4 | BYTE_3 | BYTE_2 | BYTE_1 For now we'll set BYTE_5 to zero to make things a bit easier. Recall also that a username constant is XOR'd onto this structure - for now we'll pretend we've already XOR'd out this username factor so the username is no longer affecting the password. Since BYTE_5 is zero, we get the following password structure, just by the nature of how these passwords work: 0 | BYTE_4 | BYTE_3 | BYTE_2 | 199 BYTE_2 = ITEM_ID XOR 70 BYTE_3 may be any integer from 0 to 255 BYTE_4 may be the checksum? That random 70 was definitely raising my eyebrows and when adding together all of the bytes I noticed that the result I got most of the time was exactly 140 away from 256, a power of two. So I tried XORing out a couple 70s here and there: 0 | BYTE_4 | BYTE_3 | BYTE_2 | 199 XOR 0 | 70 | 70 | 70 | 70 = 0 | BYTE_4 XOR 70 | BYTE_3 XOR 70 | ITEM_ID | 129 This seems like it's in a format that would make more sense for the password decoder to read - the item ID can now just be read out instead of needing to apply a random 70 to it. It should also be noted that BYTE_3 XOR 70 is once again just another integer from 0 to 255 so we can consider this the random element (if you'd like a more technical definition, the XOR 70 operator is a bijective function on the set of integers from 0 to 255 to itself). We'll notate BYTE_3 XOR 70 as just "RAND" and BYTE_4 XOR 70 as "CHECK". Here's the breakthrough: 129 + ITEM_ID + RAND + CHECK = 0 mod 256 Hence, CHECK = 127 - ITEM_ID - RAND mod 256 A slightly unusual checksum, but it makes a certain amount of sense. To verify the checksum, all the device would need to do is add the four bytes together and check that they equal zero (mod 256). I have a generator spreadsheet ready for those who want to generate passwords using this now, but I'd prefer to get it into a more accessible state, so I'm writing up some javascript for this purpose instead. I'm also considering creating a sort of EnWarehouse-like program for this purpose too, once I figure out some of the other password systems as well. I'll get the script out as soon as possible. Thanks to all those who have helped me on this journey! --- EDIT: I've embedded the script into this page: https://hazzabobbo.wixsite.com/mamemamelabs/password-generator The presentation is a bit sloppy for now but it's something I'm working on! There'll probably be some item IDs which don't work so any feedback is helpful.