yashsingh1/xdaforums huggingface dataset:
[Redmi K20 Pro / Xiaomi Mi 9T Pro Guides, News, & D] Jhonnythereaper:
Did you even bother reading the 4 pages, 4, before assuming it's a hardware difference? *Facepalm*
[Realme X Questions & Answers] mistamikel:
Does anyone know if there is a special way to unlock the China version of this device?

I have the 8/128gb version from China and can not unlock the bootloader. Ive tired anything and everything and it just hangs after I run the flashing unlock prompt (on cmd term) and nothing happens on my phone screen.

Has anyone else faced this problem and is there any tips/solutions?

Thanks

Edit: I also get this screen when running the unlocking script as well.

Any ideas? As I don’t speak/read Mandarin or Cantonese (apologies if I mislabeled the dialect used)
[Realme X Questions & Answers] mistamikel:
Mods, please delete!

I was able to use a different windows machine and everything worked !
[Realme X Questions & Answers] Dhop84:
Was you able to flash a custom ROM ?
[Realme X Questions & Answers] 00002972:
There are official tool and guide to unlock bootloader on Realme China forum.

Here are the links:

https://www.realmebbs.com/post-details/1163724162963877888

https://www.realmebbs.com/post-details/1164389059200561152

You can see some screenshots in the links.

0. Log in realme account on your phone.

1. Install "DeepTesting_realme-release_signed(8).apk"

https://drive.google.com/file/d/1qVV9xWvlWNQ8VPdQuU_5Rfd4WM932lpc/view?usp=sharing

2. Turn on "Developer options" (Press "Build number" 7 times)

3. Turn on oemlock in "Developer options"

4. Apply bootloader unlock in "DeepTesting" app.

5. Around 15 minutes later, your application will be reviewed. Click "开始深度测试" Your device will reboot to "START" fastboot. Use "fastboot flashing unlock" command to unlock bootloader.

The steps is my translation from the official forum article. I bought a Realme X Chinese varient online yesterday (4+64 G, CNY ￥950). It is on shipping now. I will try this official guide after receiving the device.

Note: I am not sure if there is an English version of "DeepTesting_realme-release_signed(8).apk". Here are some Chinese phrases, which may appear in the unlock app. In Chinese, "开始" means "start". "深度测试" means "DeepTesting". "已提交申请" means "have submitted application". "查询审核状态" means "check review state". "审核通过" means "Reviewed".
[Realme X Questions & Answers] TheWalker17:
Hi, the in-depth test from the indian guide to unlock the bootloader (https://c.realme.com/in/post-details/1167251892128972800) can be used on the chinese version?

If not the way to relock the bootloader are the same for both indian and chinese versions?
[Realme X Questions & Answers] 00002972:
The Chinese on your phone means "You have entered fastboot mode. Hold power button 6-10 seconds or remove the battery to quit."
[Realme X Questions & Answers] 00002972:
Perhaps not the same. I find the MD5 of the Chinese and Indian in-depth apk are different. You need to relock your phone with official in-depth app. The official unlock guides are similar. I'm sorry that I didn't translate reboot to fastboot with ADB command previously.
[Realme X Questions & Answers] TheWalker17:
Oh, so basically same guides but different APK. To relock the bootloader I can follow the Indian guide being careful to use the Chinese apk
[Realme X Questions & Answers] 00002972:
I think so, but the screenshots of the phone during unlock are kind of different. You need to read the texts on the screen to choose options with power button or Volume +/- button.
[Realme X Questions & Answers] 00002972:
I read the Indian guide carefully and find there is no "Turn on OEM unlock in Developer options" step. It is necessary in Chinese version. I have received my Chinese Realme X and flashed "TWRP 3.3.1-30 Unofficial by mauronofrio", "lineage-16.0-20200108-UNOFFICIAL-RMX1901.zip" successfully . "Modified VBMETA" is necessary for flashing TWRP.
[Realme X Questions & Answers] TheWalker17:
What's this modifies vbmeta?
[Realme X Questions & Answers] 00002972:
"Modified VBMETA" image and relative command is on https://xdaforums.com/realme-x/development/recovery-unofficial-twrp-realme-x-stable-t3959556
[General Topics] UBA Tutorials:
This rom has been online since a lot of time but no recovery was there for it to be flashed and in this Thread, It's all about it.

Introduction

This rom will only work on this device.

This Rom desont belong to me

ROM LINK:

https://drive.google.com/file/d/0BzR0tZAqInhQdGhmbm00WlNsN2c/view?usp=drivesdk

Everything works well in this rom expect,

1: The browsers may crash on some Websites

2: WhatsApp may not be able to be installed via PlayStore or Apk so it has be put in the /system/apps to work.

3: Front Camera will not be detected!

Other than this everything works well.:)

