CPS2 - This weekend I was bored and ...

I didn't know that! Link please

 

Another one:

Ultimate Ecology 931203 (Known outside of Japan as "ECO FIGHTERS")



This one is actually different from the one from Raz since this was worked out from the original japanese version. His version is based on the EURO release.

CAPCOM did "offset change" all of them to prevent attempts at decryption by file compare. Basically they put pieces of data and code of the game at different places in each regional variation of this game.

Edit: Also this game was the most annoying and gruesome piece of (Ha Capcom ! I give that to you guys since it's intentional as it's part of the protection) spaghetti code I ever touched. :x

 

So in two different region exact same revision program roms they are absolutely identical for all data, only code differs? Is it code and not data that determines the ROM's region? I remember figuring out how to change Rockman on CPS1 by changing a byte in ROM to make it run in USA region.

 

Well, there's several different situations. Towards the end of the life of the system, they got very lazy and stopped caring much.

I know I had to do a LOT more of disassembly work on the early games because they're quite well protected.

Because the games are coded in C, they use a compiler and a linker to build the binaries. With simple changes on the directives for the linker, they can move huge chunks of data or code within the program which make an "collision attack" (an attack where you just make a diff of the two files to figure what matches and what mismatches) impossible. Ultimate Ecology/Eco Warriors is one of the earliest games on the system and while the program is identical for all regions, the pointers and some of the data are not, exactly because the Capcom programmer changed the linker directives when he was making the builds.

Sadly only after I disassembled the whole Japan rom I found out about this. So it was half a week of hobby time poured on this just to discover that the different region ROMs are offset by two bytes at about the middle of the image (the complete program image is 2MB).

Games like Pocket Fighter, MvsC, VSHvsSF, the late Vampire games and HSF anniversary edition are vulnerable to the "collision attack" technique because several versions of them with the exact same code and different encryption keys do exist...

Games like the Mitchell ones have the same key on all regions so the only way of hacking them into "phoenix" is IDA or something similar. Luckly the Mitchell games are hilariously simple on their programming ... So it took me like 4 hours to decrypt Choko.

 

This one requires no explanation:




:very_drunk:

 

Awesome.

 

Another weekend, another game:


Brazil version:




Mexico version:



Hacked soundtest timer with a 6 byte patch I got rid of the timer and countdown text:


Trivia: Ryu text says he's looking forward "anxiously" for the next battle. In the portuguese version it implies a female is saying that due to the way the language deals with genders on the words. Classical mistake. That's how the original encrypted one was so I decided to leave it alone. :very_drunk:

Also I think the Mexican version it should be "ansioso" not "ans oso" lol. :highly_amused:
(I think that has to do with the text having an accent in the i character and the game engine not supporting it...)

 

:encouragement:

 

This one is special for me...

It's the first CPS2 game I've ever seen. Back in 1994, when it was new.







<CURSES>


Edit:
SHOW VERSION flag enables "FREE PLAY" at the SYSTEM CONFIGURATION:


STOP VERSION flag enables CAPCOM's debugger:

(I caused that crash through messing the stack to cause it to show up)

 

I played Alien vs. Predator a couple weeks ago at a local arcade. That's a really fun game, and quite impressive for the time it was released.

 

This Show Version/Stop Version was dumped or did you mess with flags to enable those features?

 

I had to disassemble the game completely to figure out where the non encrypted data was at, so yes I found the flags on the disassembly process. It was disabled and I enabled through editing the said flags.

 

Currently W.I.P, for a member of another forum:






Regional variations for this particular game are completely different from each other despites what version numbers say and this game has HORRIBLY complex coding.

Only feasible "attack method" for this game was disassembly and manual identification of data/code sections.

This game is a strong contestant for the most annoying piece of code I ever put my hands on.
It's on par with Ultimate Ecology on the "convoluted coding" category.

I think I exhausted all possible decryption related bugs on this game, but I'm unsure still.


by the way, this is how CAPCOM debugger looks like on DDSOM:

 

I'm guessing you saw the debugger screen come up alot. Aren't you glad 68000 had that exception capability? Unlike the 65xx which will gladly try to run just about anything as code.

 

That proves how the 68000 was designed to run complex stuff such as multi user Operating systems with memory protection and secure management/process isolation (as per 70s and 80s standards, of course).

Yes I am glad. Also I am glad the 68000 uses word aligned instructions and they're aways an even number of bytes so code never loses alignment on the hexadecimal editor...

That in particular helps a TON when I am doing things I'm not 100% sure about...

 

Hello l_oliveira

I have a question about the texts in DDTOD and DDSOM. I wanted to hack and retranslate the horrible french texts these games boast.
But alas i was not able to find the texts. Are they crunched or hidden, or do i need to get the letters hex values ?

Thanks if you can hint on this

PS : last question, are all those CPS-2 games coded in C, or are there some coded in ASM 68000 ?

Cheers !!!!