Twin Dragons Password Encoder/Decoder

It’s been a little while since I last posted anything because I’ve been occupied with some other things that I wouldn’t blog about and that’s going to continue for a while longer. But, Twin Dragons came in the mail the other day and it provided a nice excuse for a little diversion. So, funny story: a fresh and incredibly polished new title shows up on my doorstep that just screams “play me! play me!” and what do I do instead? That’s right, I disassemble it because my twisted psyche demands nothing less.

In all seriousness though, I have played the first couple of levels through and really enjoyed it so far. It’s a great game that deserves to be played and I intend to continue doing just that. That said, when I saw that it had an algorithmic password system I just couldn’t help myself and had to dig in and tear it apart right away. Long story short is that I ended up creating a little JavaScript app to edit the passwords which is probably what you are looking for if you’re reading this. You’ll find it on my Neocities page which is linked below (doesn’t seem like there is a way I could host it on this WordPress blog).

https://bacteriamage.neocities.org/twin-dragons-password-encoder-decoder.html

The rest of this post is just my usual commentary discussing some of the more interesting tidbits around this topic. Before we jump into that though, I just want to say that I’m a little worried that someone will think that I’m trying to denigrate or take something away from Twin Dragons by putting this password generator out there. Nothing could be farther from the truth; I admire and respect what Antoine and everyone at Broke Studio has accomplished with this title and it is worth my effort tearing it down because of how brilliant it is. The password generator is something I did on my own for my own purposes and I put it out there just because I think it might be of use or interest to some others and because of my belief that players always have the right to decide how they play a game.

My last post on the topic of game passwords took a really deep dive into the specifics of the system used by The Legends of Owlia. This time I’m hoping to keep the discussion much higher level and just touch on a few key points that I think are really interesting and noteworthy about Twin Dragons. Of course, I’m known to have a problem with brevity so, let’s just push ahead and we’ll see what I end up churning out. Also, I guess I owe Derek over at Gradual Games an apology for not giving Owlia the full-on password-generator treatment. I’d like to but Owlia‘s underlying data format has more complexity and so creating an editor form would require a much larger effort.

Encoding

At first glance the password encoding in Twin Dragons doesn’t seem particularly out of the ordinary. There’s a four-by-eight grid of characters so that’s 32 of them meaning each one gives precisely 5 bits of data. There’s eight characters in each password so we’ve got 40 bits or exactly 5 bytes of data; how very tidy. The characters in the matrix are just assigned numeric values from left-to-right and then top-to-bottom so the value of each character is easy to predict even without any reverse engineering.

What I found next though kind of blew me away since it’s not something I’ve seen in any game password system that I’ve investigate so far (both classic games and recent homebrew). Generally, I’ve always seen games use somekind of simple bitmask and exclusive-OR to scramble the raw data and create an appearance of randomness. But, Twin Dragons kicks this well into overdrive and uses a complex combination of shifts, bitmasks, and arithmetic to scramble the bits and it’s all interwoven between the different bytes of the raw data values. Here’s some C-style code for the basic algorithm:

p0 = (((p1 << 3) + 0x0e) ^ p0) & 0xff;
p1 = (p1 - ((p2 << 3) ^ 0xf9) - 1) & 0xff;
p2 = (((p3 << 3) + 0x13) ^ p2) & 0xff;
p3 = (p3 - ((p4 << 3) ^ 0xad) - 1) & 0xff;
p4 = (((p0 << 3) + 0x23) ^ p4) & 0xff;

What’s really hardcore about this though is that this isn’t just run through one time; it’s actually applied repeatedly for 16 rounds. This generates a remarkable amount of apparent entropy and raw values that differ by just single bit end up yielding wildly different and unpredictable results. This is the kind of behavior you’d expect to see from a real cryptographic cipher which, in my personal experience, is beyond unusual and really impressive for a game’s password system.

I’ve yet to try my own hand at the whole homebrew thing but I’ve always known that I’d want to include my own algorithmic passwords and how that would work I’ve thought a lot about. Up to now I thought I had the perfect system worked out but these fine chaps at Broke Studio have really one-upped my thinking here and given an entirely new perspective to consider. Kudos.

Validation

In some detail, I discussed in my Owlia write-up how games typically compute and embed a checksum within the password to validate it when it’s later entered by the player. The purpose is so the game can tell the difference between a real password generated by the game and one where the player just randomly punched in values. This also catches simple transcription mistakes which would otherwise produce garbled data. Twin Dragons‘ system includes such a validation mechanism so that it can reject any bad passwords but once again it takes a surprising approach.

