Anecdota

Laughter is the Best Medicine

Dyna Blaster ※ reverse engineering on DOS ※ Cracking VG Passwords S2e3


Back in mid-1990s when I was still
a novice at using computers, I didn’t play many
games on the PC, because I spent nearly all
my time programming instead. One of those that I did play,
was Dyna Blaster. Which is totally not Bomberman. I mean, you clearly don’t have
randomly generated rooms – with enemies that vary from
balloons with faces on them – to various kinds of blobs
with faces on them, and you clearly do not place bombs
that can be fired in chains, and… Okay seriously,
this is Bomberman. But in the Europe,
this game, released for MS-DOS,
Amiga and Atari ST, was rebranded
as Dyna Blaster. And this game contains
a password system. It looks like this. You can input eight letters, selected from the English
26-letter alphabet. If your input is wrong, the input is cleared
and you have to try again. The input method is also quite slow
since you can’t just type, but you have to navigate a cursor
as if this was an arcade game. Let’s study what goes
into the password. The game has 64 levels, divided into 8 areas
each of which has 8 rooms. You can collect a number
of classic powerups, such as more powerful bombs, more bombs,
running ability, remote detonator,
pass-through bombs and so on. If you lose a live, you get to keep the
bomb power level, the number of bombs,
and the running ability, and start from the same level, but everything else
is reset to zero. And these aspects are saved
in the password, too. Back in the 1990s, I was not able to crack
this password system – because it was just too slow
to try different combinations, and I ran out of patience. I tried disassembling
the game too. However, I quickly learned
that something is going on: There does not seem to be
any plausible code anywhere. For the most part, none of
this disassembly makes sense. I mean, obviously the disassembler
is going to output something, because almost all bytes map
into some CPU instructions, but this can not be
the real program code. So I ran UNP on the binary. UNP is an excellent tool
written by Ben Castricum, which is capable of decompressing
most DOS EXE files – compressed using compressors
written before 1995. And so is the case here. It detects that the game
is compressed using LZEXE, and successfully decompresses it. And now if I disassemble
the binary, I can actually find code
that makes sense. If you work with
assembler code, you will quickly learn to
recognize code that makes sense – and tell it apart from
disassembly of random data. Now because EXE files
are relocatable code, the next step would be
to use a disassembler – that can actually reconstruct
the code segments – and separate them from data. For this purpose,
I did some searching, and ended up downloading
a program called Semblance. Back in the DOS days
I used something else, but I no longer have that tool, and the open-source and cross-platform
program called Semblance – will do just fine for this purpose. When I run it on the decompressed
Dynablaster EXE file, it produces an assembler listing,
which I can open in a text editor. However, finding the password code
in it is not that simple. It’s not like I can just
search for “password” in it. I mean, I can figure out something. For example, this code seems to be
updating the VGA palette. It outputs bytes into I/O ports,
and port number 3C9 – happens to be the VGA graphics
card’s DAC data register. This stuff was the bread and butter
of graphics programming in the 1990s, so I can easily recognize it on sight. But to find code that deals
with password is not that easy. Back in 1990s, this is
where I got stuck. But now, almost
25 years later, the story does not
have to end here. I have different tools
in my toolbox now. I was already running
this game in DOSBox, which is an emulator
for the PC, but I need a version of DOSBox
that has the debugger built in. I am using Debian GNU/Linux, and the debug-enabled DOSBox can be
installed with a single command. And now when I run it, there is a debugger window
behind the emulator window. I will hit Ctrl-F1 to study the
keyboard mapper of DOSBox. I select the debugger option, and I notice the key mapping
for debugger is mod2, which is alt, plus pause. Alright, moving on. Click exit to exit the key-mapper
and resume the emulator. Now the game is running. Let’s enter the password screen,
and enter a simple password, BBBBBBBB. I am going to wait
until the music stops, so that the music will not interfere
with what I am going to do. Now I am going to hit alt+pause
to enter the debugger. Watch the data segment value, DS. I will do this several times. F5 to resume the game. Alt+pause, F5, alt+pause, F5,
alt+pause, F5, alt+pause, F5. The value of DS
seems to stay the same. If the music player was still active, the DS value would vary
between different breakpoints, but now, the password engine is the
only part of the game running, so the data segment
stays the same: B07. This is the primary data segment – that the game focuses on
while on the password screen. On the screen it says “type help”
to get an overview of all commands. Here it says use home/end buttons to scroll. What I want to do is write the
data segment contents into a file. I will call this file A.TXT. Then let’s resume the game
and make some changes. Replace the password
with ABCDEFGH, and enter the
debugger again. Do a second memory dump. And compare these two dumps. Sure there are still plenty of irrelevant
differences between these two, but look here! The first one has eight
62s in the row, while the second has
eight successive values: 61-62-63-64-65-66-67-68. Just like the password
that I inputted. This is where the game stores
the password you are inputting! It begins at address 32B5. There were also other differences. Offscreen, using this
same exact process, I identified the addresses – for the selector cursor
X and Y positions – and for the password
character position. Now let’s get back to
the assembler listing. Search for the address,
32B5. Alright. This first piece seems to copy
eight bytes into the password – from some unidentified RAM address. Let’s ignore that for now. This next part takes the
password buffer address, adds the password cursor position, and places a byte into
the resulting address. In other words, it changes a character
in the password. This seems to be part of
the password user interface. Let’s go up a bit. Okay here it seems to be comparing
the selector cursor position. If the Y coordinate is
different from 2, it reaches this spot… And if the Y coordinate was 2, then it checks if the
X coordinate is 8, 7, or 6. These must be the ←, →, and
“END” symbols respectively. If the X coordinate was
none of these, it continues with the
character input. Okay so let’s jump to where it gets
if the X coordinate was 8. That is 28C8. And that jumps to 29E7. This must be the part that
validates the password! Okay. First it checks if
the password is blank, that is it consists
of eight spaces. If it was blank, it does this. Otherwise it continues from here… Now it copies the 8-character buffer
into a different address, 30E5. Then it calls another function. If the return value of
that function is nonzero, it wipes out the password by
writing eight blanks into it. So I guess that’s the failure,
and the other branch is for the success. Let’s check out the function that
it uses for the validation, which is at 0E26. It sets the source index as 30E5,
which is the copy of the password, and destination index as 2117. It’s building something in 2117. Then it loads a character
from the password copy, and calls some function. Again, the return value is checked. This time, if the
return value is negative, it bails out and
continues otherwise. Let’s see what that
function does, at 0F72. Alright. So it takes the two lowest bits of BX
and multiplies that by 16. Then it initializes the counter
register with value 16, and performs some kind of loop. In that loop, it adds 20CF to
the value of BX, loads a character,
and compares that – to the character that
was supplied as a parameter. Hmm. I wonder what’s
in that address, 20CF. Let’s check the commands
in dosbox again. I want to adjust the memory
view window over here, and the command to do that is – “D” followed by the
segment, colon, offset. The segment is the data segment
as before, B07. The offset in question was 20CF. Hmm, that is weird. It seems to contain four
sixteen-character strings. Okay, so it searches
the character – in one of these
sixteen-character tables, and returns the index
where it was found. If the character was not found,
it returns −1. This function is called twice. With the first character,
and the second character. The two return values are merged
into a single byte at address 2117. This process is repeated four times, until all eight characters
have been converted – and packed into four bytes. So far so good. It seems it is our good friend
the substitution cipher, except that the cipher
is different for each byte. [Ominous jingle] This data is then packed
into four bytes. These four bytes could be thought
as a 32-bit integer, or as a doubleword. Then it loads the first byte, and takes the top three bits
from that byte. If the top bit is nonzero, it inverts byte 3 of the password. Then the next bit is checked
and the byte index is decremented. This process is repeated three times,
for each of the top three bytes. Then it loads the first byte again, and checks that the middle two bits
are one and zero respectively. If they are not,
the password is rejected. Finally the lowest three bits are taken. This value is passed to
some function at 0F49. That function loops
and rotates bits… If you are an experienced
assembler programmer, by now you are already screaming
that this is horrible code. It is as if it was
produced by a compiler – that does absolutely no
optimizations whatsoever. Which is probably not far off, considering that the whole game,
Bomberman, was originally just a demo for
Hudson Soft’s BASIC compiler. I mean look at this. On the left side is the
code from Dynablaster. On the right side is my hand-written
copy of that same function. Both of these routines
do the same thing. And the whole game is like this. Anyway, when we carry out the
code analysis to its end, this is what we get. First, this is the
encryption code we just saw. The three lowest bits of first byte
specify a shift count, and the other three bytes are rotated
right by that number of bits. Zeros are shifted in
from the left side, and bits from the right side
are discarded. Then, data is extracted from
the resulting doubleword. I know, this graph
looks like a mess, so let’s break it down. Six data items are extracted
from the password: The two-digit level number,
the number of bombs, the explosion length, a flag that indicates
the running powerup, and a hamming weight of
everything else combined. Hamming weight is also
called a population count, or the number of one-bits. The data item bits are not stored
sequentially in the password, but they are all over the place. The hamming weight, or number of bits,
is particularly interesting. When the password is encoded, the game puts to this field
the number of bits – that were set in all
the other five operands. But when decoding,
the issue is different. Remember the rotation? When the password is encoded,
the bits are shifted left, and when the password is decoded,
the bits are shifted right. Because they are shifted,
not rotated, the upper bits of the password
will become permanently lost, and replaced with zeros. And look what’s in
the upper bits. There is all kinds of
vital information there. During playtesting, sub programmer Yuuji Muroya
likely noticed – that the generated passwords are
not actually decoding properly. [ Genuine heavy rain sounds in the background ] Data is getting lost. Rather than fixing the design
problem in the password, he settled on a workaround: Instead of generating rotation
counts between 0 and 7, he only generates them
between 0 and 1. This way, the only bit that
gets potentially lost – is this one bit in the
hamming weight variable. But now he ran into
a second problem: The hamming weight,
read from the password, does not actually match the number
of bits set in the password. He solved this problem by not
verifying the exact bit count, but that the saved bitcount
is less than sixteen. In other words, he only checks – that the most significant bit
of the hamming weight is zero. The rest of the bits
are essentially unused. I mean, there were actual
unused bits in the password. They are the upper
two bits of byte 1. The game always generates
these two bits as zero. Maybe he originally intended – these bits as a safe buffer
against the bitshifting, but he made a mistake. And because of his mistake, there are now many more meaningless
bits in the password. Now the data items in this
password are fairly simple. The level numbers are in 1—8 range. The password fails to match
if something else is given. All the other values can
use the full range. However, the maximum number
of bombs is actually eight. Any value that is outside
1—8 range just means eight. Related to the bomb count,
I actually found a bug in the game. Likely this is already
very well known, but I thought it’s
worth mentioning anyway. Once you acquire
the remote detonator, and you fire the detonator while an
explosion is already occurring, you can place as many additional
bombs as you want – even if you have just one bomb, and the bomb limit will be permanently
maximized until the end of the room. The maximum being eight, that is. Now here is the password converter
I wrote for this game. It handles all the
special cases correctly – and reports whether the
password is authentic or not. You can download it through the
link in the video description – if you like to study it. I also created a list of English-language
passwords in this game. Surprisingly there
are not that many. All of them are fake, in that the game will
never generate them, but it will accept them. Well, all except the last eight, which are somewhat questionable
compound words, that I included – to get at least some non-fake
passwords on the list. [ Ominous jingle ] In any case, these passwords work
not only in the DOS version, but also on the other
ports of the game, such as on the Amiga. And look at that,
we happen to have one here, thanks to my colleague
Toni Rosendahl. — … — Toni, if you would be so kind. — Okay, of course. So let’s take a look
at the game on Amiga. [ Loud joystick click sound ] [ Chair creaking ] — So it’s loading
from a USB stick, but it’s simulating a floppy disk
or something? — Yeah, it’s like a floppy disk; it emulates it, and the speed
is pretty much the same. [ Amiga game music ] … which should be … – Yeah, “MOONLESS” please. – Okay, let’s try. [ Joystick clicks ] – Entering the alphabets using the joystick
is a little bit difficult, but… “MOONLESS”, end.
Let’s see what happens. — Okay, it seems to have
accepted the password. Loading… — Let’s see what happens. — I don’t believe anyone has ever
entered this password before. — Stage 3—3. Good! — And it works, as you can see. I am Bisqwit. The next time — I haven’t actually decided yet – which game is going to be
the topic of the next episode! Maybe you have good ideas? In any case, have a nice day,
and see you next time! Bye! — Bye!

