Lately I’ve been working on our trojan for the Raiden II board. Support for the trojan is in the latest UberMAME commits, under the name seicop. That name comes from what it does, it probes the SEIbu COPx-d2. It’s not specifically different from the Raiden II driver, the only change is how it handles the loading of the program ROMs (on Raiden II it has 2 interlaced ROMs. By interlaced, I mean, one ROM has the even bytes, the other has the odd bytes. The seicop driver merely changes this to be a single ROM with no modification.). Also, somewhat interesting to note, it appears MAME doesn’t fully reset the system, as the trojan currently keeps its state completely intact after hitting reset. Well, aside from the state of the sound CPU. Anyways, I’m a bit off topic, back to stuff about the trojan. The name of the trojan is COPper (interpret that either as the metal copper, or a policeman copper, but make sure you pronounce it like that!) and is written completely in V30 assembler (V30 is just NECs take on the 8086, nothing really of note there) and the code currently takes a mere 301 bytes! At present it contains a full setup for 12 different modes of operation, with 3 of them currently defined.
We have mode 1 for Memory Viewing. It allows you to view the first 0×20000 bytes in a nice easy format. Mode 2 is for Memory Writing. It will support writing an arbitrary amount of data in sequence, for things that require quick multiple modifications. As you could probably tell, mode 2 isn’t done yet. Mode 3 is a BGM music box (it’s actually mapped to the last mode, mode 12) that plays all the games background music (actually, if you replace the sound data, you can get your own music, but they have to have the same music indices).
This trojan should eventually be able to test most, if not all, the features of the Raiden II board. Specifically the COPX-D2, but it will probably test other parts too.
If you have any questions, comments, concerns, etc., please post a comment, and we’ll get back to you ASAP 
Hi there,
can you hint about what the protection is doing overall ?
Comment by dlfrsilver — 2010/12/19 @ 16:24
Well, for the most part, we’ve uncovered that the protection runs bytecode, and the games using it upload a table of commands (made up of bytecode) to the protection. Whenever the game sends a specific trigger, it executes the bytecode in the command that was triggered. The difficult part is understanding the construction of the bytecode; it’s essentially reverse engineering an entire CPU with no documentation
Hopefully you can understand why there has been little progress lately on this protection. It’s one hell of a scheme!
Comment by trap15 — 2010/12/19 @ 16:49
mmhhhh okkkk
! Because i own Zero Team, and Legionnaire. Those 2 fellas use the dreaded protection.
On legionnaire, the SEICOP protection is used for the sprites control and priorities, from what i’ve seen between my original board and the mame emulation.
On zero team, it should be nastier….
I guess decapping the chips will be useful. Because at first we don’t know what kind of MCU, CPU or whatever is lying under the SEIXXXX part numbers.
Look at the C-chip on taito boards, who will have known that it was a second z80 with 8kb ram + 8 kb rom ?
Legionnaire would be maybe a good start to begin with, because the game displays the graphics, only the game logic is lacking.
don’t you think ?
Comment by dlfrsilver — 2010/12/20 @ 07:24
We’ve taken an analysis of the bytecode (we know some of the opcodes due to the HLE and some guessing), and it seems completely alien. The SEI1000 is likely a custom chip built from Toshiba logic blocks, but we are fairly sure that the “CPU” is completely custom, as it does not match any CPU we’ve ever seen before.
Decapping them is only partly useful; if they’re logic blocks, a decap will not help very much, but a full layer-by-layer stripping will work (though that costs FAR more money).
Comment by trap15 — 2010/12/20 @ 13:47
Then 2 solutions applies. Using modified rom code to check the board registers in step by step, and compare with the samey on mame.
The other would be to disassemble the whole code eprom, and seperate the bytecode parts in the game code.
trojaning anyway would be the thing to do.
Comment by dlfrsilver — 2010/12/21 @ 10:29
The first one is what we’ve been doing :3
Comment by trap15 — 2010/12/21 @ 13:43