yashsingh1/xdaforums huggingface dataset:
[Kindle Fire HDX 7" & 8.9" Original Android Develop] p1gl3t:
Good news ( [MENTION=3556718]Phate123[/MENTION], [MENTION=6403649]awinston[/MENTION] )! I have managed to crash the surfaceflinger on 4.5.2 (should also work on 4.5.3).

I'll upload the code on github, but first I want to briefly explain how I did it.

In Android everything that is a graphical element is represented by an GraphicBuffer.

GraphicBuffers are wrapped in BufferItems and managed by BufferQueues.

Each Queue has two sites, a producer side (IGraphicBufferProducer) and a consumer side (IGraphicBufferConsumer). In the basic scenario an app is the producer and the surfaceflinger is the consumer. These are obviously two different processes, but both must use the same BufferQueue.

BufferQueues are always created and owned by the consumers and consequently live in the same address space as the consumer. Producers must go through Binder to access their side of the queue.

As with everything in Android, the BufferQueue provides the same interface for both native (in the same process) and remote usage. The remote interface is implemented by a proxy that communicates through Binder with the other side.

In android KK BufferQueue implements the native side of the interface for both the producer (BnGraphicBufferProducer) and the consumer (BnGraphicBufferConsumer). These native implementations must provide a handler (onTransact) for requests that come from the remote proxies.

You can read more at https://source.android.com/devices/graphics/architecture.html.

Naturally, the first idea that comes into mind is to attack the native implementations of the BufferQueue that reside in the surfaceflinger. As the bug is in the unflatten routine of GraphicBuffer, we would like to craft a rogue parcel that represents a GraphicBuffer and then wait for the surfaceflinger to choke with it.

Unfortunately, from my findings, the bugged unflatten method is not called from the onTransact handler in the native implementations.

Only the proxy implementations seem to be a valid target, through BpGraphicBufferProducer::requestBuffer and BpGraphicBufferConsumer::aquireBuffer. Now we have a problem: as the BufferQueue resides in the surfaceflinger, there is no proxy implementation to attack.

Our only hope is to somehow create the BufferQueue in our process, so that we are the consumers, and use the surfaceflinger as the producer. This way the surfaceflinger would be accessing the BufferQueue through the bugged proxy (BpGraphicBufferProducer::requestBuffer). One way to use the surfaceflinger as a producer is to make screen captures.

I found the screencap command to be a very nice starting point to tinker with the idea as it does exactly what we wanted - it uses the surfaceflinger as a producer and pulls screen captures from it. Next I only had to hook the vtable entry of BpGraphicBufferProducer:: onTransact.

Now we have to control the overflow in GraphicsBuffer::unflatten.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] awinston:
Wow you are really good! I had started to piece some of this together and wanted to document it for good measure even though you are going to clearly beat the rest of us to this exploit. Arguably I could never figure it out, but never hurts to try. At least I am learning.

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

http://translate.google.com/transla...dyhuabing/article/details/7489776&prev=search

http://4.bp.blogspot.com/-qQxyvr2Vc8w/VFYLxdacwpI/AAAAAAAAAes/HMMrUIwC9OY/s1600/Selection_043.png

https://android.googlesource.com/platform/frameworks/native/+/master/libs/gui/tests/Surface_test.cpp

The screenshot test is where I was focusing but wasn't really getting very far.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] p1gl3t:
Surfaceflinger runs under the system user (+drmrpc group) and should have access to /dev/qseecom, through which we can get root using CVE-2014-4322.

The problem is that the heap buffer overflow triggered by unflatten seems very difficult to exploit.

We must consider the following to achieve a controlled memory write:

sizeof(native_handle_t) + sizeof(int)*(numFds+numInts) must overflow 32 bits and remain small enough that the malloc succeeds and returns a valid heap address in h->data. If the malloc were to fail, we would memcpy to address 0 and get a seg fault.

as even after the malloc, numInts and numFds are used only after being multiplied by 4 (sizeof(int)), we can ignore the 2 most significant bits from both of them. This means that the only way to get any kind of bof is to generate transport from bit 29 to bit 30 on the sum numFds+numInts. Consequently, at least one of numInts or numFds must have bit 29 set. This doesn't sound very good because next we will do a memcpy of numFds * 4 bytes and next a memcpy of numInts * 4 bytes, meaning that at least one of the two memcpy calls will try to copy at least (1<<31) bytes. This will certainly lead to a segfault before we can trigger something from another thread...

