It doesn't matter what the plaintext contains, as long as it can be represented as a sequence of bytes. That's what all modern encryption schemes process as their input and output.
It's perfectly OK to encrypt only some of the data, as long as you can tell which parts are encrypted and which are not. It's easiest if you have one contiguous chunk of bytes to encrypt, because most encryption APIs assume that. You can have unencrypted data before and/or after the encrypted part, and just not pass it to the encryption / decryption code.
With modern AEAD encryption schemes, you can even have both your encrypted and unencrypted data protected against tampering, so that decryption will fail if either part is modified. (You'd do that by including the unencrypted parts as associated data when encrypting and decrypting. You can also include other associated data if you want, like the file name for example.) Note that just encrypting the data with a non-authenticated scheme like plain CTR mode will not protect it against tampering. CTR mode in particular is highly malleable, allowing an attacker to flip arbitrary bits in the plaintext simply by flipping the corresponding bits of ciphertext.
For maximum security and "foolproofness", I would recommend using AES-SIV (or possibly AES-GCM-SIV). It's based on CTR mode, and shares its advantages such as the possibility of parallel and/or out-of-order decryption, but it also includes an authentication layer that turns it into a proper modern AEAD scheme. And it's designed to be "misuse-resistant", such that (unlike e.g. normal CTR mode) it will retain all of its security properties (other than hiding whether or not two encrypted files have identical plaintext) even if the nonce is repeated (or not used at all!).
SIV mode does require you to find a place to store its "synthetic IV" (a 16 byte string for AES-SIV, computed from the plaintext and its associated data) somewhere in your encrypted format. You can e.g. prepend or append it to the file, just as you'd do with the IV for basic CTR mode. But you need to store some kind of a tag, nonce and/or IV with any secure modern encryption scheme, so SIV mode is no worse in that regard. (If you also want to include a nonce for extra security, you obviously need to store that somewhere too. But if your plaintext and/or the unencrypted associated data already contains some unique version identifier or timestamp, then with SIV mode you don't really need a separate nonce.)
(For completeness, let me note the one major drawback of SIV mode: it's a two-pass encryption mode, meaning that it has to store the data to be encrypted in memory or on disk and process it twice, first to compute the synthetic IV and then to actually encrypt it. This makes SIV somewhat awkward to use for things like, say, encrypting streaming video. But for a 1 kb file, it's no problem at all.)
As for its suitability for copy protection, I really cannot say anything specific without more context. Let me just note in general that reliable copy protection is hard (some would say impossible), and there are no simple or foolproof crypto solutions for it.