  INFO - FAQ - CC2-Forum - CCPro-Forum |
|
Hello Dietmar, Thank you very much for your post. > I didn't tried it yet with a GT16, but only with the QT4 and the QY4. If any wrong security byte have been transmitted, the controller is switched into a mode, in which the Flash works like an not implemented memory section. It seems the Flash is simply switched off. Maybe the difference make if the COP Control Register (COPCTL) on $ffff is first read or first written after reset. Yes, according to the flowchart in the datasheet, even if the key you give is wrong, you still have access to the monitor commands but they are limited. I haven't really looked into it but maybe there is a way to restore the access somehow by running code in RAM. Doing a "BSET #6, $40" may be part of the solution but there is probably more to it than just that. > AFAIK the only way to find the values of the eight bytes is to guess them or to use brute force. The latter might take very long. You're right, I wouldn't even try brute force. Guessing may work. BTW, is there a "default" key for C-Control or is it up to the user to pick one? IMHO there are also other ways. First off, I wanted to see the Monitor ROM because I was hoping that the Motorola guys would be clueless about security. Actually they do have a bit of a clue (at least). Let me explain. My idea was to make a timing attack on the routine that checks the key. If this routine is not time-constant, it is possible with a scope to find the key bytes one by one. Unfortunately, their routine is time-constant. At $FF43 there is the "bad guy" code (i.e. wrong key given, bit 6 at $40 is cleared) and at $FF3D it's the "good guy" code (i.e. right key given). The loop at [$FF20-$FF2C] checks the key bytes sequentially. If a bad byte is given, the PC will continue in a second loop at [$FF2E-$FF3B]. If you enter the right key, you always stay in the first loop and then jump to "good guy". When a wrong key is given, you fall into the second loop and go to "bad guy". The problem is that both loops have the same timing (NOP+CBEQ=5 cycles and AIX+BRA=5 cycles). This is a time-constant comparison. Whether you give the right key or the wrong key, the chip will always take the same amount of time to give you a reply. No timing attack is possible. I would almost bet that Motorola got once attacked this way... Since the timing analysis won't work, I can see two other attacks that could work but that are slightly harder. The first one is a differential power analysis. The idea is to make "fingerprints" of the power consumption of the chip with keys that cover all the possibilities for the first byte (256 tries). The power trace for NOP+CBEQ is certainly not the same as the one for AIX+BRA. The second one is to inject a fault (glitch on VCC or clock) when the PC gets to $FF3B (the given key is wrong so we for sure get into the second loop). With a bit of luck the BRA doesn't get executed and the PC will keep on straight in the "good guy" code. > At least in the MON08 of the QT4 and QY4 this command can write only to RAM and to registers. This command corresponds to a "STA ,X". But various registers must be set to delete and write to Flash. And it's time critical. Alternatively one can use the routines in the first ROM (FLASH PROGRAMMING ROUTINES ROM, address $1b50 to $1e1f). This makes perfect sense, the GT16 probably works the same way. > Let me know if you manage to patch the 2020. Sure... the bottom line is that it is more turning towards a hack of the chip itself than just the CM 2020... Thanks again TeK |
| Antwort schreiben |
Re: Voltcraft Charge Manager 2020 - Monitor Mode access (von Dietmar - 16.01.2006 20:36)Re: Voltcraft Charge Manager 2020 - Monitor Mode access (von TeK - 16.01.2006 21:59)