Just curious if MonoTouch has support for "Module Initializers"?
http://blogs.msdn.com/b/junfeng/archive/2005/11/19/494914.aspx
Related question: Does Mono support "Module Initializers"?
Your first link answer, at least half, your own question. The Mono runtime supports Module Initializers and the test done (to prove this) was executed with Mono's JIT.
MonoTouch uses the JIT when executing on the iOS simulator, so there's no reason why it would not work there.
It likely works (or it's a bug) for devices too, i.e. where the AOT compiler is being used. As Jason said, it's a matter of testing it. If you cannot test it yourself simply fill a bug report and attach a (self-contained) test case to it and we'll confirm if it works (or keep the bug open until it does).
From the MSDN article you linked to
Since C# does not support global functions, C# does not support module
initializer.
Related
we're using https://github.com/firelyteam FHIR library in a Xamaring application.
When testing in iOS we discovered the PlatformNotSupportedException because of the use of Emit.
We then discovered we could use the Xamarin interpreter: https://devblogs.microsoft.com/xamarin/introducing-xamarin-ios-interpreter/
and it just works!
I have some questions/doubts:
is there any difference between the "Enable the mono interpreter" option or adding "--interpreter" to "Additional mtouch arguments"
is it possible to limit the interpreter to specific libraries? I'm under the impression is now globally enabled. I tried with "--interpreter=FHIR.HL7.Support" but I'm not sure it's working: inspecting the .ipa seems to containe .aotdata for everything. I was under the impression that aotdata was not produced when interpreted
can you suggest better solutions?
Thanks a lot
You can use --interpreter=assemblyname,.... to only allow the interpreter to work on just those assemblies, i.e. include the IL in only those assemblies.
I have an Objective-C project whose .ipa was tested with this tool online: https://www.immuniweb.com/mobile
It reports that my app has a high risk security issue, pointing to the canAuthenticateAgainstProtectionSpace in the NSURLConnectionDelegate protocol.
This method has been deprecated by iOS after 8.0 version. My app is not using it directly anywhere and I suppose this is not used by apple also even indirectly, since it is deprecated.
I tried a sample ipa (new project with nothing in it) with Objective-C project and the same issue came for that as well. But it did not come for a sample ipa which supported Swift. Even if this is just a warning, is there a way to fix other than just supporting Swift language only?
The tool has detected that the .h file that defines the NSURLConnectionDelegate protocol declares the canAuthenticateAgainstProtectionSpace function. This is, of course, to be expected.
It would make more sense for the tool to report implementations of the method, not simply declarations of it
Since you haven’t implemented this method you don’t need to worry about flaws in your implementation.
As for getting rid of the issue...Don’t use the tool? It doesn’t seem very good based on this.
Is there an option to tell it not to scan .h files?
TBH it seems like a bug in the tool if not any of your Libraries or Frameworks internally uses that.
In your test for the sample Objective C project it's reported as bug however for a sample swift project it's not reported Hence I guess it's more of bug from the tool side.
I would suggest you to report this issue to them.Hopefully they will get you back with some suggestions.
or
you can try some other pen-testing tools as well.
I need to obfuscate my iOS mostly C and Objective-C based app.
https://github.com/obfuscator-llvm/obfuscator/
llvm-obfuscator provide quite well solution without much additional work related. Obviously it will not prevent people from reversing it but at least it will lift a bar a little. App it self is designed good enough to protect few security related mechanisms but I would like to compile it with custom compiler to make it even more harder. But it raises few questions
If apple actually allow compiling with custom compilers
How it may affect speed and stability of application, o-llvm is
quite old 3.6.1 while apple already published their llvm 8.0 - not
sure what has been added improved or changed
o-llvm does not support latest xcode. I have abandoned idea and wrote my own obfuscation script which encrypts all variables and methods except Cocoa ones. It's not that good like o-llvm but it works great.
If I create an Xcode project with the iOS Single View Application template and choose Swift for the language, will the compiler exclude from the release build (binary) functions that never get called?
I'm wondering because I want to include a third-party library that has a lot of superfluous classes & functions, and I want to keep my app small & fast.
While I agree with comments, it is unlikely to impact performance in any significant way even if it was included...
Xcode 6 uses Apple LLVM Compiler Version 6.1, depending on how closely related it is to LLVM Developer Group's version the optimization feature is available http://llvm.org/docs/Passes.html with options such as -dce: Dead Code Elimination, -adce: Aggressive Dead Code Elimination.
One way to know for sure what is included is checking the assembly output using -emit-assembly option in the swift compiler and review the output, or opening the binary in a disassembler such as Hopper ( http://www.hopperapp.com/download.html )
I heard that JIT compiled code is not allowed in iOS AppStore because placing executable code in heap is prohibited. It that right? Or just a rumor?
Installable code isn't allowed ("or" is the key word in 3.3.2). Everything (except Javascript) has to be statically linked.
JIT compiling into Javascript source code text appears to be allowed. (Not a joke, there is a commercial compiler that does this.) Compiling into bytecode for execution by an interpreter written Javascript and running in a UIWebView may confuse the reviewers enough to possibly reject an app doing that.
The iOS security sandbox will likely kill any app that tries to jump into any dynamically generated data.
That is right.
You can read in the iOS standard agreement, which you need to accept when setting up your developer enrollment:
3.3.2 An Application may not download or install executable code.
Interpreted code may only be used in
an Application if all scripts, code
and interpreters are packaged in the
Application and not downloaded. The
only exception to the foregoing is
scripts and code downloaded and run by
Apple's built-in WebKit framework.
JIT compiling into Javascript source code text appears to be allowed. (Not a joke, there is a commercial compiler that does this.) Compiling into bytecode for execution...
I also made my thoughts about a compiler (not JIT but real programming language) running on iOS. My idea was using addresses to assembler-written functions implementing pseudo-opcodes as instructions instead of "traditional bytecode" (1 byte per pseudo-opcode).
One ARM register is reserved as "code pointer" (here named "rCP") pointing into my "bytecode". The last instruction of a pseudo-opcode-function is "ldmfd rCP!, {pc}". This means the last instruction of the function is not a "return" but a jump into the next opcode.
Using this method you get very fast "bytecode". Maybe the commercial compiler works like this. I cannot believe that there is a JIT compiler running native code on iOS.