Hi All,

Is it possible to write a non standard CD Driver, and also my own application for burning the CD, so only I would be able to access the data on the disk?

Is some body has done it before?

Thanks in Advance
Roy

http://www.cryptcd.com/

Thanks for your reply, but this is not what i'm looking for.

I want to burn on a disk my own format that only I would be able to retrive the data, which mean on what sector on the disk each file start.

you said that you wanted to do this "so only I would be able to access the data on the disk" ... if what you want is nobody being able to access the info, this is what you need, or something similar ... but as cds are standard, there is no other way to do what you want ... not that i can think off ... if not, protected cds would be common

Have you considered encryption ?

What he is probably thinking of would involve developing a unique file system, and implementing both the software to arrange files into sectors according to that file system, and a driver to read that back.

Of course, without encryption of some sort, that would not protect the data from a simple sector scan.

One could always write a completely different raw bitstream to the CD, one which has more or less than 2048 bits per sector, using regular raw reading to access the the data sectors. Eh.

Simply encrypting your files would be a lot simpler.

exactly, and that is what something licke crytcd does ... but you can use any tool that genreates virtual (encrypted) drives

Yes kode54 this is what I want to do.
The reason I want to do this is for a projet I'm doing at my UNI.
Building a non standard CD Player so only I would be able to read from.
There is no need for me to encrypting the data.

If someone knows where I can start...
Good articles/books on the subject...
How you burn a data stream on a CD? not through NERO.
How you can start reading from a specific sector on the CD?

Thanks
Roy

then is one needs only to copy that filesystem and the disc would be readable.
theer is really no protection in it if thats what you are going for

if you don't encrypt the data, anyone with IsoBuster would be able to read it.

The secret never should be in program or algorythm. Because anyone would be able crack your program in few days or disassemble it and restore your format specification. That is easy. Even extremely good protected DRM schemes are cracked for some months (but they are flawed by design). Do not also try to use your own algorithm for encryption, because it will be also broken in few days, or weeks. Use only reliable algorithms, that many people tries to attack, but failed (for example, RCA@2048 woud be sufficient) DES is not secure anymore, there is even specialized computer for cracking DES.

Anyway, this is WERY hard task; for some years maybe.

> One could always write a completely different raw bitstream to the CD, one which has
> more or less than 2048 bits per sector, using regular raw reading to access the the
> data sectors. Eh.

You cannot write a raw bitstream to a CD with a burner, and even if you could
your burner would not be able to read it. There's no such thing as "only I would be
able to access the data on the disk" with only a driver.

