Sunday, January 16, 2011

Cop challenge, part 1

1. Debug mode?

Check end of ROM space:

(r) 0x7ffee
(r) 0x7fff2
(r) 0x7fff6
(r) 0x7fffa

(r) 0xffff in all above cases = content of ROM (unused space filled with 0xff byte)

I bet that dev system has RAM in place of ROM, so "cop" reads data from end of ram, set by developer (debug mode, whatever).

Also, there's ROM mirror at 0x80000 (as exepcted = max rom is 0x100000)

2. Content of reg 1a4

(w) 0x10043e, 0x0000
(w) 0x100474, 0x0a00
(w) 0x10042c, 0x00ff
(w) 0x100436, 0x0003
(w) 0x10042c, 0x00ff
(r) 0x1005a4
(r) 0x1005a4
(r) 0x1005a4
(r) 0x1005a4

1st test

no write = returns 0000

(w) 43e,0000 returns 0
(w) 43e,0000 (w)474,0a00 returns 0
(w) 43e,0000 (w)474,0a00 (w)42c,00ff returns:
00d9,00f9,0019,0039 (another read)
0043,0063,0083,00a3 (another read)

Difference between n and n+1 reads is always 0x20 (32 dec)

2nd test
(after 42c=ff):

(r) 5a0 = 0023
(r) 5a2 = 0043
(r) 5a4 = 0063
(r) 5a6 = 0083

Mirrored ?

3rd test
(after 42c=ff):

(r) 5a0 = 009b
(r) 000 = xxxx (result doesn't matter)
(r) 5a4 = 00db
(r) 5a6 = 00fb

Added "fake" ram read between cop regs read to check if data change is triggered by cop reg read. It's not (otherwise 5a4 should be = 00bb)

4th test
- same as above, just read from the same cop regs (5a4). Results identical.

68k code for read word:

move.l (a3)+,a4 12 cycles
move.w (a4),d2 8 cycles
move.l d2,(a3)+ 12 cycles

(four above reads = one unrolled loop, so no extra code between reads).

Each read takes 12+8+12 = 32 cycles. Sounds familiar ?

5th test

(w) 7f to 10042c reads changed - (to range 0-7f), so it's a counter mask. 8 bit (no difference between mask 0x1ff and 0xff)

6th test

Uhm.. is the above mask or maybe a max counter value ?

When 10042c is set to 0x89, data reads are : 003d 005d 007d 0013.
It's max counter val (after reach 0x89 it wraps back to 0)

7th test

Is reg 2c (10042c) readable ?

Yes, it is.

8th test

Is the reg $1a2 writable ? Nope. Nothing happens (no counter reset.. nothing).

9th test

writes to 43e,474,436 - no difference in results

COP regs $1a0-$1a6:
4x mirrored cpu cycle counter mod ( ((reg $2c )&0xff) +1)

3. DMA register read-back

(r) 0x10047e

read 0x0015 as expected

Maybe it returns DMA num(or id) when data transfer is completed, otherwise - something else (0 ? ff ? )

Monday, January 18, 2010


Mentioned early macros 105/b05 are used for (probably) simple data copy
from one mem location to another. No idea (yet) if teh data is chanegd after read/before write.

- 105:
trigger 0105 - unk 0006,fffb

Seems to be reading two WORDS from mem address stored at $4c0 and copy to mem location defined in $4c2

- b05:
trigger 0b05 - unk 0006,ffdb

Looks like extended version of 105. It's operating on 4 WORDS (address
in $4c0) and copies some (all?) of the data to address defined in $4c2 and $4c4.

4 WORDS = counter, 0, data1, data2

Here's some dasm code from zero team with comments:

mov ax,0h
mov [4A0h],ax
mov [4A2h],ax
mov [4A4h],ax
mov [4A6h],ax COP writes, unknown

mov di,0C000h data tables area
mov [di],ax
mov [di+2h],ax
mov [4C6h],di start of tabele address -> COP
mov bx,640h offset of COP crt/video area
mov word ptr [bx+56h],0A9h 696 ?
mov word ptr [bx+5Ch],5h 69c ?
mov word ptr [bx+52h],0A9h 692 ?
mov word ptr [bx+5Ah],140h 69a ?
mov word ptr [di+4h],0F000h f000->c004
mov word ptr [di+6h],0h 0000->c006

mov word ptr [4C0h],0C004h macro arg 1 = src offset
mov word ptr [4C2h],6A0h macro arg 2 = address in cop ram, where to write data
mov word ptr [500h],105h MACRO 105 CALL (copies data from oen address to another?)
mov word ptr [di+4h],0h 0000->c004
mov word ptr [di+6h],8000h 8000->c006
mov word ptr [4C0h],0C004h macro arg 1 = src offset
mov word ptr [4C2h],6ACh macro arg 2 = address in cop ram, where to write data
mov word ptr [500h],105h MACRO 105 CALL
mov si,di
add si,830h offset of the _SECOND_ (40h ) tab
mov word ptr [4C2h],6B8h 2nd arg? dest address
mov [4C0h],si 1st arg = offset of the table
mov word ptr [500h],105h 105 command
add si,4h sizeof(WORD*2) -> macro is operating on two 16 bit (word) data pointe dby the arg 1

mov cx,40h num of entries in table
mov word ptr [4C2h],6BCh dest 1
mov word ptr [4C4h],6B4h dest 2

