How can we protect Wav files for a rompler?

[Spogg]

Hi all

I’m asking this on behalf of our good friend Johan (djbrynte) because he’s not too confident with English. I would also be very interested of course.

I’ve been helping him with various versions of “rompler”. He wants to offer a rompler with a large wav folder external to the plugin/schematic. We have a good working version which accesses the files in a folder alongside the plugin, but he’s asked if there’s a way of protecting the wav files in the folder. At the moment someone could easily copy all the samples which he’s made and gathered over quite some time.

One idea is to encrypt all the wavs offline. Then there would need to be a decryption module inside the schematic, before a file was loaded into the wav player. The idea being that anyone accessing the wavs by other means would just get a mess of sound and not be able to make use of them.

There may be other ideas like making a huge concatenated file and the rompler then just chooses the appropriate chunk. That would be like the N.I. Kontakt system.

I should add there may be 500 wav files and each can be several seconds long, so these are not single cycles. Baking them into the schematic is not acceptable due to massive load times, and memory use for multiple instances.

I have no idea how to even start on such a thing and I imagine the solution would be a Ruby one.

If anyone could help in any way we would be very grateful.

Cheers

Spogg & Johan

[tektoog]

Hey, I know that you can make proprietary file format, that you can just upload and read only with your reader/player.
But this does not alter the wave file itself...
But... perhaps by making the files also read only, it would be impossible to change the extension back to wav...
But whatever way you go, it would be impossible to prevent people to take out their prefered... Windows sound recorder.... and record your files.... This is what digital age leads to.... or

[Jay]

Hey Spogg, You could also concatenate them into one big file and store it in the plugin/exe

i had a schematic that counted x amount of mono wav files in a folder, split that number in 2 and assigned each half of the amount to left and right channels of a stereo wave write, reading them in sequentially from disk via 2 analysers and re-wrote them end to end into a stereo wav file, half on the left chan half on the right! it wrote the indexes and wave lengths into a txt file! after this is done you only need to load the wave file and read back the required section of the wave via index and length! i found it quite efficient for single cycle files and waves for wave-table oscs etc!

it wouldn't stop people getting your samples but it would be a pain in the arse to edit them back into usable files to be worth it i reckon

another thing i played about with in another dev environment was storing files inside an encrypted zip archive and having my app open it and read the files in as required, again it wouldn't stop a determined person getting to them but would stop the average joe blogs from using or distributing them else where!

just some ideas! probably stupid ones mind you!

Best wishes! I hope you and all the gang here and all your loved ones are doing good and keeping safe in the current situation

Regards

[tulamide]

One idea is to encrypt all the wavs offline. Then there would need to be a decryption module inside the schematic, before a file was loaded into the wav player. The idea being that anyone accessing the wavs by other means would just get a mess of sound and not be able to make use of them.

The answer to the question of this thread is "you can't".
Whatever method you use, it will be made accessible sometime. All you can do, at that has already been said, is to make it last longer to get the audio information. If it takes a year to decode, chances are, people won't bother decoding it.
The way to go is, as also has been said, using a propriety format. Just mangle the bytes with pseudo-randomness, which can only be reconstructed with the correct seed and knowledge about the algorithm used for this prng. Well, everybody knows which algorithm Ruby uses, so there's either generating your own prng algorithm or being ok with a limited time until the correct seed is found via brute-force.

First step: Create raw audio files from the WAVs. Those have no header (so no information about number of tracks, bit depth, frequency, etc.), just the plain data. At this stage you should consider the format of the data (so called encoding), as that can't be changed later on. Most audio editors offer anything from integer 8 to 32 bit, float, compressed, uncompressed.

Next step: For each file, get the size of it in bytes and set up a prng with a dedicated seed (important, as it functions as the key to later open the vault). Half the size value and round it upwards to the next integer. Iterate through this value and let the prng spit out two integer values within the range of the original size value. These are two position values now, that you use to switch the data bytes (a = datapos1, b = datapos2, read data from a to an intermediate buffer, read data from b and store it at a, then store buffer at b).

Now the files are unreadable for audio editors. They wouldn't know the format, but even if they knew, it would only be noise you'd hear.

Last step: In the rompler you use the same prng-algo and the same seed (!). But here you do everything in reverse. So let the prng spit out 2 position values per iteration, but ignore them, until you reach the last iteration. Those are the positions in the file that were switched last. Switch them back (see above). Reset the prng, but this time stop at the last but one iteration. And so on.

