Im developing a tool that tries to dump header classes for a jailbroken device on an App.
I'm using Clutch, but sometimes Clutch fails to some newer apps, I'm thinking of integrating some tools other than Clutch.
So, I need to determine at first if the binary is written in Swift, so that I can switch to the right tool to execute.
My question is,
Is there a way, like a command tool to determine if an iOS App Binary is written in Swift?
Is there really much difference in how the binary is built when it's in Swift compare to just Obj-C?
You can use nm tool to print app symbol table. If you search for swift, for example using grep:
nm YourApp | grep swift
It will print something like this (and many more):
U __swift_FORCE_LOAD_$_swiftFoundation
For an 100% Objective-C app the result will be empty. However, you can't tell if the code is 100% Swift because for mixed objc + swift apps the result will be similar to a swift app.
Inside the .app file there is a _CodeSignature folder. Inside there is a CodeResources file. If you open that as text you will see that it contains Frameworks/libswiftCore.dylib
I believe this indicates that it has been built with swift.
Related
I have supposedly 2 security vulnerabilities in the iOS app I developed. This medium article enlisted both issues I faced.
Look for:
Usage of Insecure Random Number Generator
and
Usage of Banned/Deprecated APIs
Those are the two issues I faced in my iOS app as well. I used Xcode's and ran the terminal command like shown in the link above and saw that these deprecated methods like _random and insecure methods like _memcpy and _strlen are being used in the app.
What I want to do here is to understand where in my source code I am using these methods. I have searched my entire source code of my Xcode Project, I don't have it used or called directly.
otool outputs in assembly language format and shows random address
How can I find out in source code where I must be using these methods? or decipher the assembly code to ObjC source code? so that I can remove that code and use a better alternative which in turn will remove the security vulnerability.
There are several questions addressing this issue already, but all of them (I think) are in reference to earlier versions of Parse using an objective-C bridging header to connect the framework. I am using the latest version of Parse that has support for Swift directly, which is a different setup process.
I've downloaded and added Parse to Xcode in the Build Phases -> Link Binary With Libraries. The directions on their website are extremely straightforward...download the SDK, add it to Xcode, import it, and done.
Parse seems to be added properly everywhere it should be:
But alas, when I use import Parse, I get a no such module error. I've tried adding the framework search path $(PROJECT_DIR) under Build Settings both recursively and non-recursively, and a few other recommendations from the other questions addressing this issue, but with no luck.
I'm wondering if this could be an issue with Parse or the Xcode beta, since both are extremely new, but I'm assuming the error is on my end, just not exactly sure where to look since the quickstart guide on Parse.com seemed so simple.
Apparently if you drag the Parse library to the 'Link with Binary Libraries' section, you will continue to get this error.
You have to drag Parse to the project navigator for it to properly import.
Since it should work regardless of where you drag it into Xcode, it is possible this could be a problem with the Xcode 7.1 beta or the updated Parse API for Swift support. I'm not entirely sure, but either way, it's a really simple fix, so not a big deal.
I'm using Qt5.5 for iOS development.
I'm wondering how to find and open a file in an iOS device to read and write using Qt5.5. As I know, there's no such file tree structure in iOS. When I download a picture, for example, I even do not know where it locates. But I can see it in apps.
Is there anyone can help? Thanks very much.
I am no expert with Qt, but I believe you need the QStandardPaths class.
iOS is no different to any other platform that stores files in certain pre-defined locations.
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.
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