iOS Simulator Support

[ejohn20]

Enhancement

Add support for testing and learning how to use needle modules with the apps installed in the iOS Simulator.

Expected behaviour

For example, setting the IP address to "Simulator" or adding a new option for simulator path could have needle modules run against the apps installed in the simulator.

Benefits

This could make needle much easier to use and test in controlled environments that do not have access to jailbroken devices.

[marco-lancini]

Hi @ejohn20, I see your point, and to be fair you are not the first one to ask this feature.
However, what can you actually perform on a Simulator?
A simulator is basically a "virtual filesystem" (allow me the term) hosted on your laptop.
I foresee that most of the modules are not going to work on it.

But I'm keen on hearing your opinion on this!

[marco-lancini]

Paging also @tghosth, what do you think?

[tghosth]

I am not familiar with the iOS simulator but having had a quick look, my thoughts are as follows:

• I agree that it would be nice to have a way to test without a jailbroken device. (Or even better, a way to get root access on any device without the jailbreaking craziness!!!)
• It seems like a lot of modules depend on additional binaries installed on the device so would not be usable in the simulator.
• The best use case would be those modules which use files on the file system as noted by @marco-lancini. Even with these, there would need to be some significant "plumbing" changes as it seems like needle would have to know to look at a location on the local file-system and not connect somewhere via SSH.

If this were to be taken forward, I think the first step would be to look through the modules and consider how many of them could actually theoretically work in the iOS simulator, i.e. don't require binaries on the device. (Could @ejohn20 help with this?)

[ejohn20]

I agree with all of the above. Maybe we start with the most beneficial modules for the file system (e.g. sceenshots, plist files, sqlite files, keychain, extracting the .app files, etc). I will try to post a list of modules that I "think" will work on the simulator. I'm not very well versed in the hooking modules, so I may leave those up to you all.

I can assist with some of the coding as well, I should have some bandwidth in the next month or so.

Question - would you rather create specific modules for the simulator (e.g. /simulator/caching/keyboard_autocomplete) or build the simulator logic into the existing device modules? I suppose I could see benefits both ways...

[ejohn20]

Here is the list of current modules that I think will theoretically work with the simulator. Ordering from what I "think" would be the easiest to the more complicated:

storage/caching/keyboard_autocomplete
storage/caching/screenshot
storage/data/files_binarycookies
storage/data/files_cachedb
storage/data/files_plist
storage/data/files_sql
storage/data/keychain_dump

static/code_checks

binary/class_dump
binary/strings
binary/metadata
binary/pull_ipa

dynamic/ipc/open_uri
dynamic/monitor/files
dynamic/monitor/pasteboard
dynamic/monitor/syslog
dynamic/watch/syslog

There could be more, but I'm not well versed enough with the module to make an educated guess. Especially with the hooking modules.

[marco-lancini]

Hi @ejohn20, @tghosth: I had a thought about it.

• static/code_checks: this does not need porting since it is a StaticModule (doesn't need a connection to a device)
• storage/*: could work but we will have to move the tooling from the device to the workstation (i.e., run plutil on the workstation rather on the device) + we will have to update all the locations (I don't think we can reuse remote_operations.py at all)
• binary/*: see above
• dynamic: not sure of the feasibility. I would focus on storage/* and binary/* before tackling this

Regarding the organization, I think it would be better to create a core/device/simulator.py wrapper (similar to core/device/device.py) for all the operation that have to be executed on the simulator. Then, to avoid cluttering the rest, I would opt for specific modules for the simulator (e.g. /simulator/caching/keyboard_autocomplete)

What do you guys think?

[ejohn20]

Perfect - I think that sounds like a great plan going forward.

[tghosth]

So I agree with the core/device/simulator.py element but would having separate simulator modules lead to code duplication? In an ideal world, calls to methods in remote_op would be automatically directed to the simulator or the device depending on what the current target is. In practice, I don't know whether it would work that cleanly...

[marco-lancini]

@tghosth, good point. We could use a framework variable to hold the type of "device" (real or simulator), and then use that to dispatch to the relevant wrapper (device.py or simulator.py) from within remote_op

[marco-lancini]

Hi @ejohn20, any update on this?

[ejohn20]

Hey guys - sorry I dropped off the grid for a while. I had some non-mobile projects come up over the past couple months that tied up most of my time. I haven't had a chance to start looking at this closely yet...

[cmorell]

Hi,
I'm new in iOS pentesting. I want to set up the environment in iOS Simulator (no jailbreak device).

At this moment I have needle agent in iOS Simulator, but how do you solve the ssh connection (:2222)? I need it in order to use needles modules.

There are something in configuration to set up an iOS Simulator? Please I need help :(