This last step could be done in RAM (memory prim?), so that the files will always stay in their unreadable mangled form. But, you need a way to tell Flowstone the audio format of the data, and I don't know how. This won't be an issue of course, if you save the raw files encoded in Flowstone's internal format (I think that's single float @44.1kHz, right?).

[Spogg]

Guys!

Thanks for joining in.

I have no idea how to go about doing what is suggested, but I need to add that we want to stop the casual user from stealing the wavs. As was discussed on another thread, there’s nothing to stop a determined and skilled hacker from cracking just about anything. But these are just wav files, not an expensive DAW or pro synth.
So the solution should be something that’s easy to implement and fast to operate in the rompler itself, and deters simple direct usage elsewhere.

Cheers

Spogg

[CoreStylerz]

One simple solution can be using openssl to encrypt wave files. (no matter if it's a bundle or not).

To protect the wave you'll have to:

[list=]
[*] encrypt wave files using a public key
[*] give user a key to de-encrypt the files (normally public key don't allow that)
[*] give user a key with a short live (like 1 month) for offline use and allow key regen after it expires
[/list]

The encription is simple, since it uses openssl and should be supported by Ruby or called by a CLI exec. (you can redistribute openssl if you want).

The complex part is that you have to create a pieace of software for user license management and key generation.


This might be:
- plugin require the key
- server respond with the decrypt key
- plugin uses the decript key to load the bank
- plugin require again the key when expries

The user should receive a key with a fixed limited time that allow data decription.

The server holds the private key.

This mean few work in FS, more on a web server.

it's quite straightfoward if you know how to make the server part.

File will require too much machine-time to be decrypted. Of course, this will not stop legit public key owners to just decrypt the files and share them.

The rotation of the key prevent people from sharing the public keys.


You might create a noise sound on the entire bank for protecting un-authorized access, as long as you are able to remove it during execution.

docs:
https://gist.github.com/dreikanter/c7e8 ... dff308736b
https://www.czeskis.com/random/openssl- ... -file.html

Another cool is to encrypt data per user and give them a new key for any machine. They should then download the banks from your service that give the encrypted files for that machine.

[tulamide]

So the solution should be something that’s easy to implement and fast to operate in the rompler itself, and deters simple direct usage elsewhere.

There are a couple of easy things, but they are so easy that they really only deter the most simple try of usage elsewhere. The WAV format is based on RIFF, a cool format that is based on chunks. Each chunk is identified by a 4 byte signature and is followed by a defined set of properties. You can either change the signature of one of the chunks to something unknown, or set one of the properties to a value that is outside of its declaration.

In the first case the file would still be loaded, but the chunk with the unknown signature will be ignored. That falsifies the audio of course, therefore protecting against usage.
The other case will provoke an error message.

The plugin could use one of the Ruby WAV readers, one made by KG_is_back, the other I think by trog, extended to read the purposely changed chunk.

I'm afraid it doesn't get simpler, without being so unprotective, that the effort of protecting isn't worth it.

[deraudrl]

Another cool is to encrypt data per user and give them a new key for any machine. They should then download the banks from your service that give the encrypted files for that machine.

I've owned software with that "feature" and I'm not sure which is greater:
1. the hatred it inspires in your customer when some machine component dies and get replaced, making the software think it's now on a "new" machine, and/or
2. the further hatred it inspires in your customer when your validation server goes offline at some critical juncture, like right after #1 occurs. (Or worse, as I experienced in one case, permanently, leaving the app stranded on an ailing/obsolete computer.)

[CoreStylerz]

1. the hatred it inspires in your customer when some machine component dies and get replaced, making the software think it's now on a "new" machine, and/or

Sure. It is really bad customer side..

2. the further hatred it inspires in your customer when your validation server goes offline at some critical juncture, like right after #1 occurs. (Or worse, as I experienced in one case, permanently, leaving the app stranded on an ailing/obsolete computer.)

The availability of a werbservice in quite easy to maintain nowadays.. Like using cloud serveless services.

[deraudrl]

2. the further hatred it inspires in your customer when your validation server goes offline at some critical juncture, like right after #1 occurs. (Or worse, as I experienced in one case, permanently, leaving the app stranded on an ailing/obsolete computer.)

The availability of a webservice in quite easy to maintain nowadays.. Like using cloud services.

That assumes someone is around to "maintain" anything: the situation I'm alluding to is when the original software vendor goes out of business. I certainly would not expect the cloud services provider to keep it running when the bill stops being paid.

Usually the first warning the end-user has is when they are unable to connect to the validation server after their old computer dies. Been there, done that. (Trust me, if FS had any form of copy protection, I would not be here having this conversation.)