a release compiled App reveals all resources???

Discussion in 'iOS Programming' started by mraheel, Oct 21, 2009.

  1. macrumors regular

    Joined:
    Apr 18, 2009
    #1
    So, while i was playing around with my app, yet to be released, i decided to have a look at the file size. So, i found the filepath, had a look at the size, i noticed, "Show Package Contents". I went with it, and voila, all my image resources, sqlite databases, and the compiled nibs were wide open. And whats more? the database was fully editable and functional.

    This scared the hell outa me, as SQLite DB is the backbone of my app which is up for grabs.. specially from jailbroken..

    My question is, is there some kinda procedure that apple does before release to prevent this "show package contents" way easy to grab thing?

    any word on db encryption??

    On a side note, had one more question!. I'm testing an app where i have 3 UITableViews in a single ViewController and ofcourse single xib. On compilation, every thing works smoothly, the 3 tables show up smoothly and scroll. I've never attempted this, so I kinda am confused about the "DataSource, Delegate" part of the 3 tables. I have 3 Arrays as data sources. How can I assign each table an array, while remaining in the same ViewController. Cuz i'havent come across any viewcontroller thats got more than one set of tableview methods
     
  2. macrumors 6502a

    TodVader

    Joined:
    Sep 27, 2005
    Location:
    Quebec, Canada
    #2
    How would those files be read if they aren't there? This is pretty much how it works in this industry.

    Be happy you're not in the web script market where you need to sell your complete project with source code. I was (Well I still am) and it's awful to see the piracy and people modifying and reselling your product.
     
  3. macrumors 6502a

    Joined:
    Oct 24, 2008
    Location:
    Cambridge
    #3
    You could use symmetric-key encryption on your database and make the key difficult to extract from code (XOR it into multiple parts or similar). This should be a sufficient obstacle to keep your data from most people.

    Be aware that encryption will greatly slow database access speed (if this is important to you) and will not keep out a determined attacker (see: DRM problem).
     
  4. macrumors 68000

    Joined:
    Feb 12, 2008
    Location:
    Illinois
    #4
    You'd have to put it yourself. I just did the same thing to BeeJive and got all the chats.

    Any reason why you're using three? :O

    Anyway, if you made all three of them instance variables in the header, then in a delegate method such as tableView:numberOfRowsInSection: simply check the table:

    Code:
    - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    if (tableView == firstTable) {
     return 2;
    }
    else if (tableView == anotherTable) {
     return 4;
    }
    else {
     return 1;
    }
    }
     
  5. thread starter macrumors regular

    Joined:
    Apr 18, 2009
    #5
    Well, sounds like a problem, cuz the app i'm making, most apps use Cloud servers. I'm completely embedding sql into the app!
    this can be a little scary!

    regarding, the 3 tables, Im strongly against such acts. But theres a situation where i'm trying to rebuilt 3 tableViews so as to accomplish a pickerView.
    I did the InsetScrolls, content insets rearrangement..

    Like having an Odd number of visible cells. center one is the "picked chosed"

    all was going well, until..

    Code:
    		[self.systemTable scrollToRowAtIndexPath:indexPath atScrollPosition:UITableViewScrollPositionMiddle animated:YES];
    
    i was assuming since i kept scrollable area down to a single cell, that scrolling would take the cell either from the bottom or top row to the middle "selected zone", as it turns out NOT to be the case.

    The scrollToRowAtIndexPath takes it all the way to the top!

    so, in a way, now my goal is the Scroll the Cell1 to ROW(3) assuming odd number (5) of visible cells where 3 is the middle row.
    This is done keeping ContentInsets and ScrollInsets in mind.

    If i take these too out, the scroll wont come to the middle, if I keep them in, I cant get a cell to shift position to middle!


    any word of advice? i think i'm fighting a loosing battle!!!

    All this wouldnt happen if they let us "effectively" customise UIPickerView! not just add a selection indicator.

    I'm attaching the projectfiles, if anyone can take a look, may be its a lost cause??
     

    Attached Files:

  6. thread starter macrumors regular

    Joined:
    Apr 18, 2009
    #6
    haha, thats true man.. indeed...

    I new that files will be in there, its just that i didnt kno they were so easy accessible, in Windows atleast ResHacker or programs like those were required..

    (i'm new to mac :) )
     
  7. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #7
    If you just want to obfuscate your files and databases from casual snooping (running "strings" or a hex dump), you could just use some cheap (XOR) encoding on the characters in the strings.

    Almost anything else (including Apples own OS boot encryption currently) can very likely be broken by determined enough hackers with physical access to the raw CPU data bus(es).
     
  8. thread starter macrumors regular

    Joined:
    Apr 18, 2009
    #8
    i was hoping to messup the sqlite db within the package and make it harder to identify it as a db.

    When u say Xor the strings, im guessing i'll have XOR-ed strings in the db. and i'll hav to decrypt it client side. within app running.

    That would really make my app slower.. i think,

    isnt there some way of making that file invisible or something. encrypting the db file as a whole rather than the encrypting the data and adding it to database?
     
  9. macrumors 6502a

    TodVader

    Joined:
    Sep 27, 2005
    Location:
    Quebec, Canada
    #9
    You could encrypt the data with a algorithm that's hidden in your code. You're the only one with the key to bring it back together. It's not fail proof, but it's better than nothing.
     
  10. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #10
    Actually there is (although this still won't protect your file on a jailbroken device). Convert your DB into a hex dump. If desired, encrypt or obfuscate the hex dump. Then compile the hex dump as an initialized global array in your C source code. After compilation, the data will then end up inside your binary executable. Then at run-time decrypt and dump this hex data into a file in your documents directory and then rename it back to a DB file before using it.

    Downside is that your app (a huge executable) might load more slowly.
     
  11. thread starter macrumors regular

    Joined:
    Apr 18, 2009
    #11
    This is what i'm trying to avoid! it'll be easy to grab the file from docs directory in jailbroken devices.

    I'll try out the XOR things. Any resources of this Xor technique related to iPhone??

    thanks TodVader, firewood, jnic, Niiro13
     
  12. macrumors 68040

    Joined:
    Apr 22, 2005
    #12
    The question I would be asking myself is whether it is really worth it to put in this extra effort towards hiding files as opposed to improving the app for the user. What is the worst thing that would actually happen if someone realized the database file is accessible?
     

Share This Page