the executable code is position independent so we would need to leak an address to be able to use rop.

Things don't look good at all... I really hope that I have made a mistake or that there is another approach to the problem.

I'm afraid that the pros would have already implemented an exploit by now, if it could have been done.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] Phate123:
That have been my thoughts too. There is a memory corruption but it is difficult to use and it is not on areas that could be used to manipulate the return stack or a vtable entry. Or I just can't see the way. I have experience in this area,but it is kinda limited.

BTW: These drivers are not used by the Fire HDX by chance? https://www.codeaurora.org/projects...le-camera-drivers-cve-2014-4321-cve-2014-4324

Sadly I cannot find enough time to spend hours on digging. I hope there are some to be find this weekend though.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] p1gl3t:
I don't think a stack attack would have been feasible at all as the code should be compiled with stack protector on and we can't do a brute force on the canary value. Hijacking a vtable pointer or a got entry would have been the way to go, but we still wouldn't know what to write as everything is aslr'd.

Regarding those camera drivers, I think someone over at the Samsung section also mentioned them. I'll look into them and report back.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] awinston:
Would you mind sharing your code even though it doesn't look like you will be able to exploit this overflow? I am still trying to get my head around the basic attack through surface flinger and it would help me greatly to better understand how at least in theory this works. No worries if you don't want to.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] p1gl3t:
Here you go: https://github.com/p1gl3t/CVE-2015-1474_poc.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] zxz0O0:
p1gl3t, great job on creating a poc of the exploit :good:
[Kindle Fire HDX 7" & 8.9" Original Android Develop] ZPaul2Fresh8:
[MENTION=2376614]jcase[/MENTION] Says no on those camera group holes. http://xdaforums.com/showpost.php?p=58945240&postcount=18

It's good to see other's working on 2015-1474 also :good:
[Kindle Fire HDX 7" & 8.9" Original Android Develop] p1gl3t:
[MENTION=2376614]jcase[/MENTION] is right, only mediaserver is executed under group camera so that it can access /dev/video*. You can see that in init.base.rc and ueventd.qcom.rc.

Now returning to the original topic... I fiddled around with unflatten, giving some input that should have made it crash.

What I did is I left numInts untouched and set numFds = -numInts. I was expecting surfaceflinger to crash every single time when it did the first memcpy. Somehow it didn't. I was baffled and had to gdb the process to see where my assumptions were wrong.

I breaked just before the first memcpy and printed the params:

(gdb) p $r0
$19 = 3074255348
(gdb) p $r1
$20 = 3074340312
(gdb) p $r2
$21 = 4294967248

r0 is the destination, r1 the source and r2 the number of bytes to copy. r2 is the unsigned representation of 4 * (-12) = 4 * numFds = -4 * numInts.

How did the program NOT crash???!! It even worked a second time, but crashed with SIGABRT in a free() because of heap corruption (I suppose). So even the second memcpy passed without segfault.

Here you have the memory map of surfaceflinger.

LE I have traced the memcpy. It looks like this on my Apollo 14.4.5.2

.text:0002218C __memcpy_base
.text:0002218C CMP R2, #4
.text:0002218E BLT.W loc_222DC
.text:00022192 CMP R2, #0x10
.text:00022194 BLT.W loc_222BE
.text:00022198 CMP R2, #0x20
.text:0002219A BLT.W loc_222AE
.text:0002219E CMP R2, #0x40
.text:000221A0 BLT loc_222A2

It seems like R2 (number of bytes) is treated like a signed int and the first branch is taken and the following instructions are executed

.text:000222DC loc_222DC ; CODE XREF: __memcpy_base+2
.text:000222DC LSLS R2, R2, #0x1F
.text:000222DE ITT CS
.text:000222E0 LDRCSH.W R3, [R1],#2
.text:000222E4 STRCSH.W R3, [R0],#2
.text:000222E8 ITT MI
.text:000222EA LDRMIB R3, [R1]
.text:000222EC STRMIB R3, [R0]

This ends up copying only n & 3 bytes, which is < 4. Basically, only the 2 least significant bits from n matter).

So... I guess we are able to write to h->data + numFds*4 as long as numFds*4 is negative. But having numFds as an offset may hurt us on the malloc side.

Now we have to defeat aslr somehow.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] neoroid:
Any chance

I hope you are still working on this, we really need to get ride of the crappy Amazon OS and unlock the full potential of these amazing tablet specs.

