frida / frida-tools

Frida CLI tools
Other
348 stars 97 forks source link

Allow Frida to connect to an app process by it's identifier again #39

Closed jpstotz closed 2 years ago

jpstotz commented 4 years ago

For an unknown reason the ability to connect to an app process (e.g. on iOS) using it's bundleID was removed from Frida. By default Frida always uses the process name and ignores the process identifier.

Therefore the command-line option -n/--attach-name is now useless. I have removed this option and replaced it by the option -i/--attach-identifier which identifies the process-id to be attached using the app identifier (case insensitive comparison).

oleavr commented 4 years ago

Sorry for the delay here, I totally missed this PR :-(

Hmm, what you're describing was never implemented. However you might be confusing it with how things behave on Android, as process names typically are the same as the package names and thus using the identifier to attach happens to work (in most cases).

The -n switch is for the process name specifically and I don't want us to break that, but I'm definitely open to adding another switch to attach by app ID. E.g. -N/--attach-identifier. (We cannot use -i as frida-trace is using it.) What do you think?

jpstotz commented 4 years ago

@oleavr Thanks for your feedback. I even forgot this PR myself as most of the time I use a custom Python script to start Frida for iOS apps.

Are you sure the -n option is still used somewhere in frida? I wasn't able to identify a code section where this option is read. If you want to keep it for compatibility reasons I am fine with this, but if it is really not used anymore I would suggest to adapt the help text.

Sorry, that I had not checked -i option for potential collisions. If it is already used it is of course not an option. Your suggestion of -N (in the meaning of "not name"?) would work, but in my opinion it is not memorable at it is totally independent of the meaning.

As we are talking about a very special option which will (I assume) mostly used by iOS app hookers what about about a short option like -id. That would be easily memorable. Or is there a rule that short options are limited to one character?

oleavr commented 3 years ago

(Oh no, sorry for dropping the ball here... I'm terrible at context-switching!)

Are you sure the -n option is still used somewhere in frida?

Not in Frida, but by users.

Or is there a rule that short options are limited to one character?

Yeah that's what standard argument parsers enforce.

Thinking about this now, I wonder if this confusion about -n stems from the fact that process names typically happen to be the same as app IDs on Android, and this got confusing when using an iOS device?

jpstotz commented 3 years ago

Hi Ole, thanks for coming back. I think we can agree that for both of us this wasn't a high priority topic.

As quite some time has passed I had to bring back the main problem to my mind. I think you can see the problem from the following frida-ps output:

Truncated output of frida-ps -Ua on an Android device:

 PID  Name                                         Identifier
-----  -------------------------------------------  -------------------------------------------
 3204  com.android.nfc                              com.android.nfc
 2317  com.android.phone                            com.android.phone
29573  com.android.providers.calendar               com.android.providers.calendar
 3234  com.android.se                               com.android.se
14006  com.android.settings                         com.android.settings
 3333  com.android.smspush                          com.android.smspush
 2052  com.android.systemui                         com.android.systemui
25358  com.android.vending                          com.android.vending
29231  com.google.android.apps.docs                 com.google.android.apps.docs

Output of frida-ps -Ua on an iOS device:

PID  Name                 Identifier
---  -------------------  -------------------------------
437  App Store            com.apple.AppStore
264  EscrowSecurityAlert  com.apple.EscrowSecurityAlert
233  Reminders            com.apple.reminders
298  Setup                com.apple.SharingViewService
270  Siri Search          com.apple.Spotlight
 61  SpringBoard          com.apple.springboard
276  Wallet               com.apple.PassbookUIService
389  iTunes               com.apple.ios.StoreKitUIService
440  八度数据恢复               com.8dudata.order

So there is a major difference between iOS an Android. And if I remember correctly the process selection is triggered here:

                    if not isinstance(attach_target, numbers.Number):
                        attach_target = self._device.get_process(attach_target).pid

https://github.com/frida/frida-tools/blob/master/frida_tools/application.py#L314

If we follow the code into frida-python's core.py

    def get_process(self, process_name):
        process_name_lc = process_name.lower()
        matching = [process for process in self._impl.enumerate_processes() if fnmatch.fnmatchcase(process.name.lower(), process_name_lc)]

https://github.com/frida/frida-python/blob/master/frida/core.py#L106 we can see that by default Frida uses the name property to find a matching process. On iOS this is the app name which means that it is not limited to ASCII characters. Additionally the name may be localized so that it is pretty complicated to attach to an app you only know the iOS bundleId (what Frida calls the "Identifier").

But I noticed that the statement "-n/--attach-name is useless" from my first post is not true. If the app name does only contain numeric digits, it may be misinterpreted as process id and in this situation the --attach-name option would of of use.

On a long-term perspective it may be better to implement the possibility to select a process by it's identifier in frida-python, e.g. by a second method like get_process_by_identifier or an optional parameter in get_process that allows to select the process by it's identifier. This PR is more the quick-and-dirty solution.

jpstotz commented 3 years ago

@oleavr What do you prefer: updating this PR and change it so that the command-line option -i/--attach-identifier is added and the -n/--attach-name option is not removed or first switch to the frida-python project and update core.py so that it provides a way to select a process by process identifier?

jpstotz commented 3 years ago

@oleavr I noticed that in the recent version of frida (15.0.8) now also Android is affected, so that it is now impossible to run or attach to an app by it's package name (or did I miss something).

I simply can not understand this decision. The app name is sorry to call it this way "localized bullshit" only the bundleId(iOS) or packageName(Android) is a good and valid identifier for an application.

oleavr commented 3 years ago

@jpstotz The name is meant to be human-readable string to be displayed by a UI. With Frida 15 we finally have the parameters dict, which contains an applications parameter that's a list of bundle IDs/package names. So the mapping is not necessarily 1:1, like in the case of the phone process on Android. (This is covered in some more detail in the 15.0 release notes.) So I think we should make use of this now. (Gtg but will finish this thought later.)

s1341 commented 3 years ago

@oleavr I'm with @jpstotz. This is a break in backwards compatibility which breaks many wrapper scripts etc. for frida...

oleavr commented 3 years ago

@jpstotz So I'm leaning towards making it so -n matches on the first matching name, and if no matches, we can look through the applications parameter of each and pick the first match. This way we also maintain the old UI behavior. What do you think?

Edit: Probably best to look in applications first, and name as a last resort, as only the former are guaranteed to be unique.

oleavr commented 3 years ago

@s1341 It was always like this for iOS, and I haven't registered any complaints there. So ISTM that it's better to be consistent – and tools can match based on their preferred criteria. The new applications parameter means they have even finer grained control than before. As for backwards compat., this is a new major version after all, and even though I try to avoid breaking things, I think it's worth it in this case given the inconsistency with iOS, and also that the new API offers more control than before.

oleavr commented 3 years ago

(FYI I'm on vacation so replies may be somewhat intermittent until next week.)

jpstotz commented 3 years ago

Considering the old and current implementation I would recommend that the default mode with no option specified where to search in searches in pid, name and identifier (no matter how those attributes are now stored internally). This should be similar to how it was in previous frida versions, except that the identifier was not included.

The option to select an process by it's name -n NAME, --attach-name=NAME does already exist as well as the option to select the process by it's pid -p PID, --attach-pid=PID. So the only option missing is to select a process by it's identifier (as discussed previously in this thread).

Or would it be preferable to select an app by an application parameter? At the moment it seems those applications parameters are only used internally as e.g. frida-ps only shows pid/name/identifier as before. Are there plans to make those attributes visible on user level? But on a second glance this might get to complicated for the users, three ways to specify an app process (name, id, pid) should be sufficient.

yotamN commented 2 years ago

Hey, what is the current status of this PR? I would like to help to get it merged.

What is the resolution on the arguments, should it be -N IDENTIFIER, --attach-identifier=IDENTIFIER?

oleavr commented 2 years ago

Hey, what is the current status of this PR? I would like to help to get it merged.

Thank you, much appreciated! I didn't mean to drop the ball on this one, I'm just really bad at context-switching 😊

What is the resolution on the arguments, should it be -N IDENTIFIER, --attach-identifier=IDENTIFIER

This sounds good to me.

jpstotz commented 2 years ago

@oleavr Sorry for the delay this time it was me who missed the PR.

I have refreshed the PR to remove the conflicts. Just tested it in combination with Android and I had no problem attaching to an app using its packageName/identifier.