I am in the process of upgrading an existing application that was written in flash to play mp3 files of phone calls. The purpose of the application is to train employees of how to work with customers. Some of the calls are "negative" calls and those are used to train employees of what NOT to do.
The reason I need to not provide a location of where the mp3s are, is that if someone were to become disgruntled and leave the company and decide to take some of the negative calls with them, that would be bad. I don't ever like to underestimate the intelligence of our users so I'm sure some could figure out a way to get them regardless.
The current implementation as I said was written in flash and it loads up all of the mp3s as the swf file loads on the client thereby mitigating the necessity to ever make a call up to the server to grab a new mp3 file. None of these mp3s are huge in file size because they're all only about 30 second phone call clips.
Are there any ways to prevent a direct download of an mp3 from an IIS server. Could I serve them up with c# as an aspx file that requires a specific hash or salt in order to play?
I really dont' want to have to have them all brought into a swf like the current implementation if I can avoid it.
any suggestions welcome.
TIA
Honestly, if a user is that determined to get the data, they will. I believe the balance here is at what point will said hypothetical employee feel the gain to be had by obtaining the data is not worth the effort to get it. And how much effort you have to go through vs. what it is worth to the company.
If the audio will always be played back on your application, one simple layer of security would be to encrypt the files. Keeping it simple, you can use a symmetric key, store it in the application, and decrypt the file in memory before it is played (this way it's not stored in a temporary file the user could just grab). Sure a user with 3/4 of a brain could probably fish the key out of the executable, but frankly the sound is playing on their speakers and I'm sure they have a smartphone. They could just as easily record the output with Sound Recorder as it plays too.
Simply speaking, I believe a very minimum layer of technological security mixed with a binding confidentiality agreement should give you enough recourse. The security will keep the would-be-honest honest and deter the lazy, as well as giving you a leg up in proving the employee obtained the audio through nefarious means (i.e. it wasn't just "available for the taking").
Related
My embedded linux gets its data files from an external source (sd card). As this media is easily detachable I'd like to protect it in a certain way.
First idea that comes in mind is to do encryption. I'm afraid though this would take too much processing power. My files are not deeply sensitive, but I don't want that people can put the card into their desktop and see/copy my files. I assume these people know how to mount a standard ext4 drive.
Content is initially loaded on to the disk via a desktop linux box, so the process should be
I wouldn't care too much if the solution is not hack-proof. Basically I want to avoid to have my content copied by the general copycat.
I'm not looking for a turn-key solution, but like to get some pointers into the right direction.
A simple XOR Cipher requires very little processing. The security is limited in the sense that if someone has a both the encrypted and plain-text data, by XOR'ing the two the encryption key is revealed. However so long as you can avoid someone being knowingly in possession of both, and the key itself remains confidential, it may meet your requirements of simplicity and security.
Obviously you need a longer key that the simple 8 bit one in the example in the link. The key itself can be arbitrarily long with no impact on performance.
I'm putting together a mobile version of a webpage which consists entirely of client art. For the old-fashioned desktop version, I just used PNGs, but I really wanted to use SVG for mobile. SVGZ would be smaller and resolution independent, so it seemed like a perfect use case.
But the client is worried that, once his art is online in SVG, anyone could download the files and use his art illegally (he's had stuff he worked on pirated before, so he takes this pretty seriously.) This had never occurred to me until he brought it up, but the SVG would basically be his original source art.
I was wondering if there's any way to prevent the SVG files from being accessed by the user. As far I know this is impossible -- making the files available to the user-agent means making them available to the user -- but I wanted to ask around to be sure.
Thanks for any help.
No, this is impossible. If a web browser can request the files for display, then any computer anywhere can request the files and save the direct results.
Serving up intentionally degraded artwork (e.g. rasterization) is the only way to prevent people from having the originals. Of course, a determined thief could still re-trace the PNG and get a vectorized, resolution-independent close approximation of the original.
Your client could alternatively:
Include copyright comments in the source, proving ownership. (Yes, a thief could delete these.)
Include 'hidden' elements (0% opacity or placed under another item), proving ownership. (Yes, a thief could delete these.)
Use data steganography in the source SVG to watermark it (e.g. vary the decimal values in a path in a manner minor enough to not effect the result, but still embed custom data). (Yes, any thief suspecting this could lower decimal precision or transform all values in a manner that might remove this.)
Trust in the law to protect his works, or provide a recourse if they are stolen.
Trust in the goodness of most of mankind to not do this.
Decide that theft is the sincerest form of flattery, and not worry about it. :)
I saw allot of companies offering exe wrappers , but is there any in pdf side security programmatically ?
Well, you can encrypt the PDF. You can also use custom encryption handler and thus make your file unreadable with stock Acrobat or Reader (one will need to install your decryption plugin to Acrobat or Reader to make them understand your encryption). The problem is acrobat's DRM SDK (the one that allow you create encryption plugins) once had enormous cost (smth. like $25K to start). I don't know if this is still the case, though.
Another not-so-bad option is render everything to graphics - this makes text copying harder (though one can print everything and OCR it back).
The short answer is no. When you give someone the ciphertext, key, and cipher they will always be able to reproduce the plaintext. DRM fails universally for just this reason.
The long answer is that you can sometimes try little gimmicky tricks to prevent copying in some circumstances which may "work" if your audience doesn't try breaking it, but not in the general case. You can't really call something secure which is "safe as long as nobody tries to break it".
The PDF format itself has an "owner password" which allows the author to disallow readers from printing the document, modifying it, etc... Of course there's not actually any mechanism for preventing anyone from doing so. If you are trying to prevent the guys in the marketing department from printing it off or something, then maybe. But if you're releasing it out into the Internet, just assume that it can and will be copied however users see fit.
For not-free iphone applications, can I use sound files from this websites?
Tintagel's Free Sound File Archive
Can I download the wav files and use/play them in my app, without getting into any problems? I just need several very short wav sounds(shorter than 1 second).
If you really want to be safe, record your own sounds - that way, you know that the copyright holder has given you permission to use them. Unless you have a blanket release of copyright on those (or other) files, or an explicit licence to use them for any purpose, you can still get into trouble.
And I don't mean something wishy-washy like:
To the best of our knowledge, blah blah blah ...
That's unlikely to hold up in a court of law :-)
The main problem with digital copies is that they're perfect reproductions, meaning the copyright holder can easily tell that you've ripped off their work.
Not that I would suggest this as an option, since it's still probably a derivative work, but if you really can't record your own sounds, you might want to think about editing the sounds somewhat to make that harder, ideally fed from the computer out through a speaker back into a microphone and into another file :-)
Or, look into sites on the web where they actually state that they own the copyright and license you to use the files as you see fit. That way, you at least have some protection if they (or someone else) comes back later to collect payment.
One example is Partners In Rhyme, which has a huge range of effects which they appear to own the copyright to, and with a generous royalty-free licence. This was found as the second entry when googling "public domain sound effects" (this first was a rather useless, content-free tutorial on how to find public domain sound effects). There are plenty of other links bought up that you may wish to check as well.
To be safe, I'd actually print out the licence and screen dump the pages where you're downloading from but that's because I'm inherently paranoid :-)
Well, the top of the website says that they are provided free of charge, so that would mean they've been release to the public domain and you're fine.
However, the second sentences says "to the best of our knowledge," which implies that whoever made the website did not create the sounds, and might not have the rights to give them away. Given the way it's worded, it sounds like someone just found those sounds and put them up online. I'd look somewhere else if you're worried about the legality; there are plenty of websites that offer media with real, proper free licenses.
The very top of the page says:
To the best of our knowledge, all wave, midi, and audio files presented here are in the public domain and are available for use without restriction.
So, yes, if you trust that.
How does one combine several resources for an application (images, sounds, scripts, xmls, etc.) into a single/multiple binary file so that they're protected from user's hands? What are the typical steps (organizing, loading, encryption, etc...)?
This is particularly common in game development, yet a lot of the game frameworks and engines out there don't provide an easy way to do this, nor describe a general approach. I've been meaning to learn how to do it, but I don't know where to begin. Could anyone point me in the right direction?
There are lots of ways to do this. m_pGladiator has some good ideas, especially with seralization. I would like to make a few other comments.
First, if you are going to pack a bunch of resources into a single file (I call these packfiles), then I think that you should work to avoid loading the whole file and then deseralizing out of that file into memory. The simple reason is that it's more memory. That's really not a problem on PC's I guess, but it's good practice, and it's essential when working on the console. While we don't (currently) serialize objects as m_pGladiator has suggested, we are moving towards that.
There are two types of packfiles that you might have. One would be a file where you want arbitrary access to the contents of the files. A second type might be a collection of files where you need all of those files when loading a level. A basic example might be:
An audio packfile might contain all the audio for your game. You might only need to load certain kinds of audio for the menus or interface screens and different sets of audio for the levels. This might fall intot he first category above.
A type that falls into the second category might be all models/textures/etc for a level. You basically want to load the entire contents of this file into the game at load time because you will (likely) need all of it's contents while a player is playing that level or section.
many of the packfiles that we build fall into the second category. We basically package up the level contents, and then compresses them with something like zlib. When we load one of these at game time, we read a small amount of the file, uncompress what we've read into a memory buffer, and then repeat until the full file has been read into memory. The buffer we read into is relatively small while final destination buffer is large enough to hold the largest set of uncompressed data that we need. This method is tricky, but again, it saves on RAM, it's an interesting exercise to get working, and you feel all nice and warm inside because you are being a good steward of system resources. once the packfile has been completely uncompressed into it's destinatino buffer, we run a final pass on the buffer to fix up pointer locations, etc. This method only works when you write out your packfile as structures that the game knows. In other words, our packfile writing tools share struct (or classses) with the game code. We are basically writing out and compressing exact representations of data structures.
If you simply want to cut down on the number of files that you are shipping and installing on a users machine, you can do with something like the first kind of packfile that I describe. Maybe you have 1000s of textures and would just simply like to cut down on the sheer number of files that you have to zip up and package. You can write a small utility that will basically read the files that you want to package together and then write a header containing the files and their offsets in the packfile, and then you can write the contents of the file, one at a time, one after the other, in your large binary file. At game time, you can simply load the header of this packfile and store the filenames and offsets in a hash. When you need to read a file, you can hash the filename and see if it exists in your packfile, and if so, you can read the contents directly from the packfile by seeking to the offset and then reading from that location in the packfile. Again, this method is basically a way to pack data together without regards for encryption, etc. It's simply an organizational method.
But again, I do want to stress that if you are going a route like I or m_pGladiator suggests, I would work hard to not have to pull the whole file into RAM and then deserialize to another location in RAM. That's a waste of resources (that you perhaps have plenty of). I would say that you can do this to get it working, and then once it's working, you can work on a method that only reads part of the file at a time and then decompresses to your destination buffer. You must use a comprsesion scheme that will work like this though. zlib and lzw both do (I believe). I'm not sure about an MD5 algorithm.
Hope that this helps.
do as Java: pack it all in a zip, and use an filesystem-like API to read directly from there.
Personally, I never used the already available tools to do that. If you want to prevent your game to be hacked easily, then you have to develop your own resource manipulation engine.
First of all read about serializing objects. When you load a resource from file (graphic, sound or whatever), it is stored in some object instance in the memory. A game usually uses dozens of graphical and sound objects. You have to make a tool, which loads them all and stores them in collections in the memory. Then serialize those collections into a binary file and you have every resource there.
Then you can use for example MD5 or any other encryption algorithm to encrypt this file.
Also, you can use zlib or other compression library to make this big binary file a bit smaller.
In the game, you should load the encrypted binary file and unpack it. Then decrypt it. Then deserialize the object collections and you have all resources back in memory.
Of course you can make this more comprehensive by storing in different binary files the resources for different levels and so on - there are plenty of variants, depending on what you want. Also you can first zip, then encrypt, or make other combinations of the steps.
Short answer: yes.
In Mac OS 6,7,8 there was a substantial API devoted to this exact task. Lookup the "Resource Manager" if you are interested. Edit: So does the ROOT physics analysis package.
Not that I know of a good tool right now. What platform(s) do you want it to work on?
Edited to add: All of the two-or-three tools of this sort that I am away of share a similar struture:
The file starts with a header and index
There are a series of blocks some of which may have there own headers and indicies, some of which are leaves
Each leaf is a simple serialization of the data to be stored.
The whole file (or sometimes individual blocks) may be compressed.
Not terribly hard to implement your own, but I'd look for a good existing one that meets your needs first.
For future people, like me, who are wondering about this same topic, check out the two following links:
http://www.sfml-dev.org/wiki/en/tutorials/formatdat
http://archive.gamedev.net/reference/programming/features/pak/