I have an open tablet that I should repair, if there is need to take some photos of components please let me know, I am not into software hacking yet and it will takes me some time to get into it... but I want to contribute to make this possible, I hope more smart guys from around here join their effort to do it.

I wish if there is another tablet on the market who is as good as this one right now at an affordable price, to just see how CM12.1 behave on it, I tried it on a KFHD before I get it bricked it was fine but little bit laggy due to limited specs and low ram.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] dadreamer:
Hi, p1gl3t!

I'm interesting in your PoC and have to ask... Is your work on this done? And how might I use that for my specific device?
[Kindle Fire HDX 7" & 8.9" Original Android Develop] DB126:
Not sure what this thread was all about (didn't look back) but the last post was over 2 years ago. A lot has happened since then; every 3rd gen HDX can be bootloader unlocked opening the door to custom ROMS ranging from Android 4.4.4 to 7.1.1.

https://xdaforums.com/kindle-fire-hdx/general/thor-unlocking-bootloader-firmware-t3463982

https://xdaforums.com/kindle-fire-hdx/general/thor-4-5-5-2-easy-to-root-unlock-t3571240
[Kindle Fire HDX 7" & 8.9" Original Android Develop] dadreamer:
Well, that's true but not for my device :( I still have a slightly outdated smartphone. It is Docomo Fujitsu Arrows NX F-01F [ Android 4.4.2, build # V10R22A (kernel version 3.4.0), ARMv7 arch (armv7l, armeabi-v7a) ]. And it's got no public firmwares at all, no bootloader unlock and no root in easy ways. Besides of that, there's one "pleasant" addition - PXN (Privilege Execute-Never), which doesn't let me to root the phone with simple ways or common tools.

To bypass PXN I have to use some JOP approach but for it I need to get boot.img or kernel memory dump somehow. Because I have no factory ROMs I'm trying to pull out boot.img through known vulnerabilities of my dev. One of them is CVE-2015-1474 (GraphicBuffer integer overflow), which potentially might give me system privilegies to copy boot.img from that phone.

So I wonder if p1gl3t's code is ready to use and is able to give the system privilegies. It seems it should be compiled together with AOSP codebase. But I'm unsure if it would work well when I get it compiled.

Checked your links. There I see that the presence of root is required. But I can't gain root so can't use those tools.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] DB126:
Have not seen [MENTION=4276415]p1gl3t[/MENTION] on this thread/forum in awhile; not sure if s/he is still active on XDA. Might try a PM. Given the age and, err, uniqueness of device in question I suspect you're in for quite a ride. Good luck.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] dadreamer:
Well, I have compiled that badscreencap by p1gl3t along with android 4.4.2 codebase and then pushed it to my dev. But whenever I run it I receive segfault:

shell@F01F:/data/local/tmp $ ./badscreencap
pid 24824
display.update ret 0
IGraphicBufferConsumer::consumerDisconnect 0x18
BBinder::onTransact 0x40
BnGraphicBufferProducer::onTransact 0x34
BBinder::onTransact 0x40
BnGraphicBufferProducer::onTransact 0x34
BBinder::onTransact 0xb6889759
BnGraphicBufferProducer::onTransact 0xb6889391
BBinder::onTransact = 0xb6899048
*BBinder::onTransact = 0xb6889759
BBinder::onTransact = 0xb7b912b0
*BBinder::onTransact = 0xb6889759
--------
f1 04 00 ff f7 18 be 38 b5 04 46 0d 46 11 b1 08 46 f6 f7 50
--------
[1] + Stopped (signal) ./badscreencap

When I issue any one command after that I get

shell@F01F:/data/local/tmp $
[1] + Segmentation fault ./badscreencap (core dumped)

Of course, no any signs of system privileges for my id. Checked this with logcat and it has got the following trace:

Besides of the crash it seems to be incomplete because the code lacks any final ways of gaining elevated privileges (payload w/ reverse shell or something like that).

I assume it all makes no sense due to the loss of relevance for others. So I'll turn my attention to another CVE's out there. This could be the most elegant and shortest way of getting system though.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] DB126:
Is your goal to gain root on FireOS v3/v4/5 or are you experimenting with this for other reasons? If the former there are far easier methods (FireOS version dependent) of achieving this; even a theoretical way to unlock the bootloader sans root.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] dadreamer:
As I said earlier I would like to get temp root for Docomo Fujitsu Arrows NX F-01F and this CVE is the one of several vulnerabilities which I could use to pull out boot block. I expect that boot image to be used in iovyroot later. No any other root methods work for my device. I tried almost everything (KingRoot, Towelroot, eRoot, vRoot, KingoRoot etc.).
[Kindle Fire HDX 7" & 8.9" Original Android Develop] DB126:
Sorry - I skipped over the page with our prior engagement and thought that conversation was with a different member (in a different thread). Hope this works out for you.
[Kindle Fire HDX 7" & 8.9" Original Android Develop] Skorpion96:
i found that my device zte a5 2019 is vulnerable to this, anyone found a way to use this vulnerability?
[Kindle Fire HDX 7" & 8.9" Original Android Develop] Skorpion96:
Deleted
[Huawei Ascend P1] nudder12:
Hi.

