With most books, I find that the 100 pages could have been condensed into 5. That's not the case with Hacking the Xbox, I'm happy to report. It's MIT culture that produces this kind of writing style that is a joy to read.
That being said, these are the specific things I'd like to remember :
He started with an Apple II when he was a kid, but references to Apple end there. Thank God! No credit anywhere to Steve Jobs:)
His best advice to aspiring hardware hackers is to be persistent and to be thorough. Persistence and thoroughness come naturally if you love what you are doing.
Plenty of gems on soldering - kapton tape, chip removal alloy. Naprotek assembles BGA packages, etc. If you didn't know how valuable flux was before, you will after reading this one. I once struggled with some soldering and then the tech did it easily. I saw him use flux and said, "so that's your secret." His response, "Dude, it's no secret."
FPGAs are excellent choices for implementing cryptographic functions if you are interested in doing brute-force keysearches or encrypting large amounts of data quickly. Really?
FPGAs can interface with just about any signaling protocol - remember that - you can talk to just about anything.
Basic programming skills to be able to build yourself simple tools to analyze data and netlists are worth developing.
Intuition, pattern matching and experimentation are the core skills of the hacker.
Starting young and taking time and trying out a lot teaches you the value of thinking ahead and envisioning the final result. You do the hard work upfront only if you know the value of the hard work. If you're an employee, you won't value that kind of effort - which is what I saw in my co-workers - they never took the trouble to pick up valuable skills or decide to be knowledge sponges.
Before you start laying out your PCB, order all of them components - you'll find some that you took for granted aren't available. All you'll need is a simple change. Before you ship the layout for production, print it out actual size and place the components on there. Any gotchas?
You get the sense that this guy could see the bits and bytes of a printed out gif file and reconstruct the image in his mind.
FPGA timing models are conservative - worst case. If you know what you're doing and can figure out that you're being limited in frequency because of skews between related signals, then you can cleverly insert delays in select paths (delay elements) and recover and extract much higher than advertised speed (Pg 242).
Considering how much debugging I'll be doing in the months ahead, this one will serve me well : as a general rule, you should observe at least two, preferably three, symptoms that are consistent with a cause before concluding that you have found the root cause. So, how to apply this proactively? Easy - during the design, be grateful for every time the simulator said "doesn't work" - and record the symptom and the root cause. Collect these. Then, in the end, collect up the root-causes and symptoms - this kind of effort is the LEAST you can do.
No comments:
Post a Comment