Pier Solar HD - Not playing on GDEMU

Hi,

So I got my copy of Pier Solar the other day, tried it works perfectly on my Disc drive Dreamcast. Now I'm wanting to play this on my GDEMU Dreamcast. So I converted it to a Cdi using DiscJuggler (done this twice to confirm rip in tact). When I put it on my regular (100% working with all games) SD card It shows up on GDMenu, boots up and plays the intro movie but once the intro movie ends or is skipped the game resets. I have contacted Denaun and he says it's either something that needs to be updated in a Firmware update or the disc is copy protected.

I made this thread to see if anyone else has had any experience with this, possibly got it working on GDEmu. And if anyone knows if indeed the copies of Pier Solar HD for the Dreamcast are copy protected? DiscJuggler doesn't seem to have issues creating the Cdi though...?

Any thoughts or comments would be great

 

Only way I have successfully copied this was using Trurips proprietary software which uses a CCD container. This unfortunately isn't public software and I can't convert it to another format. It indeed has protection.

 

Well I guess it's not a FW issue then, I think I understand what you mean. I can't get a hold of the software that would rip it & even when ripped it cannot be converted to a Cdi?

Looks like I'll have to google for a potential rip someone has uploaded. Annoying really as I purchased the game & want to use it this way to preserve my other Dresmcasts laser...

 

It's a new protection scheme. The Sturmwind rip method doesn't work. It gives a false TOC from what I can see. This and Ghost Blade seem to have the same thing more or less.

And yea only Trurip dumpers have access to this software. It was first public till Redump "Rebranded" the software so Truong went closed source. And even if you had the software it requires a certain Plextor drive in order to use the software.

I need to get with ripper006 to add these games and the others I have dumped. Been almost a year since I stepped away from dumping due to personal issues. Last one I submitted was DUX 1.5 as I don't have internet at home. I just use WiFi tether from my cell. It has allowed me to limit my time wasted on my PC and more focused on my job, kid and real life.


















ped.

 

There are different way to implement copy protections on cdr.

One is to put data between tracks/session, a place where most readers assume it's all \x00. BC! has this, among other. You can verify this by burning it to cdr and dumping the cdr, the image you made won't boot. You just burned a copy protected disc!

Fake TOC are also possible. The DC only reads the Big Endian TOC, and it's possible to customize the ip.bin to bypass the standard way of booting, BC! also does this.

Bad/duplicated sectors are another typical strategy.

Those three protections can be hard to circumvent, but they can all actually be recorded in a CDI. I'm interested in how Pier Solar made it so it can't be encoded in a cdi.

 

@-=FamilyGuy=-
Pier Solar HD uses multiple means of protection, including ones you mention above.

I pre-ordered my copy 6 months before I got a GDEmu board, and don't have access to a Dreamcast with a GD-ROM drive right now, so I'm stuck in the same situation. I did a raw rip in DiscJuggler and I saw the same results that @Scribe 86 describes in the first post: it boots, plays the intro movie, then reboots at the title screen. There's a fake TOC too, like you mentioned. If you put the disc into a PC (or in my case, Mac OS X), you just see a bunch of data files, some of which are larger than 1GB in size which of course isn't valid for a real CD.

I don't think the issue is that the data can't be encoded in CDI, but instead that it just can't be ripped properly by normal means. Bleemcast did something similar, as detailed by @RaZiel above. I also tried ripping to CloneCD and Alcohol formats since the new GDEmu firmware supports those, but I don't think either of those support booting? The CloneCD image showed up in CD player and the audio track would play, but it wasn't recognized by the DC as a bootable MIL-CD. The Alcohol 120% image didn't even read at all.

