Two's Complement - Reverse Engineering the 6502

Episode Date: March 2, 2021

Ben and Matt stop talking about testing, and everyone is relieved. Matt describes the process for reverse engineering microchips by stripping off layers of silicon to look at the transistors with a microscope. With this forbidden knowledge, he explains how to defeat the copy protection on a childhood video game. Ben pretends like he understands.

Hey Ben. Hi Matt. How you doing buddy? I'm doing pretty good. It's been a while. We've been talking a lot about testing recently so what do you think to mix it up a little bit? Yeah, we should not talk about testing today. I mean, we are quickly becoming all test, all the time podcast, which wasn't really the original intention of this podcast, although an important... No, it's mostly my fault. Well, I mean, it's kind of your thing, right? You're the test person. Yes.

Or a test person. I'm very testy. You're very testing at times. No, never testing, never testing. And when we were discussing this podcast initially, you and I were thinking, the thing that we would like to do is bring along audiences that would by default follow us for the kind of things we're known for, and then show them something different you know get some people on that can talk about something that maybe they aren't in as as familiar with or um just dig into something that's just interesting to us right

i mean that's that was the idea and then we started talking about testing and we carried on to keep talking about testing because there's just so much to talk about and it's really not very well understood and not very well implemented and you know you and i've seen a lot of it done well and a lot of it done not so well so let's talk about something else yeah i want to hear about the uh chip reverse engineering stuff that you've been looking at for oh i don't know probably quite a while now, right? Well, yeah. One of my hobbies has led me down a very strange path. And so I grew up in the late 80s, early 90s with a particular computer from Britain.

And for whatever reason, I've ended up taking a trip down memory lane and writing an emulator for that computer and the thing about writing an emulator is it's an amazing way of understanding fundamentally what a computer is and how a computer works and how the peripherals work and if if for example you don't have an instinctive understanding of that, or if you've never actually written an interrupt handler, and frankly, who has, or that level of things, but you're interested in that side of computing, like how they actually work,

you can go a lot far worse than writing an emulator. It's a great way of giving you that exposure while in the familiar warm embrace of a modern IDE and sort of debuggers and all the things that come along nowadays. And in particular, the emulator that I wrote for the BBC Micro, which was a computer in my school when I was 10, 11, the emulator that I wrote, I chose to write it in JavaScript, which is not noted as a systems programming language. I think it's fair to say. Yeah, it does have that reputation as not a systems language. Right. But what it is, is universal. And more importantly,

you can put it in a website and then you can play your video games from your childhood in your web browser. and what's not to like about that right right but the thing about emulation is that there is a kind of a period at the beginning when you're writing a bunch of code and you're kind of doing it blind you're just kind of taking it on faith pretty much that you're emulating this particular facet of the cpu and you've got a big table of these things right there's a huge list in your lap um of the the the op codes the cpu runs and you're like going through them one by one or you're hopefully coming up with some level of abstraction to make it a bit easier and then you're writing peripherals and bits and pieces like that and

there's this one joyous moment when for the very very first time, you load up a ROM and you execute it, and something recognizably associated with what you're emulating happens. Something game-like happens. Yes. In the case of this computer, when you first turn it on, there's a sort of very familiar to certainly people of my age and from Britain sound that comes out. And then a particular sort of text comes up like you think of a dos mode black screen with just ascii text on the screen saying bbc computer 32k acorn moss basic and then a prompt and then you know that's it right now because the hardware at least for this particular default video mode is essentially ascii mapped that meant that all i could do is i could plumb a routine in JavaScript that just runs

through the memory area associated with the screen and dump it out to console.log and so I was able to see BBC Computer and all that stuff appear in the console before I had anything else gone. So it's a marvellous, marvellous thing to do and it's so rewarding

and as you add more bits and pieces you get more functionality. Eventually you get bitmap graphics and then then you can get the joy that you mentioned which is playing games and that's fun that's super fun but what you've kind of start doing is realizing that the the manuals that you've got or the memory of how computers work you've got or the memory of of how computers work you've got is incomplete and wrong and some of the video games of yesteryear maybe less so today with with more uh random hardware available but you know back in the day video games programmers would discover weird things that the graphics chips did or the cpu did or the interrupt system did and they would incorporate that into their game or they would incorporate it into the copy protection for their game so that it was really really hard for you to either copy or hack or they got extra performance because they were relying on some extra weird

