If I distribute an iOS app with debugging turned on how much of the code can be reconstructed by an evil person?
I am asking about an evil person being able to quickly reconstruct the source code, not about philosophical questions.
The core of my question is: what aspects of the source code are inserted by the compiler (gcc or llvm in my particular case) into the source code.
Related
What is the best application or programming languages to build an iOS application platform for chat application for beginner like me. Please anyone can tell me about it.
Apple put a lot of effort in its new `Swift' language.
On any Mac computer, you will find XCode on the app store.
iBook has a nice and clear electronic copy of the guide.
I've gotta admit I was a bit circumspect ("yet a new language ?") but it appears has they sell it, solid and sound.(It's compiled and based on llvm. It is open as well, perhaps MIT license?)
I think they basically came up with C# for iPhone (it may even spawn from `mono'?)
But, again, the license model for the source make it sound more promising.
I found the iBook guide for very comprehensive when it came to the very basic of the language and the libraries.
XCode comes with quite a few templates showcasing each major application type. (You can also check the other languages for yourself: Objective-C and javascript)
So the two complement nicely.
If you are starting from scratch, I see no reason not to start on this train.
Since it's straight from Apple, and if coming up with Android isn't yet part of your plan, it will also be your path of least resistance when it comes to technical difficulties.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to decompile a iOS 3.1.3 kernel to better understand it, but i'm not sure where to start, But don't be fooled i'm no green horn when it comes to programming.
The kernel is open source so you can view and compile it. iOS 3.1.3 is in the repo but you will also want to look at 3.0.
From Apple:
As the first major computer company to make Open Source development a key part of its ongoing software strategy, Apple remains committed to the Open Source development model. Major components of Mac OS X, including the UNIX core, are made available under Apple’s Open Source license, allowing developers and students to view source code, learn from it and submit suggestions and modifications.
The XNU kernel in its iOS incarnation is not open source, though xnu in its i386/x86_84 (and , for older versions PPC) is.
XNU is built up internally of several layers, with the bottom two - platform expert and ml_* APIs serving as the "glue" to the underlying hardware. This means that without said pieces you could compile the source (with an ARMv7 cross compiler, like the one in the iPhone SDK), but the kernel wouldn't actually boot.
Another difficulty is in the kernel extensions (XNU-speak for "modules"). These are drivers, without which you can't really do much - again, with the kernel not booting since it can't initialize any of its platform dependencies.
Also, contrary to how it may seem, though the iOS and OS X kernels are very similar, there are some subtle differences (which were visible by #ifdef CONFIG_EMBEDDED and #ifdef ARM until after 1699, when Apple realized they were leaking information of use to jailbreakers, and finally used a preprocessor to strip the iOS specific modifications before making it public.
Decompilation is a different matter. It's possible to disassemble and work back, from the kernel image (once decrypted or dumped) through fairly readable assembly (though not to a full source level). IDA and other specialized tools (e.g. jtool) have these capabilities.
There have been at least two projects to get the open source version to compile and boot for ARM. One by Christina Brooks(?) and another by WinOCM. The latter, which has gained notoriety for knowing XNU in its ARM implementation inside out, has eventually been employed by Apple, thereby reducing the chance of any open source implementation ever seeing the light of day.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
Previously with objective-c code, I could "Analyze" - CMD + Shift + B and Xcode would warn me of all kinds of wrongdoings on my part.
It seems that with Swift, I can do no wrong! No warnings of any kind! But clearly there is a memory leak in my code.
Is there some setting I have to enable to get Swift to analyze my code properly? (I am aware I should use the profiler and test on an actual device, which I do, but I wonder why "Analyze" doesn't do anything.
Unfortunately no. Even many releases later, the latest version of XCode (6.4) still cannot do Swift analysis. The 'Analyze' option only works for the Objective C files in your project.
Let's hope the next version will have it, along with the refactoring capabilities which also are still limited to Objective C code.
To this moment (Xcode 8.3.x) Static Code analysis skips Swift code. Some Swift warnings cover some of the issues previously detected by the analyzer.
Also the upcoming Xcode 9 (presented in WWDC 2017) does not announce any change in this direction.
Many issues detected by the static Analyzer of Obj-C are for the most part prevented by the actual Swift language (e.g. unintended fall-through in switch statements). Other issues and scenarios formerly caught by the analyser, are now caught directly by the Swift compiler.
Many flows and scenarios leading to program crash - (e.g. accessing null pointers, leaving dangling pointers, or accessing released memory blocks) are hardly possible in Swift. Swift strong typing, heavy use of optionals, the requirement to completely cover protocols, and switch-case over enums, etc. remove another bunch of issues previously found by the analyzer.
A Swift static code analyzer will need to go to another level in analyzing program logic, which is much harder, and theoretically impossible to do completely.
So - although I'm quite thrilled to think of some future Xcode Analyzer, I wouldn't hold my breath waiting for it
Update:
As more and more people are down voting my post, just small update from my side. It seems that indeed apple just did allow for pressing option "Analyze" but in the background it does nothing (state for 2016.04.21, though I am not working on iOS for the moment and probably I don't have the latest version of Xcode).
below my original post:
Just for next readers of this article. At this moment Xcode 7 is already able to analyze also Swift projects. Refactoring is still not working though.
BR,
Darek
I've integrated a libPd patch in iOS.
When entering a text field, and presenting the keyboard there's some crackling sounds.
How would I go about debugging this?
NB I've tagged this question with Objective-C and iOS, however this question may require knowledge in all four tags - libPd and Pure Data well:
What is Pure Data
Pure Data is a powerful programming language for the manipulating of audio from core mathematical concepts. It's widely used games as well as DJ and other music focused applications. Some example apps that are built with Pure Data and libPd are: The Rj Voyager app from RjDj and the Inception App from Warner Brothers.
libPD is a method of embedding Pure Data patches (developed using the visual interface) within an iOS app. Controlling the Pd interface is done via a publish/subscribe message interface similar to OSC or MIDI. .
The GitHub page for libPd is here: https://github.com/libpd
What help am I looking for?
I'm not sure where to start debugging this. Someone who has integrated and used libPd on iOS could surely share experience. It could be related to the following:
How threading works, and how it interacts with the main queue
What sample rates work best given the target devices
What debugging tools are available.
Other advice earned through deep experience.
I don't know anything about PD, but it seems likely that the presentation of the keyboard is causing you to be CPU-starved for some reason. You might try:
verifying this still happens when in release and not attached to a debugger (log messages cause long delays when attached to the debugger, which alone can cause hiccups like this)
profiling your code using Instruments to see if you're inadvertently using a whole lot of CPU at once or
increasing buffer sizes so PD doesn't need CPU as often.
I was experiencing the same symptoms in an app I'm working on. I did manage to ascertain a couple of things early on. My recent changes involved sending alot of messages to pd during app init. I noticed when debugging that when I reduced the amount of messages sent, the sound improved. Also, I didn't see this in the simulator, only on the device.
The libpd example PolyPatch was pretty useful in this case, if you increase the amount of patches that can be generated. I found that the sound was breaking up with many patches open, in exactly the same way as in my app. This is quite simply where the overhead of using libpd takes its toll on performance. What's also clear is that simplifying a patch (so it contains less objects) impacts performance. But by far the biggest hit is creating a new, separate patch. So you won't want to be creating huge numbers of patches. Debugging does of course take a toll too.
44.1khz works pretty much everywhere as far as sample rates go (it's the pd standard too). And there's nothing to stop you debugging the libpd code right there in xcode, i've done that a few times. Other than that, there is the issue of debugging patches. You can either set up your patch with test versions of your objects directly in pd, or you should be able to set up libpd to view the same output as you would normally see in pd's main window in the console (you just need to make sure that you have something like this
[PdBase setDelegate:_dispatcher];
in your code - it's all in the dox of course). Then you just pepper your patch with print messages as required...
Hope it helps, and is still relevant after 3 mths...!
An Ocaml interpreter app was put up on iTunes last November. I've done some Haskell programming, and briefly looked into Ocaml at one time, but never really became acquainted with it. I have a new iPad, and am curious whether the Ocamlexample app available on iPad can actually be used for anything other than working through tutorial exercises.
I.e., does anyone know if it has the capability to save scripts (in its sandbox, of course), and any ability to export results (other than cut and paste)?
I can't find any references on Google much more current than last November, so it would appear that no one is actually doing anything with it.
Apple dropped many of their restrictions on iOS software development on September 9, 2010. Here is the press release announcing the changes:
Changes to development agreement Sept 9, 2010.
The only restriction now is that you can't download code. I.e., you can't have an embedded language implementation that is its own app platform.
This does limit the usefulness of an interpreter, but there is no rule against interpreters per se or against saving and reloading scripts in a particular iPad.
You can also compile OCaml to run on iOS. That's what I'm spending my time on right now, and I'm selling an OCaml iOS app in the iTunes Store. Visit my profile for a link.
(Hmm--I just noticed this was a pretty old question. Sorry for any extra noise.)
You can download scripts, but only if the mac/pc is tethered to the ipad and you use the dropbox function of ios. in theory this could be a program which opens a socket for your own protocol, however I have not tried this. It would have to be a single threaded protocol because Lwt is not implemented
From the way it's pitched, and knowing the App Store's rules, I don't think it's actually for making OCaml scripts. It just lets you do a limited set of calculations and drawing operations. Apple would reject it if they actually thought it was a programming language interpreter.