Closed bernard-wagner closed 5 years ago
Assuming I understand correctly, this is currently 'sort-of' implemented with startup commands and scripts here. Basically, running something like objection explore --startup-command 'ios sslpinning disable'
should load and run the command before the device information queries etc run.
That being said, the app resumes like you said, and if the frida load()
takes some time, it can miss things as the app resumes. The startup commands just try and win some time that would have been lost with the informational hooks that run to populate the repl prompt.
I am also not 100% sure if we can spawn()
in embedded mode.
Additionally, I think we can totally add a flag like --pause
to start the repl, allow you to queue jobs, and have a resume
command maybe that would pop/exec those jobs.
Thinking about this now, currently you can specify the "gadget" to connect to with -g
. So if you have a device with frida-server
running, you can totally use objection on any process using it. Given spawn
will work with frida-server
, maybe we should add a flag like --pause
or something that will spawn a process and keep it paused.
@leonjza not sure if I should open an new issue, but;
Is there a way we can attach to PID without respawning the process? ie.
# => tty1
$ frida -U -f com.app.name -l script.js --no-pause
(app spawned)
# => tty2
$ objection -p <pid> explore
(repl)
Just something that I have been think about that would be an awesome addition.
Currently frida.attach is being used to get a session. This automatically resumes the application when frida connects.
Adding the ability to start objection in spawn mode, where only jobs can be queued/loaded will allow for some cool hooks. Such as root detection bypasses, better disabling of certificate pinning, preventing setting of FLAG_SECURE, etc.
Playing around with this at the moment, but might require some hectic refactoring. Any suggestions on how to integrate this into the REPL/CLI?