1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

a release compiled App reveals all resources???

Discussion in 'iPhone/iPad Programming' started by mraheel, Oct 21, 2009.

  1. macrumors regular

    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


    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

    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

    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:

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

    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..

    		[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. macrumors regular

    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

    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. macrumors regular

    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


    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

    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. macrumors regular

    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

    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