yashsingh1/xdaforums huggingface dataset:
[LG V20 Questions & Answers] Supersonic27543:
Interesting, I didn't see that the code accepted arguments! -N seems to make the exploit skip the mountspace step.

Looking at the id output you have a root shell but with SELinux enforcing and shell SELinux label. That is to say, no more than the power of a normal ADB shell. :(

The problem with the idea is, the address storing kallsyms obfuscation (kptr_restrict) is also obfuscated (try "cat /proc/kallsyms | grep kptr_restrict" in a shell) so we can't figure out where it is. Also even with the knowledge of the symbol addresses some newer devices can't be rooted because SELinux can't be disabled (always enforcing) and if KASLR is enabled (it is enabled on most 4.4.x and later) the kernel addresses are randomized to a degree on boot. (so can't be extracted with a kernel image)

You might find the SELinux bypassing section of this paper pointed out by [MENTION=10174047]chompie1337[/MENTION] interesting. We still need to figure out some trick to bypass KASLR though.

Good luck! :)
[LG V20 Questions & Answers] bibikalka:
Yep, you were right! So what does one need here? The particular address from the kernel binary extracted offline?

Here is the output:

shell@k6b:/data/local/tmp $ ./su98
MAIN: detected kernel version 3
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
MAIN: **fail** retrying
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
MAIN: **fail** retrying
PARENT: soon will be calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial portion length 0x12000
CHILD: task_struct_ptr = 0x0
PARENT: writev() returns 0x13008
PARENT: Reading leaked data
CHILD: task_struct_ptr = 0x0
CHILD: Finished write to FIFO.
CHILD: **fail** problematic address pointer, e.g., 0
MAIN: **fail** retrying
Failed to leak data: error
1|shell@k6b:/data/local/tmp $
[LG V20 Questions & Answers] Supersonic27543:
I was thinking along the lines of "a good address in 64-bit might be problematic in 32-bit" but in your device the exploit seems to fail to leak a pointer at all (address pointer 0) AFAIK when this happens in 64-bit that means the device is not vulnerable, but not sure about 32-bit. Good luck! :)
[LG V20 Questions & Answers] DrZener:
32bit porting is not (only) about switching the toolchain from aarch64 to armv7: memory layout is different and there are many things to take into account.

I'm working on it, any help(thoughts & code) is appreciated!
[LG V20 Questions & Answers] ozkaya:
thanks to this exploit, I first got a root shell, then used this shell to flash engineering bootloader and TWRP. And finally I flashed a custom kernel and magisk and now I have full root.
[LG V20 Questions & Answers] TheInfiniteAndroid:
If you have time could you do a step by step or message me privately?, I've been curious as to whether the engineered bootloader can be included in the exploit as I'm on H910 locked bootloader, you're the first person to confirm it
[LG V20 Questions & Answers] Phoenix591:
Sorry, KDZ have to be from LG, LG UP doesn't accept raw dumps or unsigned KDZ (not from LG).

Yes, this exploit can totally be used to flash the engineering bootloader. (which as a reminder STILL will NOT work on ARB 1 devices like the LS997 and H918)

get aboot.img from the dirtysanta files, onto the phone's internal storage, in the top level folder (not in side download), then in the root shell spawned by this exploit copy and paste (again this will brick any H918 or LS997 , H918 skip two paragraphs)

dd if=/storage/emulated/0/aboot.img of=/dev/bootdevice/by-name/aboot

Once the engineering bootloader is installed you can reboot bootloader to enter fastboot mode then flash twrp, then pull the battery when done flashing twrp to keep the system from booting normally (until twrp is booted, and maybe something flashed, the system will reflash stock recovery when it boots) then boot into twrp with the volume key method: power off, then hold volume -, press power until the screen turns on then tap power repeatedly until the factory reset screen appears, say yes to boot twrp, then flash magisk.

The H918, once bootloader unlocked by enabling oem unlocking under developer options in settings AND rebooting into bootloader and running fastboot oem unlock.

can use this exploit to flash twrp
[LG V20 Questions & Answers] DrZener:
I've been told that there's bug in findSymbol_memory_search: instead of assigning get_kallsyms_name(offset, name) to n, one should assign it to a new variable n1. And then offset should get n1 added to it, instead of n.
[LG V20 Questions & Answers] Supersonic27543:
I'm trying to bypass KASLR on my device and have a couple of questions, would appreciate it if someone could answer:

1) Are there a quick method to check if a given kernel base is correct or not? (if yes it might be possible to brute force the kernel base)