thing but of course everyone had the same physical hardware so they could genuinely rely on these kinds of things but you didn't know that as an emulator writer. Right. So you just emulate it like it says in the 6502 manual. It says, yeah, well, this thing, this sequence of bytes is meaningless. It's not used. And so you don't do anything with it.

And then you discover games and you've hit your debug trap that says, no, no, some game used that opcode and you're like what yeah you know the first time i hit this it was i think it was the first time i hit it was in a game called repton which is like a boulder dash kind of game and as part of the code it actually jumps to an ascii string right it starts interpreting an ascii string as bytes now as it happens it's that doesn't have any meaningful side effect but there are all these undefined opcodes in there doesn't do anything and eventually it falls

through into the real code and carries on whether that was intentional whether that was a mistake i don't know but it was like a first wake-up call to like hey well it doesn't like stop these computers didn't have the facility to like throw an illegal instruction exception at the hardware level or anything like they just plowed on yeah and of course it's all, exception at the hardware level, or anything like that, they just plowed on. Yeah. And of course, it's all logic gates at the end of the day. And so those bit patterns still meant something to the hardware, and it did something.

And so the game designers would discover that, hey, if I use this opcode, it's the store instruction, but with one bit different. Now, normally there's there's the store a the a register store x store the x register store y the y register and then in the fourth if you were literally just looking down the list of opcodes there was like no don't use that one and then it went on to the next instruction yeah and of course you know you're thinking to yourself wait a minute if any normal human being who was designing this would see that essentially the only thing that was changing from one instruction to the next are the bottom two bits you know in the store a it's o o store x it's o 1 1 o and then 1 1 you're like well what the heck is this doing and so it turns out that through whatever means

people realize that what's happening at that point is it's storing a and did with the x register and now i have literally no idea why that would be useful in a game context maybe for masking actually now i think about it i can't believe i've never thought this before but if you had like a sprite mask in the x register you've saved yourself an op code right you don't have to and with the a register and then store the a register use this this sax command which isn't again it's not an official thing but it just comes out because that's the way the hardware physically works yeah and so you start finding out more and more of these things you start realizing that the systems are not as well understood as the manuals would have you believe they're not as well as

understood understood even as the designers of the original hardware necessarily understood them and so to sort of give some context to this when i was about 14 15 a good friend of mine of mine and i were trying to take a game that was stored on cassette tape back in the day when that was a thing you know you plug in a cassette tape into the the port on the back of your computer and the beeps and boops were like really low um modem speed sounds and then it would eventually load it would take you know four or five minutes and it would load but we had disc drives right we were lucky that we had disc drives we wanted to take the game that we had on tape and put it on to disc but that meant hacking it yeah now whether we actually legally owned the cassette tape that we were hacking it from is one for the pub although in fairness i have now met and spoken to the the author and

i've kind of made my peace with him over this particular um thing but anyway this was a particularly um interesting hardware protection that was put on the cassette tape version so effectively the code was was loading the beeps and boops from the the cassette tape and then it would jump to the beginning of the uh the code now i could write a piece of code that listens to the beeps and boops and gets this big block of of uh of code and then i could probably just save it to the disc and then just run it but that it didn't work and i forget for the reasons and my friend rich who maybe listened to this will perhaps remember why but that wasn't possible what you needed to be able to do is essentially decrypt

and just pull out the bit of the code that you needed for the game now the author didn't want you to copy it the author didn't want you to put it on disk the author didn't want you to look at his code right his his admittedly compiled or assembled code so he would write an encryption routine right at the beginning of where the the program started executing and that decryption routine would decrypt the game that was immediately after the decryption routine so the code literally follows off of the last byte of the loop for all the bytes in the remainder, EOR with FF, worst possible protection system, and then it would fall into the middle of the game.

And there was no point in between those two where you could put a breakpoint or similar. And the reason for that was there were no hardware breakpoints. And the first thing you might want to do is you might want to modify the first byte after the end of the decryption routine to say, no, no, return here. But of course, you don't know what to write there, because it's going to be decrypted. So you have to write the encrypted return. Now, you could probably guess there's only 255 combinations. So you could try all of them. But then if you actually looked at the decrypt routine you see that things that go into the key you know i just said exclusive or with ff but the things

that go into the key that decrypts the rest of the code are the bytes of the decrypted code the bytes of the decryption routine itself. The decryption routine also modifies itself while it's running. So the key is mutating as it's going, and there's nowhere for you to poke in it. To stop you from doing like time-based attacks where you kind of stop it, jump out of there, and then patch up the routine, instrument it in some way,