Sincere apologies if I'm posting in the wrong place. (I counnld't ask it in the relevant thread since I am a new member and don't have ten posts already (forum rules)

I'm desperate.

I have Huawei Ascend P1 U9200..

Completely stock original build (as far as I know) ICS 4.0.3 Build GBRC00B102.

I want to upgrade to JB, but firstly save (backup) my current ROM.

I've followed this thread http://xdaforums.com/showthread.php?t=2132043&page=49 as well as many others, but I cannot access the bootloader.

I have installed adb and fastboot and drivers from many sources. Nothing works.

Hold Vol- & power button still boots normally.

Use adb - adb reboot-bootloader gives Huawei logo frozen, and PC says "waiting for device". The PC brings up install driver dialogue box but no matter what I do, no driver will install. ADB does recognise my phone using "adb devices" command.

Fastboot command does nothing, but I have noticed in my task manager that "fastboot.exe" continually loads and disappears.

Please can someone tell me how to ccess the bootloader so I can install TWRP recovery and backup my ROM??

Apologies if any of the above is unclear - I'm new at flashing/ROMs etc but usually very good at understanding and following computer jargon

Thank you, in advance, for any assistance
[Huawei Ascend P1] Sushant Rohan:
Use Vol+ and Power Button

And for the adb,

Have you installed the correct driver?

The adb/usb driver for your device

May this help you

Give me a thank if helped
[Huawei Ascend P1] nudder12:
Thanks for replying :)

Vol+ and power button enters the recovery section.

I want to unlock the bootloader, so I can install a different recovery module.

As for adb, I'm sure I have the correct drivers. I've tried many different sources, all with same result.

ADB works, but not Fastboot - and I am assuming that is because I can't unlock the bootloader to enter fastboot mode.
[Huawei Ascend P1] Sushant Rohan:
Don't install more than one driver, this may cause the problem with adb. Retain only one driver and then try again later

If this cannot resolve your problem reply me, I would try my best to solve this problem
[Huawei Ascend P1] nudder12:
Thanks for your reply.

The adb driver didn't work on the first install. And later I did remove them all and reinstall again just once (because I was getting an "adb server expired" error).

Still no luck.

If you have any other suggestions, I'd be most grateful
[Huawei Ascend P1] Sushant Rohan:
In the adb shell type

Adb devices

If you see a long number then try the code given above to unlock the bootloader if not then reply me
[Huawei Ascend P1] nudder12:
I've got the number from adb devices.

How/where do I input it?
[Huawei Ascend P1] Sushant Rohan:
May be this link help https://www.dc-unlocker.com/free-huawei-bootloader-unlock-tutorial but here your device is not listed, but you can do a try and have the best of hope. If this did not help you give me a reply as you gave me

---------- Post added at 06:42 PM ---------- Previous post was at 06:33 PM ----------

What you have to do is

Open the adb

Type

adb devices

Adb reboot bootloader

Fastboot oem unlock

May be this help you

Hit the thank button
[Huawei Ascend P1] nudder12:
Thanks again, but I have already tried DC-Unlocker - it doesn't recognise my phone.

I rebooted to the bootloader using adb reboot bootloader,

and then tried the fastboot reboot oem unlock, but it failed with the following message

"FAILED (remote failure)"
[Huawei Ascend P1] Sushant Rohan:
Hmmm. Ok I will get the solution of your problem
[Huawei Ascend P1] nudder12:
Hey Sushant Rohan

Many many thanks for trying to help me, but I think now I have got it working :)

Many times I tried to enter bootloader and the phone wouldn't allow me. Just once in the last 5 days it did. I tried dozens of times!!!

Today, just one time, it allowed me again, and when it did the PC came up with "need to install drivers for Blaze device".

I remember seeing "blaze" on some forums, so I looked there again to see how to install drivers.

I installed them and PC accepted, but then nothing - device not displayed anywhere or anything.

