yashsingh1/xdaforums huggingface dataset:
[Verizon Galaxy S 5 Android Development] Hariiiii:
It looks like the actual writing process doesn't require an modules though....right? From what I see the actual writing is done by a simple assignment. If that's the case then we just need an address for the virtual kernel memory location (which won't be the same as the physical address). An entire map of kernel memory addresses can be found in /proc/kallsyms if /proc/sys/kernel/kptr_restrict is set to 0 using root. By finding the start address of our target function, and knowing the location of the patch within the function, can't we then deduce the target address and patch it with a value assignment?

Disclaimer: I may be totally wrong about this
[Verizon Galaxy S 5 Android Development] klabit87:
The way I read it, he compiled a module so that he could read/write to memory. Which would imply that his kernel allowed module loading.

[MENTION=5414005]GeTex[/MENTION] says she has written to memory.

Since she has done it before then I don't see a reason to continue.

I guess we just wait until she comes back online to explain how and what she did.

I just don't see a need in wasting time and effort right now. Unless something doesn't cooperate the way her method works.

I feel that the way she has done it will work though.
[Verizon Galaxy S 5 Android Development] GeTex:
I'm on mobile and writing alot of text is hard.I'll make it brief, I am NOT sure i've successfully written but the method being used involves the futex vulnerability, but everytime i attempt a write, i got a kernel panic. Alot of the work isn't mine, it's older work re-purposed by my close friend cause I'll be honest, I'm partially clueless about how all this works, I'm trying to follow. All Angel told me was I'm likly writing where i shouldn't be.

please continue trying to research, If i can figure out what SHE did, and I can explain it, I will do it ASAP. I'm waiting on alot of thing right now.
[Verizon Galaxy S 5 Android Development] autonomousperson:
OP updated, tag me if something happens so I can update OP.
[Verizon Galaxy S 5 Android Development] GeTex:
OK

Update I am NOT writing to memory, apperantly I'm just causing a kernel panic because of some address violation. So I'm doing it wrong... Damnit. I should really do more research. Sorry everyone was waiting on me :(

---------- Post added at 10:13 PM ---------- Previous post was at 10:11 PM ----------

@klabit87 [MENTION=7017329]Hariiiii[/MENTION] I think you two have a waaaaaaay better handle on this then me, I'm gonna try and follow along! Let me know if I can help at all, especially testing
[Verizon Galaxy S 5 Android Development] Hariiiii:
Ok, so it looks like some research will be necessary after all. You were right about the code that I posted before, it looks like he was trying to access the kernel memory from a kernel module that he wrote. Based of what I currently understand, it appears that, short of using the Futex vulnerability, there is a small possibility that we may still be able to modify the memory we are looking for. The mmap() function is available in the kernel, which can be used to make a section of kernel memory available to user space. There is some small chance that with root privileges, that we can mmap() the appropriate section of memory with r/w permissions, write to it, and then unmap it.
[Verizon Galaxy S 5 Android Development] MarrubiOGraficz:
vulnerabiliti QuadRooter

vulnerabiliti QuadRooter you s5 g900v
[Verizon Galaxy S 5 Android Development] AdmiralKirk:
So far as I can tell, QuadRooter is just a privilege escalation vulnerability much like TowelRoot. It, unfortunately, is no help in gaining control over the bootloader of Toshiba eMMC devices.
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
http://androidvulnerabilities.org/by/manufacturer/all

This seems to be a usefull website

the one class to rule them all exploit sounds promising

I don't know if the s5 is affected by this vulnerability or not or even if it useful but just in case it is here you go

This is the vendor security message from google

https://groups.google.com/forum/message/raw?msg=android-security-updates/Ugvu3fi6RQM/yzJvoTVrIQAJ

This issue is rated as a Critical severity due to the possibility of remote= =20 code execution as the privileged mediaserver service. While mediaserver is= =20 guarded with SELinux, it does have access to audio and video streams as=20 well as access to privileged kernel driver device nodes on many devices=20 that 3rd party apps cannot normally access. Remote exploitation on Android versions 4.1 (Jelly Bean) and higher is=20 mitigated by enhancements in the Address Space Layout Randomization (ASLR)= =20 algorithm used in those versions. To reduce risk related to this issue, Google has updated the Hangouts and= =20 Messenger applications so that media is not automatically passed to=20 mediaserver process.=20

So have old apps Hangouts and messenger

application installed

and I don't know how to do the rest just trying to help

Here is the fix if I'm not mistaken

https://android.googlesource.com/pl...pt/+/edf7055461e2d7fa18de5196dca80896a56e3540

OpenSSLX509Certificate: mark mContext as transient Since mContext should not participate in the serialization process, hide it with the transient qualifier. This will prevent the field from initialization during the unserialization of this class. Then of course the instance will be in a valid state.

What is this file I just found way to put malicious files on phone =)

ZpenSSLX509Certificate.java

blob: ea3870ac8a3607ff57f4cfe2bc97fec128379c30 [file] [log] [blame]

/* * Copyright 2015 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */package org.conscrypt;import java.io.Serializable;

/** * This is a fake class to test de-serialization with malicious payloads. */public class ZpenSSLX509Certificate implements Serializable { /** This will be set via reflection in the test. */ private static final long serialVersionUID = 0L; public final long mContext; ZpenSSLX509Certificate(long ctx) { mContext = ctx; }}
[Verizon Galaxy S 5 Android Development] GeTex:
None of those exploits help in writing to the protected Kernel memory space of 5.0+
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
This exploit seems useful it says write to kernel memory right in it

http://www.clevcode.org/cve-2014-3153-exploit/

"I changed my exploit to target the addr_limit value in the thread_info structure instead. This allows me to enable one of my threads to read/write arbitrary kernel memory, and provide root-access for me (and optionally disable other kernel-based protection mechanisms, such as SELinux) without having to executing any code in kernel context."

---------- Post added at 08:11 AM ---------- Previous post was at 07:46 AM ----------

It is possible to boot into ncg firmware on a pb1 bootloader

S5 verizon Bootloader locked s5 phone using brens123 I booted ncg on pb1 bootloader thread on xda under general s5 verizon forum

from there you can towelroot and achieve root for the 4.4.2 KitKat you have installed I did it myself to get around the reactivation lock stuck on issue.

check his thread out please.

so possibly the exploit above will also work with Brens guide just a huge shot in the dark I don't own a 11 Toshiba emmc s5 verizon so I can't test it but someone else could

Brens guide uses flashfire which works on locked bootloaders and only requires root which Toshiba emmc phones can get on lollipop using ok3 root

so yeah I hope this helps you out
[Verizon Galaxy S 5 Android Development] GeTex:
I'm near 100% Sure that doesn't work, it's near similar to what i tried, all it does is trigger a kernel panic and the device kills
[Verizon Galaxy S 5 Android Development] Legitsu:
its cmd27 ? its in the doc its just that most of the cells that make up the CID are Read only or write once read only

page 128
[Verizon Galaxy S 5 Android Development] autonomousperson:
cmd26, but do you have any idea what that means or how to do it? Because I dont. Toshiba also has secure write protection. That would prob mess with some stuff too. Secure write protection should be in the specification. Ill try looking it up.
[Verizon Galaxy S 5 Android Development] Legitsu:
cmd26 is factory programmable only according to the jdec spec

CMD26 adtc [31:0] stuff bits R1 PROGRAM_CID Programming of the Device identification register. This

command shall be issued only once. The Device

contains hardware to prevent this operation after the

first programming. Normally this command is reserved

for the manufacturer.

if I understand [MENTION=711482]beaups[/MENTION] release correctly violation of that part of the spec was the reason it was possible to change the CID at all,according to JDEC the CID is write-once only
[Verizon Galaxy S 5 Android Development] autonomousperson:
beaups said he used cmd62 (pretty sure he means 26) and he did this with a vendor backdoor
[Verizon Galaxy S 5 Android Development] Legitsu:
secure write protection has nothing todo with low level EMMC registers its for user-space stuff .

command query might be interesting to look at but I doubt there is anything their
[Verizon Galaxy S 5 Android Development] FilthyFord:
I have a GS5 with an 11 eMMC as my backup. If we make good progress here i would be half a$$ willing to use it as a guine pig. I don't know all the talk and programs u guys use but with a little guidance i might could figure it out. Although it is an AT&T branded phone. My daily driver is a GS5 T mobile branded running Pheonix.
[Verizon Galaxy S 5 Android Development] GeTex:
it's worth a shot

I also 0/10 do not recommend removing an eMMC with a lighter and thermocouple

So i can't Dump it via my riff box? I should be able to force it but again needs vendor commands to do so i assume, which one of us needs to figure out

</3 My Uncle works for Toshiba but only in sales, maybe I can get a engineer or someone through him?
[Verizon Galaxy S 5 Android Development] autonomousperson:
Im sure he cant just release the firmware and vendor codes without getting in trouble can he? I did send an email just for the heck of it asking for a firmware dump (like thats going to happen). And hey the BGA came off!
[Verizon Galaxy S 5 Android Development] autonomousperson:
Also im not 100% sure about jtag but I know that eMMC's normally cant be jtaged, it would have to be through the cpu which very likely has jtag points somewhere. Ive never done any of this jtag stuff. Did some google searches but couldnt come up with anything 100%.
[Verizon Galaxy S 5 Android Development] Legitsu:
did you seriously take a lighter to your logic board ?
[Verizon Galaxy S 5 Android Development] autonomousperson:
Also I know we can somehow mount these chips as sd cards and working with them from there but that would involve taking them off the board and thats a nono.
[Verizon Galaxy S 5 Android Development] autonomousperson:
It was a waterdamaged dead board. Mostly just for the lulz, the chip is now my profile avatar. Didnt come out too bad (did rip some traces off the pcb)
[Verizon Galaxy S 5 Android Development] Legitsu:
you can remove them with the right tools

you need a decent hot air rework station and lots of flux

its not really hard putting them back on ... now thats the *****
[Verizon Galaxy S 5 Android Development] autonomousperson:
Yeah ik they are easy to take off and hard to put back on. We would still need to know how to read stuff off of it. To me it seems the ONLY way to do this with a toshiba chip is the vendor code or the CMD## things. Either way involves getting the binary and knowing the arguments.
[Verizon Galaxy S 5 Android Development] Legitsu:
just need a scope and a steady hand

the big thing is to make sure you pull it strait up and out when removing so you don't smear the bga and leave your self a shot and reworking it on their
[Verizon Galaxy S 5 Android Development] autonomousperson:
I think id rather crack vzw's signing key xD
[Verizon Galaxy S 5 Android Development] GeTex:
LOL

TIme for brute forcing?

Can we use my super computer made of all Athlon XP's :D
[Verizon Galaxy S 5 Android Development] autonomousperson:
Was jk about brute forcing.
[Verizon Galaxy S 5 Android Development] Legitsu:
no its time to stop chasing bootloader unlocks and work on kexec ...
[Verizon Galaxy S 5 Android Development] GeTex:
why? Chances are the S5 hardware isn't viable for that
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
Oh well nvm then thought I had something thanks for your hard work

---------- Post added at 07:36 AM ---------- Previous post was at 07:33 AM ----------

---------- Post added at 09:10 AM ---------- Previous post was at 08:36 AM ----------

Search Google for CVE-2014-3153 Exploit this is the name of the exploit on clevcode

https://gist.github.com/fi01/a838dea63323c7c003cd

I think this is the source for ghetto root line above my actually not 100% sure though

this might help

Idk for sure

This guy has a forum on xda where he fixed and ported original clevcode from github.com to note 2 so just maybe the fix will be there you are looking for

http://xdaforums.com/note-2-verizon/general/root-adb-ghettoroot-v0-1-towelroot-port-t2864125

---------- Post added at 09:56 AM ---------- Previous post was at 09:10 AM ----------

If your feeling up to it there are 6 different people on github.com who have a page for CVE-2014-3153 Exploit some are ports so may be useless
[Verizon Galaxy S 5 Android Development] AdmiralKirk:
That is the Futex vulnerability discussed earlier in this thread, aka: TowelRoot. It is a distinct possibility for access to the kernel memory, however no one with sufficient C/Linux/Android experience currently has the time to investigate. Also, so far as the Kernel Panic issue. I know what caused that, assuming you were making use of the Futex vulnerability to accomplish the write. Because of the modifications made to the waiter_list, when the thread which makes the writes ends, it causes the kernel to panic. The only ways around this are to never end the thread until you are completely done everything you need to do (this is what TowelRoot does), or you would need to repair the waiter_list when you were done. The former would depend on how kexec works (if the old kernel is removed from memory once the new one is started than we can just keep the thread open until the old kernel is flushed). From what I have read of kexec, this might actually be possible. Repair of the waiter_list however would require a fair bit of code and I have not found any examples of anyone else attempting it.
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
What I was doing was I thought ghetto root might have worked differently from the original towelroot exploit and that by evaluating it's source code a solution would be found

but it's good chance it is just a straight port maybe it's not if you could look into it all this shows is I'm in over my head thanks for reminding me of that.

well keep up the hard work everyone

Humbly this is my understanding clevcode website was trying to write to kernel memory then it was never a working permission escalation method towel root worked

so a different method I think but based on towelroot you are correct

look at the comment on github.com yes it causes a kernel panic

but a developer on xda did a port called ghetto root that works

this is the current status of towelroot code

"geohot for developing towelroot, on which

this code is DIRECTLY based! Reverse-engineered/decompiled, but not by me.

I don't think anyone had a licensing claim on towelroot or this code so I made it GPLv3.

fi01 for his shared exploit code on github." from ghetto root forum

maybe this is the problem that I thought he modified the code but as to fix the clevcode attempt but it might just be a straight port of towelroot as I said earlier I will try to evaluate the source code of ghetto root and towelroot see how similar they are I will come back to you on that

Thanks for your hard work
[Verizon Galaxy S 5 Android Development] GeTex:
I'll check her code later, but I thought we had the thread stay open idle, but as far as I recall, doing this on 5.0+ still triggered a panic, but I think the panic occurred during the actual write operation(I very well may be writing to the wrong spot) but Her work is hard to follow and I don't want to post it exactly, especially since its hers. What I do understand is that it looks like the write is very possible, but we need to do it using the NK2 kernel or older, just like our current root exploit. We need to look into this more(it does break charging animations BTW, freezing the device)

I may just be misunderstanding this all, but a few others in our thread working on this may have a better grip in which I believe we have a good chance at this. Our biggest issue is stopping kexec from dying when the old kernel is killed

[MENTION=4411996]Hariiii[/MENTION] you hear me?
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
Sorry to emphasize I just wanted to let you know sorry to be annoying

IT IS POSSIBLE to BOOT into ncg KITKAT FIRMWARE on a PB1 BOOTLOADER

S5 verizon Bootloader locked s5 phone using brens123 I booted ncg on pb1 bootloader thread on xda under the general s5 verizon forum

http://xdaforums.com/verizon-galaxy-s5/general/booted-ncg-pb1-bootloader-t3431692/page1

from there YOU CAN USE TOWELROOT AND ACHIEVE ROOT for the 4.4.2 KitKat you have installed I did it myself it works so if it's possible to use the towelroot exploit on a pb1 bootloader what else is possible???
[Verizon Galaxy S 5 Android Development] GeTex:
I'm not sure this would work for what we need. As far as I'm aware it's a no but, others here should have a better understanding. The Futex vulnerability could be used, but as far as I understand it's not entirely what we want.
[Verizon Galaxy S 5 Android Development] Hariiiii:
My name has 5 i's ;)

I'll give you an update on where we are at. We have the physical address of the target location for the patch, but we need some way to convert that to a virtual address. Right now the prudent thing to do would be to just run a test with mmap and see if we can even map the kernel code area of the kernel at all (and write to it maybe). I borrowed some sample code for mmap and all that needs to be done is to change a few variables, most notably the first variable of mmap to the target address. I don't know C and I'm not exactly sure how to figure it out myself. If we can complete the code and then compile it and try running it with root, we can probably get an idea about where we stand with the method. This is the target physical address (which we can also use as a test because it will almost definitely still point to virtual kernel code memory): 0x001E15F4

Here is the code:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>

#define FILEPATH "/tmp/mmapped.bin"
#define NUMINTS (10)
#define FILESIZE (NUMINTS * sizeof(int))

int main(int argc, char *argv[])
{
int i;
int fd;
int result;
int *map; /* mmapped array of int's */

/* Open a file for writing.
* - Creating the file if it doesn't exist.
* - Truncating it to 0 size if it already exists. (not really needed)
*
* Note: "O_WRONLY" mode is not sufficient when mmaping.
*/
fd = open(FILEPATH, O_RDWR | O_CREAT | O_TRUNC, (mode_t)0600);
if (fd == -1) {
perror("Error opening file for writing");
exit(EXIT_FAILURE);
}

/* Stretch the file size to the size of the (mmapped) array of ints
*/
result = lseek(fd, FILESIZE-1, SEEK_SET);
if (result == -1) {
close(fd);
perror("Error calling lseek() to 'stretch' the file");
exit(EXIT_FAILURE);
}

/* Something needs to be written at the end of the file to
* have the file actually have the new size.
* Just writing an empty string at the current file position will do.
*
* Note:
* - The current position in the file is at the end of the stretched
* file due to the call to lseek().
* - An empty string is actually a single '\0' character, so a zero-byte
* will be written at the last byte of the file.
*/
result = write(fd, "", 1);
if (result != 1) {
close(fd);
perror("Error writing last byte of the file");
exit(EXIT_FAILURE);
}

/* Now the file is ready to be mmapped.
*/
map = (int*)mmap(0, FILESIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0);
if (map == MAP_FAILED) {
close(fd);
perror("Error mmapping the file");
exit(EXIT_FAILURE);
}

/* Now write int's to the file as if it were memory (an array of ints).
*/
for (i = 1; i <=NUMINTS; ++i) {
map[i] = 2 * i;
}

/* Don't forget to free the mmapped memory
*/
if (munmap(map, FILESIZE) == -1) {
perror("Error un-mmapping the file");
/* Decide here whether to close(fd) and exit() or not. Depends... */
}

/* Un-mmaping doesn't close the file, so we still need to do that.
*/
close(fd);
return 0;
}
[Verizon Galaxy S 5 Android Development] klabit87:
Things have been extremely busy for me.

Work is hectic at this time of year but in a few weeks things should get back to normal.

This has proven a little more difficult than I initially thought it would be but I still believe it to be possible.

My question is though, would it be used?

Would our time spent on this be wasted?

I don't know but I plan to complete it. Hopefully somebody other than myself and [MENTION=7017329]Hariiiii[/MENTION] will jump in.

This has been known for quite some time.

It's funny that I was scrutinized by others in another thread when I mentioned it.

Now you have a second confirmed case.

I checked the source of each and every kernel and none of them have the /dev/mem device enabled in the defconfigs.

So no, going to another kernel version would not be any benefit to us as of now.

Also towelroot doesn't exploit the bootloader at all.

It exploits the kernel.

---------- Post added at 02:12 PM ---------- Previous post was at 02:02 PM ----------

I would like to try this again even if it does cause a kernel panic.

I just received all of my parts to build my uart cable minus the resistors which I can get locally.

So I would like to log exactly what is happening and maybe we can figure out what is happening.

Possibly a touchy address location? There are thousands of locations that shouldn't be touched.

I would also like to run it against my address that I have provided [MENTION=7017329]Hariiiii[/MENTION] in the post above.

Which address did you try to write to and with what intention?
[Verizon Galaxy S 5 Android Development] GeoHogan:
Let's say I was able to get into contact with Samsung what exactly is it that we need from them? Is it going to be the args?
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
You are right towelroot exploits the kernel not bootloader sorry about that
[Verizon Galaxy S 5 Android Development] klabit87:
Doing so would be requesting them to compromise security.

Might as well just request a bootloader unlock it you have a good enough contact.

But even that would be next to impossible
[Verizon Galaxy S 5 Android Development] tsew2674:
There are a lot of people watching this thread with high hopes. Most haven't said anything BC we have nothing useful to contribute, but in light of your question, the answer is yes, many people would use and be appreciative of your work. Thanks and good luck!
[Verizon Galaxy S 5 Android Development] hauckk@sfreserves.org:
[/COLOR]
[Verizon Galaxy S 5 Android Development] klabit87:
That question would be best answered by [MENTION=5414005]GeTex[/MENTION]

Since I don't have an s5 with a Toshiba emmc, I can't confirm.

My s5 has a Samsung emmc.

---------- Post added at 03:37 AM ---------- Previous post was at 03:34 AM ----------

Thanks! I have no way of knowing so I was just wondering.