Currently I'm using this tutorial now but I need some help in saving it to an image. For security purposes, is it possible to encrypt the file. And also, only my app will access the said file. I'm asking for help for saving it as image but encrypted, as well as how can I access the encrypted file. Thanks!
It is possible to encrypt any file. The difficult part of your question is if you really want the resulting output to still be an image, rather than a random seeming array of bytes. Image files have strict formats while encrypted files appear to be random and unformatted.
It is not clear, but you may be wanting something like steganography, where one image is hidden inside another. The hidden file can either be your plain image, or the encrypted version of your image. If you hide the encrypted version, then obviously you will need to decrypt it before you can display it.
Related
I need to read document texts with ruby and then perform some operations on their contents. Some of these documents include images that I need to upload to my server and later show the data with images. Any idea on how I can achieve this?
I'm thinking of using doc_ripper/docsplit, but ripper doesn't talk about images extraction, and docsplit seems to only take a screenshot of the entire page.
If this is not possible, I am fine with a way to recover the image file name in the right position, so then I can extract the file and upload it manually.
If I store important values in a plist in xcode, is that less secure than if it was hard coded in a class? Could jail broken devices mess with those values easily? I know there's a certain level of risk with everything, but can someone explain the relative risks of a flat file vs hard coded values (in a MyClass.m file)?
Sub question:
How do you go about storing large amounts of initial data for a game/app to run on? It's fine if the values are readable, I just don't want them easily writable.
as for reading data:
plist data is not secure at all - getting plist content takes virtually no time! (and as the ipa is just a renamed zip you don't even need a device ;))
Extracting compiled code is 'harder' but in case of plain text strings only by a small margin.
(again: no need for a device)
as for writing to it:
data is you deliver is never writable without breaking the code signature. Therefore any method is fine. Often one ships CoreData databases when using CD, but I also use xmld, jsons, plists.. to deliver my content. whatever suits the needs best
note: breaking the code signature makes the app unusable on a stock iOS device but I think It'd remain usable on a jailbroken phone as the kernel doesn't really check the signature there
The values stored in you source files (.m) are safe, it is quite hard to access them. On the other hand accessing an app's plist, image sources, and other files are quite easy, there programs to achieve this (for example: Iexplorer) and it doesn't have to jailbroken at all.
So if you have sensitive information stored in your plist, it worth to encode the file, or store it in your source code.
Anyone can access a .plist file. But if is hard coded in a class is much more secure, use the second option. Nothing is 100% secure, but hard-coded in a class if someone want to access this value, the work is more hard.
You can store your Data into NSDictionary, then convert it to NSData, then do some simple crypto (re-order bytes for ex), then write to you application folder. When you want to read them, just take the content of the file, then decrypt, then re-create NSDictionary.
convert NSDictionary to NSData:
NSData *someDatas = [NSKeyedArchiver archivedDataWithRootObject:aDictionary];
convert NSData to NSDictionary:
NSDictionary *aDictionary = (NSDictionary*) [NSKeyedUnarchiver unarchiveObjectWithData:someDatas];
The data is secure in the way that the user cannot modify the content the right way cause the data won't be valid while application read it.
If you're looking to store sensitive values that you don't want jailbroken devices or reversed engineered app to get access to, you can easily think of using UAObfuscatedString.
As quoted:
When you write code that has a string constant in it, this string is saved in the binary in clear text. A hacker could potentially discover exploits or change the string to affect your app's behavior.
UAObfuscatedString only ever stores single characters in the binary, then combines them at runtime to produce your string. It is highly unlikely that these single letters will be discoverable in the binary as they will be interjected at random places in the compiled code. Thus, they appear to be randomized code to anyone trying to extract strings.
Having values hard coded in code or in a plist file is considered risky for sure.
I am encrypting downloaded files and saving them locally in app's documents directory.
To read them you must decrypt those file and store some where temporarily.
My concerns are:
1.if I store them in doc directory for time they are being used, for that time window one can get those files using tools like iExplorer.
2.My idea is to store them in memory for the time they are being used and flush the vault after use.
This option is good for small files but for large files say 50 MB or video of 100 MB, I am afraid that app will receive memory warning in result will terminate abruptly.
I want to know the best approach for doing this.
There is no perfect security storing local files in a safe way. If a person has full access to the device, he can always find a way to decrypt the files, as long as your application is able to decrypt it.
The only question is: How much effort is necessary to decrypt the files?
If your only concern is that a person may use iExplorer to copy and open these files, a simple local symmetric encryption will do the trick.
Just embed a random symmetric key in your application and encrypt the data block by block while you download it.
You can use the comfortable "Security Transforms" framework to do the symmetric encryption. There are some good examples in the Apple Documentation.
When you load the files, you can use the same key to decrypt them while you load them from the file system.
Just to make things clear: This is not a perfect protection of the files. But to decrypt the files, one has access to your app binary. Analyse this binary in a debugger and searching for the decryption part to extract your symmetric key. This is a lot effort necessary just to decrypt the files.
Split your files into smaller sizes before saving them, then decrypt on load.
Later edit: I noticed this is mentioned in the comments. I agree splitting files isn't the easiest thing in the world, but presumably you'll only need this for video. About 100MB is a lot of text or audio. If your PDF weights as much, it's probably scanned text, and you can change it into a series if images.
And yes, splitting better be done server-side, don't want the user waste battery in video processing.
Decrypt them, obfuscate them with a toy algorithm (e. g. XOR with a constant block), and store them in documents. When needed, load and decrypt.
Since the problem has no solution in theory (a determined enough attacker can read your process memory after all), it's as good a solution as any.
I've asked similar questions before, but have not received a definitive answer. Seems that there must be a way to simply add/modify metadata to an image without loading the image into memory, without having to deal with directly reading bits.
Seems like ways exist when using CMSampleBufferRefs, but I need to be able to do this with a regular image already saved to disk.
For instance, given a very large png at /Documents/photo.png, I want to modify its exif metadata without having to load that image.
You can use libexif - I've had success with compiling it for iOS before. With libexif, you can modify any image's EXIF metadata.
If you know how to modify the EXIF, you can modify the binary data directly from the file. Just replace in the image the binary portion with the new one.
I don't know if objective-c permit this, but in ansi c should be simple. The complicate part is to identify the exact part to change.
I want to distribute a few images and not allow others to see them unless they are using my program. My intention will be to use JPG files in which I will alter the header so other image viewers cannot read them anymore. For example I can delete the bytes 7-10 which are the magic signature for JPG. Later, my program will reconstruct the header and show the JPG file.
Question: how do I do this on the fly, without reading the “broken” JPG file, restoring the header, saving the good file to disk and then re-loading it as a “good” JPG file?
Load the "broken" file into a TMemoryStream, patch the bytes in-memory, and use TGraphic.LoadFromStream() to load the fixed JPG file.
Encrypt them. Load the encrypted image, decrypt in memory and then do the loadfromstream like mghie suggested.
Why not just encrypt the images with a private key and distribute your public key to the people you want to view the images? much easier to distribute a public key than writing some custom software and distributing that. Don't forget; anything displayed on screen can be screen captured. The fact a custom-mangled JPEG can only be displayed with your app is no protection. Also don't forget; people can simply distribute your software with the mangled image.
Mghie's answer is about as good as you'll find, but it's not likely to be too effective. If someone wants to look at your images and they know anything about image formats, they'll open it in a hex editor and most likely recognize what they see as a JPEG with the magic header removed.
If you really want to keep someone from viewing your images, construct your own image format, (it's not as hard as it sounds, really,) and put as little metadata in as possible, and then hope that works. Or encrypt them, or put them into an archive, (construct your own archive format for best results,) and hope that works.
Thing is, ultimately, anything that's encoded has to be decoded before it can be shown, and any sufficiently-talented hacker can trace their way through your decoding routine and figure out how it works. Why are you trying to hide things from your users anyway?
You could make it more difficult for them by byte packing the images as encrypted resources. But like anything else if they have access to the files that could get the images out. It just depends on how much effort the are willing to use.
Depending on how secure you need it to be you could do something as simple as obfuscate the file extension to an extension that is only opened with your application. This will only work if its not super secret images that you are changing.