yashsingh1/xdaforums huggingface dataset:
[Fire HD 8 and HD 10 General] RohanBaghel:
Dear all,

i have read all the comments on this post,

highly appreciate the simplest explanation of Baiker000, all though i have tried many ways to execute the exploit in my devices. but unable to get the root.

Devices : Samsung M30S

Kernel Version : 4.14.113

Build No. M307FXXU4CVJ1

Arm 64

Kernel Base Address : 80080000

No Knox Protection

Original exploit is designed for pixel 6, I have tried on that devices which completely works fine in pixel 6.

exploit works fine till the 1st portion of it. but when it comes to overwrite the offset values, all the times either the result is 49 or device gets restarted.

methods i have tried :

1. changed the the offset value of AVC_Denied, sel_read_enforec, init_cred, commit_cred, ..etc. (failed to get the root).

2. replaced the offset avc_denied > sel_read_enforece, and sel_read_enforece > sel_read_handle_unknown,, and so on.. tried vice versa.

3. Downgraded the firmware and tried.

result is same.

Observation :

my obsservation is that, the 2nd part of the exploit is designed for kernel version 5.10.x (pixel 6), it also works for 5.4.x.

as the structre of the avc_denied and sel_read_enforece is same for both the kernel,

since the structure is different for the kernel version 4.14.x, it wont give the root access to the device.

Can anyone suggest or help me to get the root shell,

what offset values should be used to get the root access.
[Fire HD 8 and HD 10 General] Azaze666:
You have to excuse me, I googled your firmware and turns out your device is Indian, so you can technically unlock the bootloader? Except if you have kg lock but this should not be the case as you clearly stated that Knox for you is disabled, so why are you struggling to get a root exploit to work when you can technically simply unlock the bootloader? Sorry but I have to ask, maybe you are doing this for fun who knows, but many people are struggling (me including) so why are you willing to suffer? Tell me if I'm wrong on my statements (because I could). Or has samsung started to block bootloader unlock in India?
[Fire HD 8 and HD 10 General] Azaze666:
updates... i modified the c file with my offsets again, hopefully right ones? more skilled guys could check, here are all files. Remember, i know nothing about programming and i never attempted to do this kind of operations so please don't criticize. I followed here:https://xdaforums.com/t/potential-a...d-8th-12th-gen-affected.4574635/post-89350071 and on my own edited avc_deny taking it from kallsyms (but before tried with the original value from the c file), avc_deny = 0x2CD000 (this is the edited value, not the original one)

my fw version is 7.3.2.7, HD8 2018

The good sign is.... GPU crashes... but you can check the image, i'm unable to get the root shell as previously, and i tried a lot of times but i get always the same error, i probably made a mistake somewhere, someone more skilled will tell me.
[Fire HD 8 and HD 10 General] Androiduser2390:
I hope we get TWRP for HD 8 2020 at some point
[Fire HD 8 and HD 10 General] RohanBaghel:
Yes I have unlocked the boot-loader, that is the reason which helped me to downgrade the firmware, but i want temporary root in my devices. yes if the exploit have worked for me, then i would have not raised my query. the observation which i have made could be wrong or could help someone who is willing the run this exploit.

It will be much helpful if you could suggest any solution for my query.

