Bleemcast conspiracy *disclaimer tin foil necessary*

[|darc|]

After taking a second look, I'm highly suspicious the method described in post #282 of creating a bootable cd ever worked (at least with tools in 2023 - maybe it worked with a specific version of NERO way back in 2000). ISO16.RAW size should be a multiple of 2352 - it is not. It's missing the 1st 16 bytes of header data at the start. One would expect a size of 16 * 2352 = 36,632 from ISO16.RAW.

ISO16.RAW is 37,376 bytes. 37,376/16 = 2336, which is the size of a mode 2xa form 1 sector without its sync, address, and mode fields.
Sync field is always the same, no point in storing it.
Since the disc is not finished, sector addresses are not known, so no point in storing it.
Mode is 0x02, to indicate a mode 2 xa sector, but that's the way it's authored to be anyway, so no point in storing.
So you're left with 2336 bytes per sector, which is exactly how sectors are stored in the data tracks of Dreamcast DiscJuggler and Nero images.

So if the miltemp method never worked what does that even mean?
That was what the beta testers used to create the different color bleem beta disks.

of course it worked.

Looking at the bleem rainbow books it appears only one ip.bin is used. <--
So then the different beta color ip.bin theory of locking to different color dreamcast consoles is bs.
LOL

Only other scenario is 1bleem.bin has data to lock to each console or its bs.

In the archive there is one single IP.BIN and there's a 1BLEEM.BIN for every color. How is it not painfully obvious that the locking is done in the 1BLEEM.BIN?

Well it was said all were cracked and all were the same.

So, why 20 years after the fact no1 has shown any proof of this?
Just a leaked "blue" and we have gone with the story since 2003.
Its hard to believe no1 since the original cracked beta leak has cracked each color.

because there was never any reason to re-crack them?
there are other retail Dreamcast games with protection that was only cracked once by the original group in the early 00s -- even when these games were repacked by others years later, they still used the same cracked bin from Echelon or whatever. Is that a conspiracy theory too?

If you modify the batch to keep files it adds 2 temp files which are what i assume is split from the ip.bin?
Maybe view hex data from the split files and find the same hex in ip.bin then remove those sections creates the proper ip.bin?
Or maybe those 2 temp files have other data needed to create a proper nrg file? because it does merge data as well.
Idk? some1 should take the time to figure wtf all of this means lol

It's just basic CD authoring that you don't understand. There's no conspiracy.

"BURNING THE AUDIO TRACK" has you burn the first session of the disc.
"CREATING THE DATA IMAGE" has you generate a data track named IMAGE.NRG. But this data track has an empty 16 sectors where IP.BIN is.

SPLIT.EXE rips the first 16*2336 bytes from IMAGE.NRG. It saves them as "TEMP" which is the "empty" IP.BIN stored as 2336 bytes per sector. This is junk, which is why it gets deleted. The remainder of IMAGE.NRG is stored as TEMP.2.
Then it combines ISO16.RAW (the real IP.BIN, again, stored as 2336 bytes per sector) with the TEMP.2. It stores it as BLEEM.NRG. This is your second session data image. TEMP, TEMP.2, and IMAGE.NRG are obviously deleted because they aren't needed and are just data from intermediate steps.

If you want a "proper IP.BIN" from the ISO16.RAW, then just understand that it's 2336 bytes per sector, mode 2xa form 1 sectors.
that means each sector is 8 bytes of subheader, 2048 bytes of actual data, 4 bytes of error detection, 276 bytes of error correction.
Open ISO16.RAW, skip 8 bytes, copy 2048 bytes into another file, skip 280 bytes. Do this 16 times.
You'll end up with 32,768 bytes and that's your IP.BIN.


If I were Rand, I would have bought 5 Dreamcasts, labelled them each a different color, copied the serial number out of the partition 0 in the read only portion of flashrom, encrypted 1 binary with each serial number as the decryption key to produce 5 different binaries, then wrote an IP.BIN that descrambles+decrypts the 1BLEEM.BIN in memory after the BIOS scramble-loads it, using the console's serial number as decryption key.

