Related
The devices are similar enough, maybe a Desire/Eris dev can take a look to find a root.
developer.htc.com
CDMA Hero users are getting ready to see our world turned upside down. Soo much is getting ready to happen, hope to see you get root soon!
Will the Sprint Hero kernel be the same as the one for our phone?
I can confirm that the CDMA Hero source makes reference to our device specific flag (CONFIG_MACH_DESIREC) in a couple different places (all in arch/arm/mach-msm/). It is worth noting that almost all the same references were found in the original Hero source. The only thing that has been added for our architecture alone was an isCDMA flag in what appears to be USB descriptor.
That said, I don't believe this is exactly our source. Based on hardware release timelines, I would expect to see ours within the next 1-2 months.
EDIT: Following up, I would expect to see our source contain files like: arch/arm/mach-msm/board-desirec-xxxxx.c
As currently these device-specific files (board-heroc-xxxx.c) are explicitly built in the Makefile by the CDMA Hero specific switch (CONFIG_MACH_HEROC).
pinksocker69 said:
I can confirm that the CDMA Hero source makes reference to our device specific flag (CONFIG_MACH_DESIREC) in a couple different places (all in arch/arm/mach-msm/). It is worth noting that almost all the same references were found in the original Hero source. The only thing that has been added for our architecture alone was an isCDMA flag in what appears to be USB descriptor.
That said, I don't believe this is exactly our source. Based on hardware release timelines, I would expect to see ours within the next 1-2 months.
EDIT: Following up, I would expect to see our source contain files like: arch/arm/mach-msm/board-desirec-xxxxx.c
As currently these device-specific files (board-heroc-xxxx.c) are explicitly built in the Makefile by the CDMA Hero specific switch (CONFIG_MACH_HEROC).
Click to expand...
Click to collapse
That may be true, but your biggest obstruction right now is unable to root the phone. It's possible that, although the phone section itself isn't exact, the rest of the kernel may be a match. If so, you may take a look for any vulnerabilities that you can use to root the phone.
tkirton said:
That may be true, but your biggest obstruction right now is unable to root the phone. It's possible that, although the phone section itself isn't exact, the rest of the kernel may be a match. If so, you may take a look for any vulnerabilities that you can use to root the phone.
Click to expand...
Click to collapse
We know that the CDMA Hero is vulnerable to the Bluetooth socket/sendpage local root escalation, which the Eris is not vulnerable to. That alone is enough to make me bench it for now.
how would you go about finding a kernel exploit?
laxattack said:
how would you go about finding a kernel exploit?
Click to expand...
Click to collapse
Tenacity. Deep knowledge of the linux kernel. Tracing through HTC's custom code and hoping to get lucky.
I know I'm probably not up for finding and writing my own exploit. Tracing through the VMSplice exploit was like looking at a book written in Chinese, and I don't consider myself awful at C. The bluetooth socket/sendpage bug was much more readable, but also a once-in-a-blue-moon exploit, I think. If someone else found an exploit, I think I'd be in at least an okay position to try to port and modify it to suit our needs, but that's about it.
me + linux, C, or code in general = :-( so that bubble just popped, lol, but my friend is a wiz at linux so time to send him the cdma hero source just for giggles, hey you never know
True! Just let him know that the major security holes (bluetooth/sendpage and vmsplice in particular; you'll see binaries exploiting these in the Hero forums referred to as asroot and asroot2) have already been patched for our phone. Thanks for bringing another into our fold!
WARNING
The topics discussed below are THEORETICAL only, and don't imply real world feasibility.
WARNING
That being said, let me test my understanding of how the system works:
The Droid 2 has a 'locked bootloader'. This means that the kernel has an RSA signed hash. THEORETICALLY, one could break the RSA key into its two component primes to determine the private key and enable anyone to sign a kernel correctly, thereby allowing custom kernels on the device.
If this is the case, where does the eFuse technology come into play? Is it merely a means of hard wiring the correct hash into the phone?
Also, assuming the above is correct, where can one find the public key used in the RSA key pair for the Droid 2? Thank you for your time.
I actually thought of this a couple months ago, but never got around to asking, I'd like to know also.
Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.
noctolater said:
Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.
Click to expand...
Click to collapse
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?
DeBaKai said:
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?
Click to expand...
Click to collapse
Even using the General Number Field Sieve, which is the best known large integer factorization method currently available, it took a group of researchers 2 years to crack a 768-bit key in 2009 (look up RSA numbers). Every bit you add doubles the difficulty of the problem, meaning a 1024-bit key would be 10^77 times harder to crack. By their estimations, it will be feasible in roughly ten years time.
So no, I don't think the Devs would have unlocked it by now. And this is why this is a THEORETICAL discussion, instead of a practical one. I understand that what I am talking about is probably not possible at this time, I just want to make sure I fully understand how the manufacturers are locking down the phones. Thanks for you time.
I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.
DeBaKai said:
I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.
Click to expand...
Click to collapse
I did do research, about a weeks worth of Google searches, before I posted this. I couldn't really find any concise locations of information, so my knowledge is piecemeal at best. I just want to test my understanding of the concepts, even though it serves no practical purpose.
That being said, if you have any links to concise descriptions, I would be more than happy to see them
Fair enough. Although I think it may take a while before you get your answer.
Unfortunately, my knowledge in this particular subject is limited. I'm not going to be of any real help. Good luck with this, though.
Mod edit: This thread is a copy of a thread originally posted in the "development discussion" section. General posts should be made in this thread (and not in the original.) Only posts which follow the guidelines of the Development Discussion section should be made in the original thread (located here: http://forum.xda-developers.com/showthread.php?t=2048511)
Now find a one-click root application at http://forum.xda-developers.com/showthread.php?t=2130276. More exploits coming.
Hi,
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory ... what's wrong with Samsung ?
Its like /dev/mem but for all.
Three libraries seems to use /dev/exynos-mem:
/system/lib/hw/camera.smdk4x12.so
/system/lib/hw/gralloc.smdk4x12.so
/system/lib/libhdmi.so
Many devices are concerned :
Samsung Galaxy S2
Samsung Galxy Note 2
MEIZU MX
potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
The good news is we can easily obtain root on these devices and the bad is there is no control over it.
Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.
Edited
Some details :
/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)
The operations allowed on the device are (from linux/drivers/char/mem.c) :
Code:
static const struct file_operations exynos_mem_fops = {
.open = exynos_mem_open,
.release = exynos_mem_release,
.unlocked_ioctl = exynos_mem_ioctl,
.mmap = exynos_mem_mmap,
}
and the default permissions (from linux/drivers/char/mem.c) :
Code:
#ifdef CONFIG_EXYNOS_MEM
[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
| S_IWOTH, &exynos_mem_fops},
#endif
ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
Now the interesting part : mmap operation.
The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
Code:
/* TODO: currently lowmem is only avaiable */
if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
(phys_to_virt(start) >= high_memory)) {
pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
return -EINVAL;
}
The comment in above code could be frightening.
And an eye in Documentation/arm/memory.txt say :
Code:
Start End Use
--------------------------------------------------------------------------
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
In other words, this device only permit to own the physical memory including kernel code.
The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
samsung developper in charge of this would lose his job
some samsung apps with basic rights need to access it (I doubt it)
a huge mistake
A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.
In attachment, binary and source to obtain for root shell.
Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.
Front camera for example:
Code:
#ifndef CONFIG_USE_FIMC_CMA
{
.name = "fimc1",
.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
#if defined(CONFIG_MACH_GC1)
.start = 0x5ec00000,
#else
.start = 0x65c00000,
#endif
},
#endif
Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.
Update: Low-level kernel fix for developers posted here.
A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.
Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)
Also, I'm building an APK for this to make it easy.
EDIT: APK posted here: http://forum.xda-developers.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.
EDIT#2: This app now also lets you disable the exploit
would this trip the flash counter? my guess says no.
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
I'm not very good with Linux, but I did
Code:
chmod 600 /dev/exynos-mem
on my GSII international with CM10 and the camera still works. Am I safe for now?
I'm guessing no, considering /dev/exynos-mem (why would they do that?) but does any similar vulnerability exist for the Qualcomm S3?
thread cleaned. "thanks", "nice", "oooh", "ahh" and remarks about code comments are off topic.
(If you want to discuss what is/isn't of topic, please reply go here: http://forum.xda-developers.com/showthread.php?t=2017367)
supercurio said:
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
Click to expand...
Click to collapse
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
[Edit: to OP, NICE FIND!]
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.
I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? [email protected] is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.
Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
I think we all got the point you're not happy with Samsung.
The issue discussed here is off topic.
Also I'm sorry to observe that your "It'll never happen" on security sounds more like bad-mouthing than an informed comment.
On a more technical aspect, as soon as you have root permissions there's a large choice of method allowing to hard-brick or damage hardware without relying on a bug present in some eMMC controllers that I won't of course describe here.
supercurio said:
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
Click to expand...
Click to collapse
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .
I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
Well pointed, for a discover like this they should pay a fortune to alephzain, and other devs that help fixing this security problems, but they just don't care. .
I'm sure they will fix it eventually in the next updates but they will encover it of course and will leave millions of users at risk until that. .they don't want this kind of publicity.
I hope that they give a good reward to our devs that everyday work to improve our devices. .but I know they will not do it. . But that's the fun of it isn't it?
Sent from my GT-I9300 using xda premium
@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art
Your short documentation and clean writing style even made easier to learn from it.
Please keep this on topic: /dev/exynos-mem.
Sent from my SAMSUNG-SGH-I317 using Tapatalk 2
yugoport said:
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .
I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.
Click to expand...
Click to collapse
This is not Samsung-specific in any way.
Fortunately most people discovering security flaws inform original authors so they can fix the issue and release updates before the exploit is publicly released.
I'm not judging alephzain here, because its possible he tried to report the issue but found no-one listening, taking him seriously, or simply couldn’t find who to contact, hence my question to him to know if he tried or just didn't care, also because I'm a fan of the technical exploit and use similar method in my apps as apps to do things not supposed to be done.
Millions of vulnerable devices are out there now. This exploit which is very well designed and I believe very hard to detect if carefully hidden inside an Android app.
It means privacy, security of a large amount of people and corporation is at a larger risk right now as the manufacturer didn't had the chance to provide a security fix to its users, because of not being aware of the issue.
What a nuisance!
The most important question is - how to quickly patch this?
A simple chmod 0600 /dev/exynos-mem does not survive reboot.
Any ideas that does not envolve unpack/pack update images?
julandroid said:
What a nuisance!
The most important question is - how to quickly patch this?
A simple chmod 0600 /dev/exynos-mem does not survive reboot.
Any ideas that does not envolve unpack/pack update images?
Click to expand...
Click to collapse
Nobody wrote yet an app that fixes the issue?
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.
For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
julandroid said:
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.
For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
Click to expand...
Click to collapse
As far as I'm concerned I already implemented a fix into the kernel to just whitelist the FIMC0 memory space for the mmap function and to refuse access to the rest of lowmem. I'll post it later when I sorted some things with the other DMA spaces.
Okay I feel lazy this Sunday night but will still quickly write an app that fixes the vulnerability (simple chmod 660) at boot.
Just for the sake of it.
(Breaks camera on S III, not on Note II)
Quite a few of us xda lurkers are itching to get root on our devices, but the DRM-debacle of the Sony phones has made many, including myself, hold off with unlocking the bootloader. Instead, we've put our hopes to new exploits that would allow root while keeping the bootloader locked, thus making it possible to keep all DRM functions in place, and also to restore the phone to factory conditions with the bootloader intact.
However, as Chainfire explains in the post below, the chances of any such exploit surfacing are slim. He says it's more important than ever to buy phones with unlocked bootloaders if we want to keep root.
Sadly, I'm afraid he's right and that the official bootloader unlock is the only way we'll be able to get root in the foreseeable future.
What do you guys think? Worth it or not?
Check out Chainfire's post on G+:
https://plus.google.com/113517319477420052449/posts/VxjfYJnZAXP
Fruktsallad said:
Quite a few of us xda lurkers are itching to get root on our devices, but the DRM-debacle of the Sony phones has made many, including myself, hold off with unlocking the bootloader. Instead, we've put our hopes to new exploits that would allow root while keeping the bootloader locked, thus making it possible to keep all DRM functions in place, and also to restore the phone to factory conditions with the bootloader intact.
However, as Chainfire explains in the post below, the chances of any such exploit surfacing are slim. He says it's more important than ever to buy phones with unlocked bootloaders if we want to keep root.
Sadly, I'm afraid he's right and that the official bootloader unlock is the only way we'll be able to get root in the foreseeable future.
What do you guys think? Worth it or not?
Check out Chainfire's post on G+:
https://plus.google.com/113517319477420052449/posts/VxjfYJnZAXP
Click to expand...
Click to collapse
Well it's @Chainfire talking, who are we to doubt him? I'm only waiting for a way to backup my TA-Partition (DRM keys), I wouldn't mind losing some features. Even tho I must agree that losing some camera quality is really annoying, but Android is pretty open source so I have no doubts that people will find something to reverse the algorithm loss or create their own.
And also when the occasion occurs that I need to send my device out for repair, that they don't refuse it due to an unlocked BL
I'm sure that's true in the long run, just not sure if it's true now.
It's economics. The security bugs are going to get fewer and further between, but they will arguably never be eradicated. You should expect it to take longer and longer to find new exploits, but I wouldn't bet a wooden nickel that there are no exploits left.
More likely, we will reach a point where the cost of finding an exploit is so great that they're no longer worth looking for to a critical mass of hackers.
On the bright side, the implementations get better all the time, and I see very little about my z3c that I would like to change if only I had root.
And I do think Sony should find a way to make the early rooters whole again. I feel terrible that so many people's $500 phones have been seriously degraded by a completely reversible software change.
Dsteppa said:
Well it's @Chainfire talking, who are we to doubt him? I'm only waiting for a way to backup my TA-Partition (DRM keys), I wouldn't mind losing some features. Even tho I must agree that losing some camera quality is really annoying, but Android is pretty open source so I have no doubts that people will find something to reverse the algorithm loss or create their own.
And also when the occasion occurs that I need to send my device out for repair, that they don't refuse it due to an unlocked BL
Click to expand...
Click to collapse
True, but as I'm sure you're aware, backing up the TA-partition requires said exploit to be found in order to get root. So I think it'll be a looong wait. [emoji20]
He still thinks root will be achievable in the early editions of Android L so I think it's safe to say root will arrive for this device under a locked bootloader, it will just take a bit longer than it has in the past to find an exploit.
Sent from my D5803 using XDA Free mobile app
This is really disheartening. It's kinda ironic that Sony, who in recent times has been raised in its support of the developer community of its phones, and even won XDA's OEM of the Year, has such a downer in its phones.
I know this doesn't work for everyone but I'm hopeful that the new AOSP L camera API will mean that AOSP custom roms have some native low light enhancement processing. Maybe...
Chances improve with new software so I t could happen with android L too.
pricey2009 said:
He still thinks root will be achievable in the early editions of Android L so I think it's safe to say root will arrive for this device under a locked bootloader, it will just take a bit longer than it has in the past to find an exploit.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
Yup, but we're still looking at about five months wait considering Sony won't ship L until Q1 2015. Even then, there's no guarantee an exploit will be found.
Maybe I'm overly pessimistic about this. I do, however, have high hopes for the new camera API's regarding camera quality and post processing.
Personally, every day without root is a little painful, so I'll never last all those months. As soon as there are custom kernels available and a ROM like CM or PA, my locked bootloader goes bye-bye.
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
Let's hope Sony make or have made some little security mistakes.. To quote his post:
" Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on."
Here's hoping they have missed something.
Sent from my GT-I9300 using XDA Free mobile app
pricey2009 said:
Let's hope Sony make or have made some little security mistakes.. To quote his post:
" Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on."
Here's hoping they have missed something.
Sent from my GT-I9300 using XDA Free mobile app
Click to expand...
Click to collapse
Let's wait until January for the first android L release then :crying:
I've rooted two weeks ago and still enjoying the phone
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
This.
The post was mainly aimed at Android L...
Google hired one of our very own (Towelroot) and iPhone's pioneering hacker so it's going to get tougher. I hope they hired him only for NSA purposes.
That move by sony is just stupid. if they wanted to protect their code, why not store it into the camera firmware (referring to the camera algorithms)?
Why do they have to kill Miracast?
Obviously that is the other side of the medal. investments on security = far less exploits available. we are gonna wait a while, but as a developer I really really miss Xposed. Each time I look at my G2 a little tear drops.
No way I'm gonna root loosing DRM keys. The camera is already weak (to be honest I would be used a word beginning in shi but let's be polite) so I'm not in any way gonna make it worse.
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
Yes he does:
"As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well."
Then he goes on to say:
"Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now."
zxz0O0 said:
Chainfire is talking about the su daemon and problems running it (on Android L). He does not say anything about a root exploit. It seems you misunderstood his post.
Click to expand...
Click to collapse
How can anything be a root exploit if it doesn't result in a functional su? I read Chainfire's post as Google making it impossible to elevate privileges from within Android, necessitating kernel level exploits which in turn will require unlocked bootloaders to install.
Once we get to where the bootloader has to be unlocked it's really not a root exploit anymore, is it?
michyprima said:
Why do they have to kill Miracast?
Click to expand...
Click to collapse
Because they don't want to support Miracast without HDCP. Remember that Sony is also a content provider. While that may be as annoying for a normal user as the degradation in camera quality, their approach actually still is developer friendly. Request a code - get full control over the device, at the cost of losing some functionality (software functionality). It's as simple as that. CM and other roms work perfectly fine on Xperia devices, and if you want to implement an equivalent camera algorithm, you're free to do so.
Iruwen said:
Because they don't want to support Miracast without HDCP. Remember that Sony is also a content provider. While that may be as annoying for a normal user as the degradation in camera quality, their approach actually still is developer friendly. Request a code - get full control over the device, at the cost of losing some functionality (software functionality). It's as simple as that. CM and other roms work perfectly fine on Xperia devices, and if you want to implement an equivalent camera algorithm, you're free to do so.
Click to expand...
Click to collapse
Can only agree to that. If you buy a Sony phone to act like a Sony phone (most people do!) then one should leave it as it has been delivered by Sony. If you can't agree to how it is, Sony gives you the option to unlock the BL and do whatever you want to do with the HW, but don't expect it to work/act as before. Personally, I have no issues with that at all.
On a different note, Linux/Android is comprised of x million lines of code. There're bugs in this code, there're bugs in the compiler, bugs in Java, bugs even in the Hardware etc. etc. There's no reason to believe (or fear) that Linux/Android would ever be perfect or non-vulnerable. Root will come, it's only a matter of effort and time...
http://www.phonearena.com/news/The-Pixel-and-Pixel-XL-will-be-rootable-Google-confirms_id86575 for all the naysayers...google did not let us down
I did not doubt it but it is good that it is confirmed
Confused - That doesn't really make sense - While Google can (and thankfully will) make the bootloader unlockable, they don't make it rootable. They have never done that. Root is usually achieved when developers find exploits (that are unpatched by Google), and root using that.
For Google to say that the device will be rootable is like saying "we left some exploits unpatched", or "we will provide you a means of rooting" - I don't think either is true. (yes, I read the exact verbiage on the article - and saw what you are referring to)
The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk
tacosrdelicioso said:
The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk
Click to expand...
Click to collapse
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)
jj14 said:
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)
Click to expand...
Click to collapse
My point is it gets us 95% of the way there
Sent from my XT1096 using Tapatalk
The expliot is modifying the kernel. Google knows this as we do. In order to have a modified kernel you must have a unlocked bootloader. While only time will tell i believe the verizon version will never be rooted because of this new security,cause only unlocking the bootloader will allow it, hence what i believe google was getting at, sometimes people read too deep and miss whats on the surface
I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.
Fenny said:
I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.
Click to expand...
Click to collapse
Yeah what he said lol...thanks for the explantion i guess exploit is the wrong word cause it does have a negative implication
yes, even HTC devices that are unlocked and rootable is not SOFF, and you had to pay for it. Does anyone know if there is any such restriction that is "hidden"?
Is it really as "open" as the nexus devices?
Has there been any confirmation on whether or not source will be released...
Sent from my ONEPLUS A3000 using XDA-Developers mobile app