You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another approach would be to make the grep hook transparent to the caller and launch custom startup code in a forked process. This way you can also safely make the hack persistent.
Like this:
self="$0"
# Comment these out to make RedHerring persistent
# mv /data/.bin/grep /data/.bin/grep.disarmed &>/dev/null
# self="/data/.bin/grep.disarmed"
/system/xbin/busybox touch /data/InYourGrill.$$
# If this is the first execution, restart myself in background with "--pwn" argument
if mkdir /tmp/RedHerring &>/dev/null; then
mkdir /data/RedHerring &>/dev/null
( /system/xbin/busybox sh "$self" --pwn > /data/RedHerring/log.txt & )
fi
# Give control to the real grep unless started with --pwn
[ "$1" == "--pwn" ] || exec /system/xbin/busybox grep "$@"
### Beginning of persistent startup code ###
echo "### RED HERRING ###"
[start adb here]
However one thing puzzles me: there is actually no grep in $PATH, so it's not clear to me why anything would expect it to work in the first place.
The script located at:
https://github.com/MAVProxyUser/P0VsRedHerring/blob/master/grep
Does not work properly, it tries to activate adb, but logging in with adb won't work.
This is because the login script of adb runs grep in its initialisation (Causing Login->grep->restart-adb->failure).
I suggest either (this will activate adb quite late in boot):
Or if you think that is too risky simply:
Will offer a fairly risk free approach, however restoring grep function is an important thing to consider.
Or something like this:
The text was updated successfully, but these errors were encountered: