iOS App Contains Developer Path Information

Hi All,

Xcode: Version 12.2 (12B45b)
Language: Swift Version. 5.0
Development: iOS app

How to fix developer workspace path informations that get appended into our IPA File.

Issue: 
The following information is displaying when you run "strings yourappname | grep Users" for specific files only.

/Users/XXXXXXXXX/Documents/workspace/iOS/

Steps to reproduce:
  1. ) Archive your application using XCode

  2. ) go to Archive file and - > Show Package Contents

  3. ) go to Products -> Application folder

  4. ) Click on your application and - Show Package Contents

  5. ) Open your terminal and navigate to the folder from above.  

  6. ) run following cmd: strings yourappname | grep Users

Note: Only some of the files paths are showing up with local workspace information when we run strings yourappname | grep Users

I would appreciate it if any came across this issue and have a solution.




Post not yet marked as solved Up vote post of kamal_21 Down vote post of kamal_21
623 views

Answers

Can you give us an example of a specific string that’s showing up like this?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
The workspace's user name is getting included inside the iOS build.
OK.

Coming back to your original post, you wrote:

go to Archive file and - > Show Package Contents

I recommend that you avoid working on the Xcode archive because that’s not what gets shipped to the App Store. Rather, do this:
  1. In Xcode, choose Product > Archive.

  2. In the Organizer, select the archive and click Distribute App.

  3. Select App Store Connect and click Next.

  4. Select Export and click Next.

  5. Continue on as you normally would.

  6. The result is a directory containing a .ipa file. That’s actually a zip archive in disguise, so change the extension to .zip and then open it in the Finder to unpack it.

  7. You’ll find your app in the Payload directory. Run strings against its main executable.

Do you still see the offending strings?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo I followed your steps and I am able to find my workspace path as well.

I am working on this issue as well due to security reasons and I have found that disabling bitcode during export process is limiting this issue somehow, but disabling bitcode is not necessarily what I want to do because of dsym, analytics and other advantages of bitcode being enabled.

Do you have any solutions to this problem?

disabling bitcode is not necessarily what I want to do

Right, but bitcode doesn’t ship to your customers, only to Apple. So, are you trying to protect your secrets from Apple? Or from the general public? Or both?

[Any answer is fine; I’m just trying to scope the problem.]

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Maybe I have made the wrong assumption about the bitcode so thanks for clarifying. Let's start over - in general what I'm trying to achieve is to hide the user workspace info from the .app file. I checked once again and regardless of bitcode enabled / disabled during exporting the app when I run strings against main executable I get the unwanted strings.

Add a Comment

when I run strings against main executable I get the unwanted strings.

OK. Consider this:

  1. Using Xcode 13.1, I created a new project from the iOS > App template (I assume you’re targeting iOS here), selecting the simplest options (Storyboard, Objective-C).

  2. I did a Product > Archive to create a release build.

  3. I use the Xcode organiser to export that.

  4. I unpacked the .ipa.

  5. I poked at the main executable with strings:

    % strings Test676234.app/Test676234 | grep quinn
    % 
    

My home directory path is /Users/quinn, meaning that there are no home directory paths encoded in my app.

So, this doesn’t happen always, which means there’s something about your project that’s triggering it. Tracking that down can be tricky. To explore this, I added the following to the app’s main function:

printf("%s\n", __FILE__);

I now get a hit from strings:

% strings Test676234.app/Test676234 | grep quinn
/Users/quinn/Desktop/Test676234/Test676234/main.m

To debug this further I used the Write Link Map File build setting (LD_GENERATE_MAP_FILE) to enable a link map. I then went through the Product > Archive cycle again, which created a link map file Test676234-LinkMap-normal-arm64.txt. In that file I see this:

0x100007F67	0x00000032	[  3] literal string: /Users/quinn/Desktop/Test676234/Test676234/main.m

The [ 3] indicates that this string literal came from the third .o file. At that top I saw this:

[  3] /Users/quinn/Library/Developer/Xcode/DerivedData/Test676234-ajppxbraomjtoldtyvugwlwsxkqv/Build/Intermediates.noindex/ArchiveIntermediates/Test676234/IntermediateBuildFilesPath/Test676234.build/Release-iphoneos/Test676234.build/Objects-normal/arm64/main.o

confirming that this is main.o, which the output from building main.m.

Now, this is an easy case, where the string is passed as a string literal to the linker. That’s not always going to be true:

  • In some cases the string might be embedded in a large block of code or data that’s passed to the linker. You can track that down by finding the offset of the string in the file, mapping that offset to an address (using the segment info printed by otool -l), and then finding that address in the link map.

  • In some cases the string might be in segments actually generated by the linker. I don’t have any quick suggestions for how to deal with that case.

Still, my general advice here holds: First find where the string is coming from, then try to track down the relevant knobs to twiddle in order to disable it.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • I followed your advice, generated Link Map file and was able to identify in it the same files which were showing as a strings command result. I followed then the numbers in brackets to find the .o files at the top of the Link Map file. In the .o files I have found the unwanted strings, but now I am confused where does it come from?

Add a Comment

In the .o files I have found the unwanted strings, but now I am confused where does it come from?

Each .o file is the product of one source file, so you can search through the corresponding source file for likely candidates.

If that doesn’t pan out, do a binary division process, removing source from that file until the path goes away. You don’t need to go back to the link map here. You can dump the .o file directly using otool.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • What I am able to confirm so far is that I am not printing my workspace path and it is not written anywhere in the source code of .swift files which I tracked with the aforementioned process. I have never debugged linking process and related issues so I am kind of wandering in the dark here. I have looked through some of these swift files to see what can produce the strings and I don't see any particular reason. When inspecting the .o file I can see that some lines containing my workspace info lead to the pods from CocoaPods I am using in my projects. Also some lines seem to be related to the libraries that can be imported like UIKit, Foundation, WebKit and also pods.

  • I have reviewed "Build settings" in my project and in the field "Other linker flags" there are references to frameworks and pods used in my project. This is generated by Cocoapods. Does this setting have influence on the problem?

Add a Comment

Does this setting have influence on the problem?

Sorry, but I can’t help you with the third-party tools.

I am kind of wandering in the dark here

This type of debugging is like any other types of debugging: You want to confine the scope of the problem to see what triggers it. You can work this from both ends:

  • Take an empty project, confirm that it doesn’t have the problem, and then expand it to be more like your main project. For example, if you add a single library using your third-party package manager, does it immediately trigger the issue?

  • Take your main project and cut it down until the problem goes away. For example, if your remove all your third-party packages, does the issue go away? If so, the issue is related to how your project is set up. If not, you can do some binary division to find out what package is triggering it.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have taken @eskimo advices into consideration and the result of my debugging process is that these strings are 3rd party related, in this case Firebase Crashlytics and Analytics. Removing these dependencies and related code resolved the issue. I have created an issue in the developer repo on GitHub to research this case further: https://github.com/firebase/firebase-ios-sdk/issues/9027

  • Thanks for the update!

Add a Comment