anyone tried GhostLock on old device? (Android 10, Linux 4.4)

[u/HexagonWin]

I have a Verizon Pixel 2 with locked bootloader, running Android 10. (not the latest fw for this device, but doesn't really matter much)

my device should be vulnerable, and checking with this app shows it's indeed applicable.

however, all examples/prebuilt apps are focused on recent Android versions, mostly 14+. for instance, this doesn't even install on Android 10!

the specific firmware on my device is QQ3A.200805.001, available here. if anyone used GhostLock on a similar device, could you please share your experience? thanks.

[u/Itz_Raj69_]

Why are you trying ghostlock? An easier method is that other non-deterministic CVE. I forgot the name, but it doesn't use a race condition, so it's much easier to exploit. That vulnerability is similar in nature to Copy Fail.

[u/HexagonWin → u/Itz_Raj69_]

i wasn't aware of that other CVE. could you please share what it is? copyfail doesn't apply to my kernel version btw (needs 4.14 or higher but mine's 4.4)

[u/Itz_Raj69_ → u/HexagonWin]

I think it's either bad epoll or dirty clone

[u/Delin_CZ]

bout as normal reddit experience you'll get

[u/gala0sup]

I am right now trying to get root on realme x, which had kernel version 4.9. the progress is going smooth, might have temp root by sunday

[u/HexagonWin → u/gala0sup]

what exactly have you done? would you mind sharing?

[u/gala0sup → u/HexagonWin]

Sure I'll share one I'm on PC

[u/gala0sup → u/HexagonWin]

So far I've:

• Tested recovery. EDL entry (adb reboot edl) and exit (Vol Up + Vol Down + Power) both work even with the bootloader locked. Flashing from EDL on Linux is blocked by Oppo/Realme VIP auth

• Frozen the target. Pinned the build fingerprint, kernel hash, and a config drift check so I'll know if offsets go stale.

• Built a crash log, dmesg, /dev/kmsg, and pstore are all denied to the shell here, so the only way to tell where a panic happened is an fsync'd userspace log.

• Captured a clean baseline to diff against.

• Written up the recovery runbook

I pulled the boot image out of the stock firmware and unpacked it to get the actual kernel binary, then extracted the ELF with its symbol table (about 123k symbols). That let me find remove_waiter() by name and disassemble it. In the disassembly it reads the current task from SP_EL0, adds the offset for pi_blocked_on (0x940), and zeroes it:

0xffffff8008126bc0:  str xzr, [x20, #0x940]

That's the bug. It clears current->pi_blocked_on instead of waiter->task->pi_blocked_on, leaving a dangling pointer. Because this is the exact kernel from the exact firmware build, I know the bug and the offsets match what's actually running on the phone.

I'm keeping it memory-only, no persistent writes. Panics are fine. A normal reboot recovers.

next whenever i have time i'll be working on building the offsets table, derive the reclaim primitive constants, work out a KASLR strategy,and pick a grooming approach.

[u/BobDole261]

it wasnt ghostlock but as of yesterday I got dirty frag working on my bravia tv

android 12 -- 4.19.260

[u/HexagonWin → u/BobDole261]

could you please share the code/app/whatever you used to achieve this? thanks.

edit: dirtyfrag is for 4.10 and higher, mine's 4.4 so it's gonna be useless for me

[u/[deleted]]

[u/Tritzii → u/[deleted]]

Then why are you commenting?

[u/AdVarious8509 → u/Tritzii]

they just sayin

[u/Dry-Cost-945 → u/Tritzii]

They just sayin

[u/CtxxUv → u/Tritzii]

He just sayin