Iron Sword ※ Cracking Videogame Passwords S1e13 (Wizards & Warriors II)

In the advent of 1990 I played NES games a lot. Knowing nothing about programming but being geekish by nature, I obsessed over cracking the password systems in those games. In this series we will study some of these systems.

Downloads:

#Bisqwit #Programming #ReverseEngineering #Password #NES

[yosser]

Hiya. I wrote the game (and Solar Jetman too). Congratulations on your reverse engineering, particularly given that I lost the source about 20 years ago. I wouldn't fret about passwords becoming incompatible if a second Rom version comes out. It was considered vanishingly unlikely that anyone would buy two copies of a game, and yet more unlikely that they would care if their passwords didn't retain compatibility.

Finally (and please forgive me if you make this point elsewhere), in later NES games vowels were forbidden in passwords in case anyone accidentally saw a swear word. I confess that I made that suggestion to them at a developer conference because they were promoting the idea of an encrypted dictionary of sweary stuff to check against, and this seemed a bit silly to me.

[Moco]

0:50 when you're an actual robot. A new meme is born

[seancornell]

And I thought my day couldn't get better.

[artwork]

Am I the only one subscribing and watching all these videoes, eventhough he could be talking Mandarin for all it mattered. I don't understand a thing, but I love his voice :) My new favorite word is : Two bit bitmask

[cplusplusnolifer]

Congratulations on 100.000 subs! Your programming skills are insane man! Keep it up!

[JoLiKMC]

It confused me, at first… but, after my brain caught up, I appreciated the sharp-and-sudden start of this video. It kind of mirrors what you said about the game, itself!

[Bisqwit]

The assembler function from the game code shown at the top of screen at 5:39 is wastefully written. Who can correctly identify the three instructions that accomplish absolutely nothing?

[baltazarus]

Congrats on 100k subs, man! Your channel is big like *unsigned long long int*

[EximiusDux]

phew. this channel is growing fast as compared to a year or two ago. congrats.

[big_b_radical]

Using the code as password encrypt/ decrypt data may have protected against certain piracy/ bootleg measures by invalidating password usage.

[treierxyz]

Congrats on reaching 100k subscribers! Keep up the good work!

[twentysix]

dude your videos are always interesting to watch

[walkwithme]

it's amazing that almost no one dislikes your videos. Salute.!!

[christianbuendia]

I hope one day can understand everything in one of your vídeos! Im working hard to make it happen!

[NESAtlas]

If they use code as part of the lookup table, then can it still be considered a lookup table? Or maybe some kind of self-referring algorithm? That is some kind of demoscene wizardry.

[KuraIthys]

Ah... It's been a while.

This... Continues my horror and fascination with the absolutely bizarre ways these passwords function. XD

This one seems to have a larger pool of 'invalid' data than most, but again, large chunks of the password still seem to map in a surprisingly direct manner onto the data the game is actually saving...

Wonder of wonders huh.

I suppose a password system has a bunch of design constraints.
-It has to be reasonably secure against random guesses and brute force attacks.
-It has to store all the data the game needs to restore itself to a reasonable state
-it has to be as brief as possible.

That last point follows from the fact that people have to write down these codes and enter them into a password entry system through the tedious method of using a 4 button gamepad.

So... That rules out storing 2 kilobytes of save data...

And in fact, given that the longest passwords I've ever recalled personally seeing are about 20 characters long, we can infer an absolute upper bound of 140 bits of storage, with the vast majority of systems being 70 bits or less, since actual use of full 128 character Ascii codes is very rare, and base 64 or hexadecimal seems to be more common.

Of course, perhaps there ARE codes longer than 20 characters, but if there are...
Well, 20 characters is already pretty tedious.

Thinking about it, trying to encode the equivalent of a save file for a game's state in less than 70 bits is quite a feat in and of itself for a nontrivial game.
Of course, a lot of NES games took a shortcut by saving only part of the state of the game...
But still...
SNES and Mega Drive games must be even worse, since the average complexity is higher. (though password systems are rarer I guess.)

Let me think, if you had to store a game on the order of complexity of A link to the Past...

