I want to understand how to implement a key logger for iOS. And how can I avoid logging keys in my application, if there is iKeyMonitor (for example) installed on device?
After research I found that ikeyMonitor installs the following files on the device:
Library/Caches/.keycache
Library/MobileSubstrate/DynamicLibraries/MobileSafe.dylib
Library/MobileSubstrate/DynamicLibraries/MobileSafe.plist
Library/MobileSubstrate/DynamicLibraries/keychain.dylib
Library/MobileSubstrate/DynamicLibraries/keychain.plist
Of course it requires MobileSubstrate.
In keycache there are some HTML files that I can open in Safari with the URL localhost:8888.
In the plists there is only com.apple.springboard filter, it means that MobileSafe.dylib (and all hooks) will be applied only on
springboard app.
Even if I don't use the default keyboard view in my app for editing a UITextField, the keylogger still works. This means that Hooks are applied on UITextField.
After using class-dump for SpringBoard.app I didn't find any methods that can be related in UITextField's implementation. After using class-dump for MobileSafe.dylib I didn't find any implementation that can be substituted for UITextField either (maybe because it written on C), I think that I should analyze MobileSafe.dylib dynamically with gdb
How can the SpringBoard (that is in plist com.apple.springboard) app have an effect on UITextField class implementation? If I use method swizzling for UITextField in the dylib for com.apple.springboard will it work in other applications too?
What is the general difference between MobileLoader and MobileHooker? At what moment will changes from MobileHooker will be applied to my system?
What should I do to hook a method from UIKit (for example UITextField methods), and change its implementation for all apps on my device?
What method for analyzing iKeyMonitor can you advise me to use?
if it uses springboard in the filter then it can only affect the springboard, to hook all applications you use UIKit as the filter(more on that in 3)
My understanding of the two is that:
MobileLoader loads your code into the running application and when this happens, functions with the constructor attribute "__attribute__((constructor))" are called. In one of these constructors, MobileHooker functions are called to replace pre-existing functions/methods in the application. As for when the changes are applied, since they are changed in constructors they should be changed before any of them are actually called.
You simply use the com.apple.UIKit filter(which btw is what the keychain.dylib in iKeyMonitor uses)
class-dump does not show the hooked classes and methods of a tweak because they are not objective-c methods, instead they are functions...
The best option would be a disassembler like ida hex-rays.com/products/ida/index.shtml
Related
Is there any way that one could extract the information about UI elements (of the UIView) from the application’s memory during runtime of an iOS application (iPhone). Like getting a reference to the current UIView element and find a way to enumerate all UI elements contained in that view and create an abstract graph of the UIView calls of the app dynamically?
Since it looks like you may be interested n some general suggestions, I'll give you this one: look at DCIntrospect (available on github, with good documentation).
With this open source software, you can examine any item in your UI that subclasses UIView. You can see its many properties in your console.
It is very easy to use. I tried it, and it was a very simple add to my application delegate. To enable it, you press the space bar on your keyboard.
Since it is open source, you can examine the code and see for yourself what UI element properties are available and even make changes yourself.
UIView comes with an undocumented function to do that: -recursiveDescription. It's not as pretty as DCIntrospect, but you don't have to add anything to your project. Simply do:
NSLog(#"%#", [view recursiveDescription]);
or you can call it from the debugger:
p [view recursiveDescription]
See Apple's Technical Note 2239 (scroll to the bottom) for more details, and other interesting debugging commands.
Could anyone point me towards a resource which uses QuickLook to open a (preferably but not necessarily a pdf) file without using a UITableView?
I do have this example of using QuickLook but it uses a listview which I need to get away from.
http://robsprogramknowledge.blogspot.com/2011/02/quick-look-for-ios_21.html
I'm not sure how you plan to design your UI to open a file. I've used a few different ways, so I'll toss out some ideas. A UITableView is ideal for large amounts of files. A generic scroll view can also be used for a large number of files. I've used an alert view for an app that only generates one or two files. You could also use a view with document icons like the iPad Mail app. To get the document icons, use UIDocumentInteractionController. The WWDC 2010 DocInteraction sample code goes in great depth with how to use UIDocumentInteractionController.
As for opening the file, the Quick Look framework makes that easy. A simple, self-contained solution is to subclass QLPreviewController. Then, your subclass needs to conform to the QLPreviewControllerDataSource protocol and optionally the QLPreviewControllerDelegate protocol. Next, pass it an array of NSURLs pointing to your files. You can do this either through an initializer like -initWithFiles:(NSArray *)files or through a setter. From here, -previewController:previewItemAtIndex: just needs to index into the array to get the appropriate file to show. -numberOfPreviewItemsInPreviewController: just needs to return the size of the array. Once you have this class finished, you can use any UI design you like to push this view or present it modally.
Hopefully this is more clear than my tutorial you've been reading.
EDIT:
I have posted some code to Github that may help you. I have created a file previewer class as described above. I also posted a demo app that directly uses a QLPreviewController.
I'm trying to setup automated unit tests for an iPhone application. I'm using a UIWebView and need to simulate clicks on different links. I've tried doing this with JavaScript, but it doesn't produce the same result as when I manually click on the links. The main problem is with links that have their target property set.
When you manually click on a standard "popup" link (e.g. <a href="http://example.com" target="_blank">), the UIWebView will ignore the click event and won't navigate to anything. If you then try clicking on this very same link automatically via the JavaScript dispatchEvent() method, the UIWebView will completely ignore the target attribute and will open up the link normally in the current page.
I need an my automatic unit testing to produce the exact same results as when you manually click a link.
I believe the only way for this automated unit test to work correctly is to simulate a mouse click at a specific x/y coordinate (i.e. where the link is located). Since the unit testing will only be used internally, private API calls are fine.
It seems like this should be possible since the iPhone app isimulate seems to do something similar.
Is there any way to do this in the framework?
I found a similar question titled Simulate mouse click to window instead of screen, however I'm guessing this method is only valid for OS X, and not for iPhone OS.
I suppose you could simulate the touches by calling the touchesBegan/touchesEnded methods directly on the UIView (check the UIResponder class).
The proper way to do this would be to construct your own UIEvent and then post this event to your UIApplication instance via its -sendEvent: method.
However, there doesn't appear to be a public API for constructing a UIEvent, so you might be out of luck.
Could you store the locations of the clicks in a data structure that you use in your tests and then simulate standard touch events as described here described here
--- Just spotted that you didn't have much luck with the example on this link. The only other options I can suggest would be to manipulate the html when running from a test to replace any _target links (you know that UIWebView handles these properly when clicking manually, so I think a small bodge is ok for the unit test?).
Nice walkthrough in this answer
For your specific case, it may be sufficient to test in the simulator and use a MacOS event generator to make the clicks.
The private calls for recording and sending events are part of GraphicServices/GSEvent.h with the standard use at your own risk disclaimers. Every UIEvent is really a UIInternalEvent that has a reference to a __GSEvent, so for recording you can use the _gsEvent property to get the underlying event.
#property (nonatomic,assign) struct __GSEvent *_gsEvent;
I have not used any of this stuff, but it looks like GSSendSystemEvent would be a good place to start.
I am a complete newbie to mac/objective-c. My question is: I wonder if it's possible to bind a UILabel text to a variable, while not having to manually set the text when value change.
For example, on Mac OS, when I open a new Finder window and delete a file, then the global free space in the taskbar is changing. And that value also change in all the "finder" that are open.
How can I replicate such behavior using Objective-c, either on Mac or for iPhone ? I was thinking about UILabel, but I couldn't find a way different from manually set each UILabel.
thanks
Leonardo
The current version of iPhone OS (3.1) does not support bindings (such as you would find in desktop Cocoa). For the time being, you will need to write the controller glue manually to keep the UI in sync with your model.
Specifically, you would add an IBAction method in your controller, and connect the UILabel to call it when the contents changes.
This question has been covered before also:
Bindings using Interface Builder (for iPhone apps)
On the Mac, you would use Key-Value Coding (KVC) and bind the label to an object controller in IB. The bindings documentation covers this in quite some detail:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html
You will need to research the following:
Notifications Notifications
and/or
Key Value Coding KVC
Notifications will allow you to setup up automatic notifications of changes to let's say an object (e.g. variable) who's changes you want to be cascaded throughout your program. KVC allows you to hook up data to objects and may be helpful if you're using Core Data.
I'd start with notifications first.
It is very possible and there are 2 ways to do it.
Programatically by making a UILabel in the code and simply setting the myLabel.text.text of it
Though Interface Builder where you drag and drop the UILabel where you want it and have a property in the code to hook it up to and then use that property to set the myLabel.text on it.
While searching a bug in my code today I found a strange thing. When inspecting a UIView instance in the debugger the variable view of Xcode does not show the subviews member of the UIView class.
I only see this fields in the debugger (> should indicate the opening triangle):
UIResponder
_layer
_tabInfo
_gestureInfo
_touchData
_charge
_tag
_viewFlags
I'm missing the _subviews member and come to think of it also all the positional members (at least one of them should be there).
Does anybody know what I'm missing or doing wrong (as far as I can tell it is not a problem as a google search for this problem didn't got me any results).
I use Xcode version 3.1.3 with:
XcodeIDE: 1191.0
XcodeCore: 1192.0
XcodeSupport: 1186.0
on a mac with OS 10.5.7 and iPhone SDK 2.2.1 (I also tested with iPhone SDK 3.0).
I hope somebody knows anything about this. It gives me a little strange feeling that I cannot trust the debugger to show me everything I should know for debugging a problem. And it's not good if you need to mistrust you tools :(
The debugger is only going to be able to show you members, not properties. Remember that the two are different in Objective C. A property is just syntactic sugar for a setter and/or a getter. So the read-only "subviews" property of UIView only guarantees that it has an implementation for this method:
- (NSArray *)subviews;
As you've noticed, Apple has implemented many of their properties using undocumented member variables that resemble their corresponding property names, but with leading underscores. This allows you to spy on the internals of some objects to see what's going on in some cases, but many properties aren't implemented in such a transparent manner. In these cases, you'll need to inject some diagnostic code into your app to access the property and output its return value using NSLog, and/or store the value in a temporary variable that you can observe in your debugger.
Don't blame the poor debugger. It's doing exactly what it's designed to do. If it helps, you can blame properties for trying to trick us into thinking they're member variables when they're really methods.