I have been given a Shared Object file (.so) and the functions inside of it, but I don't have a clue as to how to use it, or alter it for use in an iOS application. Could someone point me in the right direction?
I know the .so came from an Android application, but I was told I could get it to work in an iOS application as well.
Actually and technically, yes, you can, but not in a way you would ever think.
If it came from Android, it is probably compiled for ARM. So it should be binary-compatible with the ARM CPU in iOS devices. However, iOS doesn't use the usual format of shared objects (that is, the ELF format), but iOS' and OS X's own Mach-O format.
This means that you cannot directly link against this shared object file nor are you able pass it directly to dlopen() and dlsym(). You have to get into serious hacking (something that you probably don't know). This involves loading and relocating the file properly.
An example of this can be found in iOS jailbreak developer and hacker, Comex's GitHub repository Frash, a Flash player for jailbroken iOS devices. Comex essentially wrote an ELF loader module (dubbed "food") for iOS and used it to make Android's libflashplayer.so work on iOS. Pretty neat, huh?
Also note that this is not going to be possible for AppStore apps as it needs dynamic loading and various alterations in the OS.
while technically possible (see h2co3's answer) for anything practical the answer is no
so files arent in the correct binary format
even if they were, dynamic loading is not allowed by appstore
Related
I want to see the code of an iOS app.
The app I downloaded is .deb.
First question: Is it possible to install .deb file on iOS or I downloaded a wrong file?
After unpacking the .deb file, I got some files, including .nib, .storyboard and some other files.
My main question is, How to decompile these .nib files?
I tried to decompile these files using NibToXibConverter, but I didn't succeed.
Answer to your first question:
I think you downloaded the wrong file. .deb files for iOS are common for jailbreak community and not for apps, I think all of the Cydia stuffs are packed into .deb's. If your app is especially made for the jailbreak scene then you may try to install it using Cydia's auto install feature on a jailbroken device.
Answer to your main question:
This is general info about decompiling and modifying iOS apps (not specific for nibs, but you may still find it useful).
iOS apps are distibuted in .ipa archives, which are ordinary zip archives. They contain, usually one executable in the form of Mach-O file, and resources like .plist, sounds, images - every resource you include in your xcode project. Decompiling the executable file is only possible on jailbroken iDevice, because it is encrypted especially for the current device and the magic key to decrypt the binary is burned inside the device CPU and as far as I know there is no software way to read that key. The encryption system here is called FairPlay.
Briefly described, one way to decrypt that binary is to have the app installed on a jailbroken device, and launch it from command line using a debugger (gdb) which you can download from Cydia. You have to set a breakpoint somewhere, and when your code execution pauses at the breakpoint, you are doing a memory dump of the device ram - and that is your decrypted bin.
So when you have the decrypted binary, you can run one tool called "class-dump", and get the information for declared classes and their methods if the app is written in Objective C. Once you know this information you can alter the implementation of given method from some class used in your app using "Cydia Subtstrate" a.k.a "Mobile Substrate". In fact that is the way all of the jailbroken iOS tweaks are made. Basically you are hooking a method call, and when that method get invoked, it uses your implementation. Furthermore your implementation can call the original implementation, and that is really useful if you want to make some small code addition.
I am not sure whether those things possible in Swift, but if you are dealing with a Hybrid app like the ones done with cordova, phonegap, etc., then you can see all of its javascript source because it is persisted as a resource inside the "ipa" file. In addition you can alter that javascript code directly if you have a jailbroken device and find where the app is installed on file system (usually /var/containers/Bundle/Application/uuid_for_your_app/). However, I think there is no way to get that patched version and redistribute it (correct me if I'm wrong).
I'm very interested in using GStreamer's iOS framework http://docs.gstreamer.com/display/GstSDK/Installing+for+iOS+development for video streaming, but when I add the framework to a blank project and add a few lines of code to take advantage of its powerful features, the final IPA is 27MB. This is just way to big to be adding to my project, what is the best way to go about stripping this down the the bare necessities as I'm sure I'm only using a small percent of the code that is included in the SDK.
Here's a pic showing the package contents of the IPA:
Thanks!
In the gst_ios_main.h you can disable all the plugins that you don't need (make sure to enable linker optimizations so that unused code is removed). If that's not enough, you can build your own stripped down version of the iOS binaries with http://cgit.freedesktop.org/gstreamer/cerbero/ (you need to remove things from the .package and .recipe files to only build what you need). Just disabling things from gst_ios_main.h should be enough in 99% of the cases though.
Note that by default you'll build applications for multiple architectures, as such the resulting application will be rather large. Depending on your use case you can drop some architectures.
On another note, gstreamer.com is providing an completely outdated version of GStreamer and is in no way related to the GStreamer project. The official website is http://gstreamer.freedesktop.org .
SDKs have their source code encapsulated away from you, the user. You get access only to header files. Thus you just can't extract some class from it because you don't have access to the implementation file.
Of course if this library is opensource you can attempt to isolate one class, but sometimes everything is so deeply connected, that it is close to impossible.
SWF files compiled for the Flash & Air (desktop) can be easily de-compiled with off the shelf software.
However, SWF files compiled for iOS are different. The header is FWS, yet the data in the file wont de-compile in any de-compiler.
I am guessing that something happens during compilation for iOS. Does anyone what this is?
Thanks
To the best of my knowledge, you won't be able to do this.
A compiled AIR for iOS file is cross-compiled to Objective-C. Apple does not allow for virtualized languages in the App Store (which is how AIR for Desktop and Android work), so this was Adobe's solution. They take your AS3/Flex and translate it to Objective-C at compile-time so that at run-time, you are actually running native code.
So you would have to decompile the Objective-C first. Then you would have to reverse-engineer the entire AIR compiler and write a way to re-translate the decompiled Objective-C back to AS3.
For the record, any questions about decompiling binaries is generally frowned upon on SO.
did you try this sothink flashdecompiler?
And there is a Mac version that can help you out in it. here
I'm working on research that requires me to be able to load an iOS app from a custom piece of code running on the device. I more or less want to modify the current sandbox and then run an existing application in it. I would rather not modify the application, although I realize at some point I'll at least have to re-sign it.
Mocana can apparently do this with their "MAP" technique, but I've not seen any papers or presentations explaining the technical details of how this is accomplished.
I was attempting to dlopen an application's executable and then dlsym on it's main. That moderately works, but requires a debug version of the application. Trying to use an archived version is problematic since the symbol table is separate. Not sure if there is a way to merge the symbol table with the executable. Tried unsuccessfully with lipo, but no real luck (says the architectures are the same and won't merge).
Any direction or good publications would be appreciated.
I was trying to get the header files from the ToneKit framework on iOS7.1, but I found that I cannot use class-dump because there are no executable files inside the framework. From what I have found after some research, it seems as if the actual executable file is inside the dyld_shared_cache on the device. After reading this article, it seems as if there are some tools to decrypt the cache, but since iOS 3, Apple has implemented ASLR which has made the decryption tools not work. How can I extract the Frameworks from inside the dyld_shared_cache on iOS7.1?
I am very new to jailbroken ios development so please bear with me.
If you're interested in how they got those headers then the answer is very simple - iOS SDK. SDK contains ARM binaries of public and private frameworks because they are required to compile iOS applications. Class-dump them and you will get headers you need. ToneKit.framework binary is also in there.
Usually you don't need dyld_shared_cache, almost everything you need is either in iOS SDK or on a device itself like SpringBoard, other system applications etc.
Of course there are rare cases when dyld_shared_cache is the only place you can find certain binaries as they are missing from both iOS SDK and device. In that case I use IDA. It has free demo version that can open dyld_shared_cache files - you can even open individual binaries inside it rather than dump everything. You just need to copy dyld_shared_cache on your PC.
I think Elias Limneos's classdump-dyld can help you. If not, check out RuntimeBrowser. Failing that, even, weak-classdump has proven to be a very useful runtime tool for me.