[HN Gopher] Hardware Security Exploit Research - Xbox 360
___________________________________________________________________
Hardware Security Exploit Research - Xbox 360
Author : nazgulsenpai
Score : 194 points
Date : 2024-12-19 20:26 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Lammy wrote:
| > So - here is a hopefully informative write up of my Journey to
| figuring out how these guys were running unsigned code in 2011 on
| a XBOX 360
|
| > XBOX 360 Security defeated - 2011
|
| I realize this post is more about hardware security than software
| security, but if the benchmark is unsigned code execution then
| the author should at least mention the 2007 (King Kong shader
| exploit) and 2009 (SMC hack -- same root flaw but executed
| automatically at boot) methods of achieving the same:
|
| - https://github.com/Free60Project/wiki/blob/master/docs/Hacks...
|
| - https://github.com/Free60Project/wiki/blob/master/docs/Hacks...
| PaulHoule wrote:
| Back in the day I really liked my 360 whereas my ONE seems like
| a mistake.
| mrandish wrote:
| Yeah, I still have an Xbox One hooked up (along with a SOTA
| gaming PC) but I now have more fun playing retro games via
| emulation than modern games.
|
| Lately I've been having a blast exploring the X360 library
| via Xenia (since I had a PS3 during that era and never got to
| see some of these titles).
| dinartem wrote:
| Good times. I was the developer at Microsoft who designed the
| Xbox 360 hardware security, wrote all the boot loaders, and the
| hypervisor code.
|
| Note to self: you should have added random delays before and
| after making the POST code visible on the external pins.
| spencerflem wrote:
| Congratulations, haven't had a reason to mess with it myself,
| but I've heard it described online as the most secure piece of
| consumer hardware before or since
| SteveNuts wrote:
| I'm curious how it fares against a modern iPhone or similar,
| has that ever been compared?
| saagarjha wrote:
| iPhone has a fairly different threat model (and is more
| valuable to attack).
| liamwire wrote:
| I have a hard time believing the 'since' part of that
| description. Intuition suggests the latest iPhone would take
| that crown each year.
| spencerflem wrote:
| Misremembered, it was saying it was the most secure code
| Microsoft has written, not anyone
|
| From the excellent: https://icode4.coffee/?p=954
| walterbell wrote:
| _> the latest iPhone would take that crown each year_
|
| Apple continuously patches zero-day kernel exploits against
| the latest iOS and hardware, https://support.apple.com/en-
| us/100100
| anyfoo wrote:
| That is far from the only thing that would be relevant
| for such a metric. (For one thing, you also have to ask
| _which_ kernel.)
| walterbell wrote:
| iPhone and iPad devices have been breached by zero-days
| for years, unlike Xbox One.
| anyfoo wrote:
| Still simplistic. "Breached" can mean a number of things,
| and the incentives here are very different.
| StrauXX wrote:
| Sure, but there are many more people looking at iPhone
| security than at Xboxes. The incentives, both monetary
| and otherwise, are much greater with iPhones than they
| ever were with consoles.
| jsheard wrote:
| I think you might be mixing up the Xbox 360 with the Xbox
| One, the former was ultimately compromised in several ways,
| but the latter's security has held up _extremely_ well for 11
| years and counting. The Xbox One and its successor are easily
| the most secure consoles ever made.
|
| Obligatory: https://www.youtube.com/watch?v=U7VwtOrwceo
| spencerflem wrote:
| Found it! I misremembered, it was making a slightly
| different claim
|
| "The Xbox 360 hypervisor is probably the most secure piece
| of code Microsoft has ever written." from the excellent
| article Tony Hawk's Pro Strcpy
|
| https://icode4.coffee/?p=954
| landr0id wrote:
| The Xbox 360 was overall a very, very secure device.
| While we don't know exactly how the folks who discovered
| the hypervisor syscall handler bug were able to get
| plaintext, it's theorized that it came from development
| kit and SDK leaks. With an SDK and dev kit someone could
| dump boot loaders and the HV.
|
| Otherwise on a retail console you can't do much. The hard
| drives are not encrypted but all content that can
| possibly contain code / save data is signed. Save data
| cannot contain code but introduces scripting engine /
| save parsing attack surface, but you can't modify it
| without first dumping keys from a retail console.
|
| To dump keys from a retail console you have to get code
| exec in the hypervisor. To attack the hypervisor you have
| be able to dump the hypervisor to audit it.
|
| To dump the hypervisor you have to be able to read its
| contents or dump it from flash. The flash is encrypted
| with a per-console key (and I don't think you can sniff
| the bus?) and RAM is encrypted.
|
| Realistically if it weren't for the original syscall
| handler bug and dev kits getting into researcher's hands,
| the Xbox 360 may have never been hacked.
| markus_zhang wrote:
| Stupid question, is the reason that people cannot simply
| dump the ROM as they do with say routers is that the rom
| is encrypted? But if they have the SDK they can decrypt
| it?
| landr0id wrote:
| The flash chip is encrypted with the console's CPU key,
| and the CPU key is unique per-console and encoded in
| efuses. So even if one person manages to dump keys
| they're mostly useless for hacking other consoles. The
| exception to this is the "keyvault" which is the
| console's own private key used for signing save games.
| You can take save games from console A and load them on
| console B, so console B is able to verify console A's
| signature based off the public key certificate embedded
| in the save. Microsoft had a revocation process for
| revoking keyvaults if they ever leaked but they just gave
| up once too many were in the wild.
|
| Dev kits are keyed differently and most of the console's
| keys for signing / encryption are in various SDK DLLs
| that if you reverse engineer you can find.
| markus_zhang wrote:
| Thanks, MS did take a lot of efforts on the security.
| Searching for X360 keyvault gives a lot of webpages. I'll
| read a bit.
| ChocolateGod wrote:
| > The Xbox One and its successor are easily the most secure
| consoles ever made.
|
| Microsoft also allowed any console to switch to developer
| mode and run homebrew, massively reducing the need for
| people to try find exploits.
| notavalleyman wrote:
| What are the reasons for why Microsoft wanted to lock down
| consoles to only run signed code? As a games console
| manufacturer, what are the business reasons for doing so?
| Thanks
| treyd wrote:
| They sell the consoles at a loss, so if you could port your
| own games to the consoles instead of buying the games that
| they could take a royalty from then they lose money. It
| doesn't have to be an _effective_ circumvention to trigger
| the DMCA making it illegal.
| Lammy wrote:
| A games console provided a platform where they could more
| effectively argue that "their" works """needed""" to be
| protected so they could farm us (people who want to run their
| own code on hardware they purchased) for digital-jail
| technologies which would never otherwise have reason to
| exist. Then those technologies can metastasize fully-formed
| over to general-purpose computing in a way that's harder to
| argue against. They learned with Clipper and Palladium that
| trying to develop jail tech on PC would be vehemently
| opposed.
| lyu07282 wrote:
| The opposition was pointless though, like everything has
| TPM/IME/etc. nowadays so we lost that war awhile ago. I
| don't see how consoles helped them win that war though.
| RGamma wrote:
| When everything is locked down for good I'll go back to
| physical books. Vaporware games and media are not worth
| preserving anyway. And the games and media I do have free
| from prison can entertain me for a _very_ long time.
|
| Another possible (even worse) future could be
| cloudification of everything. Enjoy your thin client.
|
| Of course software is bigger than entertainment which
| might represent a problem. We're increasingly societally
| locked into this digital shit.
| nemothekid wrote:
| Limiting piracy is the ongoing reason, but there is also the
| historical reason of the Video game crash of 1983 which led
| to Nintendo's Seal of Quality.
|
| Essentially as the platform owner, you want to ensure games
| sold for the platform "just work", and if you have a bunch of
| third parties running bad software, consumers would lose
| faith in the platform altogether.
| NotPractical wrote:
| Microsoft actually reversed course on this. You can make a
| _one-time_ purchase to access "developer mode" and then
| run whatever you want. It's been suggested that this is the
| reason there's been less interest in hacking the Xbox.
| Ironically it also means you have more computational
| freedom on the Xbox than on the iPhone/iPad.
| girvo wrote:
| > then run whatever you want
|
| Not quite. You (were? I don't know if this is changed)
| limited in how much of the hardware you could access: it
| wasn't 100% access. Enough for most homebrew, emulators
| and so on, but it wasn't carte blanche "replacement for a
| dev-kit" access.
| Narishma wrote:
| I don't think it much different from the official games,
| which also don't have full access to the console.
| klausa wrote:
| The "not-behind-the-paywall-and-NDA" GDK version is
| severely more limited than the invite-only GDKX.
|
| IIRC the homebrew you can run is mostly UWP stuff? But if
| you want to launch a _game_, built for an Xbox, it
| requires to be in the program.
| mrandish wrote:
| > ensure games sold for the platform "just work"
|
| To add a little more color to this, it wasn't solely to
| ensure games worked. The lesson of the video game crash was
| that third party publishers would make knock-off games
| similar to popular titles and flood the market with them at
| _much_ lower cost - sometimes as low as $5 vs for a $40 for
| a top title. These games were generally low budget and
| rushed to market to capitalize on looking like a top-
| selling title - while being _just_ different enough to
| (hopefully) avoid trademark infringement.
|
| These games usually "worked" (as in booting up and
| playing), the issue was more that that they were just bad
| versions of the title they were ripping off due to having
| little development time and minimal play testing along with
| poorer artwork and fewer levels (thus saving ROM memory).
| The flood of cheap, bad versions of more popular games is
| credited as the main factor that killed the Atari VCS.
|
| Another big factor was that later console manufacturers
| charged game publishers a license fee for the proprietary
| library code required for a console to run a game. This fee
| could allow manufacturers to sell game consoles at cost or
| even below cost and recoup the lost profit over time in the
| per game license fee.
|
| This wasn't always the case in the early days of hardware
| cartridge systems. Initially, some early console
| manufacturers didn't charge much more than a game publisher
| could buy blank cartridges for from a third party. Some
| other manufacturers chose to generate revenue simply by
| building more margin into the wholesale price they charged
| game publishers for blank cartridges. Of course, when
| console manufacturers started increasing their cartridge
| profit margin, game publishers were motivated to use third
| party cartridges - which led to console makers deploying
| "genuine hardware" checks or, later, disc checks and
| encryption. Nintendo popularized enforcing their business
| model both technically and legally (by requiring an IP
| license). Today, console manufacturer business models rely
| on 1) Collecting per game license fees, 2) Blocking piracy,
| 3) Limiting game supply.
|
| There is a lot of interesting history around how game
| console business models and the legal landscape evolved
| over time. (https://en.wikipedia.org/wiki/Atari_Games_Corp.
| _v._Nintendo_....)
| maximilianburke wrote:
| I think it's also worth pointing out that the console
| makers (and developers) pour a lot more resources into
| ensuring that the products released for their platform are
| of a suitable quality than, say, phone app store
| gatekeepers.
|
| A big draw as well is that people can't (within the
| economic viability timeframe of the games/console) hack the
| games on a console, meaning you get a much more predictable
| online experience than you might on PC.
| droopyEyelids wrote:
| There was a period of time when this was true but at
| least with nintendo, the eshop is full of shovelware now
| akira2501 wrote:
| > and if you have a bunch of third parties running bad
| software, consumers would lose faith in the platform
| altogether.
|
| Famously the reason no one ever used Microsoft Windows.
| mschuster91 wrote:
| > Famously the reason no one ever used Microsoft Windows.
|
| Microsoft in its early days invested _a shit ton_ of
| money and effort into backwards compatibility testing and
| fix development. Up until Windows 7 you could be
| reasonably sure that any piece of software from the
| Windows 95 32-bit days would still work without major
| issues - even 16-bit software would run under a 32-bit W7
| host, only W7 x64 finally dropped support for that.
| hsbauauvhabzb wrote:
| Yet Microsoft bought Bethesda
| brokenmachine wrote:
| They are rent seekers.
| hsbauauvhabzb wrote:
| I'm not sure that's a fair perspective, they built a
| proprietary product that's intended to be a loss leader,
| the opposite of that is a desktop which costs substantially
| more.
| throwaway48476 wrote:
| They sell the console at a loss but make 30% on every game
| sold. The business model is variant of "dumping" but
| antitrust isn't enforced anymore.
| doctorpangloss wrote:
| If it were possible to go the wrong way on the expanding
| brain meme, this would be it.
|
| Nobody is buying consoles for the hardware. 99% of the
| product is software. The accounting that you are using, a
| popular one, is so opppositely-informative that people who
| make consoles - and smartphones for that matter - clearly
| do not make decisions with it. It is 200% wrong to
| characterize it as dumping. Nothing is being dumped.
|
| Here's a simple idea for you: show me the vibrant market
| for Xbox 360 2005 era computer hardware. There isn't any
| right? What about Xbox One 2013 era? And yet we still play
| games that were developed earlier than 2013, like League of
| Legends. The product is software. Nobody loses anything by
| being unable to run Linux on 2013 hardware today, and
| nobody loses anything by being unable to run Linux on the
| Xbox One in 2013 because, if they wanted cheap computers
| then, they had plenty to choose from!
| ashleyn wrote:
| business reasons, the console is sold as a loss leader and
| the real money is made in licensing the games. also serves as
| brand protection i.e. preventing poor quality third party
| games from tarnishing the reputation of the console.
| vlovich123 wrote:
| I feel like random delays would make the glitch attack harder
| but it would still be possible given enough attempts. Seems
| like the bigger issue is that you can glitch the CPU reset line
| which corrupts the processing rather than having no effect or
| resetting the CPU.
| kaoD wrote:
| I assume those are probably very hard to fix since (again, I
| assume, I'm just a hobbyist in the hardware space) that sort
| of glitch relies on propagation delays (e.g. a short burst
| triggering some latches but not others, or triggering the
| latches in some specific synchrony).
|
| Can anyone confirm if I'm on the right track with my guess?
| liamwire wrote:
| Can you speak to some of the harder or more interesting
| challenges you faced during that time?
| dinartem wrote:
| One challenge was that while I started working on the Xbox
| 360 about three years before it would ship, we knew that the
| custom CPU would not be available until early 2005 (first
| chips arrived in early February). And there was only supposed
| to be one hardware spin before final release.
|
| So I had no real hardware to test any of the software I was
| writing, and no other chips (like the Apple G5 we used as
| alpha kits) had the custom security hardware or boot sequence
| like the custom chip would have. But I still needed to
| provide the first stage boot loader which is stored in ROM
| inside the CPU weeks before first manufacture.
|
| I ended up writing a simulator of the CPU (instruction
| level), to make progress on writing the boot code. Obviously
| my boot code and hypervisor would run perfectly on my
| simulator since I wrote both!
|
| But IBM had also had a hardware accelerated cycle-accurate
| simulator that I got to use. I was required to boot the
| entire Xbox 360 kernel in their simulator before I could
| release the boot ROM. What takes a few seconds on hardware to
| boot took over 3 hours in simulation. The POST codes would be
| displayed every so often to let me know that progress was
| still being made.
|
| The first CPU arrived on a Friday, by Saturday the electrical
| engineers flew to Austin to help get the chip on the
| motherboard and make sure FSB and other busses were all
| working. I arrived on Monday evening with a laptop containing
| the source code to the kernel, on Tuesday I compiled and
| flashed various versions, working through the typical bring-
| up issues. By Wednesday afternoon the kernel was running
| Quake, including sound output and controller input.
|
| Three years of preparation to make my contribution to
| hardware bring-up as short as possible, since I would
| bottleneck everyone else in the development team until the
| CPU booted the kernel.
| fragmede wrote:
| damn, that's bad ass. did that simulator run on a Windows
| system or was it something more esoteric?
| dinartem wrote:
| I called the simulator Sbox and it was just a simple
| console app. I didn't implement the GPU, so no graphics
| just the hypervisor and kernel and some simple non-
| graphics apps. I made it so that you could build the Xbox
| 360 kernel on your windows machine, then just run
| sbox.exe and it would automatically find the just built
| kernel image targeting the PPC64 and boot it. Then if you
| typed control-C it would drop into the kernel debugger as
| a sub process, and you could poke around at the machine
| state as if it were the real Xbox hardware, showing all
| the PPC instructions and registers. It was a lot of fun
| writing it, and quite useful.
| fragmede wrote:
| That sounds like a lot of fun! What was your career like
| before that, that led you to be in the place to do such
| fun things?
| Zeetah wrote:
| You should also talk about the lwarx/stecx bug. IIRC - in
| the first version of the chip there was a bug in one or
| both of these instructions. Your code booted on SBox but
| didn't on the hardware. You compared the two and then
| figured out it was these instructions.
|
| You filed a bug report and then dug into them and used
| SBox to figure out what must have been going wrong.
|
| The chip supplier came back with a workaround and within
| five minutes you simulated it on SBox and said it
| wouldn't work, why, and then said how it should be fixed.
|
| The supplier didn't believe you as yet. And you worked
| out a workaround so we could be unblocked. Two weeks
| later they agreed with your fix...
| maximilianburke wrote:
| I recall an issue when trying to use lwarx/stwcx on Xbox
| 360 directly that the compiler (or maybe even the kernel,
| on program load? it's been a while) raised an error and
| said to use the Interlocked intrinsics instead -- is that
| related?
| dinartem wrote:
| So the PPC instruction set uses lwarx (load word and
| reserve indexed), and stwcx (store word conditional
| indexed), along with variations for word size, to
| implement atomic operations such as interlocked-increment
| and test-and-set.
|
| So on PPC interlocked-increment is implemented as:
|
| loop: lwarx r4,0,r3 # Load and reserve r4 <- (r3) addi
| r4,r4,1 # Increment the value stwcx. r4,0,r3 # Store the
| incremented value if still reserved bne- loop # Loop and
| try again if lost reservation
|
| The idea is that the lwarx places a reservation on an
| address that it wants to update at some later time. It
| doesn't prevent any other thread or processor from
| reading or writing to that address, or cause any sort of
| stall, but if an address being reserved is written to,
| conditional or otherwise, then the reservation is lost.
| The stwcx instruction will perform the store to memory if
| the reservation still exists clears the NE flag,
| otherwise it doesn't do the write and sets the NE flag
| and software should just try again until it succeeds.
|
| On the Xbox 360 we provided the compiler which would emit
| sequences like these for all atomic intrinsics, but
| developers could also write assembler code directly if
| they wanted to. We'll get back to this point in a moment.
|
| As the V1 version of the Xbox 360 CPU was being tested by
| IBM, they discovered that an error with the hardware
| implementation of these two instructions and issued an
| errata for software to work around it, which we
| implemented. Unfortunately, after further testing IBM
| discovered that the errata was insufficient, so issued a
| second errata, which we also implemented and assumed all
| was well.
|
| Then the V2 version of the CPU comes out and months go
| by. But early one morning I get a phone call from IBM
| letting me know that the latest errata was still
| insufficient and that the bug is in the final hardware.
| Further, Microsoft has already started final production
| of CPU parts, even before full testing was fully complete
| (risk buy), so that they could have sufficient supply for
| the upcoming November release. I was told that they are
| stopping manufacturing of additional CPUs, and that I had
| 48 hours to figure out if there is anything software can
| do that could work around the hardware issue. They also
| casually mentioned that millions of dollars of parts
| would need to be discarded, a hardware fixed implemented
| which would take weeks, then the production could resume
| from scratch.
|
| Bottom line is that, yes, there was a set of software
| changes that would work around the bug, but it required
| very specific sequences of instructions, the disabling of
| interrupts around these sequences, a change to the
| hypervisor, and updating the compiler to emit the new
| sequences. To make sure that developers didn't introduce
| code sequences that uses lwarx/stwcx in a way that would
| expose the bug (via inline assembly, for example), the
| loader would scan the code and refuse to load code that
| didn't obey the new rules.
|
| Interesting fact: the hardware bug existed in every
| version of the Xbox 360 ever shipped, because software
| needed to run on any console ever shipped, there was no
| advantage to ever fixing the bug since software always
| needed to work around it anyway.
| markus_zhang wrote:
| Thank you so much. This is so awesome to know and learn.
|
| I'm just curious, what are the instructions that replace
| the lwarx/stwcx "atomic" pair? From my understanding,
| basic you need to generate a pair of load reserved/save
| instructions, and you have to replace the pair with a
| series of instructions. But I don't understand why do you
| have to disable interrupts -- is it because actually
| multiple instructions were used to facilitate the load,
| and an interrupt may disturb a value stored in a
| register?
|
| Sorry I know little about assembly and arch.
| dinartem wrote:
| We still used the lwarx/stwcx pair to implement atomic
| operations, but to avoid the hardware bug a strict rule
| needed to be followed.
|
| Rule: On a given hardware thread (there are two hardware
| threads per processor on the Xbox 360), every lwarx
| reservation of an address _must_ be paired with a stwcx
| conditional store to that same address before a
| reservation is made to a different address. So a sequence
| like lwarx A / lwarx B / stwcx B / stwcx A is forbidden.
| But lwarx A / stwcx A / lwarx B / stwcx B is fine.
|
| So I changed the compiler to emit atomic intrinsics that
| obeyed this rule.
|
| But there was still the issue of logical thread
| scheduling. Imagine there are two logical threads
| running, one has a sequence of lwarx A / stwcx A and the
| other has lwarx B / stwcx B. The first thread is running
| on a hardware thread and just after executing lwarx A,
| the timer interrupt fires and the kernel decides to
| switch to the second logical thread, which executes lwarx
| B, and thus violates the rule.
|
| To make sure that never happens, the compiler also emits
| disable-interrupts / lwarx A / stwcx A / enable-
| interrupts. That prevents the scheduler from switching
| threads in the middle of the atomic sequence.
|
| But there was still one more problem. It is possible for
| a page-fault to occur in the middle of the sequence
| should it span the end of one page and the beginning of
| another, and the second page is not in the TLB. So the
| thread is running along and executes disable-interrupts /
| lwarx A, then when trying to fetch the next instruction
| it faults to the hypervisor because it isn't yet mapped
| by the TLB. The hypervisor executes a bunch of code to
| add the mapping of the new page to the TLB and then
| returns to the faulting thread to complete the stwcx A /
| enable-interrupts sequence.
|
| The problem is that the TLB is a shared resource between
| the two hardware threads of a processor, so the two
| hardware threads need a way to atomically update the TLB,
| and the obvious way to do that is to use a spin-lock that
| is naturally implemented by a lwarx B / stwcx B pair of
| instructions. But the hypervisor TLB handler can't use
| those instructions because the code causing the TLB fault
| might be in the middle of using them and thus would cause
| the hardware bug to manifest.
|
| The solution was to use non-reservation load/store
| instructions to implement a simple spin-lock. If the two
| hardware threads were both trying to update the TLB then
| hardware thread 2 would simply wait for hardware thread 1
| to clear its lock before proceeding.
| bananaboy wrote:
| Amazing! Thanks for sharing! What sort of things are you
| working on now?
| kridsdale1 wrote:
| This is the coolest HN post I've read in months.
|
| Cheers.
| brokenmachine wrote:
| Kick ass. This kind of post is why HN is the best.
| n144q wrote:
| > we knew that the custom CPU would not be available until
| early 2005
|
| Sounds a little bit like the situation with Xbox Series?
| The SDKs were released late because Microsoft was waiting
| for certain features in AMD APU
| Zeetah wrote:
| You have an awesome memory, Dinarte!
|
| Eric Mejdric from IBM called on Friday and said we have the
| chips, when are you guys getting here?
|
| I took a red eye that night and got to Austin on Saturday
| morning.
|
| We brought up the board, the IBM debugger, and then got
| stuck.
|
| I remember calling you on Sunday morning. You had just got
| a big screen TV for the Super bowl and had people over and
| in-between hosting them you dropped us new bits to make
| progress.
|
| I think Tracy came on Sunday or Monday and with you got the
| Kernel booted.
|
| Good times!
|
| This is Harjit by the way.
|
| Edit: added super bowl.
| saturn8601 wrote:
| OMG Harjit! I saw you in the documentary! You and the
| entire team are total rockstars! I just cannot fathom
| ever being in a position to design something that
| provided so much joy and happy core memories to countless
| people around the world...you guys did it!
|
| Just the thought of how many people you touched with your
| work....just amazing! :)
|
| Had a question if you don't mind: Can you talk about the
| thought process behind the power supply design? Its very
| large even in the super slim models. Were you following a
| specific design driven by the hardware architecture or
| were there other reasons? I always wondered about that.
| maroonblazer wrote:
| >I saw you in the documentary!
|
| I presume you're referring to this one:
| https://www.xbox.com/en-US/power-on#watch
| saturn8601 wrote:
| Yes! It is worth watching every second. What an amazing
| production.
| dinartem wrote:
| Actually Tracy never made it to Austin. He was going to
| fly in later in the week to continue bring-up, but since
| we were done by Wednesday, we just sent the chips to
| Redmond and he continued there. He was of course always
| available on the phone to answer my kernel questions I
| had.
| saturn8601 wrote:
| You sir are an inspiration! I am but a mediocre Angular
| developer and reading this has me in complete awe! The kind
| of drive you must have had to get this done well I dont
| know how people manage to do it but it is so cool to see!
| :)
| markus_zhang wrote:
| This is really some blast from the past. Can you please
| shed more light on the simulator? Is it interpretation or
| JIT? But then I realize XBOX uses Pentium III, so maybe
| virtualization? _Edit_ Sorry it was XBOX 360 so it 's not
| Pentium.
|
| As someone who recently got interested in emulation and
| wrote two lc-3 emulators, would really love to learn from
| the masters.
| cbanek wrote:
| Small world! I worked on Yellow Door / Golden Gate
| automation for releasing 360 titles and patches to prod,
| and the beta group / KDC service code.
| dvdbloc wrote:
| What was the culture like working on this project and back in
| those days? I've always been fascinated by the development of
| consoles, especially the story of the 360. Any sources you
| recommend to learn more? I thought the Microsoft documentary on
| Xbox was the best I've found so far.
| jolan wrote:
| The Winchester revision is still considered unhackable afaik.
| It's crazy how many Xbox 360 revisions there were compared to
| other consoles.
| saturn8601 wrote:
| Was it ever explained why? This was an unanswered question I
| always wondered about from time to time. They must have done
| something to remove RGH capability?
| jolan wrote:
| Yes that revision is patched to specifically counter RGH.
| Microsoft disabled the ability to get the precise timing
| needed from the CPU and also added more
| filtering/robustness so the system will reset properly
| instead of getting into the inconsistent state of the old
| revisions.
| LPisGood wrote:
| I'm surprised this was a task that only took a single
| developer!
| cbanek wrote:
| Having a single developer allows fewer offices with their
| windows completely covered with newspaper. Plus, there's one
| person doing everything, which can be a lot better than two
| with people who have different ideas of how to make the
| system work together.
| dhx wrote:
| Have you seen Tony Chen's (development lead for Xbox One
| security) description of the Xbox 360 reset glitch hack at [1]
| and the effect this (and other console exploits of that time)
| had on Xbox One development?
|
| This is one of my go-to case study videos for the development
| effort required to architect a computer to resist attackers who
| have physical access.
|
| [1] https://youtu.be/U7VwtOrwceo?t=536
| landr0id wrote:
| Wait until you read Grimdoomer's (yet to be published) write-up
| on his recent hypervisor exploit that works on the latest OS:
| https://x.com/grimdoomer/status/1847497275289063676
|
| It's going to be a doozy
| Dracophoenix wrote:
| How did you feel about teenagers and college students
| exploiting holes in your work? Were you impressed,
| disappointed, amused, etc.?
|
| Oh and I'd just like to say thank you for your contribution to
| my childhood/adolescence.
| kaoD wrote:
| > Note - Newer revisions of XBOX 360 has no access to CLK and you
| must use Matrix oscillator
|
| If there's no CLK line on the mobo, does this mean newer X360s
| have everything that might be clocked (I assume at least CPU, GPU
| and V/RAM?) in a single chip, SoC-like?
| 15155 wrote:
| I'm not aware of any reason nor modern computer system that
| would have these things clocked by a common clock line of any
| kind.
|
| Today, GPUs connected via PCIe or the like use 8b/10b coding
| over differentially-signaled pairs. The signal itself has clock
| recovery.
|
| (V)RAM is generally clocked at a different frequency than the
| CPU as well, and all DDR utilizes strobes to determine when
| data is valid because access time is variable.
|
| In some SOCs/FPGA-based devices, a central clock generator will
| sometimes provide LVCMOS/HCSL/LVDS/etc. clock lines to each
| device, but these aren't often re-used. This allows for
| flexibility and later programmability. There's generally no
| assumed phase or frequency relationship between these derived
| clocks and the original source - especially after the signal
| has traveled 20cm across a board.
|
| In the case of a CPU/GPU, though, a 20 cent crystal oscillator
| at each device feeding into internal PLLs is typically the go-
| to.
| 14 wrote:
| Fun thinking back to the days of cat and mouse between MS and
| hackers so many cool things went down. My favorite being hackers
| making custom firmware for certain dvd burners so that you could
| burn right to the very edge of 7.5gb discs and make 8gb games
| that MS started using. Truncated games were being detected and
| then hackers came up with this idea it was so genius.
|
| Then came along the reset glitch hack and I moved away from discs
| to an external hard drive and never looked back. I did a few for
| me and a couple friends. The soldering involved was pretty
| precise in the fact that it was a very very small pad you needed
| to solder to and if you screwed up it was very easy to lift the
| pad and putting yourself into a big heap of trouble fixing it. I
| was also using a crappy $15 soldering iron with a bad tip because
| I was poor. But never did I have an issue. Depending on your
| install you could get the glitch to happen sometimes on the first
| reset or for some it took multiple resets. I was happy because
| all mine seemed to work first if not second reset which a lot of
| people struggled to get. I still have my rgh 360 my kids have it
| with a hdd full of games I backed up from my own games you know.
| jackjackk0 wrote:
| If you are not familiar with the fascinating story behind it, I
| recommend this podcast episode [1], it's one of my absolute
| favorites (along with its sequel)! I found out about it on this
| very forum a few years ago, hope to propagate the favor to
| somebody else out there.
|
| [1] https://darknetdiaries.com/episode/45/
| Aurornis wrote:
| Fun article. One note:
|
| > I have a Saleae 8 channel 100Mhz, which turned out not to be
| fast enough > I found a not too expensive 200Mhz Kingst LA2016
| Logic Analyzer on Amazon
|
| The author is confusing MHz with MS/s (mega samples per second).
| Salaea has a logic analyzer that works on 100MHz signals (with
| 500 MS/s), but I suspect the author had the unit with 100 MS/s
| that only works up to 25MHz signals.
|
| The cheap Kingst unit has 200 MS/s but only works with signals up
| to 40MHz.
| SyncOnGreen wrote:
| > Generating VERY precise timing and pulses, you need FPGA's or
| CPLD's
|
| Back in the day, I managed to create a working RGH modchip based
| on Atmega8 (8 bit micro) running at 20 MHz with hand-crafted
| assembly code. I named it RWH (Reset Witch Hack) and it was able
| to boot Xbox 360 Jasper in 1-2 minutes. Old motherboards had a
| physical pad on the motherboard allowing for slowing down the
| CPU, so no i2c was required. I also have to connect the whole 8
| bit POST bus to read the current value in one instruction.
|
| PCB was made at home, and since AVR is 5V system, I used NPNs for
| voltage conversion (all values were inverted in the software).
|
| Why? I didn't have money to buy the "real" CPLD modchip.
|
| Rush and happiness when it first booted - priceless.
|
| I still should have the source code for it somewhere on backup.
|
| photos:
| https://gist.githubusercontent.com/JaCzekanski/c02ed11c30fac...
| https://gist.githubusercontent.com/JaCzekanski/c02ed11c30fac...
___________________________________________________________________
(page generated 2024-12-20 23:01 UTC)