You've got to deal with the presence or absence of something like 20 regular items (this is off memory, so it could be somewhat wrong), the presence or absence of 4 bottles, and potentially what their content might be, (though to my knowledge there's only 5 things that can be in a bottle.), the heart pieces and containers collected (you need to know not just how many, but also which ones were collected). Since there are 3 light world dungeons, and 7 dark world ones, and you can finish the dungeon without explicitly collecting the heart, we've got 10 full hearts, and 7x4 heart pieces.
The dungeon itself would have to store a flag for whether it's been completed, and you'd need at least 4 more for stuff to do with hyrule castle.
Then there's a few random state items related to getting to various dungeons, such as the monkey for the first dark world one, or the boss in Blind's hideout.
Then there's items that have 'levels', but probably also still require that you track the individual levels, like the titan's mitt, the swords, the shields, the armour upgrades, and the magic upgrade. The armour upgrade and one of the shields is a dungeon item, but you can lose your shield and rebuy it, as well as find a second level shield in the world, so that's even more to keep track of. There's the rupees carried, chests opened, magic level, maximum and actual number of bombs and arrows...
So, we have about 58 bits for basic items and heart pieces.
the bottles could be stored as 3 bits each which would account both for whether you have the given bottle, and what it contains. (12 bits)
Dungeon completion states would be about 10 bits for main dungeons.
At least 4 for hyrule castle, and one for whether you've opened ganon's tower.
(15 bits - 85 so far)
storing up to 999 rupees requires 10 bits. Bombs and arrows top out at roughly 70 each, which means at least 7 bits for storing how many are required, and at a bare minimum, the 'maximum' has to account for at least how many unit of 5 upgrades there are from the base amount. which seems to be about 40 over the base, or 8 upgrades. (that makes 3 bits for each)
This would be another 30 bits (115 so far)
Then there's silver arrows, the upgraded boomerang, the 2 upgraded armour types, the gloves, magic upgrade and swords. Since you'd have to track where they came from too, you'd need one bit each. That's 10 more bits (125 so far)
The mushroom, and whether the witch will sell you certain things also needs to be tracked, so that's at least 2 more bits. (127 so far)
Shields not only require knowing which shield you have (none or one of 3 types), but also where you got various shields from that exist in the world. Not sure how many that is, but that's at least 2 bits for the shield type, and probably at least 3 or 4 bits for various locations ingame that may have contained a shield. (6 bits, 133 so far)
You'd have to keep track of whether you've got an object/character following you.
This can include Zelda, the thief in the forest, the guy in the desert, the monkey, the sealed chest, the old man in the mountains, the girl in blind's dungeon, and the superbomb (if I'm not forgetting anyone), Since you'd also need 'nothing' to be a possible value, that means at least 4 bits required. (137 so far)

Then there's chests that contain things but can only be opened once. Any with an item are already accounted for, but those that contain supplies (bombs, arrows, hearts, rupees, fairies, etc) would need to be tracked.
Can't say how many of these there are, but it's a few. Probably 30-40 if not more.
So let's say 50.
Same with bombable walls, since once you bomb them they stay open. That could easily be as many, so now you've got another 100 bits or so. (237 so far)

Round up for anything random I may have forgotten and a game like that would be storing at least 250 bits.
Using a typical 64 character encoding, you'd need a minimum of a 42 character password to store something like that.
And that's without any checksums or other values hidden in the code to improve 'security'.
A hex encoding bumps that up to nearly 63 characters...

Starts to get pretty unreasonable at that kind of length.
Of course, it's a moot point when you've got a way of saving data (then again, when your save ram is 1-2 kilobits, this is still pretty tight. - if you have 3 save files of 250 bits, and concerns about data integrity lead you to store your data twice, which quite a few games evidently seem to do with SRAM based saves - then you're quickly going to fill up a 2 kilobit SRAM...), but it does suggest why these codes are so frugal with their encoding.

Weird stuff to think about in some ways...

[Psoron]

very cool bisqwit! i was just about to watch your cracking password series again!

[jomunoz]

"a password scheme that is so un-orthodox that is difficult to even write them down..."
me: Captain Tsubasa for the Famicom comes to mind.

[holdenchevrotine]

Hey bisqwit I have a question not related to the video. What Linux distro you use?

[anonymousshawn]

Was that Dave Batista on the front of that game?