mov [4C0h],si arg = address in mem
mov word ptr [500h],0B05h macro b05
add si,8h add size of table _entry_ ( num, 0, data, data)
loop loop10F0685h

mov si,di
add si,30h start of 1st table
mov cx,100h 100 entries
mov word ptr [4C2h],6BCh same as above
mov word ptr [4C4h],6B0h different
mov [4C0h],si address
mov word ptr [500h],0B05h macro b05
add si,8h next entry
loop loop20F06A8h

mov si,di
add si,20h points to prepared data (encryption keys?)
mov cx,4h
mov word ptr [4C2h],6A8h
mov [4C0h],si
mov word ptr [500h],105h
add si,4h
loop loop30F06C5h

mov si,di
add si,8h
mov cx,6h
mov word ptr [4C2h],6A4h dest address
mov [4C0h],si src address
mov word ptr [500h],105h
add si,4h
loop loop40F06E2h
mov word ptr [di+4h],0h
mov word ptr [di+6h],0h
mov word ptr [4C0h],0C004h src address
mov word ptr [4C2h],6ACh dest address
mov word ptr [500h],105h simple copy ?

mov ax,1000h
mov [470h],ax gfx bank related ? somethign with screen flipping
mov ax,0h
mov [470h],ax

mov cx,51Ah
xor ax,ax
rep stosw

Sunday, January 17, 2010

Suicide Revival kit

Few words about Zero Team Suicide Revival kit.
How it works ?
1. Fills COP region 740-77f with $ffff data
2. Uploads two unique "macros" to COP:

- trigger 0105 - unk 0006,fffb - offset 0000
data 0180,02e0,00a0

- trigger 0b05 - unk 0006,ffdb - offset 0008
data 0180,02e0,00a0,0182,02e0,00c0

3. COP writes (dma/clear/videoram realted)

2000 -> 43e unknown (both accessed always before dma param change)
1e00 -> 474

(tilemap dma)
0014 -> 47e (type/slot = tilemaps)
02c0 -> 478 (2c0<<6 = $b000 = src)
027f -> 47a (len)
0000 -> 47c
(palette dma)
0015 -> 47e (type/slot = palette)
0380 -> 478 (380<<6 = $e000 = src)
00ff -> 47a (len)
0000 -> 47c

4. Tool code is creating data table at mem location $c000
- 6 pair of WORDS copied to $c008-$c01f

0000 BAE1
0000 7BBB
0000 75C9
0000 7B67
0000 26EA
0000 B7B9

- 4 pairs of WORDS copied to $c020-$c02f:

0000 0000
0000 A732
0000 B9B7
0000 6D9B

- loop that builds big data table. Every entry is 4 WORDS long:
There are 256 entries (counter starts from 0, ends at $ff)
Data are copied word by word from ROM :

So at the end, data table in RAM looks like:

- two WORDS = 0 stored at the end of table (at $c830 and $c832)
- another data table at $c840, same structure as the previous one, but shorter (only $40 pairs of data, mostly $ffff):

Does these tables looks familair ? $100 and $40 ?
Maybe sprite encryption data tables ?

5. A bunch of COP writes.
Code executes previously uploaded macros with pointers to the data tables
as inputs. Why? No idea. Upload to battery backed ram ? Could be...

6. At the end we can see a msg :

Layer enable

(assuming garbage = sprites?)

$10065c = 0000 (txt on, garbage on)

(small part of the garbage is dispalyed under text layer, rest - over)

$10065c = 0010 (txt on, garbage off)

$10065c = 0018 (txt off, garbage off)

$10065c = 0008 (txt off, garbage on)

I/O mirroring

I/O (dsw,inputs) area is mirrored 4 times:


First shot is from yesterday. $5bx contains some kind of (macro related)flags.
After "executing" a macro, data $5b6/$5be flashed (8010->0000->8010)
also some bits (15th?) in $5b0/$5b8 changed (depending on macro(results?))

But now. after few tests, and after playing with macros.. mem looks like
on the other pic .. there's always $8007 and $b4fa .. wtf ?
(heated barrel works without problems, after swapping roms, so wtf x2 ?)




Ok, here's pic of the HB pcb (with flashroms instead eproms).
Works fine.. so far.

Where's the protection device?
Good question. Looks like whole system hw is one big "protection".
Probably it's the SEI300 chi near 68k (with "TAD" sticker).
It's Toshiba gate array TC25SC gate array.
TC25 features (accordig to 'CMOS ASIC Design Manual' from Toshiba) :
- embedded megacells
- analog megacells
- MPU core (Z80 compatible)

Toshiba cell lib includes:

• 16 x 16 multiplier
• 8-, 16-, 24-, and 32-bit adder/subtractors
• 32-bit, 2-operand full adder
• 32-bit, 3-operand full adder
• 16- and 32-bit barrel shifters
• 8-bit ALU
• 8-bit CLA
• CRT controller
• Direct memory access controller (DMA)
• Programmable communications interface (PCI)
• Programmable interval timer (PIT)
• 8-bit programmable peripheral interface (PPI)
• Programmable interrupt controller (PIC)
• 4-bit microprocessor slice
• Carry lookahead generator
• Microprogram controller
• Graphical memory (256 x 24)

And others. No idea whats used in SEI300.
Of course there's more custom chips on the pcb, so there's possibility that
the protection (or rather - system features (dma, mcu(?), video) is "spreaded"
across them.

Btw. would be nice to read this