thanks is advance.
[Fire HD 8 and HD 10 General] Azaze666:
If I will be able to run this exploit I will be grateful
[Fire HD 8 and HD 10 General] abram125689:
Actually its easy process, please do ur research and find the solution
[Fire HD 8 and HD 10 General] nsfxpython:
Just wanted to input here that this was the error I was getting when trying to run the exploit on both my devices (Fire HD 10 2021 7.3.2.1 and Fire HD 8 2018 7.3.2.3). However, I was never able to get around this but I was told by @A Cool User this showed the exploit was indeed working. Keep trying it! You may get farther than I did!
[Fire HD 8 and HD 10 General] Azaze666:
Yes the problem is on mapping gpu memory i think or something like that (note that unfortunately I know nothing about programming, it's a miracle that I came to make the exploit to work up to there), I think that there are some modifications to the code to do to make it work with our gpu, but I can be wrong as again I know nothing about programming, I'm just trying to judge by the error, and since both I and @nsfxpython are getting it I don't think we both did do the same mistake, I think that the exploit code has to be changed to work with our gpu, but I may be wrong.
[Fire HD 8 and HD 10 General] A Cool User:
@nsfxpython

Could you share the mmap32.c you were using when exploiting Trona (FHD 10)? You are getting past flags_change, and successfully freeing the region which is good. This is the line

mmap64(NULL, 0x1000 * SPRAY_PAGES, PROT_READ, MAP_SHARED, mali_fd, (uint64_t)alias.out.gpu_va + i * 0x1000 * SPRAY_PAGES);

that is failing.

Thanks!
[Fire HD 8 and HD 10 General] nsfxpython:
I wiped all the files I was working with from my PC, but I can try to rerun the exploit and attach the corresponding mmap32.c file
[Fire HD 8 and HD 10 General] A Cool User:
That would be awesome if you could do that. Try to get to where you were before.
[Fire HD 8 and HD 10 General] abram125689:
@RohanBaghel FYI
[Fire HD 8 and HD 10 General] A Cool User:
I think so... Anyone who want's to can try and modify @diplomatic's script.

EDIT1:

I think I am going to download and compare 7.3.2.7 to 7.3.2.9 source code. 7.3.2.7 onyx works, but 7.3.2.9 dosen't... These devices are currently working with the expolit:

Fire HD 8+ (2020):

- 7.3.2.2

Fire HD 8 (2020):

- 7.3.2.6

- 7.3.2.7
[Fire HD 8 and HD 10 General] Azaze666:
Technically the Mali gpu exploit sets selinux as permissive if working correctly
[Fire HD 8 and HD 10 General] A Cool User:
This is the diff between the 7.3.2.7 and 7.3.2.9 for onyx mali_kbase_mem_linux.c:

Spoiler content hidden.

The addition of if (reg->flags & KBASE_REG_JIT) is the reason why this won't work on 7.3.2.9. However, GHSL-2023-005 dosen't seem to be patched yet...

EDIT1:

Confirmed here. Bad news, CVE-2022-38181 IS patched in 7.3.2.9 :(. Our only hope is GHSL-2023-005...
[Fire HD 8 and HD 10 General] nsfxpython:
Here is my file: https://drive.google.com/file/d/18qOKoT4DQ3TKX-TSJtOdT2OGL6ugEM8L/view?usp=drive_link

The line you are talking about is identical in my file (should I be changing it?)

mmap64(NULL, 0x1000 * SPRAY_PAGES, PROT_READ, MAP_SHARED, mali_fd, (uint64_t)alias.out.gpu_va + i * 0x1000 * SPRAY_PAGES);

Also: I tried compiling for both armv7a and aarch64 and the exploit only runs when compiled for armv7a and not aarch64.
[Fire HD 8 and HD 10 General] A Cool User:
I was just pointing out the lines as the thing to debug. IDK to much about it either... Thanks for the file!

EDIT1:

@nsfxpython the file is private... Could you make it public or just attach it to a message here?

Thanks!
[Fire HD 8 and HD 10 General] nsfxpython:
Sorry, just fixed it! Should be viewable now.
[Fire HD 8 and HD 10 General] A Cool User:
@Baiker000

Any more tips about /data/local/tmp/trona_jit_mali: jit init failed: Not a typewriter
? Trying to use GHSL-2023-005, but getting that error... Here is what my jit init function looks like:

void jit_init(int fd, uint64_t va_pages, uint64_t trim_level, int group_id) {
struct kbase_ioctl_mem_jit_init init = {0};
init.va_pages = va_pages;
init.max_allocations = 255;
init.trim_level = trim_level;
//init.group_id = group_id;
//init.phys_pages = va_pages;

if (ioctl(fd, KBASE_IOCTL_MEM_JIT_INIT, &init) < 0) {
err(1, "jit init failed\n");
}
}

EDIT1:

Tried merging the mali.h from raven, and got further. Now I have this error:

submit job failed: Invalid argument

Comparing to Raven trying to get the functions to work.

EDIT2:

Got past the previous error. Now a new one,

Running mem_commit
commit failed

It is a invalid argument error. I was getting a similar error when using the previous exploit. I think my gpu_addr is wrong, but I don't know how to fix it.

EDIT3:

So after trying multiple different exploits, they ALL fail when trying to run mem_commit. I feel like I am SO close, but can't get it working... Every time it fails with "Invalid Argument". The only 2 arguments are gpu_addr and pages. Since I have had issues in the past with gpu_addr, I think that is my issue. If anyone has any idea about this, help would be greatly appreciated (we really just need someone who has a lot of experience here...)!
[Fire HD 8 and HD 10 General] A Cool User:
For anyone wanting to help, I made a GitHub repo here for trona. This is based on GHSL-2023-005 instead of CVE-2022-38181 because CVE-2022-38181 is patched on 7.3.2.9.
[Fire HD 8 and HD 10 General] Azaze666:
Ahahah I'm happy I stopped updates on 7.3.2.7
[Fire HD 8 and HD 10 General] Androiduser2390:
I wish there could be a shortout a circut method so it does not get patched every update
[Fire HD 8 and HD 10 General] A Cool User:
That would indeed be very nice...
[Fire HD 8 and HD 10 General] Azaze666:
This is the shortcut, I already said this https://xdaforums.com/t/block-updates-dns-way-no-root-needed.4397079/

It works, I am connected to Internet and no updates show up and I'm on 7.3.2.7. Left a video "proof" of it as attachment
[Fire HD 8 and HD 10 General] Androiduser2390:
I ment a hardware exploit like the one on the HD 8 that could not be patched by an update, I have updates disabled on 7.3.2.9 via the limiting usage method and it works
[Fire HD 8 and HD 10 General] Azaze666:
There's no need for an hw method if sw method is working (like in my case)
[Fire HD 8 and HD 10 General] Azaze666:
Uhm, would you mind doing this or the old exploit but for fire hd8 2018? Because nobody was able to run the exploit on it still. That's why I'm asking. I will try this new repo but I think it will give me error as the other ones
[Fire HD 8 and HD 10 General] A Cool User:
This is a repo for trona, it wont work for the fire hd8 2018. I would try to get the exploit to work for the fire hd 8 2018, but I don't have the device (sorry)... Currently just interested in getting root on trona. If you do try GHSL-2023-005 on the hd 8 2018, you will have to make a few changes for the FHD8 2018's arm32 userspace.
[Fire HD 8 and HD 10 General] Androiduser2390:
It is patched on 7.3.2.9 and dm-verify does not allow custom recovery injection
[Fire HD 8 and HD 10 General] Azaze666:
I tried but as always it gives error on mmap command
[Fire HD 8 and HD 10 General] Azaze666:
I wasn't talking about custom recovery... About the dns method idk if it really does not work anymore on 7.3.2.9 but would be absurd, as to patch it amazon would have to block dns settings
[Fire HD 8 and HD 10 General] A Cool User:
@relalis Was having the same issue. See posts #44 and #16
[Fire HD 8 and HD 10 General] Azaze666:
Let's try post #44 suggestion "increasing FLUSH_REGION_SIZE"

Edit: I edited it from 500 to 1000 and then to 2000, I still get operation not permitted
[Fire HD 8 and HD 10 General] A Cool User:
Unfortunatly, I don't think that will work. In post #18, @Pro-me3us said this:

It is just because the driver is older. You are basing the exploit off raven, right?
[Fire HD 8 and HD 10 General] Azaze666:
Yes I do
[Fire HD 8 and HD 10 General] Azaze666:
guys, is there someone with a rooted fire hd8 2018? let's get the right values lol, dump /proc/sys/kernel directory and /proc/kallsyms
[Fire HD 8 and HD 10 General] A Cool User:
@SergeantFury
[Fire HD 8 and HD 10 General] Azaze666:
Well @SergeantFury flash firmware 7.3.2.7 and do https://xdaforums.com/t/potential-a...d-8th-12th-gen-affected.4574635/post-89392135 let's get my exact pool size and other stuff lol
[Fire HD 8 and HD 10 General] Michajin:
I have a unlocked karnak? anything i can send you? I should have time next weekend.... the bootrom is unlocked on mine, not sure if this helps where you are....
[Fire HD 8 and HD 10 General] Azaze666:
just flash 7.3.2.7 if you can and dump /proc/sys/kernel directory and /proc/kallsyms
[Fire HD 8 and HD 10 General] Azaze666:
Another vuln, but probably useless for us as it applies to new kernel versions but I'll share it anyway:https://github.blog/2024-03-18-gaining-kernel-code-execution-on-an-mte-enabled-pixel-8/
[Fire HD 8 and HD 10 General] A Cool User:
If only our kernel was v5.4 or newer... CVE-2024-1086 is a Linux kernel exploit just now found, that works on most Linux kernels...
[Fire HD 8 and HD 10 General] abram125689:
I tried this exploit on pixel 6a with following configuration :

Device : Pixel 6a

Andriod version : 14

Andriod Security update : October 2023

Kernel Version : 5.10.157

GPU : Mali-G78 , r43p0

but i am getting following error :

ioctl(KBASE_IOCTL_KCPU_QUEUE_CREATE): Inappropriate ioctl for device

please help me with this error??
[Fire HD 8 and HD 10 General] A Cool User:
This exploit is for the Pixel 8. Since it is a completely different GPU, it's going to have errors. I don't know to much about this exploit, so I can't really help...
[Fire HD 8 and HD 10 General] Androiduser2390:
Just unlock bootloader and install lineage recovery and sideload magisk
[Fire HD 8 and HD 10 General] bibikalka:
I have these 2 FireHD 10, 9th/maverick & 11th gen/trona. Both are on FireOS 7.3.1.9, I managed to freeze them at a good stage.

It seems the rooting process is a bit more understood now. How easily can I root these? What's the best practice nowdays?
[Fire HD 8 and HD 10 General] A Cool User:
Trona has not worked at all yet (has to do with gpu_addr I think). I think mtk-su might work on older HD10 9th gen's.
[Fire HD 8 and HD 10 General] Graysters:
Hey @A Cool User , appreciate your focus is on Trona at the moment, but did you ever try GHSL-2023-005 on Onyx running 7.3.2.9 (is the gpu_addr known for Onyx?)
[Fire HD 8 and HD 10 General] bibikalka:
I recall mtk-su only worked on 9th gen for version 7.3.1.1 - not later.
[Fire HD 8 and HD 10 General] A Cool User:
I don't have onyx, but could try porting it...
[Fire HD 8 and HD 10 General] A Cool User:
Amazon recently released a new 7.3.2.9 version I am looking at right now. The fingerprint is the same but with a different build number...
[Fire HD 8 and HD 10 General] Graysters:
That would be great if you could. I'd be happy to give it a try.
[Fire HD 8 and HD 10 General] Androiduser2390:
Lets hope that GHSL-2023-005 is not patched in the new build. (I think it has a march patch backported to Android 9)
[Fire HD 8 and HD 10 General] Jumbo100:
FYI

Amazon has released Fire OS 7.3.3.0 for OTA update :

FireOS 7.3.3.0 - Amazon Customer Service
[Fire HD 8 and HD 10 General] Graysters:
Hey @A Cool User , Did you manage to get any further with GHSL-2023-005 and Trona 7.3.2.9?

I've been having a play trying to adapt GHSL-2023-005 to work with Onyx on 7.3.2.9, but have got stuck trying to get jit_allocate to return a sensible address where it has allocated its JIT memory (jit_addr and jit_addr2).

As I understand it, the ioctl instruction in jit_allocate should result in the address of the start of the allocated JIT memory being written to the first address of the allocated GPU memory space, thanks to this line as part of the BASE_JD_REQ_SOFT_JIT_ALLOC

ioctl setup:

info.gpu_alloc_addr = gpu_alloc_addr;

However, despite the ioctl job succeeding (well, at least not returning a failure!), nothing appears to get written to, or updated at the gpu_alloc_addr address...

I have a strong hunch this is due to issues in converting the 64bit Pixel6 exploit to the 32bit address space on Onyx, or other pointer conversion fun and games. It could be that I'm not getting a sensible gpu_alloc_addr too, but the values there seem believable... (e.g. gpu_alloc_addr: f41a4000)

I don't suppose @Baiker000 or @Rortiz2 have had a look at GHSL-2023-005 on Onyx (or other 32bit userspace tablets) for us poor souls that got bumped up to 7.3.2.9?... Feels like it might be a race to get root and block updates before 7.3.3.0 drops (assuming the above exploit has been patched... can't see the source code for 7.3.3.0 anywhere yet to check...)

Cheers,

Graysters
[Fire HD 8 and HD 10 General] A Cool User:
No, unfortunately not... I haven't been working on it to much lately. I might take a look at it some time this week. As for the issues, I had the same ones on my Trona... The Trona is 64bit, so that makes me think converting to 32bit is not the issue... It is strange that the addresses look so believable though.
[Fire HD 8 and HD 10 General] Azaze666:
MediaTek Driver Privilege Escalation ≈ Packet Storm

Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers

packetstormsecurity.com

old but maybe compiling with that old same driver.... who knows

Edit, useless try
[Fire HD 8 and HD 10 General] A Cool User:
We could also try to get gpu_alloc_addr on onyx 7.3.2.7 if somebody still has a tablet on that version. Comparing that to 7.3.2.9 using GHSL-2023-005 gpu_alloc_addr, we could figure out if that looks like an issue.
[Fire HD 8 and HD 10 General] Azaze666:
Today i reached something.....

adb reboot bootloader

./brick-6312.sh

Brick preloader to continue via bootrom-exploit? (Type "YES" to continue)

YES

Bricking PL Header

Check instructions on device

target didn't report max-download-size

Sending 'brick' (111937 KB)...

FAILED (command write failed (Success))

Finished. Total time: 14.037s

or you can do ctrl+c in the meantime of the command, also after this cmd run the other one right away

sudo ./bootrom-step.sh

[2024-04-09 14:14:43.312628] Waiting for bootrom

[2024-04-09 14:15:43.616974] Found port = /dev/ttyACM0

[2024-04-09 14:15:43.655786] Handshake

Remember Fire Hd8 2018 7.3.2.7

files:https://xdaforums.com/t/unlock-root-twrp-unbrick-fire-hd-8-2018-karnak-amonet-3.3963496/
[Fire HD 8 and HD 10 General] A Cool User:
Did it complete successfully?
[Fire HD 8 and HD 10 General] Azaze666:
I'm trying, still brom on mtk is so vulnerable, I'm sure I can do something
[Fire HD 8 and HD 10 General] Azaze666:
Unfortunately I'm unable to do the handshake, I guess that is because brom is blocked... Really sad
[Fire HD 8 and HD 10 General] Graysters:
Might be interesting to check, but my understanding is that there isn't a 'correct' gpu_alloc_addr per se, as the gpu address that is returned by map_gpu is one that is allocated dynamically (or mapped) onto the virtual memory of the running process, as such it can change from run to run depending on where the memory manager decides to allocate it. I definitely see this as the gpu_alloc_addr I see changes from run to run.

Looking at differences between the old exploit: CVE_2022_38181 and the new one: GHSL-2023-005 I notice that in GHSL-2023-005 map_gpu gets called twice (once in main() and again in trigger()), whereas it is called only once in CVE_2022_3818 ... I wonder if that is having an impact in some way...
[Fire HD 8 and HD 10 General] Graysters:
OK, some progress... I'm now able to get different addresses allocated for the multiple calls of jit_allocate:

onyx:/ $ /data/local/tmp/mali_jit_32
fingerprint: Amazon/onyx/onyx:9/PS7329.3838N/0029294001664:user/amz-p,release-keys
done map_gpu fd2
done setup_mali
done jit_init
done map_gpu
gpu_alloc_addr: 100000000
gpu_alloc_region: 0xeb6e0000
jit_addr jit_addr2 100001000 100002000
commit failed
onyx:/ $

It was definitely something to do with the mmap stuff and how addresses are presented that I don't fully understand (hey, I'm a hardware guy, not a software guy! :cool:) I Expect the commit failed is due to similar issues in how the jit_addr's are passed to the subsequent stages...
[Fire HD 8 and HD 10 General] A Cool User:
Haha now you're where I got stuck... Hopefully you will get further then me!