and then jump back to the beginning of that part of the routine that you patched out, it would use hardware timers. So there were timers that were changing variably as the thing was going on it also would configure interrupts and it wrote its own interrupt handler that deliberately did not like leave the state of the machine alone it came back from the interrupt routine having modified another part of the key so where this interrupt was triggered and all that stuff, all factored into it, which made it basically impossible. So the guy built the Hellraiser cube into a cassette tape.

Effectively, that's exactly what he did. Yes, that's a perfect way of putting it. So Richard and I, back in the mid-90s, we wrote an emulator for the very computer that we were writing an emulator on in the basic routine, basic sort of language of the computer that we had in an attempt to emulate the protection system perfectly or emulate the BBC perfectly such that we could get to a point and then stop it and then save. And we spent a couple of weeks on this and we gave up because it was just so complicated all these things i just described to you were in this code

we'd have to be perfect and they would have to be cycle perfect like literally every tick of the clock all these numbers are changing hardware states changing interrupts are being scheduled or descheduled or cancelled or not cancelled and the whole thing was in there and it was brilliant and we'd like well we can't crack it so we gave up on it but fast forward 30 years oh gosh it really is fast forward several decades and i'm writing an emulator for the same machine but for recreational purposes not for nefarious purposes and i came across this game again and i'm like no this time this time game i'm getting you i'm having you so one of the evil i mean in addition to all the things we just talked about one of the things that this particular protection system does is used a rotate instruction so rotate is like a shift where the top bit goes

back into the bottom part so you know bit seven goes off and comes back into bit zero and if you think um and this particular rotate instruction was a rotate a memory address which was unusual on the 6502 normally you'd have to load something into a register do something with it and then store it back but in this particular case you could rotate directly a memory address so if you think about what's happening inside that instruction it's going to take several cpu cycles it's going to have to read from that memory location it's going to have to do something and it's going to write it back out again and this is all within a single instruction now what kevin's protection system did is it actually rotated the address of a hardware timer so the hardware this is a piece of hardware that

pretended to be memory but actually was was not memory it was a counting timer and it was it was configured on the system such that reading would give you the current value of the timer writing would reset the timer and start it again from that value or you know something equivalent to that so that's interesting now suddenly in order to mod to emulate this instruction perfectly i have to emulate within the instruction because as the instruction is executing, that timer is ticking down. So does it read from the timer on the third cycle or the fourth cycle? Does it write to the timer on the fifth cycle or the seventh cycle? Or what's going on?

And so now you're assigned to answer, this was never put in any of the data sheets to my knowledge, right? This is just like, no, a rotate takes seven cycles. So how do you answer these questions right i didn't unfortunately i didn't have a 6502 well i did but it wasn't in the bbc micro um it was in a on a breadboard in front of me right here but um how do you answer these questions and so this is when i went digging and I discovered a whole world of folks who are taking chips, decapping them. That is taking the protective plastic or ceramic layer off of the top of the chip using extremely distressing chemicals to etch away at the plastic. Yeah, yeah, yeah. Really horrible, horrible stuff. I mean, there's terror stories

out there for what happens if you don't if you don't look after yourself so please if anyone's listening to this do not attempt any of these things do not try this at home kids do not try exactly but these people are doing this and then they're using high resolution metallurgical microscopes to take lots and lots and lots of extremely close-up photographs of the dye that is the actual integrated circuit that's underneath the plastic like chip that you would see if you saw a you know computer chip right right and then they're stitching those images together and then using a combination of just brute force of human uh like line drawing a bit of very primitive ai and then a lot of head scratching they are piecing together how these old chips worked and what i'm talking about here is specifically enthusiasts that are doing this as opposed to like the professional laboratories

that will do this for like um reverse engineering of competitors project type things which is definitely not in the scope of what i want to talk about but these are like folks who are just more um uh what's the word more relaxed around scary chemicals than most people who are interested in this kind of stuff and and in particular 6502 because it was such an important processor they they they targeted that first so there's a website you can go to visual 6502.org which shows you the high resolution photographs and the polygonal data that they've extracted from those high definition photographs showing the different layers of the chip and like these these chips are old enough that the manufacturing

