I’ve always been fascinated with video games that included “passwords.” There’s something mysterious and exotic about the whole idea. Especially as a child it gave me feelings of intrigue and mastery as if I was at the apex of some grand conspiracy. Games which framed the input of their passwords in this way undeniably contributed to this as did publications like Nintendo Power’s Top Secret Passwords Player’s Guide.
Of course, the wonder I experienced as a child falls away somewhat when you consider the business reasons for why game passwords were originally created and the fact they are really little more than tiny fragments of serialized data. Despite all that, I find that I still really like the idea of it beyond simple nostalgia and also especially enjoy the challenge of deciphering the coding systems and creating my own customized passwords. I’ve personally dismantled password systems from a number of classic games and learned some things about how they work and how they were put together in the course of it.
With my recent entry into the world of Nintendo homebrew I was delighted to find that the tradition of password driven NES games continues. Whether this is for purely nostalgic purposes or is still driven by the more pragmatic concerns of the developer isn’t always apparent to me but either way it has some intrinsic value in my opinion. I’m excited for the chance to study the creations of modern NES developers in comparison with classic titles.
My first victim, as it were, is The Legends of Owlia by Gradual Games and I’ll give my micro review of it right here: A good game but I wish there was more of it. This will be the first non-classic password system that I’ve deciphered and I’ll be speaking quite frankly about what I’ve found in comparison to other systems that I’ve seen. I don’t mean to be overly critical or for this to be taken as denigrative of the title. This was a game that I enjoyed playing and seems pretty well put together; I probably wouldn’t have expended all this effort on it if I had felt otherwise.
Encoding
Passwords in The Legends of Owlia are 10 characters long and use all the capital letters and all ten numerical digits as possible characters. This means that each character is one of 36 possible values or about 5.2 bits worth of data. Only 32 of these characters are actually used with the digits 6, 7, 8, and 9 being decoys that are never used in a valid password and automatically invalidate the entry if the player ever enters them into the game.
The use of decoys is common and is often employed by games to make it harder to randomly guess correct passwords or to just round out the set of possible inputs. In this case I think it’s the latter since Owlia presents the input selection as a nice 6×6 square matrix. A common alternative is to throw out completely one of the characters in a pair that are often confused for one another. So, Owlia could have just created (but did not) a 32 character set and threw out number 0 because it looks like letter O or throw out letter I because it looks like number 1 and so on. Neither approach is clearly better than the other.
Owlia probably only uses 32 characters because that gives an even 5 bits of data per character and it is much easier to work with even bits than a fractional number. This means that the full 10 character password carries 50 bits or 6.25 bytes of encoded data. Each character represents a single number from zero to thirty-one and when you convert each character to the corresponding binary number and then paste them all together one-after-the-other you get the full 50 bits of data:
Game passwords generally want to appear as random jumbles of letters and numbers and one method of creating this apparent randomness is to assign numeric values to the characters at random. This requires a lookup table to be built into the game so that it finds the value that was assigned to each letter as the user enters it. Owlia doesn’t do this and instead follows the much more straight forward approach of assigning the numbers in alphabetic sequence and then numeric sequence after that.
This means that the character A is equal to zero, B is equal to one, and so until Z which is equal to 25. The missing six values are assigned to the digit zero starting at 26 thru the digit five ending at 31. Since the numbers are assigned in a logical sequence they can be converted through a simple algorithm. The downside of this is that the password will appear much less random especially at the start of the game when most bits are zero (the password would contain mostly A characters).
Owlia achieves the appearance of randomness through another common technique used by many other games before it. This is the only method employed by Owlia to scramble the password and it is effective on its own but it’s also not uncommon to see it combined with one or more other techniques in other games. The technique used here it to split the raw password bits out into bytes and then scramble each byte using exclusive-OR.
The 6502 instruction for exclusive-OR is EOR and it operates on each pair of bits between two bytes; one in the accumulator and one from an immediate value or a memory location. It’s not technically accurate to say this but, for all intents-and-purposes, this means the NES can only XOR complete 8-bit bytes which creates a slight challenge with the 50-bit value that we have. The only solution I’ve seen for this—and the only one that I can think of—is to just split the 50 bits into bytes and encode each one individually which is exactly what The Legends of Owlia does:
Two things might catch your attention in this illustration. One is that two bits are missing near the end. The other is that when decoded nearly all of the bits in this example password are zero.
The reason for the missing two bits (25 cents?) is because fifty doesn’t divide equally by eight but forty-eight does. Strictly speaking, there’s no reason why the game couldn’t have made use of these two bits in a fractional byte since it’s much less difficult than fractional bits. For whatever reason though the game doesn’t seem to need them and so chose to discard them which results in the final raw decoded password being 48-bits long or exactly 6 bytes.
Some form of unused or wasted space is actually very common with various password systems. Most games’ passwords have a few spare bits that are always zero in game-generated passwords and are not validated when the password is decoded. In those cases and in this one specifically, this creates some space where hacked or otherwise custom generated passwords can insert a little extra data without invaliding the password. This could be used as a form of watermark or for another purpose. In this case the two bits don’t provide much extra space but you could still set these dropped bits to create versions of any password the game itself would never generate but that it still accepts.
As for the decoded bits being almost all zeros, this is interesting for two reasons. First is that the example password used in the illustrations is the first password the game generates immediately after starting a new game. In this password basically all things the password tracks like items collected or doors opened haven’t happened yet so they are all zeros and this is reflected quite clearly in the decoded raw password bits.
Second, since the password itself is just a big zero-block the letters and numbers of this password itself basically reveal the key used to decode it. This is because when XOR is used to scramble data the effect is just that any bits that are set in the key simply invert those corresponding bits in the data. This allows the encryption to be performed or reversed by just XORing the data and the key each time. In this case since nearly all the data bits can be assumed to be zero we know that nearly all the bits that are set in the password are set because they were inverted which in turn reveals which bits are set and not set in the key.
This basically makes it trivial to derive the key and decode—or encode—any password but this is only easy because Owlia doesn’t employ any other protections or randomizations on the data. As discussed earlier, the numerical value for each character is easily predicted but if they had been scrambled with a lookup table or another method it would have been much harder to crack by hand. In the next section as we delve into the actual payload of the password we’ll continue to see that protection of the data and prevention of tampering didn’t seem to be a big design goal for this particular system.
Data format
In the last section we reversed the encoding procedure used by passwords for The Legends of Owlia and revealed the password’s raw data bits which turned out to be a 48-bit value or just a block of 6 bytes. We know these bits contain all the information the game “saves” between play sessions because when we enter the password certain things like money, items, and the current level are restored. Therefore, we know this isn’t just a single long number but actually multiple individual values or numbers, which I will refer to as “fields,” that must all be smushed together to from the one larger value.
So, our next task is just to separate out the individual fields so we can see exactly what data is being carried by the password and how it’s being stored. At this point, since we’ve decoded the raw bits the easiest thing to do is just gather some different passwords and remember what we did in the game in-between those steps. Then we can just see which bits are changed by doing those things which reveals the location and purpose of the different fields within the longer binary value.
For example, the first thing I did was to get some passwords with different numbers of bombs, lanterns, and hearts (health) since these are easily collected at any point in the game. This technique allowed me to pretty quickly and easily break apart the password into all the separate fields which, for the sake of brevity, I will just document in illustration below:
As we can see, the values are neatly packed in a simple way that makes it easy to find and understand the value. All the bits of a single field are grouped together and are consistently stored left-to-right with the most-significant bits first. This continues the theme from the encoding where it seems like the game doesn’t care too much about trying to prevent someone from cracking the code, as it were. The developer could have tried to scramble the order of the bits which would have increased the complexity of the encoding and decoding programs but would have also made deciphering the meaning more difficult.
We’ll start with the simplest and easiest fields. The fields labeled E, F, and G are, respectively, for the number of Bombs, Lanterns, and extra Hearts (“Health”) held by the player as seen on the pause screen. Nothing fancy here and all possible values from zero to seven are used as expected to just mean the number of the particular item held. Since only tree bits are allocated to each it means the maximum number of the item has to be only 7 (since 3 bits gives only 8 possible combinations including zero) which explains the reason why the cap isn’t 9 like we might have otherwise expected.
Field I is the heart of the password in that it keeps track of overall progress through the game. You could describe this as the “level” the player is on since it gets incremented each time a dungeon or major milestone is passed. This value starts out initialized to 1 at the start of the game and so is the only field which doesn’t start as all zeros. It increments to 2 when you speak with Silmaran in the forest and then once again after clearing each dungeon.
| Value | Level | After Event |
| 0 | Not Used | Breaks password |
| 1 | Town | New Game |
| 2 | Forest | Met Silmaran |
| 3 | Tundra | Beat forest dungeon |
| 4 | Mountain | Beat tundra dungeon |
| 5 | Island | Beat mountain dungeon |
| 6 | Docks/Submarine | Beat island dungeon |
| 7 | Mermon’s Fortress | Beat submarine dungeon |
This part of the password is very well designed. Some of the other systems I’ve seen have really messy methods of tracking the game progression using multiple fields that can conflict in odd ways. In those cases it’s often possible to write passwords were the system accepts the password but the game is in state which can’t be completed (although I guess shame on us from trying to break it like that?). That’s probably because those games just dump raw variable values from RAM directly into the password. I suppose that works but it’s messy and is not as efficient space wise. Owlia‘s approach on the other hand is just to increment this master-counter during major transitions and then supplements that with additional fields that get reused per level which we’ll discuss next. This is a very clean and efficient approach and I like it a lot; kudos to the developer on this one.
The single-bit entered-dungeon flag plus a byte of dungeon-specific flags are in fields B and C respectively and these fields are reset and reused each time the primary counter is incremented. For the dungeon flag it gets set once you first enter each of the five dungeons from their respective overworld or enter the submarine from the docks. Once the flag is set the game always starts at the dungeon entrance until the captive owl is rescued even if you exit the dungeon and collect a new password.
The flags byte is just a collection of eight on/off switches and each one tracks whether a particular key has been collected, a particular door has been opened, or a specific chest has been opened. This field is really important to allowing you to save and resume your play of a dungeon since it basically tracks how much of the overall level has been solved. There are only eight of these flags though which is why it’s important that the field gets cleared and reused in each dungeon. Since the field is reused the meaning of each bit varies by each dungeon and not all the dungeons use every bit since they don’t always need all of them.
| Bit | Forest | Tundra | Mountain | Island | Fortress |
| 1 | Key 1 | Key 1 | Key 1 | Key 1 | Key 1 |
| 2 | Key 2 | Key 2 | Key 2 | Key 2 | Key 2 |
| 4 | Door 1 | Door 1 | – | – | Key 3 |
| 8 | Door 2 | Door 2 | Door 1 | Chest | Key 4 |
| 16 | Chest | Chest | Door 2 | Key 3 | Door 1 |
| 32 | – | Chest | Door 3 | Door 1 | Door 2 |
| 64 | – | – | Chest | Door 2 | Door 3 |
| 128 | – | – | Key 3 | Door 3 | Door 4 |
Overall, this is excellent execution and much better use of space then I have seen in some other systems. It’s worth noting the game doesn’t seem to validate the flags so you can enter combinations that don’t make sense such as unlocked all the doors but claimed no keys. It also doesn’t care if data is present in bits that are unused or for a “level” like the town or the docks that don’t use the flags at all. In those cases this is a little bit of additional unused space where extra data could be hidden but it’s not consistently available.
Field H is a little bit of a disappointment coming out of the previous discussion. This field is just a counter for the current number of keys held by the player. That is it’s the number of keys that have been found but not yet used to open a door. It’s really just wasted space because this information could easily be recomputed from the flags by counting the number of keys found and subtracting the doors opened. Three bits are used since the player might have anywhere from zero to four keys (5 possible values). The game doesn’t validate this value either so you can give more keys in a custom password than the game would ever award normally. I think this field was just added for programmer convenience but it’s not strictly necessary.
That leads us into the final remaining field but this last field covers half of the total bits in the entire password. This field took me the most time to identify and fully understand because it defied my expectations. Just from playing the game first I knew that money (GP) in the game was always collected in increments of 100 GP so the player’s total GP was always evenly divisible by 100. I also assumed (correctly this time) that the GP cap was 999,900. This means the password could store any amount of money using only 14 bits because it could be saved as a multiple of 100. I expected to find that 2 of the remaining bytes were used for money and the third for another purpose but it wasn’t working out and kept confounding me.
I eventually realized that all three of the remaining bits formed a single 24-bit field which is for the exact number of GP the player has. Bits marked A are the 8 least-significant of this value, followed by bits J in the middle, and bits D are the most significant. Since this value is 24-bits it can save any (unsigned) number from 0 to 16,777,215 but only 10,000 of those values are possible to appear in a valid password. This works out to a utilization of roughly 0.06% and so this is a large waste of space.
The other field I was expecting to find was a checksum field which was used to validate the entire password. Every other system I’ve investigated has included a field which is computed from all the others using some algorithm (usually simple addition) and this is normally what allows the game to tell the difference between something valid and a player just trying to enter random numbers. When the password is reentered, the same value gets recomputed and if the recomputed value matches the one in the password itself then the password is accepted and otherwise it gets rejected.
Owlia doesn’t have this and it was a bit unexpected to find it was missing. Owlia still has some mechanism for checking the password but it works differently. When a password is entered into Owlia the game checks to make sure the value of each field is valid and rejects the password if one or more fields are invalid. The issue with this is that the only fields that can contain invalid values are the GP and event counter fields. All the others are valid with any possible value so there’s no way to invalidate them. It can also reject the password if the dungeon bit is set for a level that doesn’t use it (e.g. the Town).
Since 50% of the entire value is covered by GP bits and since that field has such a low ratio of valid values it means that any random entry is still very likely to be rejected. For this field, any value that is larger than 999,900 or that is not evenly divisible by 100 is invalid and breaks the password. Any random combination that you punch in is likely to not meet these constraints and so does get rejected. However, the third, sixth, and seventh characters of the password do not contain any bits for the GP value and so you can change these values freely on any otherwise valid password and get it to work 100% of the time—try it and see! The eighth character contains the event counter which is also going to be valid most of the time so you can also change it and have it work in most cases.
This validation approach is less comprehensive than the more common checksum approach (some games do both) because it ends up leaving some of the characters “unprotected” from tampering. This seems to continue the theme from the previous section where the “security” of the password is not a large concern for Owlia. There really isn’t anything wrong with this; the developer doesn’t have to be trying to prevent players from casually modifying passwords. However, this also creates a usability issue since when I enter a password, I expect it to work only if I enter it correctly and for the game to catch my mistakes. Since nearly half the characters can accept any value it means that I can easily make a mistake and still have the game accept it. For the third character especially this could be a problem since that contains flag values which if incorrectly restored could remove some of my progress or worse leave the dungeon in a state where it’s impossible to complete it.
To conclude my commentary on this, the Owlia system makes a really strong showing on the tracking of progress and state information doing this part elegantly and efficiently. It falls short on overall space efficiency though and on data validation. My recommendation on how this system could have been improved would have been to allocate only 14 bits to the GP value as I described earlier. I would then suggest allocating an additional 5 bits to some form of checksum. This would improve the data integrity issue and use only 40 bits which means we could shorten the password to just 8 characters. This would improve the player’s experience by reducing the number of characters that have to be entered and be more likely to catch input mistakes. An additional optional change would be to jettison the keys field entirely since that value can be recomputed from the flags data. We could then add those bits to the checksum for added validation strength or use them for another purpose entirely.
Custom passwords
My intention with this article wasn’t really to teach the reader to encode or decode the passwords themselves (although there is definitely enough information here for that if you want to try) but just to break it down and examine the strengths and weaknesses of the system in comparison to others. However, when I’ve made similar write ups in the past I always included a table of custom generated passwords. So I’ll continue that tradition and end on this table of passwords that will take you to any point in the game with 100,000 GP and all the items maxed out.
| Level | Step | Password |
| Town | Overworld | GCSKIHKRFW |
| Town | Dungeon | – |
| Town | Boss | – |
| Forest | Overworld | GCSKIHKSFW |
| Forest | Dungeon | GASKIHKSFW |
| Forest | Boss | GAVSIHKSFW |
| Tundra | Overworld | GCSKIHKTFW |
| Tundra | Dungeon | GASKIHKTFW |
| Tundra | Boss | GA3SIHKTFW |
| Mountain | Overworld | GCSKIHKUFW |
| Mountain | Dungeon | GASKIHKUFW |
| Mountain | Boss | GBMSIHKUFW |
| Island | Overworld | GCSKIHKVFW |
| Island | Dungeon | GASKIHKVFW |
| Island | Boss | GBMSIHKVFW |
| Docks | Overworld | GCSKIHKWFW |
| Docks | Dungeon | GASKIHKWFW |
| Docks | Boss | – |
| Fortress | Overworld | GCSKIHKXFW |
| Fortress | Dungeon | GASKIHKXFW |
| Fortress | Boss | GBNSIHKXFW |
BacteriaMage's Blog 
You must be logged in to post a comment.