Good Luck!
[Fire HD 8 and HD 10 General] lexscripta:
I have a tablet with that version. What do you need? And, how do I go about retrieving it?
[Fire HD 8 and HD 10 General] Azaze666:
Let's continue to repeat stuff over and over https://xdaforums.com/t/potential-a...d-8th-12th-gen-affected.4574635/post-89392139
[Fire HD 8 and HD 10 General] lexscripta:
Just tryin' to help.
[Fire HD 8 and HD 10 General] Azaze666:
It wasn't direct to you, if you follow the link I provided you will see what I meant
[Fire HD 8 and HD 10 General] Azaze666:
Instead of having the focus on the unlock commands like "mtk da seccfg unlock" would it be better to focus on the addresses that run these commands? A command should correspond to instructions in memory so perhaps if a command is no longer present because it has been removed by the manufacturer (Amazon in this case) perhaps would be better to find the address in memory that corresponded to the command and try to trigger it.

I think it could be an interesting idea but there are two problems, the command has been removed from the preloader in my current device, I could obviously see it in a device with an older preloader. I could also see if the memory address that the instruction corresponds to is still present despite the command being removed. Obliviously doing this wouldn't be easy, you would need another device that is the same model as the one you want to unlock and it's on an older firmware, also you would need a debugger and know how to use it, then you would probably have to unlock bootloader and with the debugger see these addresses what are. After all this write some program to trigger them from preloader. This is crazy but I think that is good to tell everything everyone thinks.