process a is visible under a you know high quality but affordable um light microscope rather than anything kind of scanning tunneling electron nonsense but also that there are so there are few enough layers that it's practical for you to extract the layers one by one by like washing it in another and counting to 10 and then quickly washing off the solution and then looking at it again and like taking off these layers you know there's a metal layer at the top and then there's various level layers of polysilicon and there's various doped regions which sometimes you can see because they look a bit different other times you just have to infer that they're there but the the whole

premises that they have now a gate level like i was going to say transistor level really it was what it is it's a transistor level simulation of a 6502 that you can go and run in a web browser and they've moreover you know as well as just emulating it and all the pads that is the big connections that come off around the outside of the chip there's been enough work that they can tag areas of the die and say well this is the a register right these these flip-flops hold the a register this is the x register here's all the other internal state here's how the pll works here's how the um the the instruction decode works so with this information they were able to explain comprehensively things like how the store ax uh instruction works you know that sax that we found yeah

they could trace the two low bits that we i was talking about before the o o the o one and say well what happens when the one on the ones on well this just activates the a register and the x register at the same time now because of the way the physics works, and this is in a particular case of the 6502, it's an NMOS type of part, the sort of pulling low of a zero wins out. So if there is a one being pushed onto the output bus and a zero being pushed onto the output bus, because both the A register and the X registers kind of like enable has been turned on at the same time then the zero wins because it pulls the one down to zero so that's the and that you're getting that's why it's store a and x if you put them both on at the same time now different fabrication would have come up with different other uh uh sort of side effects but that's like one example of like that's what's happening in that particular instruction so i was able to go to their site and do essentially a gate level or a transistor level simulation of the rotate

instruction and see exactly what happens and what cycles the read happens and what cycle the right happens and i was able to discover and this was actually well known before this is i'm not discovering anything new here but the um in between the read and a write there is a one cycle delay while this chip is like thinking it like reads a value into a temporary part of the chip does the rotate the next clock tick and then writes it out but there aren't enough pins on the outside of the 6502 uh 6502 chip itself to sort of say, I don't need to read or write to memory this clock cycle. So it's always reading and writing from whatever the pins are. Okay.

Right. So there are address pins and there are data pins. And there's 16 address pins, eight data pins, and one read not write, which means if it's high, I'm reading, and if it's low, I'm writing. Okay. So in this one in-between step step the chip isn't doing anything but these pins are still on the outside and the ram doesn't know that you're not talking to it or you don't care and so normally

it wouldn't matter right if it's no harm no foul it's like i'm reading or writing to a piece of memory that okay doesn't it doesn't matter or hopefully as long as you're not writing zero to something but it turns out that what's actually happening is it's it has already updated the address pins to sorry it's the address pins remain at the address of where it just read from okay and the data bus still has the old unshifted value on it and it's but it's already told to write so it's going to read read the address got a value 12 out and it and it's but it's already toggled to right so it's done a read read the address got a value 12 out and then while it's doing its rotate the microcode inside it's not even microcode let's not get into that but like the the the design of the chip inside i said well

we might as well toggle to a right ready to go because in a minute we're about to write out whatever we've just we're calculating but of course what's really happening is a write of the old value has happened to the memory location it just read from okay okay so so far no harm no foul doesn't really matter right if you've just read from a memory location you immediately wrote back to it and then now you're going to update it with the shifted value that's not a problem except of course if that hard was was hardware it wasn't memory. Because writing to that address changes the state of the hardware you're writing to. And so this was a really significant find because the timer that is actually on the end of this rotate gets two writes. And each time it resets itself. Now, you are about to write a new value over the top of it.

But what happens if in that one clock cycle the value you wrote to triggered the timer to go off now an interrupt scheduled and so this side affecting right actually was important to model and so that was the first surprise that was like my gosh okay there's this redundant right that happens that's normally no problem but now is is uh is important to model. And it was an important thing in getting this correct. Then there were some other things to do with the way the bus, specifically to the BBC Micro, worked in terms of slowing down.

Did you ever go through the Apple? I know I'm frothing away here, but did you have an Apple II or anything? I had a Commodore 64. Got it. or anything i had a commodore commodore 64 got it do you remember if that had a one megahertz um peripheral bus versus like a faster c main cpu i forget and i know people will be shouting at there yeah no because the i'm aware that the apple had uh like a one megahertz 6502 and the 6502 can go faster than that uh but the peripherals which are all memory maps were all one megahertz 6502 and the 6502 can go faster than that but the peripherals which are all memory maps were all 1 megahertz so they kind of just took the lowest common denominator and said well

