2

I have an NSString (which is a path to a file) in my code that I would like to somehow obfuscate or encrypt,

but still be able to call up the file path easily when needed. I searched for an answer to this, but everything I've seen either deals specifically with iOS or seems overly complicated.

I would simply like to use it with something such as this:

- (void)method {

NSString *obfuscate = @"/path/to/something/secret"; // encrypt or obfuscate

[self manageFiles:obfuscate]

- (void)manageFiles(NSString *)obfuscate {

    NSFileManager *files = [[NSFileManager alloc] init];

    if ([files fileExistsAtPath:obfuscate])

    ... .

— any help is appreciated, thank you.

joshua
  • 2,371
  • 2
  • 29
  • 58
Joe Habadas
  • 628
  • 8
  • 21
  • 2
    If you hash the file path how do you intend to access the files afterwards? You could do some very simple encryption like shifting the characters and rotating them. Functions to encrypt and decrypt wouldn't be very many lines of code. – evanmcdonnal Jun 11 '12 at 05:47
  • you can use Common Crypto library. – Parag Bafna Jun 11 '12 at 05:53
  • @evanmcdonnal, that's what i'm asking; how could i do it reasonably? i like the idea of Rot-13 or Vigenère. if that's what your saying. — are you thinking something along the lines of skram's answer? ty. – Joe Habadas Jun 11 '12 at 06:35
  • @JoeHabadas Take a look at https://github.com/AlanQuatermain/aqtoolkit/tree/master/CommonCrypto – Parag Bafna Jun 11 '12 at 06:47
  • If people are going to be looking through the strings in your app, it's going to be very easy for them to use tools to see which files your app is actually accessing. Obfuscating paths like this isn't really worth the effort. – Mike Weller Jun 11 '12 at 07:06
  • @Mike, very true. i guess the purpose would be more to confuse or mask what's where than necessarily be protecting anything. – Joe Habadas Jun 11 '12 at 08:54

2 Answers2

2

(This is an old question, but I'm replying anyway)

There's no such way to in Obj-C. Obj-C is dynamic enough that any of these methods can be trapped and intercepted. Do not ship anything in a application that absolutely needs to be secret. If your application is run on a jailbroken phone, or if it is made available on piracy sites, than it has already been exposed and it's memory contents dumped. All these above methods copy the decoded data to main memory where it is exposed.

See: https://www.youtube.com/watch?v=Ii-02vhsdVk

None of these methods above is actually secure. Again, do not embed these sorts of things in your applications with an assurance they are actually secure.

Colin Cornaby
  • 741
  • 4
  • 14
  • 1
    While that is true the same argument can be made that nothing can be made actually secure. Even Gemalto, the world leader in digital security was hacked ion 2010 and 2011 and even RSA was successfully attacked. Does that mean we should give up trying? Give up encryption? No. It is the level work factor (effort required) that is important. It is always good to increase the work factor. Encryption among other things increases the work factor. One needs to evaluate the value of the data to the owner, the attacker, to the reputation of the developer in both terms of time and money. – zaph Aug 26 '15 at 22:24
  • About the other two answers, they are nothing but obfuscation which is really weak foo but may be sufficient. The question is did the OP evaluate the value vs work factor when choosing the method of protection. – zaph Aug 26 '15 at 22:32
  • The second answer in particular is insanely weak. The first algorithm isn't necessary the worst, but put into a function is easily cracked. What bothered me is that none of these disclaimers were applied to the above. If the OP was trying to secure data that actually needs to be very well obscured I don't know if any of the answers was totally transparent with regards to how well these techniques work. – Colin Cornaby Aug 28 '15 at 17:16
  • Nor does this answer even attempt to answer the question. The accepted answer will not compile, much less work or offer any security. Ex: input: "abcdefghi" output: "jkldefghi", add 3 to each character value, rotate the string by 3 characters. – zaph Aug 28 '15 at 17:56
  • @zaph: It compiled for me (after re-doing the entire thing), I just need to figure out how get back the 10 minutes I wasted. I ended up using `RSA` for this particular task in the end, it's a bit surprising nobody mentioned anything about it at the time... The techniques used here in this thread wouldn't have even stopped me back in the 80's when I was 12. – Joe Habadas Sep 18 '15 at 18:03
  • @ColinCornaby: Yes the methods used here are fairly useless, more of a diversion than anything (sort of like an old tarp you have to move in order to see whats under it). I'm curious what you think might be a viable solution while keeping it simple. – Joe Habadas Sep 18 '15 at 18:06
  • When you say "RSA", that is rather broad. Are you refering to public/private key encryption and if so in what manner are you using it and keeping the key secure. – zaph Sep 18 '15 at 18:21
  • Initially I hid a key in the code, which decrypted another key to decrypt the data I wanted to obfuscate, which really is not that much better than what is here. I finally went with the [CoreCrypto Kernel Module](http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1956.pdf) using public/private keys. It's a bit overboard and can slow things down a bit -- I'm actually looking for other ways of doing things perhaps, so any suggestions are always welcome. – Joe Habadas Sep 18 '15 at 18:53
  • I don't see how RSA helps, there is still a decryption key issue. RSA encryption is limited to the key size and is very slow. Usually the data is encrypted with a symmetric algorithm such as AES and a random key which is encrypted with the public key. But asymmetric encryption is generally only used when separate encryption and decryption keys are needed such as PKI. If the data is small just put the data in the keychain. In the last few iPhone releases they keychain is in the "Secure Enclave", (not to be confused with the "Secure Element"). – zaph Sep 18 '15 at 19:25
  • @zaph: Alright, I had a few years to think about this and decided Colin and you were right. Your scholarly insight finally persuaded me change my vote now that I've had time to fully "digest" the data. Thanks for sharing, listening, and all that is you... :) – Joe Habadas Apr 08 '16 at 03:08
1

What I have done in the past to obfuscate a string was something to this extent:

-(NSString*)myString {

    NSString *string = nil;

    string = [@"ozzzzzzzzzzzzhazzzzzzzizzzzzz" stringByReplacingOccurrencesOfString:@"z" withString:@""];

    return string;
}

What it would do is remove all the occurences of the letter z, leaving you with ohai as a string. Not sure if this will suffice for your case, but it has worked for me.

Hope this helps!

skram
  • 5,314
  • 1
  • 22
  • 26
  • interesting idea; how would i use that with the NSFileManager function I have shown? thanks – Joe Habadas Jun 11 '12 at 06:33
  • How would you be able to get back the original file path again, after you did that? – Khattab Jul 31 '12 at 20:23
  • While it worked for the writer I also would presume it worked for the attacker. – zaph Aug 28 '15 at 17:55
  • @zaph: I changed it a bit to make it more difficult though `string = [@"llqzllqallqpllqhllq hllqallqxllqollqrllqellqd llqmllqe" stringByReplacingOccurrencesOfString:@"llq" withString:@""];` — there's only one or two people that could ever crack that. – Joe Habadas Sep 18 '15 at 18:24
  • ["Schneier's Law"](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html) per Cory Doctorow: "Any person can invent a security system so clever that she or he can't think of how to break it." In this case the patterns give it away. Most anyone would notice "llq" repeated and would disregard it, heck I just used BBEdit. – zaph Sep 18 '15 at 18:36
  • 1
    I love those type of references... and maybe I should have included (sarcasm) in there :p – Joe Habadas Sep 18 '15 at 18:55