Openness of static iOS library - ios

I wonder how to block to preview static's library .m files while i'm profiling app by Instruments like Time Profiler.
All of methods are open to view.

The symbols are visible yes, but the linker needs to see those in order to use your library. In other words, you can hide the symbols, but it would render the library useless.
However the implementation is not visible and needs serious technology to reverse-engineer back into source form (I am not aware of a product that can do it, however I haven't looked for one).

Related

How to Prevent iOS app from hook theOS or others

I've been searching for 2 days to prevent my app from jailbreak device, and I got it, the problem is I still can hook my class use theOS and override the jailbreak check function.
Do you have any proven Idea maybe , framework , library or something else ?
You can use dyld for that.
_dyld_image_count returns a number of dynamic libraries loaded into your application address space. Then you can iterate over them using _dyld_get_image_name checking dynamic library path. That way you can determine whether CydiaSubstrate library or any dynamic library with unknown path been loaded into your application.
Of course with jailbreak even those functions can be hooked and I don't think you can do much about it. Arxan claims it can do something with it but even if it detects something you can always hook any function it uses for detection. CydiaSubstrate tweaks are always one step ahead because they're loaded before main is called. Thus it can hook everything it wants in constructor and you can't do anything about it.
Without jailbreak only way to load malicious library is to modify and resign your app so that it links against the library. Without jailbreak you can't hook C functions so _dyld_get_image_name will be able to detect that library.

How can frameworks used by a static library be automatically imported on iOS?

My company makes a static library for iOS apps. One annoying step for developers is that they have to manually link against all the required frameworks that the library uses, and failing to do so leads to somewhat confusing compiler errors.
I would have previously thought this wasn't possible, but the company Chartboost claims to automatically link against non-default frameworks like AdSupport and StoreKit. Based on my testing in their sample app (available from the linked page), so far this appears to be the case (Even when disabling "Enable Modules" and "Link Frameworks Automatically" in the app that links against the static library).
Is there some way to enable this feature when creating a static library? I've tried enabling modules and the "Link Frameworks Automatically" LLVM options in Xcode, but so far haven't been able to get it working.
There's a piece of code called CBDynamicallyLoadedDependencies that calls dlopen() on the appropriate system library before making the function or method call.
My original answer wasn't correct. the dlopen() call is just in the x86 code. On the device, it's something different, but my ARM assembly isn't strong enough to figure it out. All I can say is that there's a piece of code that's acting as a trampoline to the desired functions and that references the system library files (like /System/Library/Frameworks/AdSupport.framework/AdSupport).
But the point is that it's not a simple project trick that makes it work normally. There's internal code involved.
They might use modules you mentioned and #import instead of #import, which should make the libraries link automatically.
For reference, check this question.
This might not be what you're looking for, but if you don't yet support Cocoapods, I would strongly advise taking a look:
http://cocoapods.org/
(Edit: Cocoapods is essentially linked to Xcode. Other IDEs will need another solution.)
You can advertise Cocoapods to developers as the "easy" way to work with your library, and the manual method as...well, the manual method. ;)
I'm not aware of any industry resistance to Cocoapods, so I don't see a downside to supporting it, and it does solve the problem you're talking about (albeit in a roundabout sort of way).
Also I've found Chartboost VERY developer-friendly. You might even reach out to them and ask.

How to prevent exception breakpoints firing within a static library

I've created a small static library for Mac OS and iOS, and it's working very nicely thank you. However, during testing, there were times when my code bugged out and it hit a breakpoint that I keep set on 'All Exceptions' in case of just such an eventuality. I'm not worried about the bug itself - all the ones I know of are fixed - I'm more worried that Xcode took me straight to the code that crashed - inside my library's code, thus revealing the inner workings of my library's .m file.
Naturally I don't want this to happen in the wild, or people would be able to rip my code directly. How do I prevent Xcode from displaying the internals of my static library, even when an exception occurs within it?
-Ash
This appears to be an example of Xcode being a little too clever for its own good. It was actually detecting that I had the code for this library on my computer and fetching it directly from the folder, not reading it from within the library at all! I renamed the folder containing my library's source code and project file temporarily and, lo and behold, the library code is no longer displayed when a crash occurs!
Freaky.

iOS SDKs: Renaming a lot of classes

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.

Watching memory usage in MonoTouch App

How can I find out how much memory my App is using from inside the app itself, using MonoTouch?
I basically want this:
Watching memory usage in iOS
which calls things like "task_info"
but for MonoTouch (it's OK if works only on iOS). I don't want a memory tool, like Instruments, etc, I just want to know the memory used from inside the App itself, so I can display it and be able to check it isn't too much in various field trials, etc.
I see at least two options:
Copy the "task_info" code into a new Xcode project and create a static library out of it. Then you link with that static library in your MonoTouch project, and use a P/Invoke to call logMemUsage.
Translate all the "task_info" code into C# (using P/Invokes to call native methods whenever required).
I would likely go for the first option, I believe it's somewhat less error prone.

Resources