Simple to do and there you have a disc that only runs on one Dreamcast. No idea if that's what's really going on, but would be trivial to implement for someone who knows what they are doing.

[SMiTH]

So if the miltemp method never worked what does that even mean?
That was what the beta testers used to create the different color bleem beta disks.

of course it worked.

If it works then create a disk using the miltemp method.
Document the process and upload the .nrg.

Looking at the bleem rainbow books it appears only one ip.bin is used. <--
So then the different beta color ip.bin theory of locking to different color dreamcast consoles is bs.
LOL

Only other scenario is 1bleem.bin has data to lock to each console or its bs.

In the archive there is one single IP.BIN and there's a 1BLEEM.BIN for every color. How is it not painfully obvious that the locking is done in the 1BLEEM.BIN?

You would need to crack the 1bleem.bin's to show proof that this is the case.

Well it was said all were cracked and all were the same.

So, why 20 years after the fact no1 has shown any proof of this?
Just a leaked "blue" and we have gone with the story since 2003.
Its hard to believe no1 since the original cracked beta leak has cracked each color.

because there was never any reason to re-crack them?
there are other retail Dreamcast games with protection that was only cracked once by the original group in the early 00s -- even when these games were repacked by others years later, they still used the same cracked bin from Echelon or whatever. Is that a conspiracy theory too?

yes, there is a reason to crack them and document the enc methods that were used. it might help in figuring out methods for the retails as well. more importantly to show that all beta colors are the same and that they all implement this dc console lock concept.

If you modify the batch to keep files it adds 2 temp files which are what i assume is split from the ip.bin?
Maybe view hex data from the split files and find the same hex in ip.bin then remove those sections creates the proper ip.bin?
Or maybe those 2 temp files have other data needed to create a proper nrg file? because it does merge data as well.
Idk? some1 should take the time to figure wtf all of this means lol

It's just basic CD authoring that you don't understand. There's no conspiracy.

"BURNING THE AUDIO TRACK" has you burn the first session of the disc.
"CREATING THE DATA IMAGE" has you generate a data track named IMAGE.NRG. But this data track has an empty 16 sectors where IP.BIN is.

SPLIT.EXE rips the first 16*2336 bytes from IMAGE.NRG. It saves them as "TEMP" which is the "empty" IP.BIN stored as 2336 bytes per sector. This is junk, which is why it gets deleted. The remainder of IMAGE.NRG is stored as TEMP.2.
Then it combines ISO16.RAW (the real IP.BIN, again, stored as 2336 bytes per sector) with the TEMP.2. It stores it as BLEEM.NRG. This is your second session data image. TEMP, TEMP.2, and IMAGE.NRG are obviously deleted because they aren't needed and are just data from intermediate steps.

Document the process and upload the .nrg.

If you want a "proper IP.BIN" from the ISO16.RAW, then just understand that it's 2336 bytes per sector, mode 2xa form 1 sectors.
that means each sector is 8 bytes of subheader, 2048 bytes of actual data, 4 bytes of error detection, 276 bytes of error correction.
Open ISO16.RAW, skip 8 bytes, copy 2048 bytes into another file, skip 280 bytes. Do this 16 times.
You'll end up with 32,768 bytes and that's your IP.BIN.

If you look at the bleem.nrg's that have existed since 2003 on the internet..none of them use the ip.bin that is included in miltemp.

If I were Rand, I would have bought 5 Dreamcasts, labelled them each a different color, copied the serial number out of the partition 0 in the read only portion of flashrom, encrypted 1 binary with each serial number as the decryption key to produce 5 different binaries, then wrote an IP.BIN that descrambles+decrypts the 1BLEEM.BIN in memory after the BIOS scramble-loads it, using the console's serial number as decryption key.

Simple to do and there you have a disc that only runs on one Dreamcast. No idea if that's what's really going on, but would be trivial to implement for someone who knows what they are doing.