2) Can the offsets for obtaining the user_ns address be obtained through a disassembly? I know that it can be obtained with pahole, but I'm not sure whether that will give the correct offsets. (the PC which the kernel was compiled on might insert padding differently)

Thanks!
[LG V20 Questions & Answers] zdrouse:
Has anyone had success getting the poc working on Pixel 1 XL? I've followed some of the directions to find wait_queue offset (0xa0) and binder_thread_sz (0x98) in binja and replaced those. Running the poc still freezes the phone and have to force reboot. Seems to happen right after:

printf("CHILD: Doing EPOLL_CTL_DEL.\n");
[LG V20 Questions & Answers] ilikenwf:
Same here on all counts... either something differs on our device or it's not vulnerable, I'm not sure.
[LG V20 Questions & Answers] Supersonic27543:
You have to extract the #define's at first using your kernel image. Check post #52 for the method. It rebooting should mean that the device is vulnerable. :) Good luck!
[LG V20 Questions & Answers] floemuc:
JFYI, there's a recent paper on how to break KASLR via infoleak in UDP headers: https://arxiv.org/abs/1906.10478

Regards, floe
[LG V20 Questions & Answers] zdrouse:
Yeah, I did that with binja. I mis-typed the binder_thread_sz I got in my last post. On top of the wait_queue and binder_thread_sz values, are there other defines that require changing?

wait_queue offset (0xa0)

binder_thread_sz (0x198)

My linux kernel version is 3.18.100.

9.0.0 (PQ1A.190105.004, Jan 2019)
[LG V20 Questions & Answers] Supersonic27543:
I have already studied that but I don't get the cryptographic hashing algorithm, so I can't use it at the moment unless someone explains that to me. Still thanks for pointing that out! :)

---------- Post added at 06:23 PM ---------- Previous post was at 06:22 PM ----------

Sorry, I didn't see the binja line in your post as I typed that out in a hurry. Also, try setting the binder thread size to 0x190 (-8 the actual amount) Good luck!
[LG V20 Questions & Answers] Rortiz2:
[MENTION=7860599]Supersonic27543[/MENTION]

Do you think this poc will work on the new Fire HD10 2019? It runs a 4.4 Kernel and Android 9.0 (FireOS 7.0:()

Cheers!
[LG V20 Questions & Answers] Rortiz2:
Duplicate :p
[LG V20 Questions & Answers] Supersonic27543:
I don't see any reason for it to fail. Also the new HD10 looks really nice. :D But maybe the patch could have made its way into the kernel somewhere. It should be possible to say for certain when Amazon releases the kernel source.
[LG V20 Questions & Answers] Rortiz2:
Yes looks pretty nice. Waiting for k4y0z or xyz` to port kamakiri to it xD.

I will see if I get one of these in black friday.

Cheers!
[LG V20 Questions & Answers] DrZener:
Does anyone know if the bug afflict devices using upstream (not AOSP, binder_thread_release's tasks are implemented in binder_free_thread) 3.18 binder implementation (like this)?

I've seen many 3.18 devices using that on which this PoC seems ineffective.

[MENTION=10174047]chompie1337[/MENTION] do you know more?
[LG V20 Questions & Answers] chompie1337:
this bug was supposedly fixed on the upstream a long time ago. the link you posted is vulnerable though. i've looked at 3.18 kernel sources for Nougat where the binder_thread gets queued to be freed until the process dies, which makes the exploit ineffective. the only way to know for sure if you're vulnerable is by looking at the firmwar. Or by the kernel source if you're 100% sure you have the right one (not always easy).

---------- Post added at 06:55 PM ---------- Previous post was at 06:50 PM ----------

for those of you asking about specific devices - if your waitqueue offset ends in 0 (i.e 0xa0, 0x90, etc) the POC posted in this thread is not compatible. if you have a 4+ kernel, it's possible the original POC will work for you if you have this issue. you'll need to have a bit of know how to customize that for your device, I would look at Grant Hernandez's blog post about it.
[LG V20 Questions & Answers] Supersonic27543:
Hey, BTW do you think that the ss_initialized flipping showed in that paper could still work? It was released in 2017 so I'm not sure. (As in would setting ss_initialized to 0 still reset the labels to none?) Thanks!
[LG V20 Questions & Answers] DrZener:
It was fixed on upstream 4.14, but I didn't see a backport for the patch.

It was backported down to 4.4 LTS. 3.16 LTS doesn't have it.

This is the binder driver for a device I'm testing now. Even if it's 3.18 it's different from a driver based on AOSP 3.18.

I already changed binder_thread size and wait offset but all I can leak is a page full of 0s (i can't event crash the kernel by playing with offset value)

I'm on a 32bit system but I think I already changed whatever it takes to to overwrite the correct memory area
[LG V20 Questions & Answers] chompie1337:
it looks like it is vulnerable. i'm assuming you accounted for 32bit pointers when calculating the offset? double checked in the firmware disassembly? that's best guess as to why you can't leak anything. another thing to consider is that binder_thread in the source you posted doesn't contain the thread's task_struct. you should be able to at least leak something though

---------- Post added at 07:28 PM ---------- Previous post was at 07:19 PM ----------

yes, i think that part should still work. i'm having issues getting the new executable (from the overwritten poweroff_cmd) to execute because SELinux stops the new process (running with the kernel context) from executing anything out of /data/local/tmp
[LG V20 Questions & Answers] DrZener:
I changed defs according to my binder_thread specs and the size of iovec (16 -> 8)

#define BINDER_THREAD_SZ 252
#define IOVEC_ARRAY_SZ (BINDER_THREAD_SZ / 8)
#define WAITQUEUE_OFFSET 44
#define IOVEC_INDX_FOR_WQ (WAITQUEUE_OFFSET / 8)

I played a little with data at iovec[IOVEC_INDX_FOR_WQ +- 1] but the leaked page is always 0ed.

Probably I'm missing something: can you explain me the exact purpose of the values we're putting in the iovec array?

I got that we're overwriting the binder_thread structure and we have to forge specific values for wait's memebers, but why are we placing data at index IOVEC_INDX_FOR_WQ-1 ?
[LG V20 Questions & Answers] chompie1337:
https://linux.die.net/man/2/writev

writev takes a pointer to an array of struct iovec.

struct iovec {
void *iov_base; /* Starting address */
size_t iov_len; /* Number of bytes to transfer */
};

in the writev system call in the kernel, it will take that array and for each iov_base (base address), and will write iov_len bytes from that address to the file you want to write to. in this case, it's the pipe. the idea is that when calling epoll_ctl, one of the iov_base address will get overwritten with a kernel address. effectively reading from a kernel address and writing it to the pipe file, getting you a kernel leak.

let me know if that's clear.
[LG V20 Questions & Answers] DrZener:
It's clear, but why, if we want to overwrite the waitqueue (that starts at IOVEC_INDX_FOR_WQ), we set an iovec at IOVEC_INDX_FOR_WQ - 1 ?

If I did the math right the only iov_base that falls into waitqueue is iovec_array[IOVEC_INDX_FOR_WQ + 1].iov_base, but I still get pages full od zeroes, and the fact that trying to overwrite random areas of binder_thread doesn't crash the kernel makes me think that I'm doing something wrong.
[LG V20 Questions & Answers] chompie1337:
we aren't trying to overwrite the waitqueue. the write at iovec at IOVEC_INDX_FOR_WQ -1 will be performed first, then the rest of the write will block until the child reads the dummy data out of the pipe (because we set a max size for the pipe). once the child reads, this signals that the waitqueue part of the iovec was overwritten and the writev will continue. at this point, the fields at IOVEC_INDX_FOR_WQ will be filled with the appropriate kernel pointer.
[LG V20 Questions & Answers] DrZener:
Got it.

Any idea about why I can't leak anything? is there anything I can check to see if overwriting is taking place?
[LG V20 Questions & Answers] chompie1337:
truthfully, i'm not sure. haven't worked with this bug at all on 32bit. if i had to guess, maybe wait_queue_head has some padding in it in between fields on 32bit. if you have another 32bit device that's unlocked, you could try compiling the kernel yourself and adding print statements to debug.
[LG V20 Questions & Answers] DrZener:
wait_queue_head is 12 bytes (checked at compile time), so there's no padding.

I have a couple of 3.18 with unlockable bl (one of those is already temprooted) and the kernel source available. Is there something special I need to debug?
[LG V20 Questions & Answers] chompie1337:
nah, the way i do is it by adding printk statments and looking at them in dmesg. i'm sure there are more sophisticated ways of doing it, but i don't know of any that don't require sodering. if anyone knows of any, please share! anyway, i'd start by adding a printk statement where kfree is called for binder_thread, and where the iovec array gets allocated in the writev syscall and see if they match the same memory address. you'll be able to tell what printk statements related to the exploit process by looking at the pid/tid printed by the message line. good luck!
[LG V20 Questions & Answers] DrZener:
Well, it sounds very tricky ( I have no idea how to patch a syscall) but I can try.

Stupid question: can I read back iovec_array[some_index].iov_base to see if it was overwritten with a kernel address?
[LG V20 Questions & Answers] chompie1337:
not from userspace, as it will all happen in the kernel. it's not tricky at all, as when you compile the kernel yourself you just add print statements in the places you are interested in. you just have to find the corresponding parts of the code.

for example, here is where the writev syscall is defined on this kernel:

http://androidxref.com/kernel_3.18/xref/fs/read_write.c#905.

here is where the iovec array is allocated for that call:

http://androidxref.com/kernel_3.18/xref/fs/read_write.c#754

if i wanted to know if the uaf is happening i would add:

printk("iovec array kernel ptr %lx\n", (unsigned long) iov);

and same thing in binder.c where kfree(thread) occurs
[LG V20 Questions & Answers] DrZener:
Thanks!

Patched, here's the output:

[ 256.510229] <0>binder_thread kernel ptr c8700600
[ 256.510250] <0>iovec array kernel ptr c8700600
[LG V20 Questions & Answers] Supersonic27543:
I found what kills the exploit in my device when it tries to use root privileges. Looks like HKIP (Huawei Kernel Integrity Protection) exists in these kernels, but as it looks so far it doesn't use any hardware based hypervisors. I haven't digged much into this but it seems to evaluate under certain criteria whether a UID to 0 escalation is "legal" and sends a SIGKILL if it isn't. But skimming the code it looks like setting both kernel addresses hkip_uid_root_bits and hkip_gid_root_bits to 1 would turn it off. (Not sure whether this will completely bypass it, it looks counterintuitive that a kernel protection that is meant to protect against a privileged process can be disabled by flipping an address)
[LG V20 Questions & Answers] DrZener:
Have you tried to use RW capabilities to bypass that check?
[LG V20 Questions & Answers] Supersonic27543:
I still can't figure out how to bypass KASLR (would it be somehow possible to bypass it without first bypassing KASLR?) If there is no other way I'm going to compile the kernel this weekend and find the offsets to bypass KASLR the way the original exploit did.

BTW [MENTION=10174047]chompie1337[/MENTION] did you figure out a way to bypass KASLR on your 4.4 device?

Thanks!
[LG V20 Questions & Answers] chompie1337:
i did it by searching for code signatures, starting at some base address. if you find somewhere in your kernel binary that references the global you want, i would look for those bytes and calculate the address that way
[LG V20 Questions & Answers] arpruss:
One way to bypass KASLR would be to look at some of the fields in the task structure that always correspond to a particular kernel symbol, e.g., nsproxy or restart_block.fn. Once one has the correct address for that kernel symbol, one can search forward from the symbol in kernel memory to find the kallsyms table, look up the symbol in the table, and compare the kallsyms table address for the symbol with the actual memory address.
[LG V20 Questions & Answers] f41lbl0g:
Were you able to get a root shell on your s8 active using your version of the exploit?
[LG V20 Questions & Answers] Supersonic27543:
[removed]
[LG V20 Questions & Answers] arpruss:
kallsyms tables start with 0x100 alignment. So you should align your search base by ANDing it with ~0xFF. I think what happened was that your search was misaligned and hence missed the start of the alignment.

Yes, you can't lookup fields by name, but you can be a bit clever by looking at the sort of data that neighboring fields have. For instance, the pid and tgid fields seem to both always have the process PID in them. Etc.
[LG V20 Questions & Answers] chompie1337:
no :(

i'm close, i can bypass SELinux to attempt to employ the method in the Shen paper. I get past the execute_no_trans denial but I crash. i don't know why. someone messaged me saying they could bypass Knox for the S8 but they didn't message me back, lol

---------- Post added at 07:01 PM ---------- Previous post was at 06:59 PM ----------

i think in my attempts that code was able to "find" the kallsyms table but the dereference was failing. i just used code signatures as it was easier and most of the stuff i was looking for isn't in kallsyms
[LG V20 Questions & Answers] Supersonic27543:
Yes, I was wondering why the offset in loadKallsyms was ANDed! (So I should AND search_base the same way, right?) BTW where should I AND the search_base? Just after the search_base was selected, somewhere in loadKallsyms or find_kallsyms_addresses, or elsewhere?

I left a few minutes ago and don't have access to a PC now, would try dumping addresses adjacent to the possible addresses and looking for patterns when I get back!

Thank you!
[LG V20 Questions & Answers] arpruss:
It has to happen before find_kallsyms_addresses() starts going through memory. You can do it in loadKallsyms() if you like or in find_kallsyms_addresses().

By the way, on a device with KASLR, how do you recognize a kernel pointer?
[LG V20 Questions & Answers] Supersonic27543:
Thanks, would try when I get to my PC. :)

The code I added doesn't accurately recognize kernel pointers when iterating for search_base, it just takes all addresses that are values found in the task_struct, and above ffffff0000000000.
[LG V20 Questions & Answers] chompie1337:
ok, i know what the latest issue is.... there are checks before any privileged process executes and causes a kernel panic if they are not executing out of rootfs or /system.
[LG V20 Questions & Answers] f41lbl0g:
We might be able to bypass it by using samfail or edl to write the exploit to system.
[LG V20 Questions & Answers] chompie1337:
as far as I know, SAMFAIL will only let you load a modified system partition, not actually get write access to /system. i'm looking into how to remount either rootfs or system. sigh. this seriously never ends... i was so close!
[LG V20 Questions & Answers] f41lbl0g:
Technically we have write access to the system through safestrap. if you want to drop the app or poc in /system/priv-app it'll be in the system after boot but of course we wont have write access to the system when its booted. No clue how to remount them either.
[LG V20 Questions & Answers] chompie1337:
being able to write to /system and have it persist is enough, wouldn't need to remount. i though safestrap needed root or unlocked bl? can you link the relevant info? if what you're saying is true, then there's a strong chance there's a path forward.

i have an idea on how to force a remount on rootfs or system, but it's complex with Samsung RKP. not ruling it out yet.
[LG V20 Questions & Answers] Supersonic27543:
Finally managed to break KASLR after adding some ugly workarounds! ANDing the search_base increased the entries in one search so I ANDed it with ~0xFFFFF instead, which increased it more. It looks like the problem is 30 addresses in the middle of the kallsyms table are decreasing, or somehow detected as such by the function. I added some code to just skip over it and set the address and entry count accordingly and now loadKallsyms works properly. (Verified this by setting kptr_restrict to 0, now the kernel addresses are visible in /proc/kallsyms :D)

Unfortunately for some reason, setting hkip bits to 1 doesn't seem to disable it, because it reads the bits from an array in a header named READ_ONCE, I haven't looked into how it is allocated yet.

BTW I don't think disabling it would be required if we can somehow mask SIGKILL using the kernel r/w. Does someone know whether this may be possible? (Maybe by overwriting something in the task_struct?)

Thank you!

EDIT: The process is killed by using force_sig (see /kernel/signal.c for source) on the process. Could it be possible to disable as we have the address where it is located in /proc/kallsyms?
[LG V20 Questions & Answers] arpruss:
That's so weird. Do they show up as decreasing now that you've got /proc/kallsyms working? Can you post the relevant section of /proc/kallsyms?
[LG V20 Questions & Answers] f41lbl0g:
Doesn't require an unlocked bl. I don't know if it works for the s8 active but it does work on the regular s8/+. I'm currently on safestrap pie right now but I am downgrading to oreo soon. I can flash zips to /system (including some audio mods, xposed, adblock, debloater, replace fonts and emojis) and use the safestrap file manager (same as twrp file manager) to read/write files and change permissions. Flashing a modified magisk to system (without touching (kernel) flashes fine but runs into selinux issues, which I hope we can fix using this exploit.

Here is the link to it for the regular s8:

https://xdaforums.com/showpost.php?p=76074958&postcount=3

If you are on bootloader 1 or 2 there may be a chance of safestrap on the active.
[LG V20 Questions & Answers] afaneh92:
PM for safestrap support on oreo.
[LG V20 Questions & Answers] Supersonic27543:
ffffff94c3385250 r proc_bg_uids_operations
ffffff94c3385328 r proc_fg_uids_operations
ffffff94c3385400 r proc_aware_ctrl_operations
# the gap
ffffff94c38ba780 R capability_hooks
ffffff94c38ba9c0 R security_hook_heads
ffffff94c38bb4c0 R selinux_enabled
ffffff94c38bb4c8 r selinux_hooks
ffffff94c38bc988 r selinux_nf_ops

There seems to be a huge gap there, maybe that's the case? The exploit is jumping from 0xffffff94c33f0c10 to 0xffffff94c33f0d00. Thanks!