Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

What Your Binary Says About You, Part 1: Hello, My (User) Name Is…

dawnisabel ‎11-26-2013 12:47 PM - edited ‎08-03-2015 10:48 AM

If you’ve ever run the “strings” command on an iOS binary, you know that quite a bit of information can be gleaned about an application just from the output of that one command.  If you are a developer and have never tried this on one of your own apps, you might be disconcerted to see source paths embedded in your binaries.  These paths not only reveal the names and hierarchy of source files, but often also the developer’s username on the host used to build the application.



While this is typically a low-risk vulnerability, it is also one more piece of information that can be used by an attacker to profile your application and organization.  Armed with a developer’s username, an attacker might search for matching profiles in source repositories like GitHub, or try to find postings by the developer in technical forums and mailing list archives.


How can you prevent your application from revealing too much?  Well, source paths usually end up in the binary for one of three reasons.  To eliminate them effectively, you’ll need to try toggling a few different settings in Xcode to see which work for your application.


Source paths due to debug symbols

The majority of the source paths you see in a binary are from the inclusion of debug symbols in the final compiled product.  You might dig around in the Xcode build settings and think that the correct way to handle this is to set “Strip Debug Symbols During Copy” to “Yes”.  However, this setting only applies to library files that are copied into the project during the build process, not to the final binary.  To strip the final binary file, set “Strip Linked Product” to “Yes”.  You also have to enable “Deployment Postprocessing” in order for this setting to take effect.




Source paths from assert statements


You may find that a number of source paths appear in your binary even after it is stripped.  This could be the result of using assertions such as NSAssert in your code.  These assertions typically include the __FILE__ preprocessor macro, which the compiler expands to the name of the source file.  Fortunately, Xcode provides a build setting for convenience that suppresses assert statements; set “Enable Foundation Assertions” to “No”, at least for Release builds.  For earlier versions of Xcode that do not support that setting, you can define NS_BLOCK_ASSERTIONS=1 under the Preprocessor Macros for your Release builds.  In addition to blocking NSAssert, you may also need to define NDEBUG to block assert() in C and C++ code.




Source paths from static libraries


If you have implemented the settings above and STILL find source paths in your binary, they probably originate from a static library that you’ve compiled into your build.  If the source paths are from preprocessor macros in the library, there isn’t much you can do – the library has already been preprocessed, so the macros have been expanded.  If you created the library yourself, you might be able to re-compile it with the settings discussed here to eliminate the source paths.  If not, you are probably stuck with the paths unless you can convince the provider of the library to remove them.


A layered approach


There is one other option besides modifying your Xcode settings to mitigate the appearance of source paths.  When setting up your project, use a generic directory name for your builds or a separate, generically-named account (such as User1).  Check the binary after you build it to ensure that any paths that appear use the generic directory name.  When used in conjunction with Xcode settings to strip symbols and block assertions, using generic names for project directories can add an extra layer of protection against leaking too much information.


I compiled this list of settings based on tinkering with builds in Xcode.  Did this work for you?  Did I miss anything?  Let me know in the comments!


0 Kudos
About the Author


27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all