Another idea I thought could be to use the hw mod here:https://xdaforums.com/t/root-hardmod-root-your-amazon-fire-hd-8-7th-gen.3851617/ but on other models to get emmc rw on Linux and then you can for example push a world readable file on /data/local/tmp which would be something or do better, dump seccfg with dd and unlock it and write it back, or directly flash the files from the unlock methods for our tabs....

We can as well dump emmc from another tab that is same model as our one but has an old fw and flash it back to our (this to use mtk-su).
[Fire HD 8 and HD 10 General] A Cool User:
Maybe you could look at the preloader in Ghrida and check for BL unlock stuff... I don't believe Amazon uses seccfg though. The HW mod is a very interesting idea, and could maybe work. The hard part would be finding the right pins...
[Fire HD 8 and HD 10 General] Azaze666:
no need to:https://github.com/bkerler/mtkclient/issues/180#issuecomment-1958320979

this is new preloader actually..... we would have to look at the old one and have an old device with it
[Fire HD 8 and HD 10 General] Azaze666:
look at what? maybe i can downgrade
[Fire HD 8 and HD 10 General] Azaze666:
there is only one issue.... the tool i used tries to get me to brom... but well aside from this what i did means downgrading could be possible? i really don't know

edit:Btw I just tried today some stuff on the amazon tab, but I'm seeing that sp flashtool is unable to flash from preloader. I mean it detects the device on preloader but the flashing is on brom, it tries always to reboot the device to brom (and since it is disabled it gets to system), and mtkclient. My understanding is that preloader is for sending instructions to the device, and if these are missing (like on this Amazon one), the flash will fail. Sp flashtool probably tries something like "mtk da xflash preloader preloader.bin" or maybe before tries to flash a da to boot in brom because now that I think better everytime I flashed some mtk the first thing I saw is "downloading da" but this is an instruction for preloader and looking at what happened to my amazon tab maybe this instruction is to get in brom and then do the flash