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

120px-Hello_my_name_is_sticker.svg.pngIf 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.

 

janesez.png

 

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.

 

Xcode strip settings

 

 

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.

 

Xcode assertions settings

 

 

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!

 

Tags: appsec| iOS| mobile| Xcode
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation