yashsingh1/xdaforums huggingface dataset:
[Galaxy Note 4 Developer Discussion (Devs., Only)] stvn1337:
Okay I decided to try to invoke the android terminal intent to open a new terminal window as a system user. it doesn't work for me but other people on preOTA may be able to get it to work. I disabled the factory reset crap so don't worry about accidently factory resetting your device (like I did to my tablet before I disabled them). You will need to install the android terminal emulator app from the play store prior to opening this app and clicking the button. if you get a terminal window open type whoami and post a screenshot please. If not a simple post saying it doesn't work is fine.
[Galaxy Note 4 Developer Discussion (Devs., Only)] munjeni:
This one looking good https://android.googlesource.com/pl...5d3e74ecc2b973941d8adbe40c6b23094b5abb7^!/#F0

You can decompile settings.apk and search in src/com/android/settings/accounts/AddAccountSettings.smali to see if it is patched or not.
[Galaxy Note 4 Developer Discussion (Devs., Only)] jpfulton248:
Hey I know it's already been stated but I wanted to confirm for myself. Confirmed... The string "checkAndGetTcObjectClass" exists in system.img.ext4 from NI1 that i pulled off of sammobile.com http://www.sammobile.com/firmwares/download/38838/N910VVRU1ANI1_N910VVZW1ANI1_VZW.zip/. Screenshot below.

View attachment 3138502
[Galaxy Note 4 Developer Discussion (Devs., Only)] munjeni:
Hi, I have implemented terminal emulator internaly into CVE-2014-8609.apk but from some unknown reasons it fail to start when I press "open terminal" button, I have spent 2 hours with this and I am lazy to debug more, sorry, try to decompile mine apk and fix it! Interesting thing I can start internal terminal emulator by command: "am start -n com.example.android.samplesync/jackpal.androidterm.Term", but clicking on button it no want to start :(
[Galaxy Note 4 Developer Discussion (Devs., Only)] stvn1337:
I don't understand it. I'm passing the intent the same way the sms intent and format interested t is passed back to the pending intent. It's just not working. I'm trying to make a service to hand it off to withing the app so that once it's intent is hit I can keep it alive in the background service, and then pull it back into the foreground to use it. In theory this should work even though the originating pending intent is killed shortly after the button press.
[Galaxy Note 4 Developer Discussion (Devs., Only)] munjeni:
Yes strange, when I click on "open terminal" it open settings, another clicks doing nothing until I kill app and lunch again, strange. Maybe we need to look into terminal emulator for this? I have no time now, but you can try to open another app?

It open com.google.android.c2dm.intent sucesfully but no terminal emulator, I don't know why.
[Galaxy Note 4 Developer Discussion (Devs., Only)] stvn1337:
Your correct, I wonder if terminal emulator has been patched to prevent the broadAnywhere bug from launching it? If so then we need to find another terminal emulator that allows broadAnywhere to launch it with intents. Unless someone has time to search the terminal emulators source to figure out how it's been patched to prevent it..
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Yeah that was covered 50+ pages ago. That's the kernel side of it, we know that will work but first we have to get through the Android side first. That's what 1474 should do for us.

[MENTION=6429728]soupmeister[/MENTION] Yes. This is the best place.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
I would be curious about this also, but only after root is out for pre-Lollipop. The description says through 5.0, which sounds to me like 5.0 is vulnerable but who knows if 5.0.1 or 5.0.2 is. Also Samsung, as we've seen recently with the root that works on other phones using those two CVEs not working on our phones, will backport fixes. I don't know how much Samsung is still tweaking their Lollipop update, but since this seems like a small fix, my money would be on it being fixed in the Samsung Lollipop update.

Btw I've been trying to upload the contents of system.img.ext4 from the AT&T and Verizon tar md5 files to Google Drive for easy reference but it keeps timing out and I don't want to post something missing random files. I'll try with a specialized uploader tool later.

Also CVE-2015-1474 was updated on the 17th to say that it's network exploitable(!) and I guess they gave it a 10.0 score, the highest! This seems to be more serious than that last "worst android bug ever" recently used for root in the last year.

I sure hope whatever tool that gives root that comes out also applies a fix for this. I wouldn't want to walk around with it if I could help it.
[Galaxy Note 4 Developer Discussion (Devs., Only)] Surge1223:
So after a bunch of useless posts basically asking to confirm this or thanking that..at least we can count on qcom to brighten our day...

https://www.codeaurora.org/projects...le-camera-drivers-cve-2014-4321-cve-2014-4324

Qcom camera FTW
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Just a little further reading for some:

http://www.cvedetails.com/cve/CVE-2015-1474/
[Galaxy Note 4 Developer Discussion (Devs., Only)] jasonstackhouse:
Correct me if I am wrong but camera group should actually be rather easy to take advantage of especially in modern Android. In June this last year the play store rolled out an update that groups all applications for security permissions, so in theory, any app in this group can be used to exploit the vulnerability found. Which means all apps that take picture or record audio are on the table as they are all lumped in together with the camera group.

Basic example of what apps like this can do now that they are grouped.

Camera/Microphone: An app that has permission to take pictures and videos (for example, a camera app) can now gain the permission to record audio. The app could listen to you when you use other apps or when your device’s screen is off.

If this is true than someone much smarter than me should have a lot to fool around with.
[Galaxy Note 4 Developer Discussion (Devs., Only)] jcase:
Ok I will. These "permission groups" from the play store have nothing to do with this. We are talking about a single android permission (android.permission.CAMERA) and a single linux group ("camera').

In 5.0, and many 4.x devices (i dont think it was all, it might have been all, i just dont care to find my notes, 10hr trip to take son to Dr and back, just got home and freaking tired) the linux group "camera" used in android was severed from the camera permission, declaring this permission does not put your user (app) into the camera group.

Simple test,

adb shell grep -A 10 -B 10 camera /system/etc/permissions/platform.xml

On blackphone (4.4.x), HTC Desire 510 (4.4.x) MotoX 2014 (5.0.x), the above command returned nothing.

One older devices, say 4.2.2 you would get teh following as the output:

<permission name="android.permission.CAMERA" >

<group gid="camera" />

</permission>

This means apps that are granded the permission, are put into the group "camera".

See:

https://android.googlesource.com/platform/frameworks/base/+/android-4.2.2_r1/data/etc/platform.xml

vs

https://android.googlesource.com/platform/frameworks/base/+/android-4.4.2_r1/data/etc/platform.xml

What does this mean? You cant directly talk to what you need to to exploit those camera vulns, you would need to exploit mediaserver, or escalate to system first (Which means squat, if you are system you have 100 ways to root that are easier than these camera bugs). Also must not forget about SEAndroid, might put a snag into it as well, but like ive said I just saw these today, and have been home for a whole 10minutes so far today.
[Galaxy Note 4 Developer Discussion (Devs., Only)] Root-Maniac:
Same here, AT&T NIE

C:\Users\rac1\Desktop\ADB>adb shell grep -A 10 -B 10 camera /system/etc/permissi

ons/platform.xml

<permission name="android.permission.SYSTEM_GROUP_INTERNAL" >

<group gid="system" />

</permission>

<permission name="android.permission.INTERNET" >

<group gid="inet" />

</permission>

<permission name="com.sec.android.permission.CAMERA" >

<group gid="camera" />

</permission>

<permission name="android.permission.READ_LOGS" >

<group gid="log" />

</permission>

<permission name="android.permission.READ_EXTERNAL_STORAGE" >

<group gid="sdcard_r" />

</permission>

--

<group gid="graphics" />

</permission>

<!-- Except for SysScope, DO NOT USE this permission. -->

<permission name="com.sec.android.app.sysscope.permission.ACCESS_SYSTEM_INFO

_SYSSCOPE_ONLY" >

<group gid="radio" />

</permission>

<!-- Group that can use gscaler -->

<permission name="com.sec.android.permission.USE_CAMERA" >

<group gid="camera" />

</permission>

<!-- ================================================================== -->

<!-- ================================================================== -->

<!-- ================================================================== -->

<!-- The following tags are assigning high-level permissions to specific

user IDs. These are used to allow specific core system users to

perform the given operations with the higher-level framework. For

example, we give a wide variety of permissions to the shell user
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
OK let's not forget about cve-2015-1474. This is the vulnerability that's going to get us what we want. Let's not get sidetracked about another vulnerability that we may not even need.
[Galaxy Note 4 Developer Discussion (Devs., Only)] KennyG123:
Please take any further questions to your respective device root threads.

Thanks

FNSM
[Galaxy Note 4 Developer Discussion (Devs., Only)] Venom0642:
For those out there that are not Developers , Please make sure to not use Kingroot if your not even sure what your doing Especially if your on Lollipop , I would wait till Developers can get some solution for Lollipop Since it's working in some part of KitKat , i post this here for those watching this thread, we do not want to hear you bricked your phone etc etc, since we don't have 100% Root Just a !!WARNING!!
[Galaxy Note 4 Developer Discussion (Devs., Only)] Tomsgt:
Just tested KingRoot on build NJ5 Kitkat and i have root access just an FYI

Here is the apk for KingRoot kingroot_4.0.0.apk FYI it is in Chinese. Just fit the blue button and it will install kingroots superuser app and another app along with give you root. Root is only temp at this point meaning that after a reboot it will be gone. you can run the kingroot app again to get root back. We are working on getting supersu install and running instead of kingroot app. so at this point i would wait for the developers to post a better method. :)
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
[N910V] Lollipop + ROOT + MultiSystem + FlashFire

It's too late here, but I've to tell you that VZW Note 4 (N910V) gets a permanently-ROOTED Lollipop ROM with a newer version of MultiSystem (v1.3.1 + simple one-click installation) & for sure, the powerful FlashFire tool. Now, one or two testers (

devs only

) are needed, b/c I did all tests on my

UNROOTED

DevEd.

ATT Note 4 (N910A) Users: you're next in line!

Thanks to: [MENTION=3178012]gatesjunior[/MENTION] , [MENTION=4246643]Tomsgt[/MENTION] & everyone else for the heads up about kingroot; it'll be used only fot the 1st step before being replaced with SuperSU.
[Galaxy Note 4 Developer Discussion (Devs., Only)] KennyG123:
Thread closed since no one can read and root was achieved

Post in your root threads in your device forums

If any developer has anything to add to this thread contact me

Thanks

FNSM
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Yes, there are some of us still trying to build an exploit for this vulnerability in the libui. So lets not give up hope or get impatient please..
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Great stuff ZPaul2Fresh8.

I haven't done exploits before so those more experienced please forgive me. From the NVD description to use the CVE-2015-1474 (GraphicBuffer) exploit you write some program that creates a lot of file descriptors or integer values. So in my totally-inexperienced view, that maybe could mean either opening a lot of files (might be able to open one file multiple times) or just assigning lots of integer variables. The code diff says "Fix for corruption when numFds or numInts is too large."

Python (not using list comprehension) to assign a huge amount of integer variables:

ints = {}
for number in xrange(2**62):
ints[number] = 1

So somehow using the libui.so or the native graphics framework to make numFds or numInts overflow and trigger a crash I think would be a good first step.

Since we don't have poc code for 1474, we can work off of https://github.com/retme7/CVE-2014-4322_poc and https://github.com/retme7/CVE-2014-7911_poc and maybe some of the fine work done by [MENTION=3975929]zxz0O0[/MENTION] and [MENTION=3669069]idler1984[/MENTION]. Also previous buffer/integer overflow Android exploits may help us, especially if they come with poc code.

Some searching let me to these:

http://securityintelligence.com/and...s-are-always-larger-than-needed/#.VOfVq9_Hnm0

https://nakedsecurity.sophos.com/20...googles-keystore-security-module-for-android/

https://wiki.mozilla.org/Security/B2G/RootingTools (mentions diag_exploit CVE-2012-4221)

Searches:

https://www.google.com/#q=how+to+android+buffer+overflow

https://www.google.com/#q=integer+overflow+android+exploit

https://www.google.com/search?q=CVE-2012-4221

Maybe Metasploit could help us. If they have a module for another overflow, we could maybe use a lot of what they've already done.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
So this seems good: http://www.cse.scu.edu/~tschwarz/coen152_05/Lectures/BufferOverflow.html

(I'm hoping that the "numFds" or "numInts" being "too large" are buffer overflows. Googling "integer overflow" makes it seem that way.)

Conceptually I get the part where you leave the expected boundary of your memory space/area/whatever but then running your own code I'm still not sure (running "bar" in that link's example). Somehow need to get it to run a "give me SYSTEM level".

On that note also, on Linux say to change user you can use "su", so something that changes the capability/access/privileges (not sure what the correct term is) to SYSTEM also needs to be found.

Puzzling over those two things. Someone with even basic Android and Java experience would be so far ahead of me haha.
[Galaxy Note 4 Developer Discussion (Devs., Only)] zxz0O0:
Basically you need to make a privileged process / service (e.g. surfaceflinger maybe?) to call this function with evil values. You could then for example trigger a heap buffer overflow.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Oh of course! Right, use the privileges of an existing process, that makes sense. Hrm I'm trying to google up which processes are privileged now.

Not asking you zxz0O0 directly, but thinking out loud, to get one's own code to execute means either getting your code to a memory location where it will be executed, or getting a 'JMP' of sorts to execute to move execution to where your code is in memory. Would writing your object code into the heap cause it to be magically executed?
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
I was thinking more along the lines of android.graphics.drawable.VectorDrawable as the preliminary CVE says the overflow happens when exceeding the (int) expectation caused by vectors. By looking at the original code we see the lines

const size_t numFds = buf[8]; //Allocation of the file descriptors?
const size_t numInts = buf[9];[/code //Allocation of the number of vectors?

I've made a few APKs but I'm no expert, but I'm going to be starting another today that deals with Vector drawables. I'll be using my device for debugging. If successful with recreating the overflow I'd imagine the next step would be to arc inject or ret to libc depending on how much memory is available. I'm assuming you have some idea how this works [MENTION=3975929]zxz0O0[/MENTION] since you've done this with the qseecom exploit, correct?

Also, why do you think heap instead of stack?
[Galaxy Note 4 Developer Discussion (Devs., Only)] lamarwallace:


These are the 2 vulnerability I get when I run this app. I'm on at&t Galaxy Note edge n915a 4.4.4
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Strangely enough it says my device is vulnerable too. Which I've proven is not true since we found checkAndGetTcObjectClass in our Core.odex library. I'm going to email the developer of this app to find out more.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Hm doesn't seem to check for CVE-2014-4322 which would be good info to know. Since if the tool Note 4 users end up with uses CVE-2014-4322 and CVE-2015-1474, then to get root other devices need to be vulnerable to CVE-2014-4322 also.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
We've already proven 4322 is good to go. We just need a way to deploy the exploit for 2015-1474 so we can use 4322...
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Right, sorry, I don't mean to cause confusion. 4322 and 1474 are definitely confirmed on the AT&T Note 4 (SM-N910A) and Verizon Note 4 non-dev (SM-910V) but users of other devices watch this thread since it's the most active. For other devices to use the root that we end up using, they need to be.

Btw, found this: https://android.googlesource.com/pl...6bf5f58dbd9486bbc9/docs/text/NDK-DEPENDS.text

From this: https://stackoverflow.com/questions/15534104/ldd-equivalent-on-android

And I guess I'll try to go through that list of processes running as the "system" user to see if any uses libui.so
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
SurfaceFlinger is defintely our resource we're targeting. It has System UID. It also manages buffer allocation.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Oh ok, great! Ok then, seems like you're ahead of me heh. "android.graphics.drawable.VectorDrawable" like you said is in the right direction.

"All of the visible surfaces rendered are composited onto the display by SurfaceFlinger." says https://source.android.com/devices/graphics/index.html

But to clarify:

There might be a more direct way to interact with SurfaceFlinger.

I guess feeding max values into all the things that SurfaceFlinger reads might get it to to add two numbers together and trigger an integer overflow.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Yes, and if you look at the code:

const size_t numFds = buf[8];

It tells us that the variable is unsigned meaning it only accepts a positive number. The maximum number it can accept would be 4294967295 (FFFFFFFF), so 1 more added to this would cause a number of -1 which I'm thinking will cause this bug. I'm just thinking out loud here.

To do this we'd have to execute the exploit while in debug mode when running the APK designed for it specifically, note the exception offset location and try to find the stack pointer to start code injection...

Code injection will consist of assembly code which will call our System UID and then we could use exploit 4322 to write root.

Again, I'm just thinking out loud here but after doing a ton of reading/watching/writing my brain is tired LoL.
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
[MENTION=4558078]ZPaul2Fresh8[/MENTION]

I hear that. Thanks for trying apk stuff.

Hm ok so getting SurfaceFlinger to either open 4294967295 (FFFF FFFF, from buf[8]) + 1 files to overflow numFds or 68719476735 (FFFF FFFF F, from buf[9]) + 1 somethings to overflow numInts. I almost want to run an Android dev emulator to watch memory to see what numInts is. I suppose reading through the code would also reveal that.

I hope you understand the code injection process more than I do. But I think as long as the SurfaceFlinger buffer overflow works properly then what you execute will retain the system uid privileges of SurfaceFlinger.

Shellcode does seem to be very low level, but I think it can be C and doesn't have to be assembly.

What kind of access one has from the buffer overflow defines how to proceed. Controlling the flow of execution and how one writes to memory I'm still not sure about (is any memory just executable, does it have to be somewhere 'special').
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
I think the [8] is an array rather than allocation of memory in byte sizes. because FFFFFFFF = 4GB so I can't imagine it being that way. I could be wrong but that just doesn't seem feasible.

In linux I can convert C > Assembly > Shellcode. Pretty easy there. I was just kinda paraphrasing what I've been learning about lately =)

Think of it like this. I'm attaching an image for visual reference.

[IMG="Function Memory Stack"]http://upload.wikimedia.org/wikipedia/commons/9/93/Stack_Overflow_3.png[/IMG]

Now Let's say the allocated memory for GraphicBuffer::flatten function is 12 bytes. In this image it would be located in the box with the 'HELLO\0' bytes. Now the overflow would occur if we return a value that's larger than the expected 12 bytes of data. In this image there are 4 bytes below (Char *bar), 4 more bytes for the Saved Frame Pointer and lastly 4 more bytes in the 'Return Address'.

Still with me? Good. Proceeding...

Now one of the important factors is finding the 'Return Address' because if we can create our overflow to end here, we can redirect the return to anywhere we want. So by looking at the image, our goal is to overflow this by 8 bytes to land on our Return Address. In this example we could designate a redirect with an address of 4 bytes (I know not the typical size but it's for demo purposes). This example is for a redirection for arbitrary code execution and from what I've read it's used to jump to another shared resource for further exploitation. It's called Ret to libc.

Now if there's enough memory allocated we could possibly be able to run shell code directly in the stack, in this event we would simply make our 'Return Address' point to the start of memory stack we overflow'd. There's a ton more to it and this just applies to stack overflows. Heaps are different and may be our case here. Trying to find out more.

If want to learn more about smashing the stack, check out my playlist on youtube: https://www.youtube.com/playlist?list=PLNnFEZhbCLT2XngO6KXBW1Z9wrIQQI3s3&spfreload=1

More to come after I get some sleep...
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Possible new approach

O.k. guys, so here is a thought. I know this has been done on the Amazon Kindle Fire, etc.. There is one command line tool that we all have that has /system/app and /data level access. Adb.exe, yes, through the means of doing a adb backup and adb restore. There is plenty of documentation on how to decompile the backup file and recompile it. So, this small little nugget already has the rights to overwrite in the system and data area. So my thought is this. If we can take an existing apk that already has the privileges we need and modify it or add to it so we can inject it with our own write functions to a specific area, then we should be able to gain access or at least run something with system level access.

Also, there has to be a way for us to find a vulnerability in this process. We know it has been given certain rights in order to be able to overwrite existing files. So with that said, maybe we need to shift our focus on this instead of trying to find a way to do it directly on the shell of the device or trying to exploit some kind of other on-device vulnerability.

Thoughts ??

Reference:

http://nelenkov.blogspot.jp/2012/06/unpacking-android-backups.html [MENTION=4246643]Tomsgt[/MENTION] Credit for article link.

Example: (Timing issue exploit)

http://xdaforums.com/showthread.php?t=1886460 Credit to: [MENTION=1346722]Bin4ry[/MENTION]