yashsingh1/xdaforums huggingface dataset:
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
Attack the stock recovery/verifier !

I've been studying the stock recovery source code for a while. We already have a signed CSC .ZIP file in each cache.img that could be flashed directly from internal/external SD via stock recovery (e.g, sec_csc.zip for VZW Note 4 N910VVZW1ANJ5). The public key used to verify file signature is included in the recovery ramdisk (publiccert.pem for VZW Note 4 N910VVZW1ANJ5). It may be very difficult to modify the .ZIP file and resign or keep its signature b/c we should have Samsung private key as well. However, we could find a flaw in the verifier code (verifier.cpp), which includes very useful comments that explain how it works; it returns VERIFY_SUCCESS or VERIFY_FAILURE (if any error is encountered or no key matches the signature). I've tested if Samsung has made any custom patches for it & it seems that the behavior of Samsung stock recovery exactly matches this source code.

I've also checked the source code of the target functions verify_file() and load_keys() & followed the code step by step starting from checking .ZIP archive comment that includes whole-file signature ends with 6-byte comment (footer) starts with $ff $ff... Apparently, the file is read in memory before any signature verification followed by calculating signature_start & checking keys match. We may try to trick the verifier code by HEX editing a modified sec_csc.zip after adding the required root files, so that verify_file() returns VERIFY_SUCCESS for our modified .ZIP file . This depends mainly on finding any flaw in these two functions utilizing the source code availability with explanatory comments and small-size signed CSC .ZIP files to test.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Part of the signature though is the MD5 of the file I believe, so changing even one byte of the file would invalidate the signature. Good luck trying to overwrite the verifier code in memory. I am sure it is in flashable only memory.
[Galaxy Note 4 Developer Discussion (Devs., Only)] zxz0O0:
Have tried to add a modified ANativeWindowBuffer to the queue but seems that one actually verifies numInts and numFds (see here: https://android.googlesource.com/pl...d-4.4.2_r2.0.1/modules/gralloc/gralloc_priv.h ) and returns -EINVAL.
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
Changing any single byte requires Samsung private keys to resign, but our target is to trick verify_file() or load_keys() functions. The file is opened in the memory before signature verification, but i'm not sure if it's even possible to overwrite the code in a way similar to Loki, considering the difference between .ZIP archive & kernel ramdisk. However, we may be able to modify the .ZIP file in order to bypass the signature verification assuming we can find one or more flaws in the target function(s).

For example, the whole-file signature is calculated based on the footer (6-byte comment at the end of the file). I was thinking of appending a fake signature, but this was explicitly patched,

size_t i;
for (i = 4; i < eocd_size-3; ++i) {
if (eocd[i ] == 0x50 && eocd[i+1] == 0x4b &&
eocd[i+2] == 0x05 && eocd[i+3] == 0x06) {
[COLOR="Red"] // if the sequence $50 $4b $05 $06 appears anywhere after
// the real one, minzip will find the later (wrong) one,
// which could be exploitable. Fail verification if
// this sequence occurs anywhere after the real one.
[/COLOR] LOGE("EOCD marker occurs after start of EOCD\n");
return VERIFY_FAILURE;
}
}

Here're the facts we know about the .ZIP file signature verification process:

The .ZIP file ends with a 6-byte footer = "(signature_start) $ff $ff (comment_size)"

footer[0] =
footer[1] =
footer[2] = FF
footer[3] = FF
footer[4] =
footer[5] =

FOOTER_SIZE = 6

EOCD_HEADER_SIZE = 22

comment_size = footer[4] + (footer[5] << 8)

signature_start = footer[0] + (footer[1] << 8)

signature_size = signature_start - FOOTER_SIZE

eocd_size = comment_size + EOCD_HEADER_SIZE

signed_len = length - eocd_size + EOCD_HEADER_SIZE - 2

eocd = addr + length - eocd_size

signature magic number: $50 $4b $05 $06

That's how the verifier code reads/checks the signature for a .ZIP file loaded into memory. You can check/verify signature using the following command:

jarsigner -verify -verbose -certs <filename.zip>

but we also need to match one of the public keys stored in the stock recovery ramdisk.

I've posted what I know so far to allow contributions from anyone who can help since all of us have limited free time while integrating efforts will make things run faster. If it's possible to overwrite verify_file() function with a crafted script that returns VERIFY_SUCCESS, it'd be perfect. Otherwise, we may try to find an exploitable flaw in the verifier code.
[Galaxy Note 4 Developer Discussion (Devs., Only)] zxz0O0:
Made small progress, successfully crashed surfaceflinger service with modified ANativeWindowBuffer.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
This is good news. Guys, just in case you are not aware, remember giefroot, this is the guy involved with releasing that tool that combined CVE-2014-7911 (by Keen Team) and CVE-2014-4322. Lets show him some support here with some thanks button pushes. I don't want his efforts to go unnoticed here. He is one of the people that can definitely help us in this venture.

Thank you for your support in obtaining an exploit sir.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Some resources I've collected. They are of the SurfaceFlinger & GraphicBuffer, may be helpful.

https://drive.google.com/file/d/0Bzops1FvGUi8OWR2LWJFNWx3cTA/view?usp=sharing

https://drive.google.com/file/d/0Bzops1FvGUi8MVdLRTdsU0NHLWc/view?usp=sharing

https://charleszblog.wordpress.com/2014/02/23/understanding-android-internals-surfaceflinger-iii/

Did you crash result from an overflow? Logcat?
[Galaxy Note 4 Developer Discussion (Devs., Only)] zxz0O0:
D/qdgralloc( 5403): Invalid gralloc handle (at 0xb89fcc50): ver(12/12) ints(-6/12) fds(128/2) magic(��/gmsm)

W/GraphicBufferMapper( 5403): unregisterBuffer(0xb89fcc50) failed -22 (Invalid argument)

F/SurfaceFlinger( 276): Assertion failed: disp < 0 || disp == HWC_DISPLAY_PRIMARY

F/libc ( 276): Fatal signal 6 (SIGABRT) at 0x00000114 (code=-6), thread 276 (surfaceflinger)

D/clmlib ( 274): Got activities:0x00000011

I/DEBUG ( 274): == Native crash-info: ==

I/DEBUG ( 274): UUID: cd218770-8ac2-4890-bae1-2db44c55f22d

I/DEBUG ( 274): SystemDump: requested

I/DEBUG ( 274): pid: 276, tid: 276, name: surfaceflinger >>> /system/bin/surfaceflinger <<<

I/DEBUG ( 274): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

I/DEBUG ( 274):

I/DEBUG ( 274): backtrace:

I/DEBUG ( 274): #00 pc 00022200 /system/lib/libc.so (tgkill+12)

I/DEBUG ( 274): #01 pc 00013201 /system/lib/libc.so (pthread_kill+48)

I/DEBUG ( 274): #02 pc 00013415 /system/lib/libc.so (raise+10)

I/DEBUG ( 274): #03 pc 0001214b /system/lib/libc.so

I/DEBUG ( 274): #04 pc 00021ab4 /system/lib/libc.so (abort+4)

I/DEBUG ( 274): #05 pc 00006a5b /system/lib/libcutils.so (__android_log_assert+86)

I/DEBUG ( 274): #06 pc 0001fb9d /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #07 pc 000109eb /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #08 pc 0001ae63 /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #09 pc 0001b30b /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #10 pc 0001b391 /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #11 pc 00010787 /system/lib/libutils.so (android::Looper::pollInner(int)+394)

I/DEBUG ( 274): #12 pc 00010889 /system/lib/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+92)

I/DEBUG ( 274): #13 pc 0001620d /system/lib/libsurfaceflinger.so

I/DEBUG ( 274): #14 pc 0001703f /system/lib/libsurfaceflinger.so (android::SurfaceFlinger::run()+6)

I/DEBUG ( 274): #15 pc 000008fd /system/bin/surfaceflinger

I/DEBUG ( 274): #16 pc 0000e56b /system/lib/libc.so (__libc_init+50)

I/DEBUG ( 274): #17 pc 000007dc /system/bin/surfaceflinger

I/clmlib ( 274): Sync file system

I/clmlib ( 274): System dump request: pid=276 (/system/bin/surfaceflinger, /system/bin/surfaceflinger)

Currently trying to find out the source of the crash. Seems it's in the flatten function. Unable to debug using gdb since it's from a different thread. Would be interested to get the parameter values of flatten call. Anyone has an idea how to get more info about the crash?
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
Use ADB bugreport to print all info required to diagnose a "bug" & redirect the output to a local log file, as follows:

adb bugreport > bugreport.log

This'll take a few minutes & create a very long "bugreport.log" file (~10-20 MB). Then, use cat & grep to print only relevant info; for example,

cat bugreport.log | grep 'surfaceflinger'

Good luck!

---------- Post added at 11:10 AM ---------- Previous post was at 10:28 AM ----------

Folks,

It'd be great if you don't mind to create a GitHub repo & share your source code. This may help other devs to contribute & accelerate progress.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
https://github.com/ZPaul2Fresh8/CVE-2015-1474.git
[Galaxy Note 4 Developer Discussion (Devs., Only)] zxz0O0:
Seems the crash did not result from a buffer overflow but more from a parameter I specified. :( (see https://android.googlesource.com/pl...surfaceflinger/DisplayHardware/HWComposer.cpp line 748)

Still curious about this error message

W/GraphicBufferMapper( 5403): unregisterBuffer(0xb89fcc50) failed -22 (Invalid argument)

The only place I found where unregisterBuffer is called is in unflatten function ( https://android.googlesource.com/pl...ndroid-4.4.4_r2.0.1/libs/ui/GraphicBuffer.cpp freeHandle() ). But there is no overflow occuring.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Here, read this..

https://charleszblog.wordpress.com/2014/02/20/understanding-android-internals-graphics-basics-i/

Unflattens object from buffer:

virtual status_t unflatten(void const* buffer, size_t size, int fds[], size_t count) = 0;

protected: virtual ~Flattenable() = 0;

So, yes it seems through this function is where you unregister or unflatten the buffer. Prior to that though you will notice the creation of the object passing some parameters such as:

virtual size_t getFdCount() const = (This is I believe part of the vulnerability as well)

via vectors that trigger a large number (1) file descriptors or (2) integer values taken right from the CVE
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
It'd be great if you don't mind to share your source code to CVE-2015-1474 GitHub repo so that other devs can contribute. Thank you!
[Galaxy Note 4 Developer Discussion (Devs., Only)] turbofirefox:
Install CVE-2014-4322 app using adb restore

[MENTION=3178012]gatesjunior[/MENTION] I read your post and was wondering if we might use this to bypass the "system" permission issue...

Say someone with a Note 4 dev edition were to install the CVE-2014-4322 application on that phone in the system/app folder. Then, they took a backup of just that application using adb backup and uploaded the file to here. One of us could grab that file and restore that application on our devices (others have used this functionality to move applications from one device to another). Would that application have "system" permissions when it runs?...
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Right. This is the kind of thing I am thinking as well. There are also other possibilities as well, but all of them are along the lines of using adb to gain access to the system area.
[Galaxy Note 4 Developer Discussion (Devs., Only)] jpfulton248:
If someone wants to pm me (or post here) with specifics and a link to the 4322 app, I can give this a shot tomorrow and upload the app. Just let me know.

Sent from my SM-910V Developer Edition
[Galaxy Note 4 Developer Discussion (Devs., Only)] turbofirefox:
I would ask that you install the giefroot masterpiece tool (OP) http://xdaforums.com/crossdevice-dev/sony/giefroot-rooting-tool-cve-2014-4322-t3011598 built by [MENTION=3975929]zxz0O0[/MENTION] and KeenTeam.

I would expect that the directions by [MENTION=2791414]copkay[/MENTION] here http://xdaforums.com/galaxy-nexus/general/guide-phone-backup-unlock-root-t1420351 will get you the rest of what you need... I'm guessing it will be something like:

adb backup -apk -shared -all -system [<packages...>]
[Galaxy Note 4 Developer Discussion (Devs., Only)] EMDrNote:
It looks like you would want to use an app with the necessary system-level permissions already declared as you apparently cannot declare new permissions in a system app upgrade. Otherwise, as long as the app signature doesn't get in the way, this just might work.

See: http://stackoverflow.com/questions/17219462/android-updated-system-app-is-not-granted-new-permission
[Galaxy Note 4 Developer Discussion (Devs., Only)] jpfulton248:
Didn't work. I got "Seems your kernel / device is not supported". Let me know if you guys need anything else from a dev edition.
[Galaxy Note 4 Developer Discussion (Devs., Only)] turbofirefox:
[MENTION=3647977]jpfulton248[/MENTION], it looks to me like that message is from running the apk on your device. Yes, we would like to you install the apk, but as soon as it is installed, then run the adb backup command and share the .ab file that gets created.
[Galaxy Note 4 Developer Discussion (Devs., Only)] p1gl3t:
Hi guys, you should check out our findings at http://xdaforums.com/kindle-fire-hdx/orig-development/evaluating-cve-2015-1474-to-escalate-to-t3045163. Unfortunately we didn't find any way to exploit the bug in a controlled manner. It might be impossible to do it, but I wouldn't bet my life on that.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
https://github.com/p1gl3t/CVE-2015-1474_poc

A poc in development.
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
Thanks for the heads up! I'll check your thread & look into your source code...

Yeah, I saw this. If you're using the same source code, let's delete the new repo & fork this one. Also, it seems that LP 5.0.x update might come soon (Sprint Note 4 has received it already) which has its own root challenges. Just wanted to warn everyone here not to take that update unless it's tested to be downgradable to KK 4.4.4. It'll be easy to upgrade later after achieving root (for either KK or LP), hopefully.
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
A New ROOTING method & Bootloader Unlock for LG Devices

There's a new rooting method for some LG devices originally posted here, announced here & translated/modified here, works on both KK & LP. It's based on sending a command via Bootloader (in Download Mode, after enabling USB debugging) which simply runs a script written to install SuperSU .ZIP. It may not work on Samsung devices, but the idea is very interesting. It's worth checking how the used Send_Command.exe works; it's a PE32 executable for MS Windows (console) Intel 80386 32-bit.
[Galaxy Note 4 Developer Discussion (Devs., Only)] p1gl3t:
I did a bit of googling and it seems that the download mode on the LG G2 is provided by the laf image, which is specific for LG.

This means that this technique will not work on devices from other manufacturers
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
I see. Rooting through LK is still an interesting idea though. I'm thinking loudly of cloning Odin messages to bootloader, but it'll probably be blocked by its security. So, attacking recovery or bootloader will always face the signature checks & require a low-level vulnerability.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Correct, in my opinion what we need to capture is the USB communications between the device and our PC. Specifically running either adb restore or in Download Mode while using ODIN. I think the adb coomunications would be more beneficial given the fact it can overwrite the system/app area without root during a restore.
[Galaxy Note 4 Developer Discussion (Devs., Only)] hsbadr:
I agree. Additionally, this could be the right direction for bootloader research/unlock/workaround. However, the lack of (published) research, skilled candidates/experts working on specific devices makes it harder to hack, unless we attract more devs to work on it.
[Galaxy Note 4 Developer Discussion (Devs., Only)] Android.Ninja:
Following the thread closely. If I can be of any help; I can confirm the "laf" image files are specifically LG driven for utilization when in Download Mode / Fastboot Mode, which was confirmed in the above quote. What I would like to add, if it would help in some way is, Even if you take a completely bricked LG G2, (by definition of bricked I'm referring to a complete & total failure of any type of boot.) You can still power the device up from a non powered status attempting to boot into Download Mode. Once there, on your pc go to the directory of your "laf" image files, right click in that directory, open a cmd prompt, then use the "Flash" command to transfer your "laf" images one by one to the target. If no image exist in the target directory, a new image will be written. If the targeted file already exist, but you are modifying it, it will be overwritten.

Example: laf image on pc is labeled "aboot.img"

Command would be as follows:

fastboot erase aboot

fastboot flash aboot aboot.img

You'd continue the same for boot.img, dbi.img, laf.img, misc.img, modem.img, persist.img, recovery.img, rpm.img, sb11.img, & tz.img.

I'd agree that a capture of the USB communications between the device and pc, specifically the adb communications, would be the most effective variable, considering it has the ability to overwrite the system/app target minus having root. If I can test some theories let me know. I'm here to help in any way that I can.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Looks like someone has written a POC as well on this graphic integer overflow vulnerability:

http://seclists.org/fulldisclosure/2015/Mar/64
[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
Good find gatesjunior! It seems that early this morning (not long after midnight, US time), due to Lollipop 5.1 being released Guang Gong of QIHU 360 posted POC code for CVE-2015-1530 that you linked, and POC code for CVE-2015-1474, the one we've been waiting for.

Guang Gong even mentions that the exploit works like CVE-2014-7911, the other exploit that unfortunately is patched for us.

All Android versions before 5.1 are vulnerable to both of these. Now we just need one of these, probably CVE-2015-1474, to be wrapped up into an apk with CVE-2014-4322.

Link: http://seclists.org/fulldisclosure/2015/Mar/64

Archive: https://archive.today/0ZBOM

Link: http://seclists.org/fulldisclosure/2015/Mar/63

Archive: https://archive.today/rYkjb

[MENTION=4558078]ZPaul2Fresh8[/MENTION] [MENTION=3975929]zxz0O0[/MENTION] [MENTION=3669069]idler1984[/MENTION] [MENTION=4939386]Surge1223[/MENTION]
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Excellent. We have all the pieces of our puzzle. Now it's time to put it together. Someone should download Retme7's 2014-7911 PoC from Git and put this PoC into it...
[Galaxy Note 4 Developer Discussion (Devs., Only)] jcase:
This code packed into an apk with another POC is going to accomplish nothing but probably a reboot.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
I wasn't being that literal. The PoC states it's similar in use of the 7911. But retme7's package has the 4322 already in it, I'm sure they are some offsets that need changed to use it on our kernel. It's a great base for accomplishing our goal. Someone could write a completely new package, but why?..

I believe when root comes, retme7's package will be used but I was wondering how you'd use the PoC which is in C++ and put it in an APK which is JavaScript? jnode?
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
I think there is a much nicer way of saying this. I don't think we have to come off so negative. There is a difference between saying, you probably will not get much out of this due to blah blah blah. than this is going to accomplish nothing but probably blah blah blah. A wise man once told me that it doesn't matter how smart you are or how right you are most of the time, if people do not want to work with you or collaborate with you, you are of little value to the team.

No one likes a great player on a team act like a snob or a ball hog. I personally know your a smart guy and know that you, in the past, have contributed to the community, but do you really have to come off that way to everyone here ? I can appreciate you like making money and giving what you find to those who want to pay, but if you cannot contribute to the conversation without being negative or a downer I for one would rather you just not comment. The only thing I have seen lately is you wanting to know who found some vulnerability or comments like the one you just made that add nothing but a negative tone with no real explanation or any added value to the thread.
[Galaxy Note 4 Developer Discussion (Devs., Only)] jcase:
There was nothing not nice or rude about what i said, it was just short and to the point, as most people here could not care less about details, just the facts. If you had asked why in a nice way i would have explained why in detail, instead you came off like this.

That POC is just that, its a proof of concept, its not a weaponized exploit, it doesnt give you a root shell, it doesnt install su. Take some time and effort and read it, instead of getting rude with someone merely making a relevant, non rude comment.
[Galaxy Note 4 Developer Discussion (Devs., Only)] jcase:
A POC (proof of concept) doesnt necessarily have to be something complete, but just something that proves a concept. The posted POC doesn't install su, or drop to a root shell or anything of that order.

Apks are java (dalvik) not javascript. You can use native code a couple ways, via jni (a library) or just write it to disk, and execute it with RunTime.exe.
[Galaxy Note 4 Developer Discussion (Devs., Only)] gatesjunior:
Let's just get back on topic. Enough said. We'll disagree to disagree on that.
[Galaxy Note 4 Developer Discussion (Devs., Only)] ZPaul2Fresh8:
Thanks for clearing that up Justin.
[Galaxy Note 4 Developer Discussion (Devs., Only)] howellcp:
Don't know if this helps but it looks like Droid Turbo just got root.

"Video with adb shell getting root and changing permissions of a root owned block device. Stuff on left is commands for copy paste to avoid one handed typing. No more vids for now.

youtu.be/X-eh5Qo2ifo"
[Galaxy Note 4 Developer Discussion (Devs., Only)] raynan:
Can I assume you took that on the device you're using or is that from somewhere else?

Edit: Nevermind, I saw the edge screen with a bit of squinting. Awesome news and nice work! I won't make any more comments like this :p
[Galaxy Note 4 Developer Discussion (Devs., Only)] TechBSwift:
If you want to see if Blazinandroid1 is legit please review the link below post #11. He posted an image a couple of weeks ago, and there was a couple more items that was "shell" only... Please keep this on topic and not waste time posting questions regarding legitimacy.... Devs hate reading through a bunch of unhelpful comments. I'm not trying to be rude, I merely trying to ensure the devs workings on this, don't abandon their efforts due to frustrations with messy threads. Blazinandroid1 is trying to help, so lets find things that can help him and the rest of the Devs. Search the internet pages boys and girls!!! Happy hunting

http://xdaforums.com/note-edge/general/throw-everything-sun-t3042962
[Galaxy Note 4 Developer Discussion (Devs., Only)] KennyG123:
Thread cleaned

Don't know how this ended up in General but it is moved back to Developers ONLY section

Meaning NO QUESTIONS about "what does this mean" Or "Are we there yet"

There are threads in the Verizon and AT&T General sections to discuss your thoughts

But let the developers work here

Infractions will come without warnings here

Thank you for helping XDA become a place for developer discussions once again

Friendly Neighborhood Senior-Mod