Closed jpstotz closed 2 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?
@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?
(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?
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.
@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?
@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.
@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.)
@oleavr I'm with @jpstotz. This is a break in backwards compatibility which breaks many wrapper scripts etc. for frida...
@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.
@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.
(FYI I'm on vacation so replies may be somewhat intermittent until next week.)
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.
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
?
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.
@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.
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).