You don't really need any tutorials. You can use the flash that is publicly available, and the hardware design that is being sold as is. It's all been done for you! You can thank an incredible h/w guy by the name of "no1b4me". His contributions to the NA testing scene (DTV and Nagra) are legendary.
I dug up the following that was buried DEEP in my archives. It was written by AOL6945, a great tester who got busted, and rumour has it is now working (enslaved to?) DTV. Probably one of the best posts ever written on glitching. Keep in mind that it was written quite a long time ago, and is re: DTV cards (the HU) - not Nagra. But the concepts are still valid today. Enjoy.
----------------------------------------------------------------------------------------------
Technical Aspects of Glitching
Glitch Definition
What is a glitch? There are two main signals going into the card that we can control from the outside. First is the card's power supply, Vcc. It is supposed to be a DC value of a constant 5V. Second is the card's clock signal, which is supposed to be a square wave alternating between 5V and 0V with a frequency of 4.608MHz. A glitch can be defined as any intentional sharp change in either of these signals.
One type of glitch that can be delivered is the voltage glitch. For this glitch, the input voltage (Vcc) to the card is dropped to a middle value (around 2.5V) for approximately 1/2 of a clock cycle or less. (In a few cases, longer, approaching 1 clock cycle).
Another type of glitch that can be delivered is the clock glitch. For this glitch, the clock signal is sped up to around 4x it's normal frequency (in this case, approximately 18.432MHz), for approximately 1 "normal" clock cycle. This causes the clock signal to go through 4 alternating transitions during the time period when it would have normally only gone through one.
Glitch Effects
What do these glitches do to the card? Each of them affects the card slightly differently:
The clock glitch can have an effect on internal registers/data latches within the card. Most data latches or registers consist of D Flip-Flops. For a D FF to latch a value (a bit), the bit must be present on the D input for a certain period of time (known as the set-up time, or hold time). If the D FF is clocked before the bit has been present at the D input for a long enough period of time, the D FF will fail to latch that bit. When the clock is sped up in a clock glitch, any registers/data latches in the microprocessor that are due to latch a valus from an internal data bus will likely fail to latch that value, resulting in no data movement to the intended register. Virtually any internal register in the microprocessor can be affected like this, including the A and B registers, and most importantly, the Program Counter (PC).
The voltage glitch can have a similar effect. Both TTL and CMOS logic elements require that an input voltage be in a certain range in order to recognize a value as a logic "1" or logic "0". If the voltage is out of range, the effect on the logic element will not be as intended. For a standard 5V logic system, voltages above 3.8V or so are considered a logic "1", and voltages below 0.8V are considered a logic "0". In a voltage glitch, the voltage across all circuits in the card is dropped to the "no-mans-land" middle range of 2.5V or so. Logic elements like those in flip-flops are attempting to sample a value and latch it, but are now forced to deal with a value that is neither a 1 nor a 0. The result is that they usually fail to latch a new value, and simply retain their old one. This can cause the same effect as the clock glitch - a failure to move data to a different register inside the microprocessor.
Using Glitches Effectively
OK, so now that we know what a glitch does and how it does it, how do we use this to our advantage? When the card starts up, it begins executing it's software program in ROM. Naturally, the program is intended to only perform certain functions and disallow all others. These glitches, however, if applied to the card during it's execution of a certain machine instruction, can cause that instruction to fail to do what it was supposed to do. This can cause the card to behave in a manner inconsistent with it's intended function.
Glitches like this are used in the HU loading process to do a few things that allow a bootloader to be loaded onto the card. Once the bootloader (which is a short program running in RAM) is loaded and has control, the bootloader will communicate with the outside world instead of the card's routines, and allow unconditional reads and writes.
WildThing Unlooper/Atmel Code Glitching Capabilities
The standard WildThing-style loader/unlooper delivers different variations of these glitches to the card upon command. The Atmel on the unlooper has 5 different glitches it can deliver:
Cmd 0A: Clock glitch. Speeds up clock to 4x normal value for 1/2 of a normal clock clock cycle. Not used during HU loading.
Cmd 0B: Voltage glitch. Drops voltage to the DAC value for 1/2 of a normal card clock cycle. Not used during HU loading. This is the glitch used to "boot" black sunday H cards.
Cmd 09: Glitch voltage and clock simultaneously for 1 full card clock cycle. Used as the 1st glitch in the HU loading process.
Cmd 0C: Glitch voltage and clock simultaneously, delay a few clock cycles, and then glitch the voltage and clock simultaneously again. Used as the 2nd/3rd glitch in the HU loading process. The H-card version of the Atmel code does not glitch the clock with this command, it glitches voltage only.
Cmd 0D: Glitch clock, delay a few clock cycles, and then glitch voltage. Used primarily in H unlooping process by all H unlooping programs.
As you can see, the Atmel code can do several different variations of glitching on the card.
Glitch Timing
Even though we have all of this capability to apply the glitches, they will not at all cause the card to do what we want unless they are perfectly timed. By perfect timing, I mean that not only does the glitch have to come on a certain clock cycle, but that the glitch pulse must be applied at a certain point within the clock cycle in order to be effective. This is what the daughterboard is used for on real HU loaders. The daugherboard moves the glitch pulses into the clock cycle a little more than a standard unlooper will deliver. This is more effective on the HU cards.
The HU glitch sequence to get the bootloader on the card has such critical timing that it was necessary for the HU loader developers to modify several parts of the Atmel code to adjust the glitch timing. Even the serial byte send/receive routines were modified to make the glitch timing come out correctly. What this boils down to is that the HU glitch sequence is really only barely delivered by the Atmel and the current glitching hardware.
Two factors can be spoken of when talking about the hardware's glitching capabilities. One is the glitch accuracy. Glitch accuracy is the ability to place a glitch where you want it. The Atmel can be programmed through it's assembly code to place a glitch at 1/2 card clock cycle accuracy. This actually isn't enough for the HU card, and that's why the daughterboard had to be added. When instructed through external software via unlooper protocol, however, the Atmel can only place a glitch within about 4 card clock cycles of the desired location, far too inaccurate for HU glitching, and also causes H unlooping to be somewhat hit-or-miss.
Worse for the Atmel is the other factor, the glitch resolution. Glitch resolution is the frequency which glitches can be applied to the card as well as the glitch pulse width. The Atmel, even if programmed in hardcoded assembly, can only place glitches at 1/2 clock cycle positions and the pulse widths must be in multiples of 1/2 clock cycle. This doesn't affect the HU loading too much, but is too inaccurate for HU unlooping.
I am of the opinion that HU unlooping will not be possible with current hardware because of those factors.
The reason that glitch timing is so critical is that in order to cause a machine instruction executing on the card to fail in a manner that you want, you must glitch at a particular clock cycle of it's execution. For example, the H card's "cjne" instruction takes 12 H card clock cycles to execute. A voltage glitch on clock cycle 10 of that instructon will cause the instruction to not ever take the jump, regardless of the values being compared. (This is how black sunday H cards are "booted"). Glitching on clock cycle 9 or 11 will not do this. This should show everyone that glitching and unlooping is not about "confusing the cards protection", or "stuffing the fixbin on the card". It's about perfectly timed, scientific methods to alter the cards program execution in a favorable way. A single clock cycle of error, and the bootloader doesn't go on the card.
HU Loading Specifics and Dangers
The HU card load sequence uses 3 glitches to get a bootloader on the card.
Appication of a glitch during ATR to cause the card to dump RAM. The RAM keys are recovered from the dump. (Glitch 1)
Send an INS 5E to the card to set up some registers, and at the end of the INS 5E, apply two critical glitches to prevent those registers from being overwritten with other values. (Glitches 2 and 3)
Send an INS 4C to write some values into RAM, pre-encrypting those values with the RAM key so that when they're stored in RAM, the encryption is reversed, and they're in RAM in plaintext form.
The bytes you just sent form a new stack, which makes some calls to allow some more bytes to be read in - the pre-bootloader.
When the prebootloader gets control, send the bootloader.
When the bootloader has control, you're ready to send commands to read and write EEPROM at will.
The glitches sent after the INS 5E are the glitches that are the most critical, and they're the glitches that are displayed in all the HU loading software ... i.e. "8C 1A", "8E 1A", etc. The 8C or 8E is the DAC value being used (voltage value for the glitch). The 1A is the delay between glitches 2 and 3. The glitch type being used in the Cmd 0C, which glitches voltage and clock, twice.
Now, there is another sequence of glitches in the HU software, the "8C 8E", "8E 8E" glitches, which have a different delay value of 8E instead of 1A. I traced this out in the HU code, and as far as I can tell, the 8E glitches are mistimed. They attempt to glitch at a different point than the 1A glitch, which could be successful, as the instruction they're trying to glitch would stop the register values from being overwritten, but the 8E glitch is off by about 4 clock cycles. I have a nagging feeling that this is one thing that can loop a card during the loading process.
The HU card is also extremely sensitive to the DAC value. A difference in the DAC voltage of 0.02 volts can mean the difference in whether a card will glitch successfully or not. This is why people are suggesting digital power supplies, etc. to try and get the cards to load. In reality, if the software would simply adjust it's DAC value to a voltage that works for your card/loader/power supply combination, it wouldn't matter. But everything is currently based off of HUPro, which tries these 8A, 8C, 8E DAC values only.
TurboUnloop and my Experience
Someone earlier in the thread asked what my experience was with TU and how many glitches I got a card to take. Well, thankfully, I only had 1 casualty during the development of TU - I Black Sunday'd a perfectly good H card. (Actually I didn't do it, SU2v2 did). But hey, that's life.
However, I do have 1 Black Sunday card that I test TU with. Every beta version and release version of TU has been developed, tested, and verified with this 1 card that I continue to intentionally loop and unloop with several different "killer" images that I have. This one BS card has been intentionally looped and unlooped over 200 times, and it still works.
Finally - An Answer to the Original Question
The original question of the thread was if cards are permanently damaged by extended or excessive glitching. That's a difficult question to answer given that we don't have any compilation of data. However, I view it like this:
Potential Damage to the Silicon
There is some possibility for damage to the silicon chip itself (physical damage) when a glitch goes awry. This would happen perhaps if the chip hardware were trying to write to EEPROM when a voltage glitch was applied. Performing an EEPROM write uses a good deal of current, and depends on a high-voltage generator circuit that is on board the silicon. This circuit makes 12V power from the 5V input, and the 12V power is used when writing to EEPROM. When voltage is glitched, this circuit is starved for power, and the resulting currents in some parts of the circuit can be too high, causing traces on the silicon to overload, overheat, and burn out, not unlike a fuse. The end result of this would be a card that can no longer write to EEPROM, thus making it useless. There are other mechanisms in the silicon that can potentially cause physical damage. However, I view these possibilites as low, since it requires a significant conicidence of circumstances to cause these problems.
Potential Damage to the EEPROM
A far higher possibility from extended glitching is further corrupting the EEPROM. As was stated above, if the glitches aren't properly timed, the results will not be what we want. Further, the resulting program flow through the card will be altered from what we intended to happen, possibly resulting in an unintentional EEPROM write. If that write occurs and corrupts values in EEPROM that are necessary for proper functioning of the card, it will likely loop the card. This occurs often with people using marginal hardware, because the glitch timing and voltage are off from what is intended. Combine this with the 8E glitches and you have a recipe for looping the card.
So, the bottom line on that is, if you have a good loader that is able to glitch the card on the 1st or 2nd shot every time, the question is moot. It is a non-issue. You will never have to worry about the effects of extended glitching on the card, because you're not ever glitching the card more than once or twice at a time.
If you have hardware that has to glitch the card for a long period to get in, you're going to loop some cards. That is not because the glitches are hurting the card, it's because your hardware is misapplying the glitches, causing random EEPROM writes.
Well, I believe I've covered everything. This should give you some insight into glitching and why it's not black magic. It's and exact and scientific process.
ATTENTION:
To all the newbies out there, This is one of the greatest minds in our hobby. You can take his words of wisdom or you can keep looping cards. All you need to do is read read read before asking so many questions.
Remember: **THE CARD YOU SAVE MIGHT BE YOUR OWN**
Thanx to aol6945