During static analysis of an iOS IPA binary, it was found that the application contains misconfigured settings that may affect the security of the application. The following flags were misconfigured:
• Rpath: The "Runpath Search Path" flag instructs the dynamic linker to use an ordered list of paths to determine the location of a dynamic library. Enabling this flag may allow an attacker to place a malicious dynamic library in the location of one of the initially defined paths, allowing for hijacking.
It is recommended to reconfigure the application binary to ensure it has disabled the Runpath Search Path(#rpath). This can be performed by using the "-rpath" flag during compilation.
How to fix the IPA Binary Misconfiguration?
Related
From Xcode7, any framework built with your app should have bitcode if you want to enable bitcode support for your app.
I'd like to know a way to check whether a framework project has bitcode or not.
There is a similar question here (How to check if a framework is BITCODE supported for Xcode7), but the answers there are about checking bitcode of static libary file of .a or .o extention.
I want to check the existence of bitcode inside .framework package, and have been wondering there should be a way to check it on .swiftmodule files inside a .framework package.
(One of the reasons I want to know is that I'm trying to support bitcode in my own framework project, but have never succeeded in doing so since I got missing-bitcode error when I exported my framework package to an app project and built the app. I thought it's nice to have a tool to check it directly rather than knowing it after embedding it to an app project and building the app.)
otool -l binary_name | grep __bitcode
you will see one or more segname __bitcode entries if it does have bitcode or empty output if does not.
We have been provided two frameworks from another team for inclusion in our iOS app. A Debug version that contains simulator and device symbols and the Release version that contains only device symbols. They asked us to include the framework as an embedded binary.
How do we conditionally include an embedded binary the way we specify release and debug paths for frameworks in Build Settings? We do not want to manually intervene when it is time to build for the App Store and we want to include the release version of the library.
My current solution is to create a new Target and remove the embedded binary. Then in your code use compiler directives to conditionally include the headers/code.
I don't think it's ideal, but got me working!
I am trying to understand how dynamic linking works on iOS 8 and would like to print the location of the resolved libraries when the app launches. Are there any tools for doing this? In crash reports when a dylib is not found there is some info about search paths, but I can't find this info in a non-crashing execution.
Specifically, I am trying to understand a scenario which is working, but which I didn't think would:
Swift Framework (Foo): Dynamic Library Install Name is #rpath/Foo.framework/Foo
Swift app (Bar): Runtime Search Paths is #executable_path/Frameworks
The app does NOT have any Embedded Binaries (General -> Embedded Binaries), and does NOT embed the framework as a bundle resource (Build Phases -> Copy Bundle Resources).
In the generated Bar.app folder there is a Frameworks directory, but it does not contain Foo, and Foo is not contained anywhere else within Bar.app. I do not see how is it possible for Foo to be resolved since the framework is embedded and should be unavailable?
I found what I was looking for, as documented by Apple under a document called Technical Note TN2239 iOS Debugging Magic. In this document there is a section describing various environment variables that can bet set which will force the dynamic linker to write out useful debugging information.
After setting these variables in Xcode (Edit Scheme -> Run -> Arguments -> Environment Variables) I get detailed information about how and what the linker is resolving to.
I compiled a static library for iOS with Xcode with symbols stripped. It's compiled in the Release configuration. When I copy the static library into another iOS project (I physically copy it into another directory), I'm still able to view the source of the static library when stepping through code. I clicked Show in finder in the source window and it pointed me to the appropriate source file on disk.
I opened the library in a hex editor, and it indeed contains paths to my source files on my machine, as well as a bunch of other text data that that shouldn't be exposed.
Have I missed something in my project settings? If this is expected behavior, how can I make sure that the customer will not see the symbols, source file names etc.?
Found the compiler options required.
In LLVM code generation, set Generate debug symbols to No and Symbols hidden by default to Yes. For some reason, even if you tell it to strip symbols, it's not going to do it unless these are set.
You can check whether symbols are striped or not using
nm filename
Stripping doesn't happens automatically, you need to setup xcode to strip them and there are several flags that are in charge:
a) DEPLOYMENT_POSTPROCESSING
Prerequisite for: “STRIP_INSTALLED_PRODUCT (Strip Linked Product).”
b) STRIP_INSTALLED_PRODUCT
This one is going to work in non-appstore builds only if you will have set DEPLOYMENT_POSTPROCESSING to YES.
There is a way to strip symbols manually, just call
strip YOURBINARYNAME
strip YOURBINARYNAME as suggested by #andrei-shender is not enough. You need to do the following:
strip -S YOURBINARYNAME
To get rid of the debugging symbols manually. Of course configuring your project properly is better, but if you are building a 3rd party library using a vendor script you may have to do it manually. Mapbox-native-gl goes from 550mb to 22mb if you strip the debug symbols!
I am testing an image capture library that sent over their code library as a regular header file and a file ending in a "*.a" extension. I am not familiar with using a file in this format and can't seem to find the right "magic" to search for.
What does this file extension stand for?
What if any extra steps are needed to get it integrated with my XCode project?
Maybe a bit more of theory can get you in the right track so you'll know how to search next time:
.a files are archives of object (.o) files. These object files are generally produced by an assembler, compiler, or other language translator; They contain machine code that is usually not directly executable, but are used by linker tools to generate an executable or yet another library by combining parts of these object files.
Another important thing you should know is that since these files contain machine code, they must have been compiled for the correct architecture you're targeting for (ex.: armv7, i386, etc). That can be the reason why sometimes you will be able build your project for one device but not to another if you don't have the right set of files for the targeted platform (e.g. iPhone simulator vs. actual iPhone).
It is also possible to have "universal binaries", which are files that in turn package together archives of object files (.a) for different architectures (e.g. using tools such as lipo), so that the same library file can be given to the linker for multiple architectures. Or, you may have a different linker configuration for each target (e.g. using conditional build settings in XCode). All of these files can be analyzed with certain tools (e.g. "file", "otool", "lipo -info", etc), and each has several parameters to play with. Debuggers will also check the symbols within these files for their own purposes.
When you drag the '.a' file to your project's directory within Xcode, you can notice that it will automatically add this file to the list of "Link Binary With Libraries" items under your target's "Build Phases".
Since the header files allows us to separate certain elements of a program's source code into reusable files, that commonly contain forward declarations of classes, subroutines, variables, and other identifiers that are needed for reference during the compilation step, it is common to have libraries provided as archives of compiled objects (.o) in ".a" files along with their respective headers. For instance, as soon as you include the headers files in your XCode project, the editor will provide auto-complete for these new functions.
Sometimes, you might also consider having the actual source code of the library instead of binaries inside your project as this * might * make debugging easier in case an unexpected behavior is happening inside that "library" package. Many times this is not an option though (when you have no access to the sources) when the binary distribution is made in purpose to hide implementation details (commercial libraries).
.a stands for archive. It is also known as a static library. I believe you should be able just to drag it and the header files into Xcode. Xcode should pick up the right thing to do from its extension.
Example, see appr. from 30 sec here
http://memention.com/ac3dreader/usage/quickstart.html
Another example from Google Analytics, under Setup
Drag GANTracker.h and libGoogleAnalytics.a from the SDK's Library directory into your new project.
https://developers.google.com/analytics/devguides/collection/ios/devguide