• Advertisement

Archived

This topic is now archived and is closed to further replies.

seperating data on cd or hdd

This topic is 5060 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is an extremely crazy request, but I was wondering if anyone had a link or book to point me in the right direction. I am curious about about writing my own code to burn a cd or write to a hard drive but in specific sectors. For example lets say I wanted to do a secret file burned to a cd but I wanted it spaced out so that only if I knew the sectors or location (or if I had a program automatically scan for holes or lands). LIke maybe beginning have the first 1/3 of the file somewhere in the middle of the cd be the middle 1/3 of the file and the outside track be the last 1/3. I was interested in doing it for a hard drive as well, but internet searches are fruitless and I''m getting bored of doing it with my eeprom. Any help is greatly appreciated and thank you very much for your time and effort in advance.

Share this post


Link to post
Share on other sites
Advertisement
this can be in c++ or asm, I''m not particularly picky even vb would work

Share this post


Link to post
Share on other sites
You'll find that unless you use secret hardware, a secret CD is impossible. CDs are not like harddrives with their fixed position sectors. A CD is a spiral of pits whose exact position is indeterminate (for example you can "overburn" a CD by making the spiral tighter then normal, but this may make it impossible to read in some drives because the lines are too close). For a CD to actually be read by a CDROM drive it must be possible to follow this spiral. You'd be better to use encryption, stenography, or both.

On the harddrive you would have to get around Windows. Normally on any Windows NT based system you *cannot* make physical access to the harddrive without being a driver and locking the drive. It is not simply a matter of some fancy assembly instructions.

Share this post


Link to post
Share on other sites
Windows wouldn''t be the best bet here, but even DOS had disk image tools you could probably find laying around and use.

Any decent GNU derivative (Linux, folks) would be a fine enviroment for such a task, as you can find block files for all your drives in /dev and with the correct permissions (root) you can open them up and read and write the entire disk or partition just like a file.

Share this post


Link to post
Share on other sites
1) As has already been mentioned, the more non-standard the thing you want to do is, such as hiding extra data at a specific location on the CD, the more hardware and OS compatibility issues you're going to encounter (if this is a commercial app and you don't have access to a full scale hardware compatibility test facility, be very careful!).

2) I think the first step for you is to get/write some code to burn a "standard" ISO 9660 CD without any "special" stuff. I don't have any links off hand, but you'll (usually) need to delve into ASPI and maybe SPTI programming (try a Google for something like ASPI+tutorial).

3) One trick for hiding data is a malformed TOC. You hide your "secret" data directly after a normal file. Say you have a normal file that's 20123 bytes long and some secret data of 10000 bytes, you write the normal file AND the secret file together as a single 30123 byte file; when writing the TOC though you set the file size as being only the size of the first file.

4) Another trick is to write data as (or in the middle) of an audio track. If the drive reading the data can do CDDA (or at a pinch supports audio in as a capture device for your sound hardware), you can read that data as digital and jump to the desired offset in the audio. As Michalson suggested, stenography is a good idea here so the data doesn't sound any different when the audio track is played as audio. Additionally bearing in mind that audio is recorded single speed may be pretty useful

5) On the playback/read side of things, depending on what level of access you need (rather than a simple "is it there or not" test), you'll probably need to use DeviceIoControl(..) requests (or ASPI, SPTI, or direct driver communication).

6) At a lower level, malformed data checksums are quite common to make files/areas unreadable/uncopyable. Though you should beware - some drive firmware auto-corrects/ignores bad checksums (there have been a few famous examples of commercial copy protection failing miserably on some drives because of this! - customer returns aren't good if the only reason for your protection was intended to get more sales...).

7) If this is for CD copy protection - if it's readable from program code and readable by the CD drive hardware, then it's ultimately crackable - and there are even "deep copy" programs out there that can get round many of the more common hiding/protection schemes.

8) Hiding stuff on a HD - personally I'd say don't. HD architectures, standards and drivers vary a lot (there's a lot for your code to account for). Furthermore, space is either used or it isn't - things such as scandisk and defrag are likely to seriously interfere with your "hidden" data if it doesn't belong to a particular file. Once again, stenography is probably the most robust approach to this - for example by hiding information in the file attributes of multiple files. At a pinch you could use one of the system areas of the disk to hide a few things.


Simon O'Connor
Game Programmer &
Microsoft DirectX MVP

[edited by - s1ca on June 13, 2004 8:50:31 PM]

Share this post


Link to post
Share on other sites

  • Advertisement