Then why not crack each color 1bleem.bin and document what was done? It might align with your theory of how the dc console lock concept actually worked.

Thank you for responding.
I appreciate any discussion about bleem.

[|darc|]

If it works then create a disk using the miltemp method.
Document the process and upload the .nrg.

Why? You now have more than enough information to do it yourself if you know the basics of making a DC disc

You would need to crack the 1bleem.bin's to show proof that this is the case.

No, it's obvious logic that if you have 1 IP.BIN and 5 individual binaries that it's the binaries that are specific to 5 consoles not the 1 IP.BIN

yes, there is a reason to crack them and document the enc methods that were used. it might help in figuring out methods for the retails as well. more importantly to show that all beta colors are the same and that they all implement this dc console lock concept.

It doesn't need to be shown, we already know that. If you are interested in investigating the encryption method for academic reasons, I understand, that's cool, but don't expect anyone to do the work for you

Document the process and upload the .nrg.

I've told you all you need to know, if you don't know how to burn a Dreamcast disc then why do you care?
The image wouldn't work on any Dreamcast other than 1 of the 5, and neither of us possesses any of those 5 consoles, so you'd just tell me I proved nothing

If you look at the bleem.nrg's that have existed since 2003 on the internet..none of them use the ip.bin that is included in miltemp.

Of course, they wouldn't, the binary was cracked/decrypted, so why would they use the IP.BIN that decrypts an encrypted binary based on a console specific key? It wouldn't work

Then why not crack each color 1bleem.bin and document what was done? It might align with your theory of how the dc console lock concept actually worked.

If I had infinite time, sure, but I cannot afford that. Maybe start a patreon to pay me for my time and I'll be more than happy to waste it for you.

[MoeFoh]

I was just going to post that it looks like ISO16.RAW is using 2336 bytes/sector. How darc says Nero & DJ store an image sector clears things up.

subheader + data + edc + ecc

I was going by:

[SMiTH]

If it works then create a disk using the miltemp method.
Document the process and upload the .nrg.

Why? You now have more than enough information to do it yourself if you know the basics of making a DC disc

Because I have tried creating a bleem nrg using the miltemp method and never got it to work.
I think that you would have the same issue.
But, maybe you can prove me wrong.

You would need to crack the 1bleem.bin's to show proof that this is the case.

No, it's obvious logic that if you have 1 IP.BIN and 5 individual binaries that it's the binaries that are specific to 5 consoles not the 1 IP.BIN

yes, its logic to see there is 1 ip.bin and 5 bleem binaries. so the 1bleem.bin's should be how this console lock concept is implemented.
but, the bleem color/dc color console lock concept is still a theory considering we have no cracked 1bleem.bin's to show any proof of this.
until it is documented i.e cracked bins.. then you can't prove something is the case because some1 says it is true.
besides what rand said about it was not even an actual answer about the beta colors etc. and the betatester made the assumption of this concept in the txt from the original beta leak.

yes, there is a reason to crack them and document the enc methods that were used. it might help in figuring out methods for the retails as well. more importantly to show that all beta colors are the same and that they all implement this dc console lock concept.

It doesn't need to be shown, we already know that. If you are interested in investigating the encryption method for academic reasons, I understand, that's cool, but don't expect anyone to do the work for you.

Right, because no1 can do it.

Document the process and upload the .nrg.

I've told you all you need to know, if you don't know how to burn a Dreamcast disc then why do you care?
The image wouldn't work on any Dreamcast other than 1 of the 5, and neither of us possesses any of those 5 consoles, so you'd just tell me I proved nothing

No, I would be able to see that you actually used the miltemp method and we would finally have a bleem.nrg created using the official miltemp method that the beta testers used to create a bleem disk. From there a new one could be created using the blue cracked beta. Besides this has never been done and shared with others. It would be a true representation of what the beta testers used.

If you look at the bleem.nrg's that have existed since 2003 on the internet..none of them use the ip.bin that is included in miltemp.

