Hacking the Xbox

248
Hacking the Xbox: An Introduction to Reverse Engineering
what to expect, but enlightenment only comes after you have read the
component data sheets. The more you understand about a system, the
easier it will be to figure out why things went wrong. Keep notes as you read
more about the system, and think to yourself about ways problems might
express themselves if something did go wrong. It also helps to have seen
other systems that are similar to the one you are trying to fix, and it helps to
have an understanding of the theory of operation.
Observe Symptoms
Bugs manifest themselves through symptoms, and it is up to you to
deduce the root cause by observing several symptoms and deducing the
culprit. A blank screen on a TV that should be showing the video output of
your console is an example of a symptom. There are many reasons why
your TV screen could be blank, such as a broken video cable, a broken TV, a
broken video connector, a broken video source, blank media in the video
source, or even lack of power to the system. 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. Keep in mind
that the most telling symptoms are often not outwardly obvious, and will
require a measurement or an experiment to find them. In the example of
our blank TV screen, our measurements are as simple as seeing if the power
light on the TV turns on, or if sound comes out of the TV without the
video.
The basic strategy for debugging is to start with an obvious symptom and
isolate various parts of the system to determine which part is the immediate
cause of the symptom. An immediate cause is defined as something that
directly impacts the observed symptom. Immediate causes for video failure
on a TV are lack of a signal to the TV, a broken TV, or lack of power; nonimmediate
causes would be a hardware failure in your video source or the
phase of the moon. In other words, given symptom A, think of all the
possible immediate causes X, Y, and Z, and then test each to determine
which is the actual cause. Once you have isolated the problem, think about
what might have caused it to fail and repeat the process until you have
discovered the root cause.
Isolating the cause of bugs can be facilitated by the use of known good
references. In our example, you can eliminate the TV as a source of failure by
feeding it a signal from a known good DVD player. In order for a known
good reference experiment to be valid, you must keep everything constant
except for the piece you are replacing with the reference. Plugging the good
DVD player into a different input from the consoles’ on the TV will only
tell us that the display part of the TV works. The path from the console
input to the TV is not tested. A proper execution of the experiment would
plug the DVD player into the video input used by the console.
This kind of paranoia or inherent mistrust of the system becomes very
important when tracing down subtle hardware bugs. Do not take any
factor for granted that could affect the system you are observing, and