Thanks every one, I'm a novice in this world and your reply help me a lot.
I will try to explain what I need to do more clearly:
I need to build a stand alone cd player that will play not a regular cds but one that is made especially for him, so if I'll try to play this cd on a normal player he will not recognize it.
I don't want to use encryption for two reasons:
1. The data privacy is not so important.(If some one will try to crack it on his own PC, I'll wish him good luck)
2. The stand alone player will need to have a strong CPU to encrypt the data before playing it.
What do you think is the best why to attack this problem?
What I was thinking is to creating my own cd format and drivers to read and write it.
Thanks again
Roy

To write driver you should know perfectly assembler and c++ and be able to use Soft ICE to debug it. You shoud have information about programming drivers to various OS'es (WinNT&Win9x). You should have specification of cd access commands for various drives. And its wery hard to create a competitive usable format. But IMO there should be some support for it in drive firmware (you do not want to write firmware for some drives? dont you? User should be able copy your CD RAW to image and with help of special programs get files for it, knowing most common file headers. This is matter of hours. IMO without rewriting firmware you couldnt make cd that could not be copyed RAW...


ATA Packet Interface for CD-ROMs, 209 pages
Universal Disk Format® Specification (base for your frmt) 164 pages
INFORMATION TECHNOLOGY - Multimedia Commands - 4 (MMC-4) 576 pages

The easiest way for you to create custom Packet Writing program with slightly modified UDF, which would not be recognised by standart programs. You should also fragment files to few blocks to make automatic extraction from RAW image impossible.

> To write driver you should know perfectly assembler and c++ and be able to use
> Soft ICE to debug it.

Funny, after your first post I was convinced you had no experience in cryptography
and after this one I'm convinced you have never written a driver in your life

Why should you think othervise?
Is ha.org a community of driver writers and specialists in cryptoanalysis? Or a secret hacker's forum?

I just listened some lections, read some books and tried to implement some algorithms. And i am also intrested in this thematics. So, correct me if i'm wrong and answer freewind1's question better than me.

If my posts looks so useless... i better not to post...

Interesting. What VolMax said about cryptography sounded like good advice to me. He was just saying that you should use a recognised algorithm and not try to invent your own scheme. What exactly don't you agree with in his post?

I wouldn't know if what he said about writing Windows drivers is correct or not as I have never written one on Windows. If you are going to criticise somebody then you should be constructive - at least tell them what in their post was incorrect.

This might sound ridiculus but i will go on anyway. I am not a programmer or anything like that, but my engineering background helps me think out problems logically.

All cd's spin clockwise, and all players are set up to read clockwise. Can't you find a way to make the drive read and write the data stream anticlockwise Reversing the motors polarity sounds an obvious bet.

You would probably need to program the drives firmware to be able to read cdr's headers backwards though as you can't alter this part. Perhaps even combine this with perhaps a very simple on the fly encryption method and keep the fact its a backtofront disc a secret and it sounds pretty unreadable to others to me. Played in a normal drive would just produce garbarge i expect.

Hey if anyone ever uses this idea to make money I want a decent share of the royalties lol. You could call them B2F drives

Take a look at these Unix tools sources :

The cdrtools sources:
http://www.fokus.fhg.de/research/cc/glone/...e/cdrecord.html

A firmware update utility:
http://www.fokus.fhg.de/research/cc/glone/...e/firmware.html


Hope these will help you

This is how Xbox media works, it's written reversed and can therefore only be read by a unit compatible with this.

I never knew that, I wonder how much the designer who implimented that on the xbox got paid lol. Cos its a bloody good idea

Do xbox dvd units spin anticlockwise then?

> Interesting. What VolMax said about cryptography sounded like good advice to me. He
> was just saying that you should use a recognised algorithm and not try to invent your
> own scheme. What exactly don't you agree with in his post?

There's nothing wrong, that's why I didn't react to this first post. I reacted only
because the second one was misleading and I was also pointing out that both posts were
very peremptory while Volmax's knowledge in both topics is clearly superficial .

> I wouldn't know if what he said about writing Windows drivers is correct or not as I
> have never written one on Windows. If you are going to criticise somebody then you should
> be constructive at least tell them what in their post was incorrect.

Well, the language is called assembly and not assembler, and you don't need to know it
to write a driver. Also the DDK comes with windbg, so SoftIce is not really needed either.
What is really needed to write this new filesystem is MSVC++, the DDK, the MMC specs and
sample source code to start from (e.g. from www.insidewindows.info). And btw Xbox discs
are not written backwards.

Thanks for corrections, spath.



posts are very peremptory because the lack of knowledge of english.

yes, and additionally the first layer is unused to further complicate it.

Xbox DVD do NOT spin backwards and they are not "written backwards".
Please stop spreading this crap.

X-Box drives spin in perfectly normal straightforward directions, as you can tell by simply opening the thing while it's spinning and looking at it.

Now, one thing that is different about a console: Unlike vinyl LP's, CD's and DVD's read and write from the inside of the disc out to the edge. In the particular case of DVD's, the first layer starts at the inside and works out, and the second layer starts at the point where the first layer ends and works inward. This allows for a quicker layer change, since the head doesn't have to reposition, it just has to refocus.

Gamecube discs start at the outside and work their way inward instead. But this oddity of the gamecube is the only trick in commonplace custom disc based formats that I am aware of. They all spin clockwise.