I have supposedly 2 security vulnerabilities in the iOS app I developed. This medium article enlisted both issues I faced.
Look for:
Usage of Insecure Random Number Generator
and
Usage of Banned/Deprecated APIs
Those are the two issues I faced in my iOS app as well. I used Xcode's and ran the terminal command like shown in the link above and saw that these deprecated methods like _random and insecure methods like _memcpy and _strlen are being used in the app.
What I want to do here is to understand where in my source code I am using these methods. I have searched my entire source code of my Xcode Project, I don't have it used or called directly.
otool outputs in assembly language format and shows random address
How can I find out in source code where I must be using these methods? or decipher the assembly code to ObjC source code? so that I can remove that code and use a better alternative which in turn will remove the security vulnerability.
Related
I have an application Unity that uses the iOS static library. Then this application Unity is build in XCode. I found several utilities that allow you to obfuscate the library in the application. for example this - PPiOS-Rename.
I carefully read their documentation "Obfuscate Static Libraries", but at the time of building, the iOS static library are already "hidden in the root" of the Unity app, and XCode cannot obfuscate this.
So I need to first obfuscate the library and then add it to the application. or is it not possible?
In my understanding of the documentation PPiOS-Rename stays an external tool, just the files *.plist can be added into the releases, for being able to use the tool on the compiled releases.
I might be completely wrong about it, especially as without iOS I can't test it, but I'd check if my statement is right and if you can omit the step to include the library in your compiled releases.
About handling of *.plist files, follow the instructions on the linked page, I'm not sure if you have one or more in the end. As it doesn't seem relevant to the core of your question, I never verified it deeper.
I am trying to use the finder comment field of a file stored in the folder of my iOS application (I'm talking about local storage, not in the cloud). The function MDItemCreate that would enable me to do so easily is not available in iOS applications apparently, which must be why the build currently fails with the error warning : "Cannot find 'MDItemCreate' in scope". Apple documentation in fact states that this method is only available on MacOS.
I have tinkered with FileManager but it doesn't grant access to comments.
This topic seems related but the solution is quite opaque to me.
My understanding of Swift is rather limited, if you would be so kind as to provide a simple and detailed answer I'd be much grateful.
With thanks,
Julien
I'm not completely certain, but messages like "Cannot find 'X' in scope" are often due to a forgotten import statement. MDItemCreate(_:_:) (docs) seems to be part of the Core Services framework, which has been part of iOS since iOS 12. Have you imported the framework?
You can do this (at the top of your .swift file) as follows:
import CoreServices
Out of educational purposes I'm trying to use Eigen in my pet project. In order to speed the math I included macro EIGEN_USE_BLAS which activates use of blas library.
But I encountered an issue when I tried to upload my project to Testflight. The Apple response to that was:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: _saxpy_, _sgemm_, _sgemv_, _strmm_,
_strmv_. If method names in your source code match the private Apple
APIs listed above, altering your method names will help prevent this
app from being flagged in future submissions. In addition, note that
one or more of the above APIs may be located in a static library that
was included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I know that Apple has blas library as a part of Accelerate.framework and it should be use strictly through Accelerate API. But the thing is that Eigen also has their own blas included in their source and the library actually has no intention of using Accelerate.framework private guts. So that is why Apple asks me to rename those functions or remove them completely in order to get rid of that inconvenience.
But I'm not even sure that it is possible to do - to tune Eigen and its blas to use alternative names.
Is there maybe a way to solve that issue in some efficient manner? Or maybe I don't know something about Eigen usage in iOS environment?
I was lucky to figure out the problem with few tips from my fellow colleagues and a strong will to get the job done, and now I want to share with you my conclusions.
The problem: Eigen doesn't have BLAS binary provided, it only has it's headers. And when one uses EIGEN_USE_BLAS macro and it actually works, that means that Apple is linking Eigen BLAS functions to their binary - BLAS binary which is a part of Accelerate.framework. The trickiest part is that your project doesn't necessarily should have Accelerate.framework inside. XCode will add necessary files automatically and of course it won't bother to tell you that.
What's weird for me the most here is that using "naked" BLAS provided by Apple's Accelerate.framework is a clear violation because it's private API. So... from my perspective it's kind of XCode violates this rule without my intention and tells me nothing about it. Strange...
So, in order to fix it, you need to build BLAS or OpenBLAS binary (I have built OpenBLAS), add it to the project and link through Other linker flags in Build settings. After that the error is gone and you're able to upload your build to Testflight.
In order to save you some time in building OpenBLAS for iOS, I will leave you few links. I think those would be enough:
http://www.programmersought.com/article/2638161057/ - very clear tutorial on how to build OpenBLAS
https://github.com/xianyi/OpenBLAS/tree/release-0.2.21 - source code of the library
https://github.com/xianyi/OpenBLAS/issues/1531 - discussion where you can find solutions to problems you might encounter
What I found the most confusing part of this whole story is the message from Apple. Here's another copy of that:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: saxpy, sgemm, sgemv, strmm, strmv. If
method names in your source code match the private Apple APIs listed
above, altering your method names will help prevent this app from
being flagged in future submissions. In addition, note that one or
more of the above APIs may be located in a static library that was
included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I'm not a native English speaker but I feel pretty confident to say that this text is a non-sense and has absolutely nothing to do with the solving of the actual problem.
It says absolutely nothing about the fact that private API was linked to my code and that is the problem. And that I need to provide my own backend for those functions in order to make error disappear. It says about names matching and that altering my names will help to solve the problem, when it clearly will not in my case.
I hope Apple will bring more clarity into this problem and that errors descriptions will have more sense in the future.
My goal is to build a swift iOS framework which uses two other frameworks (included as separate projects) and which shouldn't reveal the source code after built.
Is there some text/guide/documentation which would explain and navigate me through the process of building such a framework properly and correctly?
I built framework with aggregate target adding and linking frameworks on which my custom framework is dependent using run script as indicated here. I was able to add built of my custom framework to my custom app, together with other two dependencies (again as a separate projects), and run it on the device. However, I am not convinced by the correctness of my custom framework built.
Moreover, I was not able to upload the archive to the Appstore due to the various errors of "Unsupported architectures...", "CFBundleIdentifier Collision...", "Invalid Bundle...", "Invalid Binary" and so on. After sorting these errors out according to the various stackoverflow answers and installing the app from the TestFlight, the app crashed after launch and wasn't working at all.
I was checking various blog posts, stackoverflow questions/answers and Apple Framework Programming Guide but nothing gave me comprehensive understanding on building custom framework under conditions described above.
Everything I did was just following step-by-step tutorials without explanation of the purpose of the steps. I am sure I am missing the basics. Could you please help me and give me some guides?
I can understand you frustration. I, a while ago too searched probably for many documents on how to write a framework correctly but like you I also didn't find anything really that satisfying. From my own experiences I can give a couple of advices.
NO External Libraries
In my opinion DO NOT use external libraries in your own framework. I don't really know what your frameworks purpose is but most of the stuff you want to do can be done without using external libraries. Depending on other libraries is not a good idea especially if its a framework you are working on. Anytime these libraries get updated or even worse if they don't you will have to wait for them to be updated or find another library.So rather than this happening later on I think its better if you do it from the start. So loose the external libraries.
Universal Framework Binary
Second one is pretty easy. Generating a universal framework. I suggest you don't use a script. Most of the scripts I found were either outdated or they didn't work at all. Later on I found out that actually it was pretty easy to generate one on your own. You can do this by building your project once for a real device and one for the simulator.Then you can generate a universal binary by using the command lipo -create "Your simulator executable path" "your iOS device executable path" -output "your framework name". What this does is that it combines your two executable files and generates a universal one. Then you can just go and copy your simulator documents from the modules file and paste them in you iphoneos modules file. I am going to share a link were you can go through the walkthrough yourself. https://medium.com/wireless-registry-engineering/create-a-universal-fat-swift-framework-b7409bbfa18f
Use Objective-C(If you can)
This one is bit of a tricky one unless you know objective-c. What I would recommend is that you implement your framework using Objective-C and writing a swift wrapper around it. I would not have said this if you were creating an iOS app but in case of a framework I still think you should go for objective-c. This is because Objective-c has been around for over 30 years and most of the very old apps are in objective-c. If you want your framework to easily be used by older apps coded in objective-c I recommend you go with it. I have read tons of posts on how people have problems trying to use frameworks written in swift in their objective-c apps. Swift will be the first and probably only choice in the near future but not just yet. On the plus side if you still haven't you will have learnt Objective-C which will give definitely give you a better understanding on how things work. It will be challenging but I promise you it will be worth your while .I have a good read on this which you can checkout yourself. https://academy.realm.io/posts/altconf-conrad-kramer-writing-iOS-sdk/
Naming Conventions
This is a pretty straight forward one. I suggest you stick to apples naming conventions. This is because you will be sharing your code this time and people will look for familiarity when trying to integrate your framework. This will make your code easier to understand. You can check out these two links for more info.https://github.com/raywenderlich/objective-c-style-guide (obj-c) https://github.com/raywenderlich/swift-style-guide (swift)
Access Control
This in my opinion is an important one. When working on you framework think before you implement a class or a function. Consider if you would like someone else to be able to use that part of your code. You may want to limit the user while they use your framework and correct access control is the way to do it. You can easily guide the users so the users do exactly what you want them to do with your framework.
Document Your Code
This is a must if you want your framework be a professional one. You should be documenting every function and variable the user will use. Documenting and explaining what your code does makes a lot of peoples lives easy. You don't one anyone trying to understand what your code does for half an hour while you could have easily written a small explanation for what the parameters do and one that function or variable should be used for.
Test Your Code
Last but not least do write tests for your code. This does take some time but it assures you that your code works the way it should.
Look at other good frameworks
You should definitely checkout other open source libraries and look at what they have done. Usually there is no point in reinventing the wheel unless you are doing something absolutely different but even then there are very familiar ways to do things. I can suggest you check out the mantle sdk(https://github.com/Mantle/Mantle). Another one is the very popular Alamofire sdk(https://github.com/Alamofire/Alamofire) and also the Realm sdk(https://github.com/realm/realm-cocoa). These are good examples of frameworks. Take a look at them. Look how they have done things. It will give you an insight on how your framework should look like.
I know all of these points may also be valid if you were writing an app but what makes these a must is the fact that you will be sharing your code with others. You may manage by not doing some of these while implementing an app but for a framework things do change a little bit. It is always a pleasure to work with easy to use frameworks which make coding a pleasure. These types of small things will make your framework preferable. Happy coding.
I'm developing an iOS SDK that integrates other SDKs (Facebook SDK 3.5, for example).
To prevent collisions and allow my customers to import those SDKs as well, I want to rename all of the classes/enums in my code (for example, rename FBSession to RDFBSession, etc).
Is there an easy way to do this instead of going class-by-class and using Xcode's rename feature?
Apple provide a command-line tool called tops(1) that is designed for scripting large-scale code refactoring (renaming C functions, Objective-C methods, classes, and other tokens):
tops -verbose replace "FBSession" with "RDFBSession" Sources/*.[hm]
If you have a lot of replacements, you can put all of the replace... commands into a file that you pass with the -scriptfile option. The man page has more information on the more complex commands/options (and examples).
Xcode also offers textual Search and Replace. This will be faster than individual refactors, but it is ultimately less automated. You can make the step by step refactoring faster by first minimizing the project to the relevant dependencies/sources (if possible).
However, renaming the declarations in a library will not alter the symbol names of its associated binary. If it is distributed with a binary, then renaming will just result in linker errors or (in some cases) runtime errors.
The best idea if you need to use a 3rd party library which your clients might also use is to simply inform them they need to link the library with their app, then publish the version(s) the current release supports so they know they have some extra testing if they go too far ahead with some libraries.
I think that a better approach than simply renaming your classes would be to download Facebook's open source code, rename the classes there and compile a new static library with a set of renamed header files. Then you can be sure that no collisions occur and that you're using symbols that you named yourself.
I must warn you though - working like this may make updating the SDK a nightmare regardless of how you tackle this specific issue.