Is it possible to manage the memory of a process alien to itself in iOS?
By this I mean to be able to read and write bytes on iOS applications, something like ReadProcessMemory and WriteProcessMemory functions of Windows.
I know I have to program in Objective-C, but I do not know if these functions exist in it, or if iOS has them in its libraries. Or something similar to them.
Any hints?
This will absolutely get your rejected from the app store, so there is no reason for them to exist in objective-c. If you don't need to submit the app to the app store, you will need to look into unix tools and a possible jail breaking requirement.
Related
I am designing an iOS app UI with a freelancer UI designer and was referring back an forth to an app that I like as an inspiration for my app design.
I asked my designer to design something similar to that app we are looking at, then my designer told me that the way to do this is by coding and not design and he claimed that he hacked the app and is looking at its code !
Is it really possible to simply jailbreak and app and look at its code ? If so then is it at risk that someone would simply copy the code and re skin the app and put it up on app store ?
Code gets uploaded to the app store as a binary so there's never any source code up there to begin with. I guess its possible that your designer is reading the binary somehow but that would be pretty unlikely.
Edit:
It turns out it is possible to load the app into gnu debugger and view assembly. Or to decrypt the app and use class-dump to get the headers. However the original implementation code is gone.
So I know it's possible on a jailbroken iOS device to inject a dylib into a running process and interpose/hook system functions. I'm wondering if it's possible on a non-jailbroken device to interpose system functions at either link or run time, assuming I'm the one building the app? Maybe the equivalent on linux of using dlfcn and LD_PRELOAD?
An example: I want to take an app I've built that uses various Cocoa/Core Foundation abstractions for filesystem access and wrap the underlying open/read/write/close calls. I know about swizzling in Objective-C, but I'm looking for something at the libc level so I capture everything. This is for something test/debug related so it doesn't need to be App Store friendly. Thanks!
No, it's not possible (to my knowledge) on non-jailbroken iOS device. All traditional forms of dynamic loading (interposing, dlopen/dlsym, etc.) have been removed.
Since you mention that your needs are related to test/debug, you might want to try to make use of DTrace if your problem exists on simulator. You can use DTrace on simulator, but not on real iOS device.
OSX has functionality not available in the iOS SDK, and occasionally I'll find an answer like this one: no route.h on the iPhone SDK, that says "just copy the header file from the Simulator (or OSX) SDK and it'll work fine."
That seems suspect to me on multiple levels, including App Store approval, but then I read something like this from an Apple employee who says "if you're using sys/route.h declarations on iOS for an App Store app, please get in touch with me...", which sounds like tacit approval (or a ruse to catch misbehavior :)
Anyone know where the official line really is, and whether something like this is at all safe to do in production code? I'm particularly interested in lower-level BSD functions and whatnot for portability, as opposed to undocumented Objective-C methods.
I would not regard that comment on the Apple forums as tacit approval. It sounds like they're just trying to decide if some additional BSD APIs should be added for use in iOS apps.
In general, if there isn't an iOS header available for a function, then it's considered a Private API (for example, something under https://developer.apple.com/library/ios/). The official policy on Private APIs is that they're not to be used in apps distributed through the App Store.
Now, you can certainly use them for personal/hobby apps, or apps that you deploy in-house (Enterprise Distribution).
If the APIs you're talking about are APIs that are publically documented for OS X, and you can get them to work for iOS by copying headers, then they're probably part of the Darwin source base. It's very likely that they'll continue to function in future versions of iOS, although that's not guaranteed. Of course, nothing is guaranteed (really), as public APIs get deprecated, too.
Then, there's the issue that not all review checks are automated (I don't work for Apple, but can deduce this from things I've seen get through review). It isn't that unusual for apps to be approved with Private API usage, although if they get popular, Apple frequently pulls those apps from the store within a couple weeks. The review process isn't perfect.
So, my answer is that if you're submitting to the app store, don't expect copying in headers to work.
P.S. If you can tell us specifically which BSD function you're referring to, we might be able to give you a better answer.
P.P.S. The answer you link to about Route.h is from Grant Paul, who writes quite a bit of non-App Store software.
Additional useful information on Private APIs and the App Store
Apple never knows what header files you use - the danger of course is the definition from the copied file is close to, but not exactly, what iOS uses. If this file is important, or a few select files, post a question on Apple's internal forums and you will surely get an answer to such a question. Failing that, burn a DTS incident (you get two a year, I almost never use mine).
from one of the stackexchange questions Here,its proved that we can decompile the iphone application to its source,Now here comes the question how can we protect the ipa file/iphone application from cracking to its source?i have already verified this answers
here 1
method 2
but sad thing is it fails to protect the code,any updates to prevent app to source code
You can't really.
The iOS runtime on the device needs to be able to interpret the binary, so the binary has to be there, unencrypted and ready to run.
You could obfuscate it, by running it through a tool that scrambles method names, property names and so on. .NET and Java have tools that do this but I'm not aware of any for Objective-C, so I think you're on your own.
(Tools like anticrack, the one you linked to, will work for a short time until someone comes up with a way to reverse what anticrack does - but because your app eventually has to be there in a format the runtime is ready to run, all you can do is make it more difficult. It's like the age-old arms race of pirates vs protection mechanism in desktop applications).
This has been much discussed. Generally, you make more money spending time improving or promoting your app, then spending time trying to prevent it from being cracked in any way.
I was halfway through developing an iOS app but have sadly lost the development files (it's a long story). I have the latest version still on my iPhone. Is there some way of recovering it or even just part of it for use in Xcode?
Thanks.
In theory you can decompile the binary, which should be backed up in your iTunes backup. It is not a simple process, and if you encrypted the binary you should maybe just give up. The result of the decompilation will be nothing like what you started with -- rather it will be a bunch of cryptic C functions that don't necessarily make sense but which will compile back to your app. You might get something usable. Assuming that you actually are able to decompile and rebuild your app, the challenge you will face is in the future -- maintaining/updating cryptic code.
So my advice is to check the possibility of local backups/checkins (as per other answers here). You might try undeleting the files from your hard drive (DON'T save any more files to your disk, just download undelete software and try it). Short of those things, you can take to heart the advice of my Comp Sci 101 professor. I quote:
Don't fret - it's always easier the second time around.
Good luck.
If you have Time machine enabled on your mac you may want to look in there. But other than that I don't think so.