run the cpu at the same speed as the the peripherals and then there's no problem and later on there were like aftermarket boards that you could plug into the apple that sort of sped up the cpu and then they detected when it was accessing peripheral memory and they went, whoa, and they slowed the clock cycle down to match. And that's what the BBC Micro did out of the gate. But that exact synchronization, when you imagine you've got something running twice as fast and it can be an even or odd cycle with respect to the 1 MHz. And now also, this is happening every time it accesses these peripherals.

So in that rotate instruction not only is it having a side effect of writing to the uh the one megahertz bus speed peripheral that's the timer that slows the chip down as well because it's like well i read once that slowed me down i wrote once redundantly that slowed me down again and then finally i wrote the actual value that i wanted to write and i got that through And that was also slow down. So finding this out was amazing and a godsend and piqued my interest entirely because staring at a bunch of seemingly hugely cryptic rectangular regions that don't appear to be connected in any way was somehow something the wizards could read and say oh that's an and gate and i'm like what no it isn't it's like you highlighted that one green and that one red why did you do that yeah oh well this one's clearly dope this way because it's an even number of things from the outside that i know that and i'm like what how are you

doing this well this is witchcraft yeah and as it as it happens, you know, the 6502 is, and I'm probably definitely belittling the work that went into it because it was a huge amount of work. But as I've learned a little bit more, the NMOS fabrication technology that was available to them in like the early 70s is easier to understand coming in from the outside. And you can sort of see, oh, that's a really big squiggly bit.

That's probably a resistor um this bit over here is like a power transfer transistor this thing here with like that you can sort of see if you squint but again it's one of those things where i don't know how often you have this experience when something you're being explained makes perfect sense while you're listening to the engaging present presenter i mean that's happening right now but then you're gonna walk away afterwards be like that was really good but i still i don't get it as long as there's not a quiz later i'm completely fine all right no no that's it that's it no it's it's i've had that experience with a whole bunch of folks and so there's a there's a number of people on on on youtube that have like cataloged their reverse engineering of of chips uh there's um robert baruch if that's how you pronounce his name there's a fantastic person um uh ken sheriff

ken sheriff has got a blog and he does probably one or two a month where he tears down uh a an ic or similar from from like prehistory usually you usually like something from the 70s or 80s. Like he's on one bit computers. He's done the 80, 88, 80, 86. And it's just super interesting and exciting. And it's written engagingly. And again, it's like a bit like you can let it flow over you and you just appreciate somebody else understands this

well enough to be able to do it and explain it well enough for you to at least understand how cool it is yeah and so i've really loved that it's been a really fun experience um and so you know obviously it's touched me in terms of my emulation work and then more recently some friends of mine have started looking at a disk drive controller which was something that came alongside the bbc micro to control the disk drive i mean i know on the commodore for example they actually just threw another 6502 inside the disk drive and said well that can just drive the disk and do all of the the magic to understand how to you know shift the the stepper motors in and out and how to

turn on the sense detection and all those kind of bits and pieces how to do the mfm and fm decoding which made it really a an amazing target for like well here's a co-processor if it's not running the disk drive surely we can do something else which is exactly the kind of cool thing that you know we that was done back in the day because again you could guarantee it on the end of a wire i just loaded off disk um i got a spare 6502. Brilliant. Now, the disk controller that my friend took apart is an Intel disk controller. And it's long had this, again, a big list of here's the commands you can run. You're like, well, there's a gap somewhere in this list of commands. I wonder what it does. Right.

But yeah, through decapping it and getting a friend to photograph it and then go over it, they were able to isolate an area which looked like ROM. And so it became clear that it was basically a CPU, an embedded CPU, probably with a very strange opcode list, but they were able to isolate where the ROM was and then using some real tricks of known bytes that were written to the disk drive when you format it, for example, they were able to find regions of the rom that corresponded to that and then theorize and

later on essentially reverse engineer the op codes for this cpu that was the drive controller that lived inside the uh the the the bbc micros uh disk drive. And I mean, that's just amazing. And I love that kind of stuff. It's just so interesting that there's always a layer lower than where you are, right? You can be writing in high-level language and be vaguely aware

you're interacting with an operating system. You could be writing an operating system and you could be using C++ or you could be using C and you'd be thinking like, yeah, I'm laying memory out. i know exactly what i'm doing and then you're like well there's a dma controller that can also read and write to memory or the network card can also read and write to memory and there are interrupts and you know you kind

