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 512K 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 (7ns. 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. All that is missing at the current time is a complete list of the timing for all of the instructions being executed. Without these, in it's present form, this prototype does work but is very dangerous to experiment with on a good card as one mistake can seriously loop it. We are currently syncing this circuit to the standard glitch sequence used by the loader part of the circuit and to the software used to control it.
The entire circuit is, for all intents and purposes, the reverse of the circuit used in a high speed memory scope.
The circuit has been modified somewhat to make it glitch more precisely. We have increased the amount of cache ram used and incorporated a mixer circuit for the loader glitches and the new circuit glitches. We moved the clock for the card back to the 74HC4053's and daughter board circuit to simplify interconnection of the glitching circuit.
The high speed clock is simply one of the SN7404 oscillator circuits using one 1K and 2- 270 ohm resistors. It operates at 18.432. One more gate was utilized to send the 18.432 that runs the loader, to a quadrupeler circuit that gives us our 73Mhz.. It is very stable as everything runs off the same crystal. The counter chain was replaced by a PLA (AVR) device because of too much delay in the discrete counters. The glitching is now very precise and with the proper DAC programming, a bit can be glitched at any point on the card or any instruction, assuming that you know the number of clock cycles it takes for the instruction to execute.
I have moved from C++ for the programming of the DAC. As time permits, I will put up the Database program prototype that we have been using to program it. You can address the glitch points, set the voltage and glitch width and clock cycles required and this saves the data to a database. The companion program reads the database and loads the DAC via the Parallel port.
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 in the usual sense and the card is still functional. 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 this device was designed to be used with a data logger that intercepts communication between any device and an HU card. This works in conjunction with a program that allows it to duplicate virtually any loader, locker, or whatever. I have worked with all of the current scripts that work with a normal loader. A lot of the timing was created from this device. While I do use it, I don't recommend you try to build it unless you think you have a need.
Page updated April 22, 2002
