Hello,
I'm releasing the newest version of the tool so everyone can already have it. Don't get too excited, it doesn't contain any tables yet.
I have ready the SF3-NG table that works great on MAME but for some reason not in the real thing. As soon as I sort this out, I'll release it.
Stay tuned for more.
http://netload.in/dateiiXLtCUuBJv/cps3_iso_converter_v0.4.rar.htm
Wednesday, December 12, 2012
Monday, December 3, 2012
Going public
Due to the request from some followers, I'm publishing the link to the special version of ElSemi CPS3 Emulator.
Everyone who'd like to contribute or that would like to see speed up the convertion process of his/her favourite game is welcome.
Just download this special version of the emulator: http://netload.in/datei37DARnQNE7/cps3.rar.htm
put your favourite romset and...play!
What you have to do is very simple, jut start the game you want and start playing, play it to the end with P1, then with P2 (you can change settings in the bios), then start a game with P1, then in half combat join P2, wait for time to finish, make so many combos as you can, etc. The idea is to execute so much code as possible. so then my robot can trace it.
If you play for let's say 1 hour and you need to do something else, you can let the emulator running. If you quit the emulator a file called "codeacces.bin" will be created. Good news is that when you start the emulator later, it reads the existing codeaccess.bin file and continues modifying it.
VERY IMPORTANT! BAD NEWS is that you can't start another game with the same codeaccess.bin. If you for example, played in total 3 hours of SF3-NG and then start another game even 5 seconds, the resulting table is compeltely messed and useless, so if you want to play another game, you need to rename the codeacces.bin table to something else like: codeacces-sf3ng.bin
Please don't send a table unless you are 100% sure that it's not mixed with another game. Even different versions of a game will corrupt it, so if you play i.e. SF3-NG 970204 then stick to 970204.
When you think you are done, please send the codeacces.bin file to pablofg_ [_at] hotmail.com
Stay tuned for more.
Everyone who'd like to contribute or that would like to see speed up the convertion process of his/her favourite game is welcome.
Just download this special version of the emulator: http://netload.in/datei37DARnQNE7/cps3.rar.htm
put your favourite romset and...play!
What you have to do is very simple, jut start the game you want and start playing, play it to the end with P1, then with P2 (you can change settings in the bios), then start a game with P1, then in half combat join P2, wait for time to finish, make so many combos as you can, etc. The idea is to execute so much code as possible. so then my robot can trace it.
If you play for let's say 1 hour and you need to do something else, you can let the emulator running. If you quit the emulator a file called "codeacces.bin" will be created. Good news is that when you start the emulator later, it reads the existing codeaccess.bin file and continues modifying it.
VERY IMPORTANT! BAD NEWS is that you can't start another game with the same codeaccess.bin. If you for example, played in total 3 hours of SF3-NG and then start another game even 5 seconds, the resulting table is compeltely messed and useless, so if you want to play another game, you need to rename the codeacces.bin table to something else like: codeacces-sf3ng.bin
Please don't send a table unless you are 100% sure that it's not mixed with another game. Even different versions of a game will corrupt it, so if you play i.e. SF3-NG 970204 then stick to 970204.
When you think you are done, please send the codeacces.bin file to pablofg_ [_at] hotmail.com
Stay tuned for more.
Saturday, December 1, 2012
Help with the tables and latest update
I have ready a table version for SF3NG that should work on a SF3-2I. It works great on MAME but for some reason when I test it on the real thing it doesn't work. Nothing...just black screen.
I see two options, either the BIOS is checking something that needs to be patched or there is some code in the game, that is not marked as code in the decryption table, and that MAME doesn't execute, BUT the real hardware does.
While I try to find a solution for this. I'm asking for the support of the donnors to help creating very accurate tables.
They will get a special version of the emulator of ElSemi that will create the table as you play, make combos, enter in different menus,etc.
more news soon.
I see two options, either the BIOS is checking something that needs to be patched or there is some code in the game, that is not marked as code in the decryption table, and that MAME doesn't execute, BUT the real hardware does.
While I try to find a solution for this. I'm asking for the support of the donnors to help creating very accurate tables.
They will get a special version of the emulator of ElSemi that will create the table as you play, make combos, enter in different menus,etc.
more news soon.
Thursday, November 8, 2012
Update on the tables
As I said in previous posts, the tool is ready and ready to be released anytime, the big problem are the tables that are needed and that tell the CPS3 Tool what is code and what is data.
I have choosen a very tiny format for the table. The range of memory to which the table refers goes from 0x06000000 to 0x06ffffff. that means a range of address of 16Mb. One efficient way to do it, is by creating a table of 2Mb in which each bit, represents if a byte is code (1) or data (0).
As I know that in the SH2 instructions are executed in pairs of 2 bytes, I've splited the table on half and now each bit, means if two bytes are data or code, what leaves with a table of 1Mb.
Moreover, I've found that in SF3-NG the range of code goes from 0 to 0x3d0000 what means that a table of 250k would be enough. I haven't analysed in detail any other game yet, so I won't squeeze the table before being sure that it works.
Regarding the bot, I've decided to use a combined effor, creating 4 different 'tiny' programs.
The first one, will take a several Gigs file generated with MAME's commmand 'trace' and will update the table.
I have created several of these files so I have to make several passes.
Playing a game, when the trace command is on, is almost impossible, luckily I have the Special version of ElSemi (thanks mate).
The second version of the tool will update an existing table with the table that generate the program of ElSemi. Again several passes are needed as I have several tables generated
The third tool is the robot, which will basically analyze the code of the game and will look for all conditional branches (BF, BFS, BT, BTS) and if "we are over one instruccion that it's code" and "the destination branch is not marked as code" then we launch a exploring subroutine that will explore this specific branch.
As you will understand when you are inside a branch, you have to check instruction by instruction until you find something that will stop the lineal execution, which basically means a jmp, a subrutine, a BT, a BF, a RTE, etc. This has a small inconvenient, because the robot sometimes can't determine i.e. the address to which 'JMP R14' is pointing to, so several JMPs, BSRs, JSRs,etc. have to be manually checked with the MAME debugger.
Evern with all that I only got like 70% of the code validated. so I generated a 4th tool that will look through all the memory and will look for all the addresses marked as data that point to any adrress in the range of 06000000-063d0000. At this moment this means 2500 branches that I have to analyze by hand (looking at the dissasembled code) and if they are really code, then include them in a file called "manual.txt" that will use the robot of the 3rd tool to manually analyze those areas.
I hope you all understand the lack of updates due to the long process that this takes. Luckily now I seem to have a procedure and the right tools.
I'll try to get several tables ready before christmas as a present you all CPS3 lovers.
Expect more news soon.
I have choosen a very tiny format for the table. The range of memory to which the table refers goes from 0x06000000 to 0x06ffffff. that means a range of address of 16Mb. One efficient way to do it, is by creating a table of 2Mb in which each bit, represents if a byte is code (1) or data (0).
As I know that in the SH2 instructions are executed in pairs of 2 bytes, I've splited the table on half and now each bit, means if two bytes are data or code, what leaves with a table of 1Mb.
Moreover, I've found that in SF3-NG the range of code goes from 0 to 0x3d0000 what means that a table of 250k would be enough. I haven't analysed in detail any other game yet, so I won't squeeze the table before being sure that it works.
Regarding the bot, I've decided to use a combined effor, creating 4 different 'tiny' programs.
The first one, will take a several Gigs file generated with MAME's commmand 'trace' and will update the table.
I have created several of these files so I have to make several passes.
Playing a game, when the trace command is on, is almost impossible, luckily I have the Special version of ElSemi (thanks mate).
The second version of the tool will update an existing table with the table that generate the program of ElSemi. Again several passes are needed as I have several tables generated
The third tool is the robot, which will basically analyze the code of the game and will look for all conditional branches (BF, BFS, BT, BTS) and if "we are over one instruccion that it's code" and "the destination branch is not marked as code" then we launch a exploring subroutine that will explore this specific branch.
As you will understand when you are inside a branch, you have to check instruction by instruction until you find something that will stop the lineal execution, which basically means a jmp, a subrutine, a BT, a BF, a RTE, etc. This has a small inconvenient, because the robot sometimes can't determine i.e. the address to which 'JMP R14' is pointing to, so several JMPs, BSRs, JSRs,etc. have to be manually checked with the MAME debugger.
Evern with all that I only got like 70% of the code validated. so I generated a 4th tool that will look through all the memory and will look for all the addresses marked as data that point to any adrress in the range of 06000000-063d0000. At this moment this means 2500 branches that I have to analyze by hand (looking at the dissasembled code) and if they are really code, then include them in a file called "manual.txt" that will use the robot of the 3rd tool to manually analyze those areas.
I hope you all understand the lack of updates due to the long process that this takes. Luckily now I seem to have a procedure and the right tools.
I'll try to get several tables ready before christmas as a present you all CPS3 lovers.
Expect more news soon.
Tuesday, October 16, 2012
It's gonna be bot
After careful consideration and after giving up the idea of doing something manually, I've opted for creating a bot that will go through all the code and will detect all branches and artificially run through them.
As a starting point I will use the tables that I have created with ElSemi's special version and MAME and I will do the following:
* analyse the game code and search for all conditiional jumps that are in the parts of the memory that we already know that's code.
* search if both possibilities have happened (jump/no jump). If any is missing, launch a subroutine that will follow that second branch line by line, jump by jump.
* search next conditional jump unit end of Code RAM.
I'm going 10 days off, so don't expect any updates in that time.
Stay tuned...
As a starting point I will use the tables that I have created with ElSemi's special version and MAME and I will do the following:
* analyse the game code and search for all conditiional jumps that are in the parts of the memory that we already know that's code.
* search if both possibilities have happened (jump/no jump). If any is missing, launch a subroutine that will follow that second branch line by line, jump by jump.
* search next conditional jump unit end of Code RAM.
I'm going 10 days off, so don't expect any updates in that time.
Stay tuned...
Sunday, October 14, 2012
Moving to cartridge modding
As I can see no other option at the moment to adapt games to SF3-2I cartridge than analysing the code in SH2 Assembler line by line, I decided to take a mind break and retake the cartridge conversion idea.
I had the idea that the last 256 bytes of the BIOS were somehow including the keys to make it work, but apparently that wasn't the case. I filled up the BIOS from 20000 to 7ffff on the battery free cartridge and still works, so I'm inclined to believe (and that's bad news) that in order to reprogram a cartridge with other keys, we need to connect the cartridge to the special device that communicates with the SH2 in a way that we don't know.
This also implies that even if we know how to reprogramm the cartridges, they would still need a battery, as the keys are not stored in the BIOS.
Luckily we know that all cartridges when having the battery removed, work as a SF3-2I with battery. That means that anyone, with a dead cartridge could just remove the battery, use the new version of the tool and play all 6 games.
I'll keep on thinking how to obtain 99% accurate tables. The only option I see at the moment is using some kind of bot that runs through the code, following some rules and determining what's code and what not.
That's not an easy task in the SH2 as you have many weird PC based JUMPs like
MOV.L @($20,PC),R14
JMP R14
which can be somehow controlled.
However things like
MOV.L @(R0,SP),R14
JMP R14
is a different story.
Any ideas are welcome. Just post them down here.
I had the idea that the last 256 bytes of the BIOS were somehow including the keys to make it work, but apparently that wasn't the case. I filled up the BIOS from 20000 to 7ffff on the battery free cartridge and still works, so I'm inclined to believe (and that's bad news) that in order to reprogram a cartridge with other keys, we need to connect the cartridge to the special device that communicates with the SH2 in a way that we don't know.
This also implies that even if we know how to reprogramm the cartridges, they would still need a battery, as the keys are not stored in the BIOS.
Luckily we know that all cartridges when having the battery removed, work as a SF3-2I with battery. That means that anyone, with a dead cartridge could just remove the battery, use the new version of the tool and play all 6 games.
I'll keep on thinking how to obtain 99% accurate tables. The only option I see at the moment is using some kind of bot that runs through the code, following some rules and determining what's code and what not.
That's not an easy task in the SH2 as you have many weird PC based JUMPs like
MOV.L @($20,PC),R14
JMP R14
which can be somehow controlled.
However things like
MOV.L @(R0,SP),R14
JMP R14
is a different story.
Any ideas are welcome. Just post them down here.
Saturday, October 13, 2012
More about the tool
Thanks to Alex and Matt I finally managed to get a proper dump using MAME.
I just run MAME and all the PCs will be dumped to a file. It has some nice efficient tricks as when it notices that it's inside a loop it simplifies the output and only dumps the loop once, so I thought the file should be quite small.
When it's dumping the PC, the thing runs damm slow and it takes 5 minutes to start playing, but the best of all is that the dump file in those 5 minutes is quite small and only takes 24Gigs of data :)))
I created a new tiny tool that reads all those PCs and puts them in a table (the famous decrypting table). So we are ready to see if using MAME will make this game finally work on another set.
I create a new JOJOBA CD to tried it on MAME, I update with the new CD and....didn't work!
For some reason it starts executing code from other addresses which didn't do before, so I started adding one by one those special locations. The process is quite tedious, as you must
A) Update game in MAME
B) Run it and see if it works
C) If it doesn't work, look for the code that isn't updated in the table
D) Update table
E) Create new CD
F) Go to A)
Good news is that apparently SF3-2I only executes code from 06000000 to 06100000. In the worst case and unless I come up with a better idea, there is always the option of analysing the whole 1Mb of code and data in Assembler BY HAND and create the table in this way. That can take me like a month, so I'll keep as plan B or C or X ;)).
More coming soon.
I just run MAME and all the PCs will be dumped to a file. It has some nice efficient tricks as when it notices that it's inside a loop it simplifies the output and only dumps the loop once, so I thought the file should be quite small.
When it's dumping the PC, the thing runs damm slow and it takes 5 minutes to start playing, but the best of all is that the dump file in those 5 minutes is quite small and only takes 24Gigs of data :)))
I created a new tiny tool that reads all those PCs and puts them in a table (the famous decrypting table). So we are ready to see if using MAME will make this game finally work on another set.
I create a new JOJOBA CD to tried it on MAME, I update with the new CD and....didn't work!
For some reason it starts executing code from other addresses which didn't do before, so I started adding one by one those special locations. The process is quite tedious, as you must
A) Update game in MAME
B) Run it and see if it works
C) If it doesn't work, look for the code that isn't updated in the table
D) Update table
E) Create new CD
F) Go to A)
Good news is that apparently SF3-2I only executes code from 06000000 to 06100000. In the worst case and unless I come up with a better idea, there is always the option of analysing the whole 1Mb of code and data in Assembler BY HAND and create the table in this way. That can take me like a month, so I'll keep as plan B or C or X ;)).
More coming soon.
Wednesday, October 10, 2012
Progress on new version of the tool
Some of you have been wondering why there has been no news about the new version of the tool. The main reason is that for now we can only convert cartridges into SF3-2I. Due to the special encryption of this game (it only encrypts code, but not data, and code and data are mixed in memory), we need to either A)manually disassemble all the memory and mark what is code and what is data or B) create a version of any emulator and have it dumping all the PCs that it runs. Obviously the B is the most logical one. We can start from this version that works almost perfect and when people find a bug, they can report that or contribute fixing it.
The problem is that I got a special version of the CPS3 Emulator of ElSemi, but apparently he's using some very clever tricks in ordere to emulate some things. On the Other hand MAME appears to be more Hardware-compatible, so after working for some time on the first version I just shifted to MAME.
I didn't give up the option of trying to fix the cartridges towards another type of encryption which would ease things a lot and will avoid people having to worry about a game crashing.
Here you can see a video of my setup running with A and B cartridges (sorry for the quality):
http://youtu.be/rToOhdwp1wY
Having said that, the new version of the tool is ready, the only problem are the tables that must come with it and that will tell the program what to decrypt and what not inside the 10 and 20 files.
Stay tuned for more.
The problem is that I got a special version of the CPS3 Emulator of ElSemi, but apparently he's using some very clever tricks in ordere to emulate some things. On the Other hand MAME appears to be more Hardware-compatible, so after working for some time on the first version I just shifted to MAME.
I didn't give up the option of trying to fix the cartridges towards another type of encryption which would ease things a lot and will avoid people having to worry about a game crashing.
Here you can see a video of my setup running with A and B cartridges (sorry for the quality):
http://youtu.be/rToOhdwp1wY
Having said that, the new version of the tool is ready, the only problem are the tables that must come with it and that will tell the program what to decrypt and what not inside the 10 and 20 files.
Stay tuned for more.
Friday, September 21, 2012
All cartridges can be restored now!
Our friend Oliveira found the way to unbrick the remaining A and B cartridges!
All cartridges can be restored now!!
The trick was with the black cable left after removing the battery.
At the moment All cartridges can be restored to work as SF III-2nd Strike.
More news coming soon about the latest version of the conversion tool.
Our Big thanks to our friend Oliveira.
All cartridges can be restored now!!
The trick was with the black cable left after removing the battery.
At the moment All cartridges can be restored to work as SF III-2nd Strike.
More news coming soon about the latest version of the conversion tool.
Our Big thanks to our friend Oliveira.
Thursday, September 20, 2012
Another one goes down
Today I managed to get one more kind of cartridge to work without battery and this are the ones that have a C sticker on the CPU. Olveira managed to get the D sticker working.
So basically we got 50% of the 4 versions that can now work without battery and we are missing the A and B type which are the ones that in the back side of the cartridge have a FM1208S instead of a MACH111.
Oliveira already told what needs to be done for a cartridge without battery to work, so for the ones who missed it, here it goes:
"The SH2 CPU needs to see a specific sequence of 8 bytes at a certain address (0x7FF00) when it has no keys programmed before it can operate."
So If we put this sequence in the BIOS of any C or D cartridge, the cartridge will boot without battery and with a specific default key.
The thing is that with my tool we can convert all games to work for SF3-2nd, as soon as this is supported. As you know a table needs to be done in order to separate instructions from code.
Today ElSemi told me that he will create a special version of his emulator to create this tables.
Thumbs Up! We are on the right way!
So basically we got 50% of the 4 versions that can now work without battery and we are missing the A and B type which are the ones that in the back side of the cartridge have a FM1208S instead of a MACH111.
Oliveira already told what needs to be done for a cartridge without battery to work, so for the ones who missed it, here it goes:
"The SH2 CPU needs to see a specific sequence of 8 bytes at a certain address (0x7FF00) when it has no keys programmed before it can operate."
So If we put this sequence in the BIOS of any C or D cartridge, the cartridge will boot without battery and with a specific default key.
The thing is that with my tool we can convert all games to work for SF3-2nd, as soon as this is supported. As you know a table needs to be done in order to separate instructions from code.
Today ElSemi told me that he will create a special version of his emulator to create this tables.
Thumbs Up! We are on the right way!
Breakthrough
By some very lucky accident, our friend Oliveira, managed to revive a dead SF3-3 Cartridge and convert it to SF3-2.
We are now trying several roms reencypted to see which conclusions we can draw from it. The only fact till now is that only one kind of cartridge (out of 4) can be revived.
Apparently after re-encryption, the cartridge can work with any game's BIOS, so we could re-encrypt all this cartridges with the SF3-3 BIOS that allows using only 1 single CD for update.
This will also mean that one can have a collection of 6 CDS that will work with that BIOS....
Stay tuned!
We are now trying several roms reencypted to see which conclusions we can draw from it. The only fact till now is that only one kind of cartridge (out of 4) can be revived.
Apparently after re-encryption, the cartridge can work with any game's BIOS, so we could re-encrypt all this cartridges with the SF3-3 BIOS that allows using only 1 single CD for update.
This will also mean that one can have a collection of 6 CDS that will work with that BIOS....
Stay tuned!
Monday, March 12, 2012
adding support for SFII-2nd and decapping
Hi,
This is a small update on the status of the breaking process.
I used the sygnal analyser without much luck, so before putting much of my time into something that I'm not sure if it will pay off, I contacted a colleague that has previous experience in the retro-engineering ICs and we'll try to decapp a couple of custom SH2 and find out how to reprogram them or at least narrow down the number of pins that are accessing the encryption module.
Regarding the support for SFIII-2nd I have tried to creat a new version of MAME that will just 'printf' each address (PC) that is being executed by the SH2 but I I can't get to have them all printed out.
For that reason and following Alex's propositionI'm asking for support of the experts around there to provide new C files that need to be changed in order to get printed all the addresses that are executed. An improved version should ideally generate a table that sets to one te value of an address if it was exectued, so we avoid getting laaaarge output files. This is not critical, as a little script in Notepad++ could do the job.
When we have a working C version, then I'll ask you to run it, send me the output files that you get, so I can integrate them all and put them in the latest version of the tool.
We'll (hopefully) set up an open code environment for this, so meanwhile please send your files via www.mediafire.com
Waiting for your feedback....
This is a small update on the status of the breaking process.
I used the sygnal analyser without much luck, so before putting much of my time into something that I'm not sure if it will pay off, I contacted a colleague that has previous experience in the retro-engineering ICs and we'll try to decapp a couple of custom SH2 and find out how to reprogram them or at least narrow down the number of pins that are accessing the encryption module.
Regarding the support for SFIII-2nd I have tried to creat a new version of MAME that will just 'printf' each address (PC) that is being executed by the SH2 but I I can't get to have them all printed out.
For that reason and following Alex's propositionI'm asking for support of the experts around there to provide new C files that need to be changed in order to get printed all the addresses that are executed. An improved version should ideally generate a table that sets to one te value of an address if it was exectued, so we avoid getting laaaarge output files. This is not critical, as a little script in Notepad++ could do the job.
When we have a working C version, then I'll ask you to run it, send me the output files that you get, so I can integrate them all and put them in the latest version of the tool.
We'll (hopefully) set up an open code environment for this, so meanwhile please send your files via www.mediafire.com
Waiting for your feedback....
Thursday, February 2, 2012
The Spider is ready
With the help of Raf, I've managed to get replace the 29f400 with a socketable 28f400. The result can be seen in the pictures below.
Good news is that it works perfectly and that means several things:
* Both 29f400 and 28f400 can be used
* I changed the BIOS from a Mexican one to a USA one and worked perfectly.
* This is an SF2 cartridge, which might be even better given the peculiarity of the encryption in this game (data not encrypted, code encrypted).
* It´s much easier and safer now to attach the probes from the signal analyser.
* Nope, I can't get back to life dead cartridges yet....
I will setup everything this weekend and let's start seeing what's going on.
Stay tuned.
Good news is that it works perfectly and that means several things:
* Both 29f400 and 28f400 can be used
* I changed the BIOS from a Mexican one to a USA one and worked perfectly.
* This is an SF2 cartridge, which might be even better given the peculiarity of the encryption in this game (data not encrypted, code encrypted).
* It´s much easier and safer now to attach the probes from the signal analyser.
* Nope, I can't get back to life dead cartridges yet....
I will setup everything this weekend and let's start seeing what's going on.
Subscribe to:
Posts (Atom)