How to change file bits without reading entire file

[Mr.M]

Hi DW.

How can one read a file or change a file bits without reading the entire file. But first of all how can I read a file in such a way that I get it's bits. I want to read MP3 file and change it bits but I don't want to change the information stored on it like artist name, album year, but want to read it and change bits in such a way that MP3 players won't recognize this file as MP3, and most importantly how to change the file back to original bits. Some one also mentioned XOR to me which is also reversable as he said but XOR was out of my understanding, I mean I know this from Gate (OR gate, NOR gate,etc) but I couldn't figure how could I apply it to my problem, case.

I'm really stuck on this problem.

[ddanbe]

To change the read/write position in a file use the lseek function. There is a XOR operator : ^

[Gribouillis]

Are you looking for a xor cipher https://en.wikipedia.org/wiki/XOR_cipher ?

[AssertNull]

You'll probably need to refine your question. You have it tagged with two different languages. You don't "read a file to get its bits". You "read a file to get its bytes". So to "read a file to get a bit", you do a few things in order...

1. Figure out which byte you need to read in order to get the bit
2. Read that byte from the file (however you choose to do it)
3. Isolate the bit WITHIN the byte (see your previous thread for code on how to do that)

The important thing to remember is that 1 and 2 involves files and number 3 does not. Thus all the functions you might use to do 1 and 2 will have nothing to do with "bits". Take ddanbe's lseek suggestion

http://man7.org/linux/man-pages/man2/lseek.2.html

If you search this page for the word "bit", you won't find it (well, you'll find "bit" as part of a larger word, but you know what I meant). Similarly if you search C++'s istream library or any API from any language, I doubt you'll find any function in there dealing with reading or writing "bits".

I want to read MP3 file and change it bits but I don't want to change the information stored on it like artist name, album year

You avoid doing that by consulting the MP3 spec and figuring out where those bytes are located and not writing to those bytes (again bytes, not bits).

Regarding XOR, tons of encryption/decryption algorithms use it. In its most basic form, you're talking about Gribouillis' link. No serious encryption technique uses ONLY XOR. Read the link to see why, the most blatant being that the plaintext and the encrypted text XOR'd together yields you the encryption key.

I couldn't figure how could I apply it to my problem

Again, see link. When you XOR a portion of your playable MP3 file with the encryption key, you'll end up with "encrypted" unplayable bytes. When you XOR the unplayable bytes with the encryption key, you get the playable MP3 bytes, and in a computationally inexpensive manner (very handy when converting on the fly - you could actually decrypt as you were playing the MP3 song as opposed to beforehand and there would be no delays, whereas more computationally intensive and secure techniques might require you to decrypt/buffer, THEN play the sound).

The fact that it's so computationally inexpensive plus the fact that the plaintext and the encrypted text XOR'd with each other yields the key makes it easy to crack. Hence the "salting", multiple rounds, and bit jumbling / shifting used in real encryption techniques to make the bad guys at least put in some effort.

[Mr.M]

Thanks and I've just played around with XOR and I was able to understand it now. @NULL

very handy when converting on the fly - you could actually decrypt as you were playing the MP3 song as opposed to beforehand and there would be no delays, whereas more computationally intensive and secure techniques might require you to decrypt/buffer, THEN play the sound

This is what I was also after and I think XOR is the way to do this. Also thanks for clearing about the bit,bytes now I understand it. I will try this thing out and see. Thanks again everyone and sorry for late reply was trying to understand this.

[Mr.M]

@Null I've tried playing around with bits and changed it using VB5.0 and the file keep on playing. On the other post you also mentioned other 16 bits that comes with bit located in position 16 which is 'D' - (CRC). I don't seem to understand that part because bit D is 1 bit. Also there is something strange I will say according to this thing. These are suppose to be 1s and 0s but some return numbers like 32, 77, 105, and also even on D bit I can write anything which is not 1 or 0. Aren't is suppose to only take either 0 or 1? Also is there anyone know where the audio actually start because I notice that you can access more bits on this and some return lager numbers because I don't want to change that.

Coming back to XOR. is it posible to just xor the file straigth if so, I'm sure I will have to read it and xor it bytes am I correct?

If I successfully XORed the file it won't be supported am I right?
I think if there could be a way that the players detect the mp3 format without using it extention just like other files, taking .exe file, it is posible to detect it if it is an exe or not by just checking the MZ if exist or not. How to check similar thing on an mp3 file?

[AssertNull]

I can't help you with anything in Visual Basic. I gave you some sample code in C++ in your last thread. It was intended to be used as an example and be changed to your needs. I'm not sure if you are referring to that code or if you changed it. You should post whatever C++ code you are using, even if unchanged, in this thread so that people aren't guessing. You still have this tagged as both C++ and Visual Basic.

On the other post you also mentioned other 16 bits that comes with bit located in position 16 which is 'D' - (CRC). I don't seem to understand that part because bit D is 1 bit.

D is one bit. Set that D bit as 1, which means you are using CRC. That changes the header from 32 bits long to 48 bits long. Bits 33 through 48 are CRC bits. Since the unplayable mp3 file is designed to be unplayable, you can use those CRC bits to hold whatever you need them to hold in the invalid file. For the VALID file, once it's decoded into something playable, you would change those 16 bits to the actual CRC.

Yes, a bit is 0 or 1. It can't be 77 or 105 or 32. I can't comment on what that is about since you haven't posted the details, but clearly something is wrong somewhere.

Regarding the rest of your post, I'm not sure what is happening. I'm actually working on my own little similar mp3 project, so I'll post some of that. Perhaps it will clear things up for you.

[AssertNull]

OK, looking at my project and my code, it's going to be difficult to adapt it to something workable for you, but the basic idea is that you set the D bit to 0 in your intentionally unplayable MP3. That makes your header 6 bytes long instead of 4 bytes long. Bytes 4 and 5 are yours to do with as you please. There are roughly 38 frames per second of music, so a five minute song is 300 seconds, which is 300 times 38 equals 11,400 frames per song, which is 22,800 CRC bytes for the file since each frame has two CRC bytes when you use the CRC. That's 22,800 bytes that you can use for whatever you want in your intentionally unplayable file since, given that it is unplayable, the CRC bytes need not match the calculated CRC.

You will NOT be able to use those 22,800 bytes in your legitimate, playable MP3 file since for the CRC to be playable, you have to fill the CRC bytes in with the calculated CRC. One way to get around that, potentially, if you need those 22,800 bytes in the legitimate MP3 file is to write your own MP3 player and in that player, skip the actual CRC calculation and check.

However, this all brings us back to the larger issue discussed in your previous thread. If you are going to write your own MP3 player or your own format, you really don't need to follow the MP3 standard at all. You can simply, for example, take a legitimate MP3 file and simply add whatever you want in front of the file and keep the MP3 portion the same. Or encrypt the MP3 portion and have the algorithm/key stored in those bytes at the front of the file. Changing around the MP3 seems like a lot of unnecessary work. But that was the last thread, not this one. You said you had a reason that you couldn't fully explain due to proprietary code/techniques and were thus constrained to messing around with the actual MP3 bytes. Thus, my solution allows you 22,800 bytes to write whatever you need to while keeping with the MP3 format.

Good luck.