And after that, again I couldn't access the bootloader in many attempts.

I kept trying and kept trying.

Finally, even though I hadn't done anything different, fastboot finally recognised my device (? fastboot) and I flashed the TWRP recovery image using fastboot command.

Fastboot said success!

I rebooted phone into recovery mode - Vol+ and power button, and there it is - the TWRP recovery mode :)

Now I'll attempt phone backup. (looking good so far)

Again, thanks so much for trying to help me - I really appreciate someone giving their time to try.

I have no idea why it suddenly worked for me when I didn't install anything new or different etc (but I remember reading another forum where someone said they tried 39 times and it finally worked)

I'm sure I'll reply here again if I have any more trouble
[Huawei Ascend P1] Sushant Rohan:
Its my pleasure to help someone in trouble
[Huawei Ascend P1] nudder12:
Well, the TWRP backup worked, although I was expecting just one file, but there were many - I suppose I'll have to read some more about TWRP backups!!!

But, booting into bootloader or recovery mode still doesn't work by using the phone buttons - but I can get there using adb commands.

That will have to be enough I suppose.

Thanks again for your efforts
[Huawei Ascend P1] Sushant Rohan:
Use can also use Clockwork Mod Recovery instead of TWRP. However both are mire or less similar. So enjoy flashing
[Huawei Ascend P1] nudder12:
Hopefully the next steps will be a lot less painful and time consuming than this was.

I hope to upgrade from ICS to JB now - but I might wait a few days - my loved ones will appreciate me not being stuck on the pc and phone all day for a while :)
[Huawei Ascend P1] yepi15:
You do not need unlocking bootloader

visit www.shuame.com download just plug bootloader mode by pressing power and volume +. the program takes care of downloading drivers adb
[YU Yureka Q&A, Help & Troubleshooting] Limbudipesh:
The fm app on the device tunes only to frequency that end in odd number frequency like 93.1 and 95.7 etc but doesn't tune to frequency like 104.0, 102.6 which ends in even digit.

Has anyone else faced a similar problem and is there a fox to it?

Thanks in advance
[YU Yureka Q&A, Help & Troubleshooting] ujilraj:
try to clear data & cache of FM Radio app...
[YU Yureka Q&A, Help & Troubleshooting] Limbudipesh:
Found the culprit. Regional band under the setting of the app was set to US and setting it to India fixed the problem.
[Android Q&A, Help & Troubleshooting] cutjo:
Hello!

First ! Sorry for my English!

Is there a chance to make self an working LK.BIN for my P6I Elephone!

The Prozentage showing in the screen isnt correct! from 100% to 92% then to 70% then to 59 or 40% and akku is zero!

not always the same ! But at 50% or 40% always to zero (0) ! i hat that!

or can anyone make this?

thx for answers!
[LG Optimus 2x] QA Bot:
Q&A for [TOOL] Full Brick Repair (Clean & Easy)

Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.

Before posting, please use the forum search and read through the discussion thread for [TOOL] Full Brick Repair (Clean & Easy). If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.

Thanks for understanding and for helping to keep XDA neat and tidy! :)
[LG Optimus 2x] blossomcutie:
Anyone with a fresh link please.
[LG Optimus 2x] tropaect:
link

I need to unbrick my p990 but your link is dead... can you host it somewhere else?
[LG Optimus 2x] typofonic:
In the same boat :confused: Anyone have a link?
[Verizon Motorola Droid Turbo Q&A, Help & Troublesh] nlinecomputers:
Just got my Droid Turbo Sunday after having a Moto X 2013. On my Moto X the Owner toggle had my Name and photo from my Google + account info. I've logged into Google + on my new phone but the toggle still says Owner with a blank photo icon. Pressing it takes me to a blank ME profile in people. I have a contact for myself already in my phone, carried over for years from phone to phone via Google and Exchange.

Is there a way to set this up using the Google+ profile or point it to my existing contact? Not a big deal to do so, just curious if I was overlooking something.

Thanks.
[Verizon Motorola Droid Turbo Q&A, Help & Troublesh] the_rooter:
link up google plus and the google photos app and should be golden. May have to do a reboot
[Verizon Motorola Droid Turbo Q&A, Help & Troublesh] nlinecomputers:
???

I don't follow what you mean at all.
[Verizon Motorola Droid Turbo Q&A, Help & Troublesh] the_rooter:
on the phone open up google + and the google photos apps and let them load up. normal set up when u download them. Once u reboot the user contact should show up.