Is there a way to decompile an iPhone binary file in order to extract it's resources like images and sound files?
If you have sync the app to you Mac, just open the following folder:
/Users/YOUR_USER_NAME/Music/iTunes/iTunes Media/Mobile Applications
Or open iTunes and go to Apps and right mouse button on the app and select "show in Finder"
Copy the app you want to inspect, f.e. Demo.ipa
Change the extension ipa to zip => Demo.zip
Extract the zip
Open the folder and then the folder "Payload"
Right Mouse Click Demo.app and select "Show Package Content"
Change your .app file extension to zip and then extract the files. You will be able to get all resource files.
An iPhone .app file is simply a folder. If you're viewing it on a Mac (or even on the iPhone with iFile), just remove the .app extension and you should be able to view the resources. On Windows and Linux (tested with Ubuntu 14.04), it should "just work" and you'll be able to view the folder's contents without any renaming.
Edit: Removed the assumption that images/sound would be used in another application.
First, off you shouldn't be reverse compiling code so that you can get images/sound files from an iPhone or any other application for that matter.
Second, reverse compiling does not always guarantee a successful file generation of whatever file you're looking for. Whether it's an audio or image file.
It would be a much better approach for you in the long run, and in the process of learning that you either contact the authors of the app and ask for permission to use the images/audio that you're seeking (since you think it's such an awesome sound/image that you can't live without). Or you can do an audio mixing or image generation yourself.
If your lacking the time, skills or applications that would get you the quality of work you're looking for. I would recommend bring in a graphic artist or sound engineer/mixer.
You'd be learning how to manage a group or individual, convey your ideas correctly and informative, and you're more likely to build a better application as a result. And that is something you can't get from reverse compiling an iPhone application :-)
Related
I recently learned that it's a bad idea to store data you want secure in a plist, and it's better to store it in a keychain, since a user can get access to what is stored there.
This makes me ask what other data can a "motivated" user get access to from inside your Xcode project, once it is in the App store. For example, can someone download the core database of a project just by downloading the app? Or if you have a .csv file in your project folder which you use to parse data from, could a user download the original .csv file just by having access to the app?
This may be an obvious answer like "of course not, the user can't get any files from your project." But I'm fairly new, and I couldn't find any discussion about this, so I wanted to make sure that I am going about things in a secure way.
Thanks!
Apps on iOS are "bundles", which just means they're a directory with a name that ends up in .app. Any file that you include for your app to use ends up in the bundle, and a motivated user should be assumed to have access to everything in the bundle. This includes any data models, CSV files, images, sounds, etc, that you include as well as compiled storyboards and so on. Decompiling code is challenging but reverse-engineering data models is easy.
Here's how you can have a look:
Compile your app.
In Xcode, go to the file browser on the left. Under "Products", find your app.
Right-click on the app entry and select "show in Finder".
In Finder, right-click the app and select "show package contents".
Now browse the bundle contents and see what's there.
This isn't the same thing as saving data, it's what comes built in to your app. Saved data is also mostly available. Keychain data should be unavailable because Apple encrypts it and keeps it separate from the app.
A "motivated" user has access to everything that ends up in your app bundle when Xcode packages the app for upload. Look at the "Copy Bundle Resources" Build Phase of your project to get an idea which files are copied in addition to your compiled code.
I have *.ipa file which is the iphone application.
Is that possible to use reverse engineering in that ipa and extract
code..?
Well, its not really a hacking but it can surely help you identify some parts of the UI... Do the following:
1- Create a new project on the Xcode (doesn't really mater what you choose)
2- Connect your device to your computer
3- Profile your project on your device.
4- On the Profile, pick Core Animation
5- On the options choose Color Blended Layers
It will look like this:
6- Unplug your device while the profile is running.
Your phone will look like this now:
7- Go to the app you want to check.
Although you can't see any code, this can help you out to identify key parts of the application. To get back to normal, you can restart your device, or just go to the profile and run it Again, and uncheck the Color Blended Layers option.
As stated here: How to use Xcode to open decrypted IPA contents ipa is only a "zipped" version of the executable.
So if you are able to extract, its mostly an issue of dissasemble the executable (assembly code/dissasemblers).
But somehow this smells like fish.
Not possible the way you intend it! .ipa files contain the resources(images,sound files, database files,etc) and compiled classes only. The code is contained in these compiled classes as binaries and thus, you can at the most see how the app was structured into classes and how the resources were used but can not get the actual code as written by the developers. You can refer this SO question to get a brief idea as to how that can be done.
I am working on an iPhone application, latter to which i need to convert it into iPad application (Not universal)
I have seen somewhere a project that contains two separate xcodeproj file say
AppName_iphone.xcodeproj
AppName_ipad.xcodeproj
in single folder that are sharing common files, but opens as separate application when i double clicks *.xcodeproj files.
I goggled for doing same but i can't find good resources that shows how to do that.
Please suggest good way of doing same.
Thanks.
or try this i think that could help you http://developer.apple.com/library/ios/#featuredarticles/XcodeConcepts/Concept-Workspace.html
It is important to make sure every iOS application submitted to the AppStore is under 20MB in size so that it can be downloaded over-the-air.
I am working on an app that may be getting close to that limit, and I've discovered that there does not appear to be an easy way to tell the current output .app bundle size from within XCode.
In XCode4 in particular - by default every build is tucked away in a hard to get at and cryptically named temp directory. I don't want to override this default behavior unless I have to.
I know I can track down the .app bundle by looking at the build logs, opening a shell window, changing to that directory, and using 'du' - but I am hoping to find a quicker and easier way to keep track of the .app file size after each new build.
There isn't even an easy way directly on an iPhone or iPad to determine the size of an application. Mostly I appreciate this - but not when I am in the midst of optimization.
Any thoughts on best practices?
UPDATE: I am using XCode 4 now for most of my day-to-day development, and it seems that every solution so far doesn't work on XCode 4 either because functionality has changed or features (such as Archiving) are still coming soon. I think the ultimate answer may be "use XCode 3" for the particular phase of development. I know I will still need to use XCode 3 for the final build and submission anyway...
Where I work, we make an archive form Xcode (Build and Archive) and then we export that archive on the disk from the Organizer Window (using the Share button).
This will generate an .ipa file. The size of that file is what you're looking for.
There should be a 'Products' folder in your Xcode project. Inside that folder will be your .app files. Right click on your file and select 'Reveal in Finder'.
Create a script (perl, bash, AppleScript, whatever...) and add it to your Build Scripts. The script can then cd to magic location, zip the .app to /tmp, du -s -h the resulting zip, and pipe the output to some log file... maybe even flash bright red warning lights hooked to a USB parallel port relay to warn you of exceeding some file size limit.
Actually, it is the size of the .ipa, not the .app, that has to be under 20MB. Since .ipa is a zip archive, you get a little more space to work with. The only way of finding the size that I know of would be to do a Build and Archive in XCode and look at the file size in Finder.
The file you send to Apple is a .zip file, it's your compressed binary file. For example I'm working on an app that's over 120mb uncompressed but compresses to about 19mb as it's mostly data. I'd guess you have plenty of slack is most of your files aren't a compressed format.
I have an app that has about 60 png files and a couple of cfg files in the main bundle. Runs great in the simulator, and when I download from Xcode to iTouch. But I'm stumped on distributing to my testers. I have their provisioning profiles, etc. But when I created the app and sent it to them, it showed up as a folder (NR1.APP) with all the individual resource files under it.
Do they drag this entire folder into iTunes/applications? Or is there something in xcode that creates a single binary app with all resources in it?
Application bundles are just folders. Navigate to one in finder, and right-click -> 'Show Package Contents'. An exciting world awaits.
Dragging the application bundle into the library in iTunes should take care of it, however you can also distribute an .ipa file, which is just a renamed .zip with a directory called Payload in it, with the application bundle inside.
I presume your testers are on Windows? The short answer is that iPhone apps are in fact folders (called bundles) with a specific file layout. On Mac OS you don't notice because finder hides it for you, though you can look inside by selected "Show Package Contents" from the contextual menu in finder.
Anyway, yes, they can install it by just dragging the app, assuming everything was decompressed correctly. THe problem is that the most Windows decompression tools mangle archives of bundles (at least with respect to how iTunes expects them). You can read all the gory details on what you can and can't do in this blog post.