Rather than a checksum, Twin Dragons just dedicates a single byte of the raw data to a fixed and predetermined value (0x3F in this case). The one value is written to every password before its encoded and so is expected to be present once the same password is decoded. If the value matches after being decoded then it’s a valid password and otherwise it’s not. This is somewhat akin to the concept of a “magic number” sometimes used to identify different types of binary file formats.

With other games, I think the variability of the checksum helps to increase the apparent randomness of the total password. Using such a fixed value could potentially standout and create obvious consistencies between different passwords. I think Twin Dragons can get away with the fixed value because of the elaborate cipher it uses which just erases any trace of the static value embedded in the raw data.

Stages

As expected, the password contains the next stage of the game to play. The passwords are issued on the world map which only appears after bosses between completely different areas of the game. So, we’d probably also expect that the password would just contain what the next area is. A single byte contains a counter for the number of the next stage but this value is more granular than just the broader areas. Each of the individual stages that compose the areas have their own identifier as do bosses and other things like animated cut scenes. While I don’t think the game will ever issue a password with a more specific value, it does happily accept these additional values if you encode a password to contain them.

This allows custom passwords to be created that go directly to specific portions of the game. This also includes the game’s ending and credits. I can only guess as to why the game has this otherwise inaccessible capability. My best guesses are that at an earlier stage of development there were plans to allow more granular passwords that were later abandoned or that the specific passwords were included to make it easy to jump to specific places during development and play testing.

Unused stages

The game uses a full byte value to store the stage number which is 256 possible values but only 25% of those values are actually used. All of the other unused values seem to just send you back to the main menu if you put them in the password. However, I only own the standard edition gray cartridge and it is my understanding from the Kickstarter campaign that there are also special green and pink versions which each contain an additional area or stage for Dinky or Minky, respectively.

Lacking access to either special edition I don’t know how they work but I’d guess that those versions might use some of the unused values for those other stages. That would mean that if you used those special stage passwords on another color cartridge it would probably just send you back to the main menu. Other possibilities are that the special stages aren’t accessible through a password or that the alternate versions encode the passwords using a different algorithm and so the passwords aren’t interchangeable between them at all.

Anyway, if you have a special edition cartridge and obtain a password for one of the exclusive stages I’d be interested to see it if you wanted to send it to me. Alternately, you could try encoding some passwords with some of the unused values and see if they have any different effect on other versions of the game. I haven’t tried nearly all of the other values but I’d suspect the ones for the special stages would be in the 0x40 to 0x50 range right after all the other currently used values.

Invulnerability flag

On the topic of interesting secrets embedded in the passwords is Twin Dragon’s invulnerability flag. Simply put, there is a single-bit flag within the password that if set causes Dinky (or Minky) to be invulnerable to enemies, spikes, projectiles, etc. The only things that are still fatal with this flag set are environmental hazards like water, lava, or falling off a cliff. The game always clears this flag before encoding a password so even if you have it set while playing any subsequent passwords issued do not contain it; the only way to set it seems to be to create a password yourself that has it set.

Again, I can only guess as to why something like this exists in the password. It’s really interesting that it’s there but it definitely isn’t used by the game under normal circumstances. It’s possible that it was intended for debug uses. It’s possible that it’s part of some kind of internal cheat code and the flag just happened to be stored in RAM in with other stuff that normally goes in the password and was never intended to actually be set in the password. It’s also possible it’s an Easter Egg inserted for password hackers to discover.

Other Observations

When you start a new game you select the level of difficulty and this gets encoded in the password so you continue that same level when you resume playing with a password later. There are 3 possible difficultly levels stored in the password using 2 bits which leaves an extra unused value. The game crashes if you set the difficulty level to unused value.

The password dedicates a full byte each to the number of lives and the number of peppers. This means each one has possible values starting with 0 and going all the way to 255. The number of each is capped at 99 as is usual for most games. The minimum number of peppers is zero and the minimum number of lives is 3. You can encode passwords that contain other values but they just get rounded up or down to the respective minimum or maximum value when the password is decoded. To simplify things, I made the password app follow the same rules but you could easily remove the validation by editing the JavaScript if you wanted to use it to encode numbers outside the usual ranges.

There’s a flag which keeps track of whether the player character is Minky or Dinky. This is mostly ignored by the game since the level will use whatever character is normally used with the specific stage. But, for the last couple of levels where you can freely switch between characters this field will affect the player that you start with.

The lower 2 bits of the upper nibble of the flags byte appear to be unused. I believe they are always zero under normal circumstances and if I set them it appears they have no effect. This isn’t terribly surprising since most passwords do contain some unused slack space like this. I did include the flags in the password editor though so if you ever see them set in a real password or set them yourself then notice some effect let me know since I’d like to investigate further.