Home | Forums | What's new | Resources | |
program loader from PAR |
Daniel Eriksson - Aug 24, 2003 |
IBarracudaI | Aug 24, 2003 | |||
I think that is what PAR's already does... But to unlock the cd-drive to allow reading from cds a security check must be perfomed... |
IBarracudaI | Aug 24, 2003 | ||||
Are you sure? When booting a game from the PAR menus, when you select start game, security track is read. the same happens when you change cds by opening the cd drive door, it drops to the cd-player and when you use the start app button, it checks for the protection. Or do you mean other "security process" ? I know about that code you are referring, and if I remember correcty the problem was that the drive has to be unlocked to use that unlocking code... |
slinga | Aug 24, 2003 | |||
What's the benefit to this? |
vbt | Aug 24, 2003 | ||||
It seems IBarracudaI is right, when the CD is unlocked the security process is called. So there is no benefits of doing that if it doesn't bypass the read of the security area. Also it would be interesting to make a CD without an IP.BIN but with a data track and read its content with the program loaded in memory. I just hope that the saturn don't try to read the security area when there is a data track without an IP.BIN |
IBarracudaI | Aug 24, 2003 | |||
I'm almost sure saturn won't ask for a security check if IP.BIN isn't found, after all, that way saturn won't consider it a valid game cd. hmm, probably some code that runs the file indicated in IP.BIN as being the first file to boot... |
ExCyber | Aug 24, 2003 | |||
As I understand it (based on info from TyRaNiD), the main program controls when the security check happens (it's a separate CD block command), but the CD block will return garbage data beyond the first 32K or so of data tracks. In theory it should be possible to develop an alternate mastering program and CD library that works by encoding/decoding data in audio tracks, but whether or not that would be worth it is questionable given the limited compatibility it would result in. |
mrkotfw | Aug 24, 2003 | |||
i may have something special, http://ss_snk_359.atheos.net/tmp/security.c... - maybe that will help? see this may sound stupid but if we somehow add some code and compile, upload it with a PAR, put in a modified cd to make it work with the compiled bin... and feed it to the saturn when its looking for it. or... put it all the way at the end, injecting it into the last sectors possible of a CD and see if the saturn will actually load it. those are theories |
antime | Aug 24, 2003 | |||
Isn't that just the block of data that must be present in the IP? |
AntiPasta | Aug 25, 2003 | |||
well, if the bootdisc can bypass the whole security ring check procedure with some code in its AIP there's prolly some undocumented CD block command to ignore the security ring, or rather the absence thereof... |
antime | Aug 25, 2003 | |||
Try loading the code from the disc using a PAR, then you'll know if it can bypass security checks or not. |
mrkotfw | Aug 25, 2003 | |||
compile the security.c ? -- i checked a Ip.bin from saturn and if you look at the end of the array it has something the Ip.bin doesnt have anywhere... but it resemeble the text on the security ring... he would Have to probably enable the cd-drive... but how? assembly? |
antime | Aug 25, 2003 | |||
No, that code (sega_security_code[]) is definitely the same as the block of data the bios checks for (sys_sec.o in SGL). The second array (area_code_us[]) is the area code for the U region (sys_areu.o in SGL). |