of think well okay i know where i am with with interrupts okay i've written an interrupt handler i've written games before and i've kind of had to feed the graphics unit by every time it ran out of work i would you know all these cool things and you think i've i'm talking about myself here like i think i've reached the bottom of the stack now yeah i've written an interrupt handler i'm that's it i've we're done now it's like you know when lord kelvin said there's no more physics we're done here but then you go no no no there's there's more you know you can dig down and on intel processors you can go well there's microcode um you know what you put into the processor is Intel processors, you can go, well, there's microcode. You know, what you put into the processor is not even remotely what it actually executes.

You know, oh, really? Well, that's fascinating to me. How do we know? How can we observe it? And there are all these clever tricks. And you kind of start learning down further and further and optimization. And you're like, wow, that's amazing. And then somebody else comes along and blows your mind by saying, you know, you can take the lid off that chip. Yeah, right.

See how it works inside. And like, oh oh my gosh yes it's so cool it's so cool and i've yeah i've really enjoyed the journey and i'm still learning an awful lot about this but it's it's just a lot of fun so how do you think that uh going back to the game that you were you were trying to crack how do you think kevin was his name you said you talked to him kevin evans yes yes oh how did he figure out all these things because if you didn't figure it out for 30 years later by stripping the top off the chips how in the heck did he do it that is a splendid question and one that we thought for a long long time about but my friend rich was able to

theorize how he did it and got him to reply on a forum post that indeed that was the case and through that we've become i wouldn't say buddies but you know we were acquainted now which is great right um they say don't meet your heroes but i've had some great experiences with the people who are writing video games in the the late 80s early 90s probably because they're only a couple of years older than me even right you know it's not like they're that far ahead of me in age terms at least but but yeah so the way that he did it so the way that it actually would i simplified it a little bit a little bit earlier obviously for for the purposes of explanation but what really happened is that the code ran the decrypt code ran and it landed not in the game but in a crc check and that crc checks checked the crc of the decoded game and if it didn't match the expected known plain text crc it jumped to the rom routine that wiped

all memory and reset the computer okay so there was still no way you couldn't go in and say, oh, let's take out the jump to the reset and kind of get in there. Because again, the CRC code itself, that is the bytes that implemented the CRC were part of the key. So by modifying it to say, hey, don't do that, you would destroy the key and it wouldn't decrypt correctly and all that stuff right so essentially any minor perturbation to the code anywhere would either crash it or it would get to the end of the decode routine the crc check would fail and it would wipe the memory of the computer and it would have to start again loading off tape for another four or five minutes of your life right and so richard theorized that kevin had desoldered the rom on his motherboard and replaced it with a rom that did not wipe memory when you jumped to the it failed the CRC routine. Oh. So far, so okay. How do you use that to help, right? Because you run it, and if the CRC was wrong, well, it would just reset the computer, but the memory would be okay still.

Yeah. he was wrong well it would just reset the computer but the memory would be okay still yeah the second thing is to that richard realized is that the way that the cipher worked essentially is cyclical it's like a random number generator style like code uh encryption key generator right dynamic but but cycle cyclical and so it would repeat after a certain amount of time certain number of iterations so what the process was is kevin loaded up this decrypt and crc put the known crc of the unencrypted game into the CRC code, because that's how it should, that's how it knew it got the decode right. And then he put the unencrypted game after it. And then he put in his desoldered ROM with the don't wipe memory, and he executed it once. So what, of course, happened is that the decrypt code ran on the unencrypted game and caused it to change in some totally unpredictable way.

But, critically, the same way every time, and in a way that if you were to continue doing it, it would eventually cycle back to where it started. Oh, okay. So then it would get to the CRc code the crc code would fail and it would reset the machine but keep everything intact kevin would save that image to disk and then he would run it again and then he would run it again and keep running and saving and running and saving every time it reset he knew that he he was another iteration along this is

the idea here it eventually it cycles back around and then you get something. Yeah, okay. And then, yeah, on the last iteration, it would cycle back to the beginning. The CRC check would complete and it would jump into the game. And of course, at that point,

he was locked out. You couldn't do anything, but that's fine because he kept the previous iterations disk image and that was the one that was sent off to be fabricated. Right.

