Basic HU Unlooper Added Circuit
Below is the basic circuit we have started with. It is currently, here, in block diagram. This circuit replaces many strings of high speed counters and multiplexers for glitched vcc voltage. While we could have eliminated the counters in the RAM circuit, they may prove useful, later.
The DAC is programmed via the 32K high speed cache ram. The clock for it's programming can be a multiple of the Unlooper clock/Atmel clock. (We may run the unlooper clock at higher speed and divide down to run the Atmel. (Not sure yet).
The cache ram (15ns. static) is programmed via the Parallel port. The ram is set to write, data loaded, and set to read for the DAC. At this point, the Ram data controls the glitching sequence of the DAC. The DAC can also sync the normal glitching sequence from the Atmel/multiplexer output of the Unlooper and add the new glitches. This is much more precise that not syncing them. The DAC can also control the clock line to the card, over clock seperately or in conjunction with the Atmel code. Any daughter board clock line glitch is just added in without any problem.
The above circuit is able to supply as many as 8 stable negative glitches per clock cycle if needed. Their width and depth can be programmed from software to the parallel port. (This assumes the card being clocked at 4.6mhz.)
In preliminary tests, the above circuit can glitch over all of the startup routine if necessary and still glitch over the entire jump vector table of the eeprom without even breathing hard.
The entire circuit is, for all intents and purposes, the reverse of the circuit used in a high speed memory scope.
While there is no right or wrong way to do what this circuit does, it was the simplest way, without a complete rewrite of all existing software that only talks to a serial port. There are many possibilities. The reason for making the circuit a minimal connected add on was to allow existing unlooping and glitching functions to remain the same and allow the circuit to be switched in and out of circuit. In theory, the circuit could be run from the serial port if more chips were added to the circuit. What we have done, so far, was simply to replace my strings of high speed counters and combiners with a circuit using a lot fewer chips and using no custom logic. While an AVR (PLA) could be used to supply the glitching....say for an ECM'ed card, reprogramming the logic would be beyond the ability of most users as the software is not easy to understand. Also, the fixed PLA method does not allow any variation in function, easily, although it does work very well to glitch over a precise set of instructions or area of an eeprom on the existing cards.
To attack an HU that was ECM'ed what you have to do is as follows:
1. You will have to glitch over the corrupted Jump Vector part of the card.
2. You will have to flush the ram. This is because the ECM packet is still there and will overwrite the jump vector if the code executes again.
3. You will have to write the bootloader over the jump vector part of the card and change the execution and call points to the bootloader to match. You will also have to replace the cleanup code normally used with the bootloader to rewrite the jump vector area you wrote the bootloader to.
4. Remember, these cards are not FF'ed and the WDT is working just fine. The above can be done with a modified Eclipse script with the exception of glitching the jump vector tables which must be done with the new hardware addition.
At the present time, there is one group looking at the use of multiple Atmels and combined multiplexers to do the same thing. In theory, this may also work. As I said, there is no right or wrong way to do this. I have played a little with this method but did not have good results. JUST BE AWARE THAT ANY ATTEMPT TO SELL YOU AN UNLOOPER WITH MULTIPLE ATMELS AND STRANGE AND CLOUDED CLAIMS THAT IT WILL UNLOOP AN HU CARD SHOULD BE TAKEN FOR EXACTLY WHAT IT IS WORTH......Which at this time is nothing.
Page updated July1, 2001
