<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I need to write some license checking code in Swift.</div><div class="">I know Swift is not optimal for that kind of code in the first place, as it is harder to obfuscate and easier to patch than say, pure C.</div><div class="">But if the code that needs to know whether&nbsp;the app is registered is written in Swift, this is still better than putting the license checking code in a separate framework that can be swapped out.<br class=""><br class="">To make attacking that code harder, I'm trying to obfuscate the code by at least removing the symbols related to it.<br class=""><br class="">For this, I have some inlined methods with internal visibility as follows:<br class=""><br class="">&nbsp; &nbsp; @inline(__always) static func checkLicense() { /* license checking code */ }<br class=""><br class="">Inlining should also help with forcing the attacker to separately patch the licensing function at each call site, rather than just patching the licensing function itself. (I am e.g. not using protocols in my licensing code for similar reasons.)<br class=""><br class="">Given that the method should always be inlined, there should be no need to include the method's name in the binary's symbol table. (I know that `inline` annotations often only are hints to&nbsp;the compiler, but I have reason to believe that they do work in this case.)<br class=""><br class="">In line with that, `nm MyApp.app/Contents/MacOS/MyApp` does not contain references to `checkLicense`.<br class="">However, the output of `strings MyApp.app/Contents/MacOS/MyApp` still contains references to `checkLicense`, and I'm afraid that an attacker could use that information to somehow more easily&nbsp;attack the license checking code.<br class=""><br class="">Here are my questions:<br class=""><br class="">1. Will these strings help an attacker, or are they useless without the corresponding symbol info (which would be exposed by `nm`)?<br class="">2. Would the strip settings listed below (in particular, stripping all symbols and "-Xlinker -x") cause a problem when shipping my code - e.g. when trying to symbolicate stack traces? I do keep the dSYMs of&nbsp;the shipped binaries.<br class="">3. Would setting "Perform Single-Object Prelink" to Yes help in obfuscating the code? The only effect I can see is that the dSYMs size shrinks from ~8 MB to ~6 MB.<br class=""><br class="">I am currently using the following build options:<br class=""><br class="">* Deployment Postprocessing = Yes<br class="">* Strip Linked Product = Yes<br class="">* Use Separate Strip = Yes<br class="">* Strip Style = All Symbols<br class="">* Other Linker Flags = "-Xlinker -x" (this seems to be the only option that actually cause the symbols to disappear from the results of the `nm` command.)<br class="">* Perform Single-Object Prelink = No (see above)</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Daniel Alm</div><div class=""><br class=""></div><img src="https://master.mailbutler.io/tracking/C379B3A8-A5CB-4913-8E9B-108392706D86" align="left" width="0" height="0" style="width:0;height:0;border:0;" title="" alt="" id="MailButlerTrackingPixel" class=""></body></html>