Post

kinda crazy how much phone you can buy for £92 these days - this thing is still getting security updates *and* it has a headphone jack

and this is from a brick and mortar store, with 5 year warranty (2nd hand though)

very nice of them to label their test pads. I wouldn't be surprised if the MT6769V has some known brom vulns but that's not what I'm interested in

what I *am* interested in is the interface between the CPU and the DRAM. I've removed the epoxy and carefully sanded away some of the solder mask. what happens when I poke the data lines with a needle?

answer: bitflips!!! each channel is only 16 bits wide, so exploitation will be slightly trickier than on a wider bus - within e.g. a 64-bit PTE, we are forced to target 4 different bit-offsets at once, 3 of which will probably cause a hard crash. but 25% isn't bad!

so, can I use this to LPE into kernel? probably. I'll try to use the approach I described here, although it'll need some tweaking for aarch64/android: www.da.vidbuchanan.co.uk/blog/dram-em... if it works, this is a Play Integrity bypass on a fully patched device, without using any software bugs.

I'm letting claude port the exploit, which may be a bad idea.

some *very* promising initial results, although it crashed at the end, while trying to test the r/w primitive. plausibly because I flipped too many bits - will keep attempting (this one was on the third attempt, previous attempts just crashed the device)

hell yeah - second attempt after this, the r/w primitive worked fully. now I need to figure out the second half of the LPE - overwriting a setuid binary won't work

the exploit so far: github.com/DavidBuchana...

succeed at locating the current pid's struct cred, but for some reason died during/after trying to patch it

debugging it is tedious because it takes several attempts for the phys r/w setup to not crash the whole device

plausibly this is a SELinux thing™, I thought I'd keep things simple to start with so I'm just patching cred - if anyone has any guesses what the issue might be lmk

ok yeah this is a SELinux Thing™, will need a more intelligent exploit strat. surely there is good prior art of anrdoid phys r/w -> root?

Actually I might be hitting samsung's "DEFEX" mitigations: docs.samsungknox.com/admin/fundam...

I've had an unlucky streak in terms of getting the exploit to trigger, I'm currently trying to dump all of physmem to a file for analysis but it hasn't landed yet.

finally had some good luck, physmem dump is in progress

I was about to mention yep you'd be better off trying this on not a Samsung but if I recall it's pretty trivial to defeat defex

DEFEX puts the cred struct in a hypervisor writable only memory region, so you can't write to it even with a kernel physical write. you probably want to overwrite one of the executable paths that are used by a usermode helper and trigger it, or overwrite a libc file cache page and pivot into init

I'm able to write the memory, it just doesn't like when I set the ruid to 0

it's been a loooong time since I've done android pwn, can you not just poke something to disable selinux if you have phys arb w anymore?