So he himself doesn't understand how his own code works, right? He still doesn't understand't understand i mean he does because we've talked about it but like at the time that he made the um at the time that he made the code all he knew was that it was deterministic and that the it would be um enough repetitions of that decrypt code would eventually cause it to repeat back to where it started from. And I think that's just genius. So it was both, you know,

an incredible piece of engineering in the first point to think of all the things that a hacker would use, timers and counters and, you know, self-modifying code and, you know, all this kind of nonsense to stop them from hacking it. It was understanding enough about the way that this particular type of encryption works that it would cycle and it was at the end of the day de-soldering something off the motherboard of your machine and replacing it

which like nobody thought of it's so cool it's so cool and so interesting and and yeah i'm glad to say that um jsb will run the Alien 8 protection system. And in fact, Kevin gave me permission to make it a test. So we can get back to testing. One of the tests is to actually run all of that that I just described and make sure that it gets to the end and executes the first byte after the CRC code, which incidentally, I don't even have. The rest of that code is like, no, it stops here.

There's not enough for it to be the game. that code is like no it stops here there's not enough for it to be the game so it's just the code but it's so fun it's so cool and there's so much to learn from it and this is again 40 50 45 year old computer now yeah quite a mate not 45 gosh no i'm 45 35 year old computer that's slightly better yeah wow so do you have any experiences like that i mean i mean we've talked that like at uh you know late teens early 20s we our paths diverged yeah no i i was not into hardware at all as a kid i mean i i was very uh very much into uh you know i i learned how computers work mostly to play games because it was not exactly

a straightforward thing back then to, you know. You meant, hymen.sys. Yeah, yeah. Figuring out what the heck was wrong with my sound card and all that sort of stuff.

Oh, gosh. Moving jumpers. Yeah, exactly. That was my first real attraction into it. And so, you know, for me, it was about,

you know, when I was a kid, my dad owned this software company. It's kind of how I got into it and so you know for me it was about you know when i was a kid my my dad owned this software company it's kind of how i got into it um that did audio video processing and so i can't believe i never knew that yeah that's so cool we're gonna have to talk about that well yeah that was it was i mean it was amazing for me as a kid because i got access to you know computers and high-end video cards to do video capture. He had built a system for digital editing. I mean, now you can do it on your phone.

But back in the early 90s, late 80s, it was something unique. Gen lock boards and things that were that kind of nonsense. I remember the time TV shows that we were watching, the music TV shows would be using the same kind of technology that you're talking about to like do their onscreen graphics and city. Yeah. And you had that like in the basement or wherever. Yeah. Let me tell you, I had some really amazing video presentations as a grade schooler when I was a kid, I was just blowing the other kids away. It was kind of unfair actually um but um but yeah so i mean i never really got too much into hardware until very much later in life i mean it was really like 10 years ago and it was like you know arduinos and you know i built this little um like house

temperature environment monitoring system with zigbee radios and um you know stuff like that but it was always just like a hobby thing for me as an adult it's never never something that i really did as a kid i mean i had like little like electronics kits and stuff like that you know make the buzzer go off make the light go off but nothing really serious so you know this is this has been sort of more of a um for something to me later in life early was all about you know software and and to i guess to some extent some of this video hardware but it was all super specialized i never really got down to the bits and bytes it was all about you know if i take this video stream and i blit myself on top of it that sort of stuff right

right but i mean there's it's just so much interesting stuff going on with with with hardware oh yeah i mean outside of the box and that's what i love the most about the both the emulation and the sort of hacking side of the of of that was like you really have to think how how could i achieve what i need maybe not by not using the manuals maybe by using some other observable thing you know just it was just it forced a lot of problem solving which i think ultimately ultimately if you strip away everything about what i love about our job and what i do is a hobby and what i do in my evenings when i'm not doing my hobby hobby um it's problem

solving yeah yeah in a in a sort of constrained doing my hobby hobby, it's problem solving. Yeah, yeah. In a sort of constrained environment as well. I think that's what makes it more interesting. Like if you've got like no real constraint, then you just kind of do the next obvious thing. But if you're like, no, I have a two megahertz, eight bit computer and I want to do ray tracing. You kind of have to pull something magical out to make it work and that's that's kind of it and i was gonna say it's sort of like there's two kinds of people in the world people who watch apollo 13 and are compelled by the story and people who watch apollo 13 and are

like man i really want to figure out how to get that air filter into that square hole right like you're like really like i i wanted exactly how did you figure it out you had the things of the thing um and and yeah that that sort of mentality is kind of unique. And it's super fun when you have those sorts of problems that are like, all right, guys, we have 90 minutes to figure this out. These are the materials you have. It has to fit into this box. Go.