84 thoughts on “Dyna Blaster ※ reverse engineering on DOS ※ Cracking VG Passwords S2e3

  1. First! (Placeholder comment reserved for announcements.)
    Note: In the latter parts of the narration there are some noises on the background, which head-phone users will identify as rain. That is correct. It was raining very heavily while I recorded those lines — and the raindrops hitting the aluminium window sill produced loud sounds, which were picked up even by the directional microphone — and I decided to keep it. Many a car got damaged on the flooding roads that day.

  2. Love this series. Cracking video game password systems is one of the perfect examples for edutainment of reversing asm algorithms/encryptions, in my opinion.
    Take care

  3. Hello from India , Now How on earth did I just understand all of what u just sed . I just took one semester of assembly class at my college 😅 . The video so so so good . Make more of it .

  4. Great video! The game "The Incredibles" on the Gameboy Advance also has a password system, so perhaps it would be interesting how reverse engineering a GBA rom would be? Cheers!

  5. Hello Bisqwit. I would like to talk about unused bits. This game is a port with TurboGrafx-16. The console version has a checksum, which checks the correctness of the entered password. Checksum is not in the DOS version, so there are many bits that do nothing. In the console version, significant bits are not lost due to randomization. Also in the DOS version, you can create a password with 0 bombs, which cannot be done in the TurboGrafx-16 version.

  6. You should try this, it's made for you : https://www.pwnadventure.com/
    You can get more info from this guy : https://youtu.be/RDZnlcnmPUA

  7. It was fun to see a DOS one. I've done some 6502 and Z80 work in the past, but DOS and x86 disassembly is where most of my nostalgia is. I took apart Legend of the Red Dragon once, for example, which is my favorite BBS door game.

  8. By the amount of time and efforts I see you are putting needs to be worthy, like atleast 70-80k viewers on average (minimum)… I'm curious as to, if you have so much interest and grind capability why don't you apply for a game making company or platform or start your own (if you think big) or anything where your skills would be comparatively useful, Very curious. There has to be some big corporation up to hire you. I feel sad about the amount of views you get even after doing sooooo much. At the same time I can't be a very helpful patron.

  9. Do you know of any good decompiler gor 16 bit programs (what did people use in the DOS days, was there something else then Hackers View) was there something for DOS like IDA is for windows now?

  10. I think the reason why it's called "Dyna Blaster" was that they didn't want to call it "Bomberman" in Europe (I don't remember why, terrorism probably). Dyna Blaster was the second name change. The first was to "Eric and the Floaters", which is obviously not a good name.

  11. Please, please, please…tell me what kind of books I need to learn Reverse engineering?
    Asm still is used to reverse engineering? Or today exist others tools and methods?

  12. One year ago im discover this channel and today can i say "Bisqwit is my favorite channel on all youtube" i really enjoy any of ur vídeos, thank you. Greetings from México.

  13. I like how you took care of explaining step by step the process of reverse engineering. Kudos you for having the patience.
    So, we'll not going to see more scheme code in the future? Didn't you fall in love with functional programming?

  14. You are a great, great programmer with a huge amount of knowledge and I love this series and your c++ programming videos (considering it's the only language I've thoroughly studied). Also what's the music in the background that starts at around 4:33?

  15. Huge fan of your videos! I am wondering if you are aware of the new findings in Mike Tyson's Punch out that have recently led to a new world record. The researchers on this haven't fully figured out the RNG in MTPO but are making progress. I thought this might interest you so I thought I'd link it here:

    https://docs.google.com/document/d/1haVqEMyMtdr-zXUzGHcERdyJAXHC00O8hAodKA7n-5I/mobilebasic

    I know you are busy but any help you can give them may transform the game as we know it. Keep up the great work on your videos

  16. Love this series of episodes, truly. As a programmer who grew up with ASM and C back in the "let's see how much we can pack in to 1k of memory" days, seeing what they came up with, as far as algorithms / encryption inside a game for the sheer purpose of extending play-time, truly amazes me. Not to mention, your methods of breaking it down are just gold to the ears.

    Keep it up, good sir. You're an inspiration to us all. Hopefully the new coders (if you can call them that) these days will latch on to this kind of knowledge as well.

  17. I really enjoy you using different programming languages for your encoder/decoder through the episodes. It's just a minor detail but it adds a lot to these videos.

  18. Clearly after a few difficult ones, you went for something easier, and that's fine.

    Was actually kind of interesting to me because I didn't know that PC games of the era would even use passwords – I guess I'm just so used to most of the games of that era that I'm familiar with having save files, but given the nature of the game and the minimal number of things it needs to encode, a password makes sense.

    Now what I'm wondering, as a long-time viewer of your stuff (and especially the Cracking VG Passwords series), is how the hell is this game's password somehow less complex than NES Bomberman!? Guess keeping that score, subtotal, and grand total was totally worth the extra password length…

  19. I learned something, today. I learned that the MS-DOS version of this game uses Creative Music Format for its soundtrack, and I learned that several songs are nowhere to be found, including my personal favorite, Round 3. 'cause, I ripped the soundtrack, myself, after watching this. Cheers, Bisqwit!

  20. This series is one of my favourites of yours. These videos are always very interesting deep-dives into often unusual programming practices and errors, while still being relatively accessible for those less experienced in these tasks.

    If you fancy an obscure SNES game for this series, Mohawk & Headphone Jack might be interesting—that game is something of a programming marvel. It has a TCRF article that lists some "joke" passwords, as a potential starting point. While the game's only speedrunner was given a copy of the source code by the game's developer (D.Scott Williamson), I don't think it's ever been leaked onto the public internet.

  21. The older Bisqwit get's the more he is morphing from the archetype of an obscure nerd into Scandinavian handsome masculinity. No homo yo.

  22. [16:08] Ow, please be wary about the high-frequency noise in your audio track coming from the CRT monitor, it made listening to that segment somewhat uncomfortable.

  23. Inspiring as always! This is the kind of wizardry I had wished I understood when I was In my teens. I wanted to thank you again for all your hard work and going over the process in detail so we viewers can follow. I especially like how you show the tracing of some code and commenting in your disassembly as you go along. It helps me as a viewer follow along, and also showed me how I can comment better when I am doing a disassembly.

  24. Are you still driving a coach? Your videos are of top notch quality, and shows the fruits of years of hard work, and thank you for sharing it us.

  25. That is quite the process.
    Most of it was unfamiliar to me until I saw you messing around with a debugger and that suddenly reminded me of stuff I've actually done in the past. XD

    To be fair, I've never tried messing with existing games on this level.
    The closest I've ever gotten is doing Birth of the Federation mods.
    Since all the game data is in binary files, it involves making changes in a hex editor.
    I did do some investigation of my own, trying to work out additional things that could be modified, but someone else had already documented basic things pretty well.
    Still, changing ship parameters by tweaking values in a binary file is already pretty complex as far as modding goes.
    Come to think of it, most of the games I've ever tried to mod have been star trek ones. XD
    The other thing I did was mess around with the python scripts behind Bridge Commander.
    – possibly one of the most moddable games I've ever come across, and perhaps the only reason I know any python coding.

  26. Wow, I never saw the actual process of reverse engineering before. This was such an educational video. Thanks for posting Bisqwit.

  27. This might be off-topic, but I am curious as to when you're going to post videos about theology again. I would be honoured to discuss the history of Christianity, the Church Fathers, the Roman Catholic perspective on the authority of the Church and what it is, the Eucharist, the Most Holy Trinity, praying for the dead and to the saint, venerating the Mother of God Mary, the Pope etc.

    May Almighty God, Jesus Christ, bless and keep you always, and may you be consecrated to the Immaculate Heart of the Holy Mother of God, Ever Virgin Mary. Virgo potens, ora pro nobis! Amen. +++

  28. It is all fun and games up to 12:17. How do you know the information described in the 'Data Content' portion of the video? That seems like some incredibly hard things to find out just by looking at the code.

  29. You may want to check out r2 (radare), if you plan on doing disassembling in future. It probably will save you some time. I mostly use r2, gdb and some tools of my own https://github.com/Cloudef/memutils

Leave a Reply

Your email address will not be published. Required fields are marked *