I'm hoping someone will take care of this in the next few weeks.
If not, there's a fairly obvious solution: use the DC to dump it. That's probably going to require a custom version of httpd-ack. (I assume it doesn't support MIL-CD right now?) I really don't want to code that, but if it comes down to it and there still isn't a dump by the time I'm off work for the holidays I might do it.

 

I know bleemcast quite well yeah..

You can dump cdrs with dcsdrip, but I don't think it'd fix the protections honestly. Most likely this would require a complete raw dump of the whole disc as a big single track and manual analysis. That's how bleemcast was done anyways.

I'm not interested in piracy of homebrew games, as I think the developpers deserve their money, but a way for users that legit own the game to make their own dump and play on GDEMU would be fine IMO.

 

ah oh! other Earthbound incoming but in the modern era!

 

I completely agree, especially for something so new. I have a physical copy, but no present means to play it. (I had the means when I paid for it, but they delayed the game by over a year.) If they wanted to send me a CDI image encoded with DRM to ensure I wouldn't spread it just so I could play the game, that would be good enough for me. But since that's not an option, I'll just do what needs to be done.

I've never heard of dcsdrip before now, but I just checked it out and it doesn't support RAW ripping. httpd-ack does, but I since I'm still assuming it doesn't support CD-ROMs I'll need to make modifications if it eventually comes down to that. I don't think we need to worry about users without GDEmu being able to run it at the moment, the ripped CDI seems to crash emulators prior to the point where it makes it on real hardware.

 

dcsdrip does support raw ripping. Check version 1.1.
http://jj1odm.sizious.com/dcserial_ft232bm.html#dcsdrip

It's the original SD ripper from the designer of the cable himself!

 

not in this case. they are already got their money 3 years ago, but f*cked people who orderd DC version (and paid more than half of whole money collected on kickstarter) quite long time, everyone else got this game in 2014 already. ah, and also creator of this game left the company, so - who cares.

 

I don't think it have fake TOC. but yes, it have fake 4GB file
https://www.dropbox.com/s/04wrininxxmxz83/Скриншот 2015-11-23 18.28.39.png?dl=0
with weird LBA, which can make some dumping/cloning software crazy.

main binary is 17.DAT, which is scrambled in regular way, and then deXORed in bootstrap2 (actually deSUB-ed)
code is highly obfuscated and (was attempted to be) protected from emulation/debugging.

 

I'm not judging this particular case as I don't know the story, but my argument is that if homebrew commercial games are not pirated during their commercial lifetime, then we will have more of them which is good for us.

Off-topic, I like Cyrillic. "screenshot", so familiar yet so different!

 

The screenshots show it ripping track by track, and even if it's RAW I don't actually want to do that. The result of that would be the same thing as dumping on a PC. This probably needs to be dumped sector by sector, with utter disregard for the track layout. Any weirdness with the track layout or data between tracks won't be picked up if you're just dumping the tracks individually. If you tell it to, the DC's drive will seek to and read whatever LBA you want regardless of the track. I would expect them to have taken advantage of that.

 

You can burn a single track 80 min CD in data and/or audio format and swap it, without triggering the switch, for the PS CD and rip the whole disc at once using dcsdrip this way.

This is what we did, both with a pc drive amd the dc to dump BC!.

 

do you have a copy of bleemcast except the beta that boots normally on GDEMU because i used the patched cdi version that bypass the game detection but it freeze in the legal screen

 

None work on gdemu so far. There's data between the two sessions that gdemu probably assume to be all zeros.

 

Response from Deunan

 

Regarding Deunan's reply, I'm just going to speculate here:
1. Since he only sees normal sector reads, my first guess is maybe how it handles corrupt sectors. Could he be transparently using EDC/ECC to repair sectors for reads where he shouldn't, or vice versa?
2. Is it just a timing issue, where Bleem expects a real drive to only be so fast and it decides that GDEmu must be not be a real drive since the data is coming back too fast? At the time it was released, I think Sega wasn't producing MIL-CD compatible machines anymore, so they could've had access to all of the various supported drives to know the expected range of read times.

Anyway, back on topic... It looks like httpd-ack can read CD-ROMs in RAW mode just fine. The following URL (with your actual dreamcast IP) will do a raw dump of the entire disc sector by sector:
http://192.168.1.xxx/track327802.bi...352_gap0_dma0_sector_read1_sub0_abort0_retry1
Argument session 150 says to start at sector 150 (which is LBA 0, per that weird LBA vs ABA thing where the first logical sector is actually 150 sectors into the disc) and track 327802 tells it to end on that sector. 327802 is what the PSHD disc reports as its final sector. That appears to be true, the DC will not read past that sector. Dumping on hardware takes a very long time, because when there's an unreadable sector the DC drive will sit and make clicking noises for 30 seconds. Then you'll see "READ ERROR: sector: ####, FAILED" on the TV screen. Changing the arguments to read multiple sectors at once can help this go faster, but is not a good idea because I think you'll lose good sectors in that range too? (I may be wrong about that, it looks like the unreadable sectors just get filled with a repeat of data from previous readable sectors so maybe it doesn't matter.) You can also enable sub channel data if you want that. The resulting data still needs to be converted into a CDI for GDEmu. I can't provide instructions for that right now, I'm probably going to do it by hand.

At this point, I can confirm that they're storing data outside of the tracks. There's a small chunk of data starting at LBA 7645 which is still part of the first session. It has EDC+ECC like data sectors should have, but is otherwise unrecognizable as any particular file format. The data itself looks fairly random, so it could either be encrypted, something they use elsewhere, or just something they verify to ensure it's a real disc. That data appears to repeat multiple times until hitting the invalid sectors between the first and second session. I didn't notice any other data in areas that shouldn't exist besides that.

Once I'm done I guess I can post further instructions how someone can repeat this process, assuming I manage to be successful. Either way, it looks like dumping MIL-CD directly on the DC is the easiest way to do it.

 

so far I can say disk check based on subchannel data.
after game binary decrypted&run it read TOC of SD area, then do 4 subchannel reads - one in each of modes (raw, Q-data, MCN, ISRC), after this I can't see nothing suspicious it just reads FMV data(*) and shows intro movie onscreen, then jumps to some trash code (probably incorrectly decrypted), at this point reboot happens like on GD-Emu )

(*) FMV data is hidden in first session, after audio track