Of course, they wouldn't, the binary was cracked/decrypted, so why would they use the IP.BIN that decrypts an encrypted binary based on a console specific key? It wouldn't work

Wouldn't it be great if we had cracked bins to document all of this?

Then why not crack each color 1bleem.bin and document what was done? It might align with your theory of how the dc console lock concept actually worked.

If I had infinite time, sure, but I cannot afford that. Maybe start a patreon to pay me for my time and I'll be more than happy to waste it for you.

It will never be done because no1 can do it.

[MoeFoh]

@darc Can you write a Windows program to do this? ISOBUSTER is not working for me with NRG images.

"Open ISO16.RAW, skip 8 bytes, copy 2048 bytes into another file, skip 280 bytes. Do this 16 times.
You'll end up with 32,768 bytes and that's your IP.BIN."

Thanks.

[|darc|]

@darc Can you write a Windows program to do this? ISOBUSTER is not working for me with NRG images.

"Open ISO16.RAW, skip 8 bytes, copy 2048 bytes into another file, skip 280 bytes. Do this 16 times.
You'll end up with 32,768 bytes and that's your IP.BIN."

Thanks.

sure, I just wrote this:

conv2336to2048.zip

(1.77 MiB) Downloaded 123 times

run like:
conv2336to2048.exe ISO16.RAW IP.BIN
and you'll get your IP.BIN

will also convert any series of mode 2 xa form 1 chunks (subheader+data+edc+ecc) to standard 2048 chunks
(filesize must be multiple of 2336)

[|darc|]

Because I have tried creating a bleem nrg using the miltemp method and never got it to work.
I think that you would have the same issue.
But, maybe you can prove me wrong.

I've been burning dreamcast discs from audio track, IP.BIN, data track for over 20 years. You have that. What's the problem? I don't think I'll forget how to do it after 20+ years now.

yes, its logic to see there is 1 ip.bin and 5 bleem binaries. so the 1bleem.bin's should be how this console lock concept is implemented.
but, the bleem color/dc color console lock concept is still a theory considering we have no cracked 1bleem.bin's to show any proof of this.
until it is documented i.e cracked bins.. then you can't prove something is the case because some1 says it is true.
besides what rand said about it was not even an actual answer about the beta colors etc. and the betatester made the assumption of this concept in the txt from the original beta leak.

you literally posted the assembly for the routine in your OP

i showed you how to get the IP.BIN
you have the decrypted bins
you have the encrypted bins
you have a partial code snippet from the IP.BIN that partially explains how the routine works in your OP
you have beta testers telling you this is how it worked
you have the leaker telling you this is how it worked
you have the original creator telling you this is how it worked

iT'S JuSt a tHeOrY

Right, because no1 can do it.

Someone already did it, that's why we have all the bleem betas floating around the internet today.

No, I would be able to see that you actually used the miltemp method and we would finally have a bleem.nrg created using the official miltemp method that the beta testers used to create a bleem disk. From there a new one could be created using the blue cracked beta. Besides this has never been done and shared with others. It would be a true representation of what the beta testers used.

We already have cracked bleemcast beta, there is literally no benefit to re-creating the protected disc

Wouldn't it be great if we had cracked bins to document all of this?

We do. It's been floating around the internet for 20 years and you've posted it yourself.

It will never be done because no1 can do it.

It already was done 20 years ago.

[SMiTH]

I know who you are.
I'm not questioning your expertise.
I know you have knowledge on everything dc and more.
I am just wanting some1 to create a bleem disk using the miltemp method and document and share it.
As for the 1bleem.bin's (retails, beta all colors)..
I stand by what I said, no1 can crack them now or in the future.
No1 can even recreate what was done 20 years ago with the cracked beta.
But, I would love to be proven wrong.

Thank you for the app, now we can extract the ip.bin

[|darc|]

There was an error in the previous file (accidentally skipped 240 bytes instead of 280).
whoops

redownload it please.