Installation:

Recovery must be installed, it can be found here:

https://xdaforums.com/general/general/alcatel-popup-6044d-custom-recovery-t3972789

Then it's simple, Go to recovery, Wipe, Preflash.

When the data is wiped, go to install Zip, SdCard and select Miui8 which is called 000.zip

Installation will take about 5-10 min, wait patiently and don't touch anything!!!

Reboot once done:)

SIMPLE HUH??!
[Xiaomi Mi A2 Lite Questions & Answers] Matiasmora:
Hello, any guide for install GCam?

I'm on SuperiorOS right now.

Thx
[Xiaomi Mi A2 Lite Questions & Answers] pawelik001:
Flash camera 2 API and install suitable GCAM :)
[LG V20 Questions & Answers] arpruss:
Anyone have any luck running [the poc exploit](https://xdaforums.com/galaxy-s9-plus/how-to/compiled-executed-zero-day-exploitcve-t3978059) for CVE-2019-2215 on an Oreo LG V20? It's listed as one of the affected devices in the news reports. I'd love to get even a temp root.

For me (LS997) the poc stops with writev returning 0x1000 (it should return 0x2000 if the poc is working).

I have played around with the poc.c source code and noticed that if I change WAITQUEUE_OFFSET to 0x90, the device crashes and reboots. Since an untrusted app isn't supposed to be able to reboot a device, this suggests that there may be an exploitable thing around there somewhere.
[LG V20 Questions & Answers] arpruss:
Looking at the kernel source on the LG site (at least for the LS997), the LGV20 does have the bug in the kernel. However, the LGV20's kernel has a different layout of struct binder_thread than the version of the kernel the poc is designed for. And unfortunately it's not just a trivial fix, because the poc assumes the waitqueue field is 16-byte aligned, while on the LGV20 it's only 8-byte aligned (because there is one less field in the struct). There is probably a way around this, but I am not good at this sort of stuff: I don't really understand how the poc works. If anybody here does, maybe we can pool our minds and work together.
[LG V20 Questions & Answers] chompie1337:
what is the waitqueue offset in the binder_thread struct in your kernel?
[LG V20 Questions & Answers] arpruss:
0x98=152, assuming the kernel source I downloaded is correct and assuming I counted all the fields right. Here is my count (counting 64-bits at a time):

struct binder_thread {
struct binder_proc *proc; // 1
struct rb_node rb_node; // 4
struct list_head waiting_thread_node; // 6
int pid;
int looper; /* only modified by this thread */ // 7
bool looper_need_return; /* can be written by other thread */ // 8
struct binder_transaction *transaction_stack; // 9
struct list_head todo; // 11
struct binder_error return_error; // 15
struct binder_error reply_error; // 19
wait_queue_head_t wait; // spinlock_t + list_head
struct binder_stats stats;
atomic_t tmp_ref;
bool is_dead;
struct task_struct *task;
};
[LG V20 Questions & Answers] chompie1337:
hmm. i see what you mean by alignment now.

this define

#define IOVEC_ARRAY_SZ (BINDER_THREAD_SZ / 16) //25

makes me believe that the size of iovec_array[ IOVEC_ARRAY_SZ] defined on line 75, has to equal size of struct binder_thread this is because somehow, the contents iovec_array overwrites the contents of a binder_thread structure. which means, that iovec_array[IOVEC_INDX_FOR_WQ] should contain the contents of binder_thread->wait.

wait_queue_head is defined as:

struct wait_queue_head {
spinlock_t	lock;
struct list_head	head;
};

meaning you have to make sure that the values in iovec_array[IOVEC_INDX_FOR_WQ] correspond correctly to the wait_queue_head but also line up so the writev works. there's definitely some trickery you could do to make this work. my first thought is you know that &iovec_arrary[9].len (offset 0x98) should point to values that make sense for a wait_queue_head struct. i'm working on understanding this better, though.
[LG V20 Questions & Answers] GoofMan69:
don't you guys think that 0xDEADBEEFs should go away before this so-called poc start working? any ideas on that one?
[LG V20 Questions & Answers] chompie1337:
that's where the use after free bug should come in.

ioctl(binder_fd, BINDER_THREAD_EXIT, NULL);

when this is called, the binder_thread structure is freed in the kernel.

immediately after the parent process calls,

b = writev(pipefd[1], iovec_array, IOVEC_ARRAY_SZ);

in the kernel, memory is allocated to copy over iovec_array from userspace. this poc depends on the pointer from this allocation, to be the same as the recently freed binder_thread memory.

then, when the child process exits, the EPOLL cleanup will use the waitqueue in the binder_thread structure, that has been overwritten with the values in iovec_array. when EPOLL cleanup unlinks the waitqueue, 0xDEADBEEF will get overwritten by a pointer in kernelspace. this has to happen just before the writev call in the parent process starts to copy over the second buffer, which gets us a kernel space memory leak.

if writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
[LG V20 Questions & Answers] arpruss:
One simplifying issue is that with Kernel 3.18, we don't have KASLR, so we don't need to leak the kernel address. Hence the first part of the poc is unnecessary, assuming we can get the addresses.

Are there any rooted LGV20 variants using the 3.18 kernel? If so, it might help if someone with one of these were to post a copy of /proc/kallsyms
[LG V20 Questions & Answers] djcal1985:
try

lg q710 kernel 3.18 View attachment 4843819
[LG V20 Questions & Answers] GoofMan69:
chompie1337, thank you for such detailed description.

So, child must exit and epoll-cleanup code should be done to the time when parent's writev() starts to copy 2nd buffer (as you say, 0xdeadbeef will be replaced by that time). But there's a sleep(2) in the child. Do you think it is appropriate? Hardly it'll take writev 2s to copy first buffer, maybe 2ms or smth?

Also, why does child call epoll_ctl(EPOLL_CTL_DEL)? Isn't it a thing, that we should NOT do for the bug to come in?
[LG V20 Questions & Answers] arpruss:
From reading the poc, it looks like deleting the event from the epoll queue, after the binder thread has terminated, (somehow) causes the pointer wq->task_list->prev to have the value &(wq->task_list->next). If the kernel allocates its copy of the iovec array in the same place as the old binder_thread structure was, the wq->task_list->prev pointer will fall in an iov_base location in the array, and hence an iov_base will get overwritten. Moreover, the poc ensures this happens AFTER the kernel has checked that the iovec is one the user has permission to use for reading or writing. In the clobber function, then, the epoll event deletion makes the iov_base point to a position in the kernel heap--indeed, inside the kernel's pre-checked copy of the iovec array--which the poc leverages to write data to any location the kernel has access to (by first rewriting the next little bit of the pre-checked iovec array).

Unfortunately, with the 3.18 kernel, the event deletion causes a value to be written to an iov_len location in the iovec array, which allows one to change the amount of data being written but not the location being written to. This is good enough for crashing the device and probably for leaking a lot of data, but I have not been able to figure out how to use it for rooting.

If the kernel could be manipulated to allocate its copy of the iovec array 8-bytes further down in the heap, that would solve the problem, but I don't know if it can be done: I don't think the kmalloc-512 allocator will do that. But I could be wrong. Otherwise, I think one needs some other technique than the readv/writev trick used in the poc.

I am, unfortunately, quite new to this kind of thing. An experienced kernel hacker can probably see in an instant what to do.
[LG V20 Questions & Answers] Supersonic27543:
I'm not sure the PoC crash is entirely because of the kernel version. My device (not the V20, just here to cooperate to develop the exploit) has kernel version 4.4 but it crashes at the first EPOLL_CTL_DEL. Where does the V20 crash when you change the WAITQUEUE_OFFSET?
[LG V20 Questions & Answers] GoofMan69:
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?

Btw, i've managed to get some memory from kernel (from my device, not the V20) and non-null curent ptr, but kernel_read fails, even when reading 4 bytes from cur_ptr without any offset

Can anyone comment on line 119:

current_ptr = *(unsigned long *)(page_buffer + 0xe8);

What is 0xE8? Where does it come from?

Another strange thing: if i run poc with wd offset like for ex. 0xb0 right after reboot - i get another reboot right away, repeatability 100%. but if i run at first with offset like 0xc0 - of course i get writev 0x1000 and poc exits, but if i rerun poc with 0xb0 right after that - it will not cause reboot, but correct leak of mem happens
[LG V20 Questions & Answers] arpruss:
The sleep(2) is needed to make sure the THREAD_EXIT, which frees the binder_thread object, as well as the subsequent allocation of the iovec buffer in kernel memory take effect before the EPOLL_CTL_DEL. The pipe blocking happens only after the the EPOLL_CTL_DEL.

I'm guessing that 0xe8 comes from the author's looking at a hexdump of the page to find where there is a pointer to kernel stuff to help figure out where the address limit is held in memory, so it can be clobbered.
[LG V20 Questions & Answers] chompie1337:
page_buffer + 0xe8 should point to the current thread's thread_info structure, where the addr_limit is held

---------- Post added at 08:35 AM ---------- Previous post was at 08:19 AM ----------

yes, you are correct. i believe it is because remove_wait_queue is called for the wait_queue_head found in the binder_thread structure which eventually results in a call to __list_del where this happens:

http://androidxref.com/kernel_3.18/xref/include/linux/list.h#87
[LG V20 Questions & Answers] arpruss:
I can now leak data on my LGV20 with the 3.18 kernel using this modified poc: https://github.com/arpruss/cve2019-2215-3.18

The key is to realize that the following happens during the after-free cleanup at least on my 3.18.71 kernel:

1. The spinlock appears receive the value 0x10001

2. The prev and next pointers in the queue head point to the queue head.

If everything works, you will have a bunch of hex data, which starts with two 8-byte pointers with equal values.

This may or may not get us closer to actually elevating privileges, but I thought I'd share it to help others.

1|elsa:/data/local/tmp $ uname -a
Linux localhost 3.18.71-perf+ #1 SMP PREEMPT Tue Jul 17 14:44:34 KST 2018 aarch64
elsa:/data/local/tmp $ ./poc98
Starting POC
PARENT: Calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial page
CHILD: dummy data
CHILD: leak data
writev() returns 0x12001
CHILD: Finished write to FIFO.
PARENT: Done with leaking
00000000 a0 f8 c4 f3 c0 ff ff ff a0 f8 c4 f3 c0 ff ff ff |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
[LG V20 Questions & Answers] chompie1337:
Nice work. Now without the spinlock issue crashing, the kernel write is failing. This is because the recvmsg implementation for the 3.18 kernel checks each address right before it's copied over to the buffer. In the writev/readv the access check for addresses are all done at once at the beginning of the call, so that's why the leaking works. Working now on trying to use readv instead of recvmsg
[LG V20 Questions & Answers] arpruss:
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c

Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.

Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.

Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.

Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
[LG V20 Questions & Answers] chompie1337:
Amazing work! Going to try it out now. How do you know that current_ptr points to task_struct? On my Pixel (3.18 kernel) current_ptr points to thread_info. Wondering why that's different?

edit: nvm, i see now. it's in an offset of the binder_thread structure.
[LG V20 Questions & Answers] DrZener:
Isn't thread_info pointed by the stack field of task_struct?
[LG V20 Questions & Answers] Rortiz2:
Bricked mine and forced to return to EMUI xDD

Tried the exploit here and kindof the same. The only thing different is that reboots after finish:confused:

Cheers!
[LG V20 Questions & Answers] ozkaya:
OK, it works for a V20 and I can get a root shell. Is it possible to mount /system rw? I tried some terminal commands but it fails, most probably because dm-verity is still active. The interesting thing is Adaway app can write to /system/etc/hosts file and it stays until a reboot then reverts to stock hosts. Any thoughts?
[LG V20 Questions & Answers] Rortiz2:
Pretty much dm-verity as you said..

What's the main issue of unlocking the bootloader on this phone tho (I don't owned it that's why I ask xD) ?

You can't just access into fastboot mode?

Cheers!
[LG V20 Questions & Answers] TheInfiniteAndroid:
Does anyone know if it is possible at all to bundle in the engineered bootloader so that someone with a locked bootloader can unlock the bootloader & flash magisk all in one go?

This'll eliminate the need to rollback & follow the dirtysanta root procedure, thanks in advance!
[LG V20 Questions & Answers] shawn2323:
LS977, LS99720A rooted. Thanks to those who worked towards this
[LG V20 Questions & Answers] ozkaya:
The problem is I own a version of H990 which doesn't have a vulnarable KDZ that I can downgrade to and apply dirtysanta. Right now, I am able to get a root shell. The question is, can I just use the dd command on the adb terminal to write engineering aboot or is it protected somehow? I am planning to flash eng. aboot and twrp from the terminal, then boot to twrp, flash a custom kernel so I don't get static screen and flash magisk. Does this sound right?
[LG V20 Questions & Answers] Supersonic27543:
I don't have an LG so I can't say for certain, but if your device doesn't have an efuse or other hardware based downgrade protection this should work, provided that the aboot you are flashing is compatible with the other software. If it does however then there is a good chance that this will brick the device at aboot level (or maybe lower) If you have a way to recover from it, try going ahead :)
[LG V20 Questions & Answers] Rortiz2:
Yeah this should work but be with caution because if you flash the wrong aboot, say bye to the phone:p

If you guys can't access into fastboot mode because it's locked down, zeroing /laf partition should do the trick:

dd if=/dev/zero of=/dev/block/platform/bootdevice/laf

(laf address may change in V20, I'm not sure).

Cheers!
[LG V20 Questions & Answers] shawn2323:
Tried flashing supersu forgetting that there's no ls99702a kdz to reflash and I got it boot looped with a message saying your device has failed a routine safety check factory reset has no effect ADB sideload and download mode can't get a shell to open without error I think all I need is just to reflash is it possible now dump I'll kdz of the said firmware is there any way out or his phone now for parts
[LG V20 Questions & Answers] floemuc:
I have a rather rare/weird device (Lenovo Mirage Solo) running kernel 4.4.78.

Regarding the exploit, I think I'm in the same boat as rortiz2: https://xdaforums.com/showpost.php?p=80711563&postcount=172

When I just run the su98 exploit via adb, I get "open: permission denied" when trying to join the namespace.

When I run "./su98 -N", I appear to get a root shell:

130|vega:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0
vega:/data/local/tmp #

But this is apparently just a rootshell in name only, whatever I'm trying to do that would actually require root just gives me "permission denied". And I can't get to the kallsyms without a system image (which Lenovo never released).

Would it be feasible to use the kernel r/w access to disable kallsysms obfuscation, and then in a second step get full root once the symbol addresses are known?

Regards, floe
[LG V20 Questions & Answers] bibikalka:
I second the armv7 request! I tried this on LG LS676, but immediately ran into the 64 bit issue:

1|shell@k6b:/data/local/tmp $ uname -a
Linux localhost 3.10.49-gf2315c3 #1 SMP PREEMPT Thu Jul 6 13:57:38 KST 2017 armv7l
shell@k6b:/data/local/tmp $ ./su98
/system/bin/sh: ./su98: not executable: 64-bit ELF file

Anybody can put together a 32 bit executable???
[LG V20 Questions & Answers] Supersonic27543:
This exploit looks heavily biased towards 64-bit. Anyway I compiled it for 32-bit (note that this is very unlikely to work, but you can still test. My guess is this will fail with a problematic address pointer) Here you go :) Good luck!