CD-ROM File System.

Hey,

I was wondering if someone knew how to use a program like ISO Buster or something similar to strip/delete the File System structure out of an BIN Image?

Thanks!
 
iso buster and cdmage both have extraction funtions somewhere, i know because i spent the better part of 2 hours messing around with it trying to get a copy of wipeout to work on my psx before realizing that it was the saturn version
 
Hey,

I was wondering if someone knew how to use a program like ISO Buster or something similar to strip/delete the File System structure out of an BIN Image?

Thanks!

I'm not sure if this is what you're looking for, but you can just extract the first x number of sectors out of the BIN image or from the actual CD to get the file system structure. First you need to know where the file system ends and the actual first file data begins. To find out, you can use IsoBuster to view the BIN image or CD, then sort from smallest LBA to highest LBA by clicking on the LBA column.

Currently, I have the Shining Force III Scenario 3 CD in my CD-ROM drive. After sorting by LBA order in IsoBuster, I see that the first file starts at LBA 47. Knowing that, I used CDRWin to extract sector 0 to sector 46 from the CD and saved it as MODE1/2048 data to a file which I called SF3SCN3.ISO. SF3SCN3.ISO is exactly (47 sectors) x (2048 bytes/sector) = 96,256 bytes = 94 KB in size. You may open it like any ISO with IsoBuster or CDmage and you'll be able to view the file system structure.

If you're working with a BIN image of Shining Force III Scenario 3, you can use a hex editor to extract the first 47 sectors of data out and save to a new file. However, you need to know the sector size of your BIN image, whether it's 2048, 2336, or 2352. If you have a BIN+CUE, the cue sheet should tell you. If you just have the BIN image without a cue sheet, then take the file size (in bytes) of the BIN image and divide by 2048, 2336, and 2352, respectively. The divisor used that results in a whole number is the sector size. For example, I have a BIN image that is 509,713,680 bytes in size. I see that dividing by 2352 results in a whole number, therefore the sector size is 2352. Knowing the sector size, I can calculate how much data I should extract from the BIN image. In this case, that would be (47 sectors) x (2352 bytes/sector) = 110,544 bytes. Next, I open the BIN image with a hex editor and extract starting from position 0 to position 110543 (hex equivalent would be 0 to 1AFCF). Note that the ending position is 1 smaller than the calculated size because we're starting position 0, not 1 (think in terms of an array in C++). Save it to a file and call it SF3SCN3.BIN. Again, you should be able to open it like any image file with IsoBuster or CDmage to be able to view the file system structure. Additionally, if you want, you can use CDmage or any of the BIN2ISO or RAW2ISO tools to convert it to a MODE1/2048 .ISO file.

iso buster and cdmage both have extraction funtions somewhere, i know because i spent the better part of 2 hours messing around with it trying to get a copy of wipeout to work on my psx before realizing that it was the saturn version

LOL! You could've just looked at the header of the ISO to find out if it was the Saturn version using a hex editor or something.
 
LOL! You could've just looked at the header of the ISO to find out if it was the Saturn version using a hex editor or something.


yeah, that wouldn't have been as much fun as wasting my last 3 cds and a few hours of my life though
 
I'm really not in the mood to read through it at the moment, but information on where stuff sits in an ISO 9660 filesystem can be found here.
 
Originally posted by Trenton net@June 23 2002,13:14

Well, thanks, but I want to know how to Delete the file structure out of a bin. As in, remove it or blank it out with zeros.

In that case, use a hex editor like WinHex to do it. All you need to do is find out where the file system starts and ends. Looking at some MODE1 ISOs, I find that the file system starts at the 20th sector (i.e., offset A000 if 2048 sector size, offset B7C0 for 2352 sector size). Following the procedure I wrote above and taking the Shining Force III Scenario 3 example again, I know that the file system ends before LBA 47, so I calculate the ending offset to be (47 x 2,048) - 1 = 96,255 = 177FF (use Windows calculator to convert decimal to hex in Scientific mode). If the sector size was 2352, then my calculation to find the ending offset would be (47 x 2,352) - 1 = 110,543 = 1AFCF.

Once I know the offsets for the start and end of the file system block, I can Edit > Define Block... in WinHex and type in the offset values for Beginning and End and that both are with respect to "Beginning of file". Then Edit > Fill Block... to fill the block with 00 hex values:

fill_block.gif


Hit OK and you should see the file system block all blanked out with zeros. Now save and close out of your hex editor. One last step if you're working with a 2352 sector sized BIN image would be to "Rebuild Sector Fields..." using CDmage so that the overhead sector fields (e.g., ECC and EDC) are updated to reflect the 00 hex values. You wouldn't have to perform the last step if you're working with a 2048 sector sized BIN image because there wouldn't be any overhead data to update.
 
If the file system doesn't start at 0, how did you calculate the starting offset?

I suppose there isn't a simple way to tell the start and end of the file system of a BIN file? If so, I could just write a simple app to detect the start and end of the FS and blank it out automaticly without the need for calculating it.
 
Originally posted by Trenton net@June 24 2002, 08:29

If the file system doesn't start at 0, how did you calculate the starting offset?

I know it doesn't start at 0 because the first 16 sectors contain the boot code (IP.BIN if you will). The next sector contains the volume info:

volume_info.gif


Past that you'll most likely see blank values in a hex editor (unless you have Joliet volume info or something which would take up another sector), until you reach the file system area, that is where you'll start seeing actual file names separate by what seems to be random hex values. Taking the hex code of the offset of where that begins and converting to decimal, followed by dividing by the sector size, I get exactly 20:

(hex) (dec)

A000 = 40,960 ==> 40,960 / 2048 = 20

BC70 = 47,040 ==> 47,040 / 2352 = 20


It was probability a nice coincidence that I happened to pick an offset that divided evenly with the sector size,
smile.gif
If I didn't get an even 20, I would've probably rounded it to about that number or so. After testing on some other BIN image files, I came to a conclusion that 20 was the number.
 
Back
Top