It is currently Sun Dec 16, 2018 10:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sat Aug 04, 2018 9:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
A very partial emulation that runs Block Force. Using the Square Force ROM from GoodNES, setting it to mapper #355 (and CHR-RAM to 8 KiB), and making sure that CPU->RAM Initialization is set to 00 in the emulator, should run the game. The initial high score (which is 006502 on the unprotected multicart-extracted version) is very sensitive to IRQ timing and therefore probably displayed incorrectly.

Right now, I am just firing an IRQ 13760 M2 cycles after any write to addresses 00D7 or 00E8. Emulating 3D Block will not be possible with such fakery and will definitely require dumping the microcontroller ROM, because that one will actually contain some gameplay code without which the blocks will never fall.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 10:41 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7833
Location: Seattle
What I personally find weird is that the PIC here is running directly off the same 1.8MHz clock that the CPU is, but the PIC has a ÷4 prescaler on the CPU, so it's actually running at ≈450KIpS.

The 12 I/O lines on the PIC are connected to CPUA[4...14] and /IRQ; so theoretically the PIC could choose to assert /IRQ based on that portion of the address, possibly requiring specific addresses in sequence. But it's not paying attention to the R/W line, so whatever's going on can't be related to direction.

This very old model of PIC doesn't have (internal) interrupts, and the only thing it could be doing is polling the address lines; to check for specific addresses will take 8 Tcy (32 6502 cycles) with some code that looks something like
Code:
a:
movlw 0x55
xorwf PORTB, w
btfss STATUS, Z
goto a
movlw 0xA
xorwf PORTA, w
btfss STATUS, Z
goto a

although I'm certain there's a little more cleverness possible.

Due to using the same clock as the CPU, we know that the PIC can only check its inputs (the address bus) exactly every 4th cycle. But at the same time, there's nothing to keep the PIC synchronized, so I don't think there's reason to think that the code inside is only checking 6502 CPU cycles n where n≡1(mod 4)


I know I'd read some article in the past about defeating the code protect using a die photograph to find the location that the CP bit is and erase it...

Apparently the PIC16C54 follow-up PIC – the PIC16C84 – is vulnerable to a variety of relatively inexpensive deprotection attacks. https://www.cl.cam.ac.uk/~sps32/mcu_lock.html

There's also more invasive solutions: http://caps0ff.blogspot.com/2018/05/mos ... 16c57.html


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 3:05 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 449
Location: Poland
I read the PIC's contents from MLX's cartridge:


Attachments:
pic.png
pic.png [ 27.93 KiB | Viewed 3321 times ]
pic.BIN [1 KiB]
Downloaded 112 times
Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 3:55 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Cool! Was it not protected after all, or did you manage to disable/evade the protection?


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 3:58 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 449
Location: Poland
I did not do anything.


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 4:26 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Data sheet wrote:
In code protected parts, specifically PIC16C54/C54A/CR54/C55/C56/C57 devices, the contents of the program memory cannot be read out in a way that the program code can be reconstructed. A location when read out will read as: 0000 0000 xxxx where xxxx is the XOR of the three nibbles. For example, if the memory location contains 0xC04 (movlw 4), after code protection the output will be 0x008.

That seems to describe the data in PIC.BIN rather well, so it is protected after all, and the data you have read is not the actual data.


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 5:59 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 449
Location: Poland
Ok, I will brute force the chip with logic values soon.


Top
 Profile  
 
PostPosted: Wed Aug 22, 2018 9:32 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7833
Location: Seattle
NewRisingSun wrote:
That seems to describe the data in PIC.BIN rather well, so it is protected after all, and the data you have read is not the actual data.
Heh, I was going to say those bytes didn't look like actual code.

It does let us see that there's only 151 words of code in it, at least.

edit: on the unlikely chance this is helpful, I'd made a table of the 12-bit PIC instruction set sorted by instruction encoding:
Code:
00X-03X 000000dfffff movw*
    000 000000000000 nop
    002 000000000010 option
    003 000000000011 sleep
    004 000000000100 clrwdt
005-009 00000000ffff tris
010-017 000000010fff movlb
    01E 000000011110 return
    01F 000000011111 retfie
02X-03X 0000001fffff movwf
04X-07X 000001dfffff clr*
    040 000001000000 clrw
06X-07X 0000011fffff clrf
08X-0BX 000010dfffff subwf
0CX-0FX 000011dfffff decf
10X-13X 000100dfffff iorwf
14X-17X 000101dfffff andwf
18X-1BX 000110dfffff Xorwf
1CX-1FX 000111dfffff addwf
20X-23X 001000dfffff movf
24X-27X 001001dfffff comf
28X-2BX 001010dfffff incf
2CX-2FX 001011dfffff decfsz
30X-33X 001100dfffff rrf
34X-37X 001101dfffff rlf
38X-3BX 001110dfffff swapf
3CX-3FX 001111dfffff incfsz
    4XX 0100bbbfffff bcf
    5xx 0101bbbfffff bsf
    6xx 0110bbbfffff btfsc
    7xx 0111bbbfffff btfss
    8xx 1000xxxxxxxx retlw
    9xx 1001xxxxxxxx call
Axx-Bxx 101xxxxxxxxx goto
    Cxx 1100xxxxxxxx movlw
    Dxx 1101xxxxxxxx iorlw
    Exx 1110xxxxxxxx andlw
    Fxx 1111xxxxxxxx xorlw


Top
 Profile  
 
PostPosted: Thu Aug 23, 2018 7:43 am 
Offline

Joined: Tue Feb 14, 2017 9:50 am
Posts: 97
Out of curiosity, would the mentionned version of 3D-Block (CRC 5E8764F8) work on this PCB (did they leave compatibily code in the PIC?).


Top
 Profile  
 
PostPosted: Thu Aug 23, 2018 11:14 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
That is unknown at this time. Since both games' PRG-ROMs are already dumped however, one could reprogram the EPROM on the Block Force PCB with 3D Block's PRG-ROM data and see if it works --- if it doesn't, one can always reprogram it with the original Block Force PRG-ROM data.


Top
 Profile  
 
PostPosted: Fri Aug 24, 2018 10:50 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7833
Location: Seattle
I found a trivial way to get the contents of a 16C54 out: http://www.piclist.com/techref/microchip/crackpic.htm

In short, you can read the XORed ROM contents, re-program the ROM with all FF0h, read the XORed ROM contents, re-program the ROM with all F00h, read the ROM contents, and then combine the three dumps together.

It does require a some extra effort to program an already-programmed PIC.


Top
 Profile  
 
PostPosted: Fri Aug 24, 2018 11:48 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Not to mention that if something goes wrong, the PIC data will likely be lost, so the original cartridge owner should consent to the attempt first.


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 1:57 am 
Offline

Joined: Tue Feb 14, 2017 9:50 am
Posts: 97
If that's the only way to go, I'd like the person to try their hands with another 16C54, serving as a guinea pig.

I'm not interested in digging for years to find another copy.


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 2:24 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Seems like a good approach.


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 4:05 am 
Offline

Joined: Tue Feb 14, 2017 9:50 am
Posts: 97
(I do prefer that one attempt of feeding it with addresses and see how it reacts is done before going that way too).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group