Right. Yeah. And I mean, sort of just to try and sort of give something out that our listeners can play along with rather than just listening to me babble on this kind of nonsense there's things that you mentioned actually like if so if any of this is interesting to people i'm sure you can google and find a lot of this stuff reverse engineering chips um ken sheriff's blog um is great as well i think which is rito.com but you mentioned arduino's you know there's Raspberry Pis, there's Arduinos. And in fact, like the Raspberry Pi very specifically is modeled on the BBCB because the founder of the company was like, I don't have a way to hand to my children the same experience that I had when I was hacking around on my BBC Micro. It was at school.

I had one at home. It has all these vague vague weird ports hanging out the back which is another sort of like relatively unusual thing about the bb you know you could put a ribbon cable on the back of it and then you could like plug it into turtles that drove draw lines on the on the ground or hardware things and magazines would even have like printable stuff i remember having like a uh an eight uh element led um one that you could build and there was inside of it was a like a motion detector

or actually it was a mercury switch. And so it could tell how quickly you were waving it backwards and forwards. And for those listening on the podcast and not looking at me in the video, which is only Ben, I'm wiggling my hand

backwards and forwards like I'm batting a bat. And so it's right. And then it allowed you to like write a message in the air by serializing out and turning on the leds and that was so cool because i was building with a regular computer so anyway that exposure to hardware and the low level and the fact that just hackability was what

inspired the raspberry pi and so i feel like there's a nice warm glow i get from like realizing that now on my desk here as you can vaguely see just had a shot i have a whole bunch of raspberry pi related gear because i'm hacking on this kind of stuff again and it's brilliant and so people can get raspberry pies they can get arduinos the arduino ide in particular is just really really user-friendly yeah it's so you can write an emulator you can um hack around with this hardware and there's just a lot of cool things that people can still do this nowadays even though we it feels as we're staring at these these huge supercomputers in front of us well even the ones that we have in our pockets are supercomputers by anyone's um yardstick these are all there's still an accessible route to playing around with interrupt handlers and assembly and and and just understanding at a deeper level how computers actually really work

yep yeah and it's super fun and i love it when you can kind of solve a problem that you have with some of these devices it's it's really amazing uh and if you can if you know you can get your kids interested too that's a huge promise well for for us that's a big deal right i if you can get them to see that life isn't all minecraft and it isn't all roblox yeah it's there you can do a real thing with a relatively small amount of code and get something interesting happen yeah uh yeah and as i'm saying this my son has just popped his head around the corner and he's looking at me quizzically like no i won't it's like yeah, yeah, right. I missed that part. Well, redstone is the gateway drug.

So if your kids are into Minecraft and they're playing around with redstone, you'd be like, how would you like some real life redstone? Well, that's the funny thing. I did a sort of passive aggressive parenting technique of buying some sort of textbooks on CPU design and on physics and on on i can't remember the other but they were like manga style ones and i left them around the house and then my eldest did pick it up and kind of read enough of the cpu stuff for two things one thing was for him to go hey this is just like redstone which is like the biggest compliment we could get is like well you understand

enough about how redstone works and you were able to see it out of context in like a truth table in a in a admittedly in a manga style but a relatively dry text and then the other thing is he found um how numbering systems work in binary and he said pointing at the thing he goes for signed numbers going like oh i see where you got the name of your podcast now so like the circle is now complete the circle is complete all right my friend well it's been so much fun thank you for letting me froth and talk excitedly at you and i don't know this is fascinating if our listeners or listener however many we've got um found this interesting too if we haven't just alienated everyone then i'd be surprised but

i mean i'm just hoping that the the the enthusiasm which i feel for this subject comes across and some you know at least one person is inspired to go and have a look or hack on some hardware or dig down through the chip layers or read up how their cpu isn't really doing what they're telling it to do it's a deep deep subject but yeah I guess we can talk about other things another time, right? I mean, yeah. Different topics every week.

That's what we should do. I dig it. You reckon? Okay. Yes. It's a deal. My friend. All right.

See you next time. Yep. You've been listening to two's compliment, a programming podcast by Ben Rady and Matt Godbolt. Find the show transcript and notes at twoscompliment.org. Contact us on Twitter at twoscp, that's at T-W-O-S-C-P. Theme music by Inverse Phase, inversephase.com.