We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Reversing the Nintendo 64 CIC

00:00

Formal Metadata

Title
Reversing the Nintendo 64 CIC
Subtitle
Reversing a 20 year old copy protection chip
Title of Series
Part Number
15
Number of Parts
18
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This presentation covers our successful efforts to reverse engineer and clone the Nintendo 64's copy protection chip: the N64 CIC. We describe the processes and techniques we used to finally conquer this chip, nearly 20 years after its introduction. Nintendo's NES, Super NES, and Nintendo 64 used a series of copy protection chips known as CICs. As the consoles grew more sophisticated, so did the chips. While the NES and Super NES CICs have been cracked and cloned, up until recently the Nintendo 64's has remained an elusive target. Our team approached this chip by exposing the die (decapping) and optically imaging it, including its mask ROM. Through visual inspection we determined the CPU core and instruction set, and we were able to extract the program code from the mask ROM. We wrote an emulator on PC and ultimately cloned the chip on a PIC microcontroller.
Projective planeGame theoryReverse engineeringVideo gameGroup actionMultiplication signContent (media)Forcing (mathematics)Nintendo Co. Ltd.Absolute valueEinsteckmodulComputer hardwareBitComputer animation
Video gameMassFamilyGame theoryComputing platformGame controllerQuicksortArithmetic meanPhysical systemBoiling pointMereologySet (mathematics)EinsteckmodulNintendo Co. Ltd.Inheritance (object-oriented programming)Video game consoleBitComputer animation
Nintendo Co. Ltd.Source codeReverse engineeringBlock diagramEinsteckmodulGreatest elementCloningPhysical systemIterationRight angleOffice suiteComputer fileGastropod shellMultiplication signPersonal identification numberInterrupt <Informatik>Game theoryQuicksortGame controllerMereologyDifferent (Kate Ryan album)BitCASE <Informatik>Physical lawMoment (mathematics)RectangleVideo game consoleDigital electronicsProcess (computing)Machine codeRevision controlNegative numberDivisorComputer animation
Nintendo Co. Ltd.Game theoryOptical disc driveNumberQuicksortCopyright infringementEinsteckmodulInformationMereologyGreatest element
Flash memoryEinsteckmodulQuicksortSoftware developerProjective planeNintendo Co. Ltd.Computer hardware
Nintendo Co. Ltd.Goodness of fitProcess (computing)Inheritance (object-oriented programming)Ocean currentSoftware developerVideo game consoleCopyright infringementBitCASE <Informatik>Product (business)WhiteboardFigurate numberDialectSheaf (mathematics)Computer animation
LogikanalysatorQuicksortCASE <Informatik>Computer hardwareShift operatorMachine codePoint (geometry)Streaming mediaNintendo Co. Ltd.1 (number)WhiteboardSet (mathematics)Game theoryLogic
Process (computing)PressureWater vaporBuildingPattern languageMereologyAdditionExecution unitQuicksortLevel (video gaming)LaptopBitNumberScaling (geometry)Slide ruleInformationMultiplication signStandard deviationRight angleSoftware testingSpherical capGraphics tabletTube (container)Field programmable gate arrayMechanism designDistortion (mathematics)Functional (mathematics)Computer animation
LaptopObject (grammar)BitHydraulic motorMultiplication signElectronic mailing listMicroprocessorSerial communicationPhysical systemLevel (video gaming)Sound effectMachine codeArmMedical imagingMathematical analysisInformationDevice driverPoint (geometry)NeuroinformatikState of matterComputer animation
Process (computing)Sound effectNumberTracing (software)Graph coloringBitQuicksortResidual (numerical analysis)Product (business)2 (number)Medical imagingRight angleMultiplication signFirmwareOpticsResultantProjective planeBuffer solutionMereologyACIDMathematicsPoint (geometry)AreaSimulationProcedural programmingMathematical analysisEquivalence relationType theoryGreatest elementData structureBounded variationVortexFigurate numberStandard deviationGame controllerExterior algebraTablet computerDot productSummierbarkeitCore dumpConcentricoutputScaling (geometry)Computer programExact sequenceInformationTerm (mathematics)Materialization (paranormal)Ring (mathematics)
Auditory maskingLiquidReal numberCovering spaceProcess (computing)ResultantBitAngleGradientRight angleBefehlsprozessorCore dumpAreaProduct (business)Multiplication signGame theoryCartesian coordinate systemProjective planeTunisToken ringSlide ruleACIDBlock (periodic table)Bookmark (World Wide Web)IterationAdditionCircleResidual (numerical analysis)CausalityMereologyConcentricPoint (geometry)Level (video gaming)MicrocontrollerComputer architectureCellular automatonQuicksortMedical imagingMachine codeProgram codeFrame problemAnalogyService (economics)Perturbation theoryConnectivity (graph theory)Category of beingMixture modelRaster graphicsSuite (music)Logic gateComputer animation
Type theoryCASE <Informatik>Pairwise comparisonParameter (computer programming)QuicksortAuthorizationSampling (statistics)Medical imagingPoint (geometry)Entire functionBitMassSpacetimeProcess (computing)Maxima and minimaMaskenprogrammierungDifferent (Kate Ryan album)Computer animation
Semiconductor memoryBitPairwise comparisonValidity (statistics)Process (computing)BootingStructural loadMedical imagingVideo game consolePoint (geometry)Run time (program lifecycle phase)Block diagramBefehlsprozessorGroup actionEmulatorHeat transferInformationLine (geometry)LogikanalysatorDisassemblerZoom lensPositional notationLevel (video gaming)CalculationBus (computing)Game theoryRecursionComputer architectureEinsteckmodulData streamDebuggerOpen setMachine codeType theoryNintendo Co. Ltd.SimulationTheory of everythingMultiplication signRight angleReverse engineeringProjective planeAsynchronous Transfer ModeLogicPhase transitionAlgorithmContent (media)Similarity (geometry)File viewerLink (knot theory)Text editorFunctional (mathematics)Radio-frequency identificationIdentifiabilityPower (physics)FreezingSequelMicroprocessorBlock matrixTerm (mathematics)Inheritance (object-oriented programming)Mereology2 (number)Computer animation
Machine codeBitOpcodeResultantDifferent (Kate Ryan album)Physical systemVideo game consoleEinsteckmodulProcess (computing)Line (geometry)Ultraviolet photoelectron spectroscopyDisassemblerInterpreter (computing)Asynchronous Transfer ModeLatent heatFunctional (mathematics)Multiplication signSemiconductor memoryCASE <Informatik>AlgorithmDevice driverAnalogyQuicksortDigitizingData conversionMaskenprogrammierungEmulatorBootingKey (cryptography)Information securityVideo gameNintendo Co. Ltd.Copyright infringementContent (media)Point (geometry)Reverse engineeringScaling (geometry)Digital electronicsRandomizationFrequencyDependent and independent variablesOrder (biology)Game theoryBlogRadio-frequency identificationStructural loadState of matterPower (physics)Source codeWeightMass
CASE <Informatik>Personal identification numberGame controllerTotal S.A.Expert systemOrder (biology)VideoconferencingBooting
VideoconferencingBootingGame theoryDependent and independent variablesAlgorithmNeuroinformatikGame controllerEncryptionCellular automatonComplete metric spaceComputer fileMachine codeWordReverse engineeringElectronic mailing listRun time (program lifecycle phase)Scaling (geometry)CloningWhiteboardComputer animation
Level (video gaming)Rule of inferenceMachine codeFactory (trading post)Open sourceSoftware testingMedical imagingLogicNintendo Co. Ltd.BefehlsprozessorConsistencyBitMicrocontrollerComputer architectureAsynchronous Transfer ModeMikroarchitekturForcing (mathematics)FlagMereologyPoint (geometry)Reverse engineeringRevision controlState of matterAreaCASE <Informatik>Digital electronicsDemo (music)Information securityPower (physics)Spherical capCloningCarry (arithmetic)MathematicsPersonal identification numberWhiteboardMetropolitan area networkLink (knot theory)Control flowComputer animation
WhiteboardWordMachine codeValidity (statistics)MassMedical imagingProgram slicingAuditory maskingBit
Game theoryBootingFirmwareField (computer science)CASE <Informatik>CloningNintendo Co. Ltd.Data conversionBitScatteringFlash memoryAsynchronous Transfer ModeMedical imagingPersonal identification numberSoftware testingLogicResultantComputer animation
Medical imagingoutputLibrary catalogPersonal identification numberWeightRhombusSet (mathematics)NumberCellular automatonMachine codeFunctional (mathematics)Pattern languageDevice driverRight angleGreatest element1 (number)Computer animation
Software testingGame theoryInternetworkingScaling (geometry)Projective planeNintendo Co. Ltd.BootingPlastikkarteSega Enterprises Ltd.BitComputer animation
PolynomialProcess (computing)Point (geometry)BootingMachine codeMoment (mathematics)Order (biology)Asynchronous Transfer ModeMultiplication signBefehlsprozessorVideo gameOpen sourcePhysical systemGame controllerRegular graphGame theoryLinearizationCloningData managementNP-hardMicrocontrollerRight angleVideo game consoleComputer hardwarePlastikkarteFunctional (mathematics)EinsteckmodulNintendo Co. Ltd.Shared memoryHacker (term)BitPersonal identification number
Transcript: English(auto-generated)
Hi everybody, my name is Mike Ryan and we're talking to you today about reverse engineering the Nintendo 64 sick a little bit about us. I
Really like to play video games My name is Marshall and I've had a lot of interest in Nintendo 64 specifically for a long time So it's been really great that these two people have helped me make it happen. I'm just a video game enthusiast
This guy's the PM. He's taking all the credit though Hi, my name is John McMaster, I run silicon prawn org and am a general hardware enthusiast and like working with computer chips Alright, so before we get too into the technical content of what we're talking about today I want to give you guys a little brief history of the video game industry and the
Motivations that and the forces that led to the creation of the sick so back in the early 1980s Atari was a very popular video game company They released some very excellent games I'm sure a lot of you have heard of pong and and Nintendo's original Donkey Kong And everything was going really well for them until around 1983 or so when the market became flooded with just absolute garbage games
I'm sure a lot of people here are familiar with the story of ET a whole bunch of cartridges ended up in a landfill somewhere out in New Mexico A lot of us thought this was an apocryphal story So there was an art project last year that went out and exhumed some of those and it turns out that yes indeed
The landfill was absolutely loaded with trash games And this did not work out well for Atari or for the home video game market You can see it takes a major dive starting around 1983 and then at 1986 The very bottom of the market was everybody had thought the video game industry was dead
Meanwhile Nintendo was having massive success in Japan with their Famicom and they wanted to bring it to the United States Hiroshi Yamauchi the president of Nintendo believed that Atari failed because They allowed anybody and everybody to publish games for their platform. They didn't do any quality control whatsoever
So he believed that there had to be some sort of a technical mitigation for this a technical Means of preventing people from making unauthorized games for the system and it really all boiled down to this So when you went out to the market if you were a kid in the 80s And you bought a Nintendo game and it had this seal on it. You're reasonably sure that you were getting a pretty good game
So the technical means by which Nintendo accomplished this was the sick Now what the sick is is part of a system to basically enforce licensing from Directly from Nintendo. So what happens is It's like you have a sick chip in the console and then one in the game and then they talk to each other
When you start the game, so they're always talking Just constantly so that if anything happens It just resets itself and anyone who has an NES knows they are very very very flaky. This is one of the reasons
Because of the bad cartridge connector it usually wouldn't make good contact and For the Super Nintendo It was pretty much the same story. They just took the same chip. They shrunk it down a little bit problem solved So there's no much difference there. Now there were pirate games for the NES and there's a couple ways that they did this
It was pretty Interesting, I think the the top picture that the picture on the top There is part of the game circuit board and there is no lockout chip instead There is a boost regulator Which is just a circuit that generates very large negative Spiked voltage and it goes and then it instead of talking to the chip
It just punches it in the mouth and then it shuts it up Wow, so it's definitely not kosher it did work Sometimes some of the times it just kills your console Nintendo actually released a console revision that had some inline resistors that that That prevented this and some of these game manufacturers actually sent out
Manuals that said how to open up your console and clip the pin on the sick that enabled it That's how desperate these companies were to make games for the system right because the licensing costs were very Prohibitive you could make money, but you did have to work very hard for it
And on the bottom is a actual clone made by tension Which is actually Atari they just made a shell company so that they could sneakily get away with stuff like this So this is actually a pretty interesting story. I'm some of the people in this room might be familiar with it. So at the time Nintendo
Sorry Atari was attempting to reverse engineer this chip using invasive chip methods so they tried to get inside the die package and Remove the die and then figure out how the chip worked in the meantime Somebody inside Atari decided to go to the copyright office and file a bogus copyright claim to get the source code to
Nintendo's original 10 NES chip and then they produced a perfectly functional clone using this this is pretty illegal and Nintendo sued them for that and Atari ended up having to pay him a whole bunch of money However, the interesting outcome of this lawsuit was that one of the district court judges noted that the reverse engineering process
Assuming Atari had not stolen the code Actually qualifies as a fair use so we've got a pretty rock-solid case here that what we're doing is fair use under copyright law Right, so he was just skipping to Nintendo 64 now. We're done with all that older stuff now They basically took the same system that worked for them on the older stuff and they tweaked it a little bit modernized it just
Slightly just enough for it to be different and then so here's a block diagram of the n64 I'm not going to talk about how it does the game graphics and stuff like that What's inside the yellow rectangle is the protection system? same deal these two chips are talking to each other from the moment you turn the game on till you turn it off always
Talking to each other but instead of being two symmetrical things you know executing a lockstep the PIF is just they rolled it into a Chip that handles all the system bring up and pulling the controllers and the interrupts the resets and all that sort of thing
So here's an actual game cartridge. This is a legitimate one. So the chip on the left is the lockout chip It looks exactly the same. They're made by sharp. It's just The more modern iteration I suppose Now I should say unlike the older Nintendo stuff instead of having very widespread
pirate chips this Pirate game is actually very very very rare If you actually have one of these and you're willing to donate in the name of science We actually really like to see what's inside those There there's a very small number of pirate games made in Hong Kong to have this chip and we have very little
Information about the history of this pirated sick. So again, please let us know if you have any leads on these Continuing our talk about dubious legality This is how you would pirate games Basically it has a bunch of RAM inside this piece on the bottom the top part is the n64 if you're not familiar with it, it reads to the games off CD drives and then
It did not have any sort of way to emulate or copy the lockout chip So what you had to do was in the cartridge slot in the top You would insert a real game and it would connect just the lockout chip. So it would fool it into running Now here are a couple flash cartridges that let you run homebrew and do
sorts of development on modern With modern technology and and really that's what this is all about The sick made sense perhaps 10 years ago 20 years ago when Nintendo actually was making considerable money off these consoles but nowadays we want to be able to do homebrew development and actually use them for interesting purposes and
The sick is just getting in the way of what we consider a very reasonable use of the hardware. So Not only ourselves but earlier projects also started looking into cloning the earlier chips right
And if you were to take that the lid off one of these older production chips We have these swapped around. This is actually the older NES and Super NES lockout chip There had this is basically showing you the existing efforts to clone them Which they have accomplished and we haven't accomplished that for our current development tools for the Nintendo 64
Which is what we're going to do in this talk. So that's what this talk is about I'm not sure if we actually explained that in the beginning Good job presenting team. Yes so Unlike the older Nintendo's where they had one lockout chip or you know, like six or seven years
Nintendo got a little bit smarter and throughout the lifespan of the console They would periodically introduce new lockout chips just to stay ahead of the pirates by a few months So they'd have to you know, figure the new secrets out. So there are six variants per regions and then they're NTSC which is America's Japan and some other things and then the rest of the world basically
So it made things it made it much harder and more difficult to pirate There were some special cases like this is a arcade boards it's a jam aboard that plugs into an arcade cabinet has a Nintendo chipset and They just have the the game plugs into some sort of custom connector just two different, you know a special case
Lockout chip and yeah this this even the arcade hardware had the same exact lockout chip It's labeled as a 5101 but it's actually running identical code to the 6101 NTSC chip So at this point we know what the chip does we don't know how it does it if you were to look at what the chip
Does physically loaf with the logic analyzer or something. You will just see a Stream of zeros and ones and it's completely random You can log it for days and days. It will never repeat. You don't know how it works so what we did is we switched to We started to get to know John McMaster here for a little while and who's working with Andrews on it
Who just gave a talk what they do is they? use very dangerous chemicals and they just Get right in there onto the chip and then to see exactly what's going on. So I'm gonna turn it over to him He's gonna explain exactly the mad science he used to look inside Hey there. So while these guys were cowering behind their laptops and their cubicles
I was out in the trenches getting my hands dirty So let's talk a little bit about what that involves and what we got out of it So Andrew is apparently going to get bored to death by this slide, but we're gonna beat the dead horse a little bit just one slide so the first part of this process for actually getting to the dye and extracting information is to
Actually open up the chip and expose it by removing the epoxy. That's basically blocking access to the chip Unfortunately at the time I was having trouble getting some of the chemicals that I want to use So the very first step for me which is shown on the left is that I actually Distilled the nitric acid that I wanted to use to cap the chip. So once I got that we move over to the right
Now normally the way that I would do this is maybe with a heat gun and a little small test tube Just to the cap one chip as we'll see later though This process had some issues where I had to kind of play around with a little bit So I've actually decapping a bunch of chips at the same time
Unfortunately, this reaction is very exothermic that is, you know puts off a lot of heat and Actually can explode if you don't monitor it carefully So for here I put it in a water bath And that kind of makes it keeps under control and make sure I don't have to get a new eye or something
the other big problem too is if you notice there's this kind of red gas building up in there and This red gas is actually rather unpleasant to breathe So the second notable part of the setup which is kind of in the background there is there's some tubes that feed it through What's called a scrubber unit that actually makes it so very little of this very red unpleasant gas gets released in this process
Once that done that once that completes you get something that looks like this. I think this is some xylinx Fpga of sorts, but you know the same sort of idea you get this kind of tangled mess of bond wires and silicon The bond wires being the gold wires that connect from the plastic package
You're used to seeing on circuit boards down to the actual silicon die This makes it difficult to clean and makes it very unstable on microscope stages and leads to a number of other problems So we really need a way to rip those suckers off and you know just get the bare die So the first way to do this Which is what a lot of people do is actually just to take tweezers and you know very carefully under a microscope
Pull these guys off one by one and that's what I did initially and you know it works, okay But if you want to do a bunch of these it really doesn't scale well, and it's just kind of a soul-crushing process Maybe soothing for some people, but you also can you know risk scratching the die you know if your tweezers
Slips you can you know gouge it and maybe crack the die in half if you're really sloppy You know just want to avoid that if possible Additionally you know this yanking process is pretty brutal. You'll actually take chunks out of the die sometimes Not necessarily a problem, but it looks kind of ugly so after looking around a little bit I saw that there were a few other methods that people use for stuff like this
one of them is actually take mercury and You know use that to dissolve the gold on the die just like you know the gold miners would you would do Mercury even by my standards. I decided I don't really want to deal that if I don't have to Looked into it and a hot solder seems to work just about as well Not exactly the greatest chemical either, but a little bit better than mercury
So if you look on the left you can see a ball bond on a chip and on the right after applying some solder to This what it's done is it's basically just dissolve the gold wire we have the bond pad which is a little bit Distorted from the ball bonding process, which is a you know kind of high pressure Mechanical process, but otherwise we have basically a perfectly functional bond pad, and it's very clean the way it turns out
So once once we get to this point We've got a bare die and we need to start extracting information from it So I looked into the market for getting a full computer-controlled microscope and unfortunately
It's you know very expensive so what I did instead was kind of hobbled something together from a bunch of pieces collected basically across the US So the microscope body itself came from Craigslist the motor controllers came from the school dumpsters The laptop came from a surplus shop, and you know the list kind of goes on
Everything's kind of hobbled together and somehow it kind of managed to make a working system Basically the way that it works is there's a lamp house which shines light onto the die the objectives You know actually do the magnification and then the motors go through an arm processor that I wrote some very crude But effective C code that goes over to a USB serial interface to the laptop on the lower left corner
that runs some Python as well as a camera driver I wrote for the microscope camera and That's able to you know take pictures from the USB camera and then send commands to the arm processor to issue a step commands to move the stage one bit at a time and
That's how I produce the images that are later used for analysis Okay, so at this point. We were able to get some top metal images of the chip You know the highest layers, but unfortunately for this project that showed not that was not enough We were looking for the ROM which we'll talk about a little bit more later. You know the actual firmware in this device
But we couldn't see it You know we could see some metal traces and a little bit below But we had to go a little bit deeper You know to get the information that we're looking for so basically this process is called d layering and essentially what you're doing is Removing the silicon dioxide and the metal that are on those upper layers silicon oxide silicon dioxide is essentially the supporting material
that holds everything together and The first thing to do is to use a hydrofluoric acid Which you can get through a number of kind of home rust cleaner products. Don't try this at home by the way and And you know use that to dissolve it unfortunately this had a few big problems the first is that it's somewhat uneven
Which I'll talk about later causes some real problems and the second is that it leaves this aluminum fluoride residue And that's going to deposit some gunk on the dye. That's going to cause some other later problems After a little bit of researching looking through some failure analysis books the general recommendation is to use so-called buffered oxide edge
And the idea is that you add Ammonium fluoride, which is you know a buffer that is you know it keeps the pH more constant and therefore You know as the acid kind of gets depleted on some parts of the chip The buffer will help kind of replenish it to the original concentration and keep it a lot more even across the chip even as some
parts start to etch a little bit quicker to begin with and the second part is that I use the vortex er which is basically a glorified mixer and Kind of just shakes it around and goes into seizures and also use a heat gun that's temperature controlled not exactly your standard Home Depot one and
That way everything is very temperature controlled It's kind of sloshing around which keeps everything well mixed and so far that seems to give pretty good results Alright, so now we run into a little bit of a roadblock so if you look at the top what we have is a We call a nor imp a nor active programmed ROM that's off the Motorola
68k that's the microcode and it's very plainly visible basically you can see some squiggles and Essentially you know squiggle means one and no squiggle means zero and that's great because you know after some amount of effort We can use CV or you know manually type it out whatever and recover that into the microcode
on the bottom though we see the sort of equivalent structure off of this CIC chip and We don't really see anything. It's kind of a blank slate There's a little bit of dots here and there, but that's basically just you know Another garbage on the die so at this point. We're a little bit stumped. You know well
What can we do so then it turns out if you look a little bit more through some failure analysis books? You find upon something called dash edge, and there's some other alternatives But this seems to be the most standard and this basically gets you from the image on the left under the microscope To the image on the right under microscope and on the right now We have very clear concise bits that aren't too bad to image so with that in mind
Let's go through this process because although they made it sound pretty easy in the books it turns out It's it's fairly involved to actually get good results So first a little bit of background so basically what we're doing is these semiconductor chips have a positive and negative doping Which is you know what actually makes these transistors work?
They add small impurities like boron or phosphorus to the silicon in very small quantities Now what it turns out we can do is we use hydrofluoric acid Just like we did for d layering to destroy the silicon dioxide we also can use an oxidizer such as nitric acid To actually turn the silicon substrate into silicon dioxide
And if we use both of those at the same time we get a competing reaction Where some of the chemistry is creating silicon dioxide and some of the chemistry is taking it away And it turns out that if you have thin layers of an optical transparent material such as silicon dioxide You actually get thin film interference Just like soapy bubbles you know you see the rainbowy colors
We're talking about you know the same sort of effect here, and so if we do this we actually can create crests and valleys Such as the sim image that some guy named Andrew took I think that is the cool runner too, and you can see some areas a little bit lower and some are a little bit higher
So and of course that also shows up under an optical microscope as well as a sim so once again Basic procedure is you know maybe 10 or 15 minutes of etching. It's actually rather quick Failure analysis books recommend that you put a strong light on it like the lights that are blinding me from the audience members and
Unfortunately I haven't really seen much Changes when I've put a strong light, but that's what people recommend Unfortunately I ran into quite a few snags which we're gonna go through and the last unfortunate point that you'll find is because you Really are etching away the chip if you don't get it right the first time you basically lose the data
So it's definitely good to have you know kind of figure out what you're doing So the first issue you run into is that there's process variation and what that means is that? Some chips are actually made. You know small over time. You know you hear about You know 65 nanometer or you know 22 nanometer chips right you know there's kind of this shrinking over time now
We're dealing at a much larger scale, but it's basically the same idea The other part is that these chip manufacturers will actually vary the chemistry used So for example this you know we generally will call the silicon dioxide. Well. It's not really that simple. You know sometimes
It's thermally grown sometimes. It's been on glass. You know all these sort of variations of essentially what you're trying to get is the same Sort of chemistry and that all defects. You know the way that this is chip is going to etch and give you your final product So fortunately for this chip there are these old sports games which basically nobody loves
You know the favorite sports guy you know for one year, but you know after 10 years You know no one really remembers them And they're dirt cheap on eBay So I was able to get a big pile of these to play with and that was great because it didn't I didn't just Have one try to get it right. You know we can go a few rounds and iterate
So the next issue that you run into is that things need to be very high purity And I think this is one of the issues I ran into using the early You know hardware store chemicals was that they had you know different additives in there that were causing interference The picture to the right for example Talk talking about interference those little circles on the left and the right
I believe those are from Tweezers that grabbed the die and they deposited a very small amount of residue onto the die and that was enough to completely ruin the Reaction on the die and cause lots of problems so part of the process was finding ways You know to develop very high purity basically you know washing a die long instead of picking it up
And just keeping it you know no hands on it. Nothing like that that would cause contamination Another issue I found was I was using the same beakers for doing the decapping as for the hydrofluoric acid etching and The problem is that nitric acid will react with copper very readily Which is you know present as the lead frame and a lot of these chips and
What this does is it creates these copper nitrate? Which then interacts with the hydrofluoric acid to cause a lot of side reactions that will kind of copper plate the die and Basically stop this reaction all together So use dedicated glassware, and you know things started working a lot better
Another issue I ran into is you know kind of the back-alley chip service I don't exactly have you know some sort of high-tech You know temperature or humidity control facility instead. I'm doing this you know in basically in the garage, right? And so why temperature swings you know cold in winter hot in summer? The main component of this dash mixture is acetic acid
You know basically concentrated vinegar and one of the very interesting properties about this liquid is that or solid rather Is that it it melts at room temperature so depending on how you look at it? It's either a solid or a liquid and this becomes a real problem because if it's not a hot day
This will actually precipitate cover your dye and actually interfere with the reaction So the way that I get around this is actually to use a heat gun just like I was using for Maybe decapping or some of the de-layering work and just run it at a slightly elevated controlled temperature So that regardless of whether I run this in summer or winter You know I get kind of a repeatable process running at about the same temperature
And below you can see an example of you know what this looks like when you do it at too cold of a temperature So even with all this unfortunately I still ran into a lot of problems where I would take the exact same process or it seemed and I would actually
Get very different results sometimes I would get the masqueron out and sometimes I wouldn't and and So after a little bit more research what I found was that If I lapped the dye at an angle, which is basically precision polishing What this will do is it will add?
You know kind of a gradient where you can see that The different heights of the transistors essentially to see you know What is the optimal height that we should be operating at to get the best data retention? And what it showed was you actually want the lower layers of the transistor which is at the right to get the best data readout and
The left area of the dye I just turned completely black You know there was no time when it actually showed the data It just went immediately black And you know no real data could be recovered so kind of an ongoing project is figuring out ways to kind of tune You know how far can I dig down in this dye reliably to make sure that I get the best data every time?
And also I get a lot of questions about safety, so I thought I'd have a token slide about this So the hydrofluoric acid is in fact. You know not exactly the nicest chemical on the block So for this project. I actually did purchase a full hazmat suit
Which was good because I was able to work with the concentrated hydrofluoric acid at least with you know reasonable safety Fortunately I don't have to work with that very long you basically take that make some weaker solutions and most of the time you just deal with those So with that I think I'm going to hand it off to Marshall
So at this point what we have is a bitmap of The mask ROM which contains the program code for the microcontroller now I mentioned the piff and the sick before there are the two chips that are talking to each other So here's what they actually look like once you take the lid off
Six is on the left if is on the right they actually share the same CPU core It is called a sm5 core CPU made by sharp We didn't know that at first we just We just saw a bunch of gates So we gave the shots to this guy named Seger Who has seen a lot of these sharp chips before and he's a very he's actually a sharp guy himself
sharp as in like You know a lot of stuff up here not working for sharp anyway. He was immediately able to identify that Architecture and tell us it's an sm5 It's probably custom there's all sorts of stuff hanging off of it that you can't immediately know what it's doing
But there you go. So that was our starting point So, like I said, we have this down in the lower left That's the ROM image. That is actually what the code that executes so using John McMaster's dash edge process we could figure out what it looked like and then get an image. So
Once we had the image which is that big thing on the right, that's the entire mask ROM It's eight kilobits one kilobyte of data. Not exactly the hugest thing doesn't need to be so What I did was instead of trying to go ahead and use open CV to You know, is this a zero or is it a one scan through the entire thing? The quality was not that good
This was actually a process we started It has spanned like what is it like several months a year a year and a half From when you started doing the dash edge to when you were starting to tweak it So these early images are what I basically worked off of and I decided I would just do everything by hand now I think this is a pretty good case
There are pretty big argument for just manual entry when you just have to do something once Like it only took me two days to write this tool and I slept a lot. So I made it tool in C sharp. I have a big case of not invented here So I didn't even look at a lot of the other stuff out there There is a tool if if you have this same sort of problem
There's a tool out there called rom-par Which is a great tool lets you figure out the alignment of the grid and then you know sample along at different points So if you have cleaner imagery, it's definitely something I would check out Like I said, I'm mr. Not invented here. So I didn't use it. It would probably work for you. So Here's my tool It took me half an hour once I wrote this tool just to punch in all the bits
Lets you set the grid you're just spacing it max off all this stuff that you don't need to know It'll actually check to make sure that you typed in everything So here's just a comparison of the old process versus the most recent process John's You know best work is on the right
So and that's something that you could probably automatically image and it would be fine Here's a block diagram of the CPU, it's a 4-bit CPU It has 1k of ROM. It has 32 nibbles not bytes nibbles of RAM So that's 16 bytes of RAM and it has four stack levels. So no recursion
Not that you'd have room to do anything anyway So once we had the architecture somewhat identified Like our friend Seger indicated to us, he said these were actually used in a lot of calculators and Stuff like, you know handheld games from the 90s
So we were able to locate about five or six data sheets that had this information in them The problem was there was a lot of ambiguity But I still managed to write a disassembler. Okay Just to give you an example. Here's a few of the instructions It's really hard to figure out what you're looking at here the mnemonics are the same but it has like three different
actions that it causes so and I'm not good with the assembly anyway, so what I did was This middle column at the top is registered transfer notation So you can see what's going on and then on the rights the branching instructions so that I can see what's going on
So once we had this disassembly I worked for a long time and then that's when Mike actually came in on this project So starting from Marshall's disassembly, we were able to get some idea of what the chip did and how it works But this was pretty opaque code. I'm not terribly good at reverse engineering despite giving a talk here and I'm much more of a debugger type of guy. So I wrote an sm5 emulator based on these data sheets and
we were actually able to run a simulation of this chip pretty effectively and It's a decent little emulator, it's got a built-in debugger code and memory breakpoints memory viewer and editor right now
I'm working on undo functionality since we know that's very important So this is actually open source, I'm gonna have a link to it at the end of the talk so having the disassembly from Marshall and The emulator we were able to get an almost complete picture of how the chip actually operates
So at this point we were able to understand the the major phases of execution and be able to interpret some of those logic captures We got off the wire So to give an overview of how the chip actually works the second the console turns on The six sends the following data to the PIF first It sends a hello and a region ID to identify whether it's a PAL or an NTSC chip
It sends a value called a seed and a checksum Now the PIF looks at this data and it decides whether it likes what it sees at any point in this process the PIF can decide that it's not going to allow the console to boot and Just cause the console to freeze and the sick will just sit there waiting forever
if the PIF does like what it sees it sends the sick two nibbles of data to kind of precede memory and then both chips enter the main runtime and This is actually what it looks like on a logic analyzer You can see the boot the checksum and the RAM load All happen in the first second and a half or so after the console starts and then they enter this main runtime and this main
runtime ever stops So to drill down a little bit into the boot here You can see the hello and the region ID followed by the seed but the seeds encoded We'll get back to that in a little bit. This is how you actually interpret the data So there are the the PIF and the sick are connected by two lines on the cartridge bus
The top line is a clock line that's driven by the PIF and the bottom line is an open drain line that is driven alternately by the PIF or the sick it's There's no explicit bus arbitration. It's all implicit They're running pretty similar code So they know they won't step on each other's toes and you can see here that
The encoded seed in this particular example is BD three nine three D and we'll talk about what that means in a second a Little zoom in on the checksum here You can see that it's a bit longer than the seed and finally at the very end The you see the two nibbles sent from the PIF to the sick
I'm out of my art. So the two nibbles sent from the PIF to the sick So this is the first time that the the PIF actually talks to the sick and sends any meaningful amount of data So after it the PIF sends those two nibbles to the sick They enter the main runtime mode the the PIF tells the sick
Go into memory compare mode and they enter memory compare mode So at this point we start to see similarities with the earlier sick chips Remember that the earlier sick chips didn't have very much intelligence the Nintendo and the super NES They had they were two chips that operated in lockstep and if either chip
Thought that there was a problem with the data stream They both reset each other in on this chip on the PIF and the sick The PIF and the sick both run the same algorithm on on the same memory But they don't do it in lockstep instead They run the algorithm and then they dump the contents of memory and compare each other
So first the PIF sends its first bit of memory Then the sick sends its first bit of memory and on each step first the sick validates that the PIF has sent the correct Bit and then the PIF validates that the sick has the correct bit. So it's Should I choose the other mic Okay, so in in this case, I'm gonna use the other mic. Sorry technical difficulties
So by doing this Nintendo not only made sure that the cartridge in the system was legitimate
They also made protected against people from trying to pirate the PIF instead of trying to pirate the sick So you can't have a pirate console This is a pretty interesting technique and you can also see here that there's a small delay I've highlighted it in red when the sick sends a zero
The first bit there is the PIF sending a zero and you can see both the clock and the data line are driven low and high At the same time, however The when the sick sends a bit it waits until the data clock goes high before releasing the line So if you were looking at some unknown ship in the future and you saw some behavior like this
You might be able to deduce from this that it's two chips talking at different times Finally at the very end of this the PIF tells the sick to go back into the memory compares mode So it runs this forever until you turn off the console the party never stops There is no delay. And if there's ever a single problem the console locks up
Now I said that the PIF and the sick run the same algorithm on the same code. This is what that algorithm looks like Don't try to get your eyes crossed trying to understand it. It's just garbage and The point here is that it's essentially security through obscurity. There's no way that you could possibly
deduce this algorithm realistically without Decapping the chip and extracting the contents of the mask ROM So it's security through obscurity, but it was effective for about 20 years Which is more than the useful life of the console. So I'm gonna I'm gonna put this in the win column
So we mentioned earlier that there are several variants of the sick One of them in particular the 6105 had a special extra mode just to try to foil the pirate pirates a little bit more in this mode the game could actually query the sick send it a challenge and the sick would send a response and This is what the code looks like inside the sick for doing that. It's just another case of security through obscurity
What's interesting to note about this is that? A gentleman by the name of X scale actually was able to take a huge pile of data because we can log this data and He was able to reverse engineer the actual algorithm used to generate this without looking at the code. So that was very very impressive
So at this point in the process we had the disassembler we had the emulator we could get a pretty good Interpretation of the data coming over the lines. We still couldn't completely clone the chip. We had a few more hang ups One example here is that the data ship sheets were not the best data sheets. They had some some
Some incompatibilities for example, you can see in the top one that they skip if BL equals zero And in the second one skip if result of BL equals FH So depending on how you implemented these instructions, you could have very drastically different code paths And now the other thing is we had this encoded seed in this encoded checksum
so with these data sheets There was an there was an opcode called DTA and depending on which data sheet you were looking at It did something different for example in one of the chips It would drive LCD drivers in another chip. It would drive analog digital converters
So it seemed to be just sort of a general purpose instruction used to do a chip specific Function and in this case we had no idea what this chip specific function was However, we could definitely tell looking at the code that it was related to this encoded seed in this encoded checksum It was loading some data from somewhere and then that data ended up in memory
Then this encoding process happened and that data got sent over the wire Interestingly enough we looked at this encoding algorithm and I said hey It looks like you could probably run that in reverse so we came up with the inverse algorithm for this and then based on that data sent over the
Wire, we could actually decode it and get the contents of that secret data without actually having to understand how this instruction worked So in the first example, you'd see one chip when it boots It sends BD 393 D and when you decode it you get 3f 3f That's the seed for that particular chip. The next example the seed is seven eight seven eight
Interestingly enough when the the system boots this encryption key the first two bytes there at first two nibbles rather are always be five The checksum is a little bit more interesting It's longer for one thing and then it uses a Ford nibble quote-unquote key and this value actually Varies depending on a delay from the PIF. There's a random period of time that the PIF waits before telling the sick
okay, send me the checksum and That is just based off of the RC circuit delay from a capacitor that hangs off of this chip so Finally with all of this we actually were able to completely clone at the chip
So in order to test this we I had this guy over here. Who's an Altium Pro Put together a PCB. Do you want to talk about the PCB Marshall? Yeah, as you can see I am a total PCB expert All it does is it adapts about four pins from the sick footprint to the we used a PIC
Microcontroller to pick 16f something or other So as you can see that PCB is very very compliant to everything If you use, you know, our OHS or a lead-free solder, you're fine. You're compliant for all cases. So anyway, that was our
basically our testbed for the first first few chips so I'm gonna go ahead and run a video of this thing booting and Apologize in advance the video quality is not the best I looked around my house for anything that accepted composite in that didn't wasn't also mounted to a wall and
This studio monitor is the best I could come up with so so the first thing that I'm gonna do here is boot banjo 2e and as You can see the game actually successfully boots and this is one of those games that uses the 6105 chip It won't even get it won't even boot if you haven't implemented the 6105 challenge response algorithm correctly
actually this game It encrypts all of his game assets and it uses the response as a decryption key. So it decrypts itself at runtime. So the way they actually emulate this on a computer is to Just capture all the responses as someone plays through the entire game because there are over several hundred
Responses that you have to know actually an interesting side note about that after X scale Was able to reverse engineer this algorithm. He you generally regenerated the list of all the challenges and responses and it turned out that this there was a somebody fat-fingered one of the
responses in the in the file, so So after banjo 2e boots So we just had a guy by name of Arbin play through this game 100% and he just finished playing at 100% last night and he did not run into any problems whatsoever So we're very confident that our sick clone is working 100% effectively
so after that game finishes Interesting it does have sound So just for completeness. We also went ahead and booted in another game with another sick This is using our our little adapter board that I can show you after the talk This is just booting Star Fox and again
I've left this game running overnight and it never stops and never never seems to cause any problems. So we're we're pretty confident in in our code oops That looks close enough. I'm bad at computers. Sorry guys
If I hit ctrl Q is it gonna quit PowerPoint? Sorry, I've only been a Mac user for a for a couple weeks now Marshall tell a joke Put me on the spot here Wow Well, I see a joke on the stage here. Ooh
Wow, I was gonna buy you a beer but nope. It's alright. He could take it Alright, so that was our demo. I wasn't gonna lug a Nintendo 64 from the States here to show it but
in any case really really All right, in any case so some of the features of our clone ship is it's actually region free I discovered a technique for making it able to boot in either the PAL or the NTSC region I'm not releasing that code, but I am releasing a bare-bones version of this code
Open-source, so there's gonna be a github link at the end if you want to check out my really awesome 8-bit pick Assembly go go nuts, man. I never want to look at that architecture again Funny thing about pick it's pretty terrible But for this particular Microarchitecture it had some nice features that made implementing this stuff pretty easier than it could have been
Otherwise remember we mentioned that this is a 4-bit microcontroller. So when you've got things like like carry It all depends on not carry in the 8th bit. It's carry in the fourth bit Pick actually has a feature called decimal carry. So if the fourth bit carries, there's a flag in the status register
So we were able to actually implement the code in a pretty straightforward manner Not having to think too hard about 4-bit math versus 8-bit math. We ran into an interesting problem with a piff. So The the CPU clock for the sick is around 1.6 to 2 megahertz and the internal logic of the chip actually runs at half That speed so we wired up a pic to the same clock and we thought great
We're gonna have twice as many instructions To actually implement the same thing because we'll have we'll be running at the full external clock speed Well fun fact about 8-bit picks they actually run at 1 4th the external clock speed so we had half as many instructions that didn't work out luckily microchip makes a pin compatible part to the one we originally specs and
It has an internal Forex PLL. So we were able to get around that So I guess you win some you lose some with with pick All right, last but not least we I definitely want to mention some related work We spent about two two and a half years working on this and in the meantime At least one other independent effort came about to reverse engineer this chip
So a German team led by two guys named Marcus Wrote a paper called this breaking this integrated circuit device security, addy-adda They found a factory test mode on this chip They they they like we did they decapped the chip and optically imaged it
They traced out some of the logic on the chip and found that there was actually a factory test mode and so they found that they were actually able to perform arbitrary code execution on this chip and So using using their technique we could actually start to understand what some of these unknown instructions did and
And and run some code on the chip. So once again PCB Pro over here made us a board It's a very nice board I like it I made it last year so it's not that out of date anymore And So this this board has a footprint for a sick on here and also has the ability to burn pics
It slices it dices and so this was a plugs into an FPGA board there And we were able to clock some code into it and run arbitrary code using this technique we were able to Extract the mask ROM using code and validate that our image that we have obtained optically was bit for bit
Identical to the the image and it turns out it was so that was really great to find out that our technique was was very effective So one of the other things I'm working on that's also related to Nintendo 64 is An HDMI converter that you know upscales the signal
So I needed a way to be able to update the firmware for that in the field So I thought okay, you just make yourself a custom game you put in a Nintendo it boots and then it reflashes everything So this was this is one of the biggest use cases that I can see right off for this Sick clone ship is that you just put on there it costs like 70 cents And then you can make like you schedule these things and not have to worry about getting them back
So you're not depending on you know scavenging stuff from older games So we'll talk a little bit about the future work we also John decapped an image the piff the more advanced chip that lives on the Nintendo 64 and We we traced out John traced out some of the logic on that ship and found the same two test pins that Marcus and Marcus had
Identified so we strongly suspect that the internal test mode is present on this chip We did extract the die image the ROM image optically, but when we try to interpret it we ran into some weird problems So I think for a future work
We're going to try to identify the bus that that actually you clock the data in and out So this is some stuff that you did Marshall, right? I took the die image that John made and I went around the periphery of the chip where the inputs and outputs are and I tried to catalog What nets were driving what pins and it turns out some pins only driven or drove one net?
Which and that is basically a signal so? around this The outside the periphery of the chip there You'll see the pin number the function of the chip and then this blue number The blue number is the number of nets that that IO driver has so if you look at the top right corner
You'll see you know six six six three six three six four And then the those are a lot higher than the ones in the bottom left So I'm thinking that these pins have alternate functionality Just like the sick and that we could use them for arbitrary code execution now. This is future work Well, you know we just discovered this like a week ago
So, but we're really hoping we could run our own code on this chip this has its own 1k ROM as well But it's actually fully utilized unlike the sick that is basically half-empty. So So yeah, we have some interesting ideas about how we might find those pins So if you want to talk to us after the talk about that be happy to That's pretty much all we got for you today
Give out some thanks Marcus and Marcus very graciously helped us out Seger who is crazy smart as long kitty as well helped a lot on this project I think nobody knows more about how the Nintendo 64 boots than he does emucated out in Australia helped a lot with a pal testing Arvin and Jura who are running through games and Making sure that they continue running so that when we release this to the public there will be solid as a rock
Shout outs to some friends on the internet and 64 dev pinchy lack X scale Nico Jovis rest in peace Andrew thanks for Thanks for everything And with that we'll open it up to any questions and these are our contacts and stuff awesome talk you guys
Hey, you can't see me, but I'm gonna ask you a question So the from what I understand the NES sick had this Hack that you could lift one of the pins and just ground it and that would disable the sick in the console So any game, you know any party games you could just run on it Did you notice anything with the n64 sick either by looking through the code or like figuring out something else that it an easier way to
Bypass this whole thing if you could put you know modify the console Well, like I said The PIF is what you got to worry about and it lives inside the console and it does all the system bring up And it does handle all the resets and anim eyes for the MIPS CPU and it pulls the controllers and a lot of stuff So basically, yeah, you can't blow that away and replace it with your own
You'll have to lift some copyrighted code bootloader out of there put it in your new one and then replicate all this functionality It's not a practical approach. But if we get the PIF code, maybe there's a hidden mode where the sick can tell it Hey, just stop bugging me and let it run forever Is this on? Yeah technical difficulties here, too. Okay, so really they're they're almost solving that problem
Just by hiding it inside of more silicon. They're hiding it inside much more complex silicon. Yeah any other questions? Or there Take a moment to say that I really enjoy video games
Hey, so when you guys approach the dash etching for the PIF and sick you guys had a bunch of cartridges You can just buy or 50 cents each but how did you approach dash etching the Chip in the console where you only had like a couple of them or did you guys just sacrifice like 20 and 60 force?
So at that point I had already developed the process for the 6102 and the process on the PIF was very similar. So I was able to just say okay Look, these chips are made on the same process. It's gonna require the same recipe So it really wasn't that big of a deal to get the process working on the PIF once it was working on the sick
I think we have more questions near the front So I hand over here. It's a miracle. I could see anything up here. Oh, hi So the modern ever drives boot, how does that work? And are you gonna share this stuff with the everdrive guy?
So all so the the clone of the sick is open source. So if he wants to use that he can The currently as far as I know they're they're using the the just the same same technique that the 64 drive uses Which is a cop an actual chip inside the console our original
Nintendo sick, so yeah Any more questions? Like this is the most questions I've ever gotten from a talk
Yeah, this is a little bit of a last-minute question. I know the old CIC had like an unusual 4-bit polynomial instruction counter I was curious if there are any hardware quirks of the N64 or CIC they have similar Aside from just being a 4-bit microcontroller. It was pretty vanilla. It had a regular linear counter
Nothing all that out of the ordinary Because I've seen the reversing efforts for the previous CIC, but I was always curious how they had You know manually reversed that polynomial instruction counter and gone through the code for reversing that that's that's a hundred percent He's one of those those people who you just like all right. You're crazy smart. Just just take this and do your thing
Alright, I think that's it