[TIMOB-23183] iOS Non-public API usage: The app references non-public symbols in <APPLICATION NAME> : _ptrace
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2018-02-26T22:06:20.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 7.3.0 |
Components | iOS |
Labels | ios |
Reporter | ngweixing |
Assignee | Eric Wieber |
Created | 2016-03-31T14:58:45.000+0000 |
Updated | 2018-07-11T20:09:50.000+0000 |
Hello, There is a similar reported issue in the stake overflow. But that seems to be for the native platform. http://stackoverflow.com/questions/21829521/fails-to-distribute-my-app-your-app-contains-non-public-api-usage. Can you try following the ticket. Regards, Sharif
Hi, If you have read my post above carefully, you would have noticed the difference between your link and our issue. The ptrace problem was due to the fact that version 5.2.1 has a fix for the appc-security-debugger-detect crash on ios 9.1. You can search in your jira where there is that bug. So we believe your team tried to tix that problem while introducing another bug in the process. It seems that appcelerator is not really willing to check such a major problem where it impact app submission to the Ios App Store because we have submitted ticket for so many days and no one bother to care about it. It is quite a disappointment really.
Hi, We already used the previous version to compile and submit to app store. We will try the latest release very soon. By the way, did your team use "ptrace" in your code in order to detect users connecting debugger tool? And thanks for giving us something related to the issue which could possibly be the solution. Thanks, Heng
I just got this error: The app references non-public symbols in LilyPad: _ptrace from iTunes when using GA 5.2.2. Any suggestions?
[~peterladis] May I know if you configured this in your tiapp.xml?
and if removing all 3 properties helps? [~ngweixing] may I ask if you faced the same issue with all 3 properties above removed on 5.2.1.GA? Thanks.
Hi @cheekiatng, with or without the 3 properties also has the ptrace problem. Even with just appc-security-debugger-detect, it also has the error. I haven't tested with version 5.2.2 yet though.
[~ngweixing] Thanks, we will continue to investigate. If it's related to ptrace, there indeed 1 line of code that may include that, but there's been no changes to it between sdk versions so I'm not sure why it would come up now.
Hi kiat, if you want to do a quick test. We try using sublime text editor and search through the build folder in the titanium app folder which contains the xcode project files. Sublime was able to detect the presence of ptrace in the binary somehow. When we do the same using sdk 5.2.0, no ptrace string was found. As long as ptrace is found, apple will reject it. you can also test upload to your testflight via ituneconnect
ok our team just did a quick test. This only happens if this property is existing in tiapp.xml (no matter if value is remote or embed):
So it looks like our jaibreak detection is broken. We will try to fix this. Meanwhile, the workaround is to not have any of these 3 properties in your tiapp.xml.
Thanks for the update. Finally, your team can recognise that there is a problem and is an independent issue from the issue posted on stackoverflow since last year. For sdk 5.2.1, no matter you include any of those 3 properties or not, build always contain ptrace with failed submission to app store. I assume sdk 5.2.2 is what you are experiencing which is the same behaviour on sdk 5.2.0 in which as long as we do not include any of those properties, it submits fine. We really hope you can fix this problem soon for everyone's benefit and for those who have been using these properties to protect their codes and is in urgent needs to upload a new version to the app store.
[~peterladis] [~ngweixing] Based on our investigations so far, ptrace is only used for detecting debugger, so since our primary concern is detecting jailbreak, please let me know if setting the following properties work for you while we continue to find alternative solutions to this problem.
@Chee Kiat Ng Actually our primary concern is getting debugger detect to work and not jailbreak detect. We don't need to detect jailbreak. We want to use debugger detect to protect our code and api keys in the code, etc
Hmm. At the moment we still are unable to find a better way to do debugger detect without the use of ptrace. Will keep you posted see what we can do.
Ok sure. Thanks for this!
Hi Kiat, appcelerator is seriously facing big issues with these parameters. We tested with the latest 5.2.2.GA and still fails to submit to testflight because of ptrace. We placed all 3 parameters you suggest from your previous post. May I know if we don't specify remote for appc-sourcecode-encryption-policy, what is the default value? Now we just want to ensure encryption policy is remote and set the other 2 to false and still get ptrace problem with 5.2.2.GA.
Don't specify these 3 properties at all, and it'll default to our non-remote encryption. With no jailbreak or debugger detection enabled. Ptrace will not be a problem because the library that has it won't be included [~ngweixing]
I'm also getting this problem with 5.2.2.GA - I'm not specifying any of those 3 properties. Its currently stopping me upload a update to the AppStore?
Looks like appc-security-debugger-detect is enabled by default when building for distribution. But even by explicitly turning this off is not enough to remove the _ptrace symbol from the application binary.
[~michael@thecodesharman.com.au] That's an interesting problem you have there. I'm quite sure the debugger detect is not enabled by default. Do you think you can provide me with more details? Are you using any external modules or libraries?
No external modules or libraries, I've been trying to figure out where the _ptrace symbol is coming from by passing the using the "-why_live _ptrace" option to ld, this is the result: _ptrace from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk/usr/lib/libSystem.tbd _icucfasf7797nnzz from /Users/msharman/Documents/walta/walta-app/build/iphone/lib/libtiverify.a(TiVerify.o) +[ApplicationRouting initialize] from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o l_OBJC_$_CLASS_METHODS_ApplicationRouting from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o l_OBJC_METACLASS_RO_$_ApplicationRouting from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o _OBJC_METACLASS_$_ApplicationRouting from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o _OBJC_CLASS_$_ApplicationRouting from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o ltmp10 from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o ltmp10 from /Users/msharman/Documents/walta/walta-app/build/iphone/build/Intermediates/Waterbug.build/Release-iphoneos/Waterbug.build/Objects-normal/arm64/ApplicationRouting.o So it looks like it is being linked in from the ApplicationRouting.m code via the libtiverify.o library regardless of any settings.
Also I'm using the appcelerator CLI version 5.3.0-43 for this. I note that the libtiverify.a is symlinked to /Users/msharman/.appcelerator/install/5.3.0-43/package/node_modules/appc-cli-titanium/support/ios/libappcverify.a so this may be related to specifically the appcelerator CLI version ?
[~michael@thecodesharman.com.au] Do you mind sharing the ApplicationRouting.m content? It's in your build/iphone/Classes/
Thanks for pointing that out [~michael@thecodesharman.com.au]. Those are actually 2 different libraries (libtiverify.a vs libappcverify.a). Are you sure they are symlinked?
Sure this is the content:
Yes this is the contents of my build/iphone/lib folder: $ ls -l lib total 32 lrwxr-xr-x 1 msharman staff 94 18 May 16:43 libTiCore.a -> /Users/msharman/Library/Application Support/Titanium/mobilesdk/osx/5.2.2.GA/iphone/libTiCore.a lrwxr-xr-x 1 msharman staff 103 18 May 16:43 libti_ios_debugger.a -> /Users/msharman/Library/Application Support/Titanium/mobilesdk/osx/5.2.2.GA/iphone/libti_ios_debugger.a lrwxr-xr-x 1 msharman staff 103 18 May 16:43 libti_ios_profiler.a -> /Users/msharman/Library/Application Support/Titanium/mobilesdk/osx/5.2.2.GA/iphone/libti_ios_profiler.a lrwxr-xr-x 1 msharman staff 113 18 May 16:43 libtiverify.a -> /Users/msharman/.appcelerator/install/5.3.0-43/package/node_modules/appc-cli-titanium/support/ios/libappcverify.a
[~michael@thecodesharman.com.au] Now that's odd. This file should only contain this content if debugger detector is enabled. if you didn't enable it, it should only have:
Can you make 100% sure that your tiapp.xml has ZERO mention of any of these properties:
If you are using Ti SDK 5.2.2.GA and you do an appc new, the default created project's tiapp.xml will NOT have these properties. you can make reference to that.
Doing a *appc ti clean* would be helpful just in case. I noticed that you have libappcverify.a inside your build/iphone/lib. It shouldn't be there.
I found some references I hadn't noticed previously:
The basic 'encryption' you are seeing encompasses a way for us to verify that you are using legit titanium sdk when building the project. It's not possible to disable it, but it's nothing to worry about. that stuff has been around since the birth of titanium.
Hi Kiat, problems remain that we still can't use the remote encryption policy. I have a feeling that 5.3.0 and above is not stable and causes problem. Hope Appcelerator can test properly by test uploading to test flight.
Hi Chee Kiat, after 2 months, any update on this?
Hi Chee Kiat, so after more than 6 months, still no update on this? When we set the 2 properties in tiapp.xml and submit to app store, it still show the ptrace problem described above with the latest 6.0.3.GA. I am surprised that Appcelerator team still does not address this issue even after more than 6 months. If this feature does not work, at least you should update the Doc and inform us about it rather than leaving this setting hanging in the air.
Hey [~ngweixing], we've reassigned it and checking it out the upcoming sprint, thx! And to be more specific, do you know if only the combination of both or one specific of them is causing the rejection? Here are the two bad-boys again, I guess meant those two as well:
If it's
appc-security-debugger-detect
causing it, then we might have a possible solution already that we could test with you.thanks Hans! I was surprised these settings still produce the same problem. Hope you can fix this loop hole.
In your documentation, it says to turn debugger detect on, appc-sourcecode-encryption-policy has to be set to remote. When we set to remote, it has the ptrace problem. Even we tried remove appc-security-debugger-detect from tiapp.xml and leave only appc-sourcecode-encryption-policy set to remote, it still has ptrace problem. So i think it is appc-sourcecode-encryption-policy that is the culprit.
PR's: - appc-verify: https://github.com/appcelerator/appc-verify/pull/10 - appc-cli-titanium: https://github.com/appcelerator/appc-cli-titanium/pull/222 *QE-Test-Steps*:
Ensure to replace the
libappcverify.a
binary from the appc-cli-titanium PR in your local envCreate a new Titanium app with
appc new -p ios
Include the following three properties in your tiapp.xml
Run your app on the Simulator and Device (should not crash)
Observe the app-symbols by navigating to
Please feel free to reach out to me for further questions. *Additional Notes*: What I tried to do is to obfuscate the<app-root>/build/iphone/build/Products/Debug-iphoneos/<app-name>.app
and usenm <app-name> | egrep "(ptrace)" | wc -l | sed -e 's/^[ \t]*//'
. The result should be0
with the patch and2
(because of the different device-archs) without the patch. Alternatively, you can observe [this files](https://www.dropbox.com/s/5mmdf879mypj0cu/ptrace_before_after.zip?dl=1) that include both the fix and the old version.ptrace
method used for the anti-debugger feature. Please note: This is really just a hack and every developer using this feature should be aware that the app could still be rejected because of private API usage (although it should go through now). During my investigations, I've read that people explained the reason for using it to Apple and Apple approved it (and future update) afterwards. This should be documented around the jailbreak / debugger detection.FR Passed. Able to have remote source code encryption policy, debugger detect and jailbreak detect enabled and submit to the app store without issue.