yashsingh1/xdaforums huggingface dataset:
[General Questions and Answers] vaibhudgr8:
can i install jelly bean cutom rom which is for galaxy y on xda...im my spice mi 280 bcoz it is dual sim....
[Android Q&A, Help & Troubleshooting] guiillaume-d:
hello I have a problem with sms notifications! there are answer / call / read? :confused:

how to disable it please ?

Thnk

Sorry for my english i'm french
[Android Q&A, Help & Troubleshooting] dexter1123:
I think these r good and wud love to have a delete option as well bcoz most of SMS I receive r spams.
[Android Q&A, Help & Troubleshooting] guiillaume-d:
I hate this !
[AT&T Samsung Galaxy S II SGH-I777] Cyanescen:
So after my original usb port completely crapped out on me I bought a replacement online. After installing when I plug in my usb it immediately reboots and just does this reboot cycle again and again. I've tried two separate usb ports, both do the same. The any ideas?

You've been hit up by the original Cyanescen
[AT&T Samsung Galaxy S II SGH-I777] willbs94:
You might not have everything securely fastened to the mainboard. Check that first.

Its like something is shorting out or isnt grounded.
[AT&T Samsung Galaxy S II SGH-I777] Cyanescen:
I think it was uh improper grounding hence the importance of sticky tape that comes on the components. I took it apart again and just stuck it down all that much better and it seems to work properly now

You've been hit up by the original Cyanescen
[AT&T Samsung Galaxy S II SGH-I777] willbs94:
Well I had an issue with the one I ordered and it caused me to have no signal... I'm glad you got yours working
[AT&T Samsung Galaxy S II SGH-I777] Volcomstone000095:
Hey I was wondering, could you send me the link to the one you bought? I bought one online but they sent me the wrong one, and refunded my order so if you could send me the link to the working one that would be great! Thanks :)
[AT&T Samsung Galaxy S II SGH-I777] wildiin:
where did you get it?
[Nexus 7 Q&A, Help & Troubleshooting] crazysorku:
When you wipe your data do you lose your backup as well?

Recently got a Nexus 7 and I'm kind of new to this stuff.
[Nexus 7 Q&A, Help & Troubleshooting] Kiwyxda:
UP +1000

I have the same question.

I use TWRP recovery and in fact I figure out that wiping data is wiping your virtual sdcard also, I can't understand why and ca't find any viale workaround.

It 's due to new feature of android 4.2: Multi user

If someone knows how to wipe data without wiping sdcard
[Nexus 7 Q&A, Help & Troubleshooting] rcarnes911:
I just use my drop box fit all my back up stuff
[Nexus 7 Q&A, Help & Troubleshooting] VanillaG0rilla:
The only way it will delete your sd card is if you choose to delete internal storage.

Wiping data/factory reset doesnt delete whats on the internal sd card.
[Nexus 10 Themes and Apps] flight777:
Hey.

I stumbled upon this browser last week: https://play.google.com/store/apps/...=W251bGwsMSwxLDEsImNvbS51Yy5icm93c2VyLmhkIl0..

Its called UC Browser. Works great with flash (best of all browsers I tested, with this you can actually use flash in full screen... ) It also looks great, better than Ocean. Haven't done any benchmarks but it feels fast and that is what is important. Just to give you guys a heads up.

EDITED THE LINK WORKS NOW

Found this browser test as well. UC seems to be the fastest browser currently around: http://www.youtube.com/watch?v=wRaGdAkq_NE
[Nexus 10 Themes and Apps] digitalrelic:
Thanks! I love Ocean but I'll have to check this out :).
[Nexus 10 Themes and Apps] houseboatwayne:
Really nice. Great find.
[Nexus 10 Themes and Apps] xJakeyy:
Gonna give a try now, great find!
[Nexus 10 Themes and Apps] flight777:
Tell me what you think after :)
[Nexus 10 Themes and Apps] ShadowVlican:
Its small size leads me to believe it's only a front for the built-in rendering engine.. pass
[Nexus 10 Themes and Apps] dadebue:
Flash

Overall very good, but i'm not able to play flash in fullscreen mode...
[Nexus 10 Themes and Apps] xJakeyy:
Tried it out for quite a while, and I've got to say it is very fast! Flash plays fine, and I've not had any problems so far.

My only issue with it is that the buttons on the side always seem to come back even when I disable them. (The page down/page up buttons)
[Nexus 10 Themes and Apps] digitalrelic:
It's a pretty decent browser but unfortunately it can't hold a candle to Ocean as far as scrolling speed goes. Thanks for the find but I'll stick to Ocean :).
[Nexus 10 Themes and Apps] 3473:
check out 'floating browser flux'

scrolling is VERY smooth... i normally run two windows side by side, works great on the nexus 10
[Galaxy Note 10.1 Themes and Apps] eumel79:
Hi

get someone Swipeswitcher to work on the Note 10.1?

It recognize my Gestures, but don't open the last used App.

Rick
[Galaxy Note 10.1 Themes and Apps] Jasonchewy91:
Never tried it before but not going to coz I have swipepad, Appclip, Dock4droid which are all nice. You can try them!
[Galaxy Note 10.1 Themes and Apps] eumel79:
I'm looking for an app to simply switch bettween the last two oppened apps with a gesture /swipe, blackberry playbook like.

To optimize my workflow, one app read the ebook,second app write down notes.

I want it this way because the multiwindows are too small for me to work effective.
[AT&T, Rogers HTC One X, Telstra One XL] waydhee:
Dears

Does anyhas link to ruu htc one xl

I needed at once
[AT&T, Rogers HTC One X, Telstra One XL] CheesyNutz:
:what: :screwy: :what:
[AT&T, Rogers HTC One X, Telstra One XL] superchilpil:
I found multiple lists of them by searching, you should do the same.
[AT&T, Rogers HTC One X, Telstra One XL] ECEXCURSION:
Searching in a language you don't speak is slightly harder. (obviously English is not this person's first language)...

Might have well have just copied and pasted links for this person since you already did the search successfully.

Sent from my HTC One XL
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.

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:

#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.
[Galaxy Note II, Galaxy S III Developer Discussion ] Chainfire:
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://xdaforums.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 :)
[Galaxy Note II, Galaxy S III Developer Discussion ] supercurio:
@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.
[Galaxy Note II, Galaxy S III Developer Discussion ] RyanZA:
Hey curio,

No need, here is a very quickly put together app in 5 mins that lets you toggle on/off world writability to /dev/exynos-mem

So you can toggle the fix off if you want to use the camera, then toggle it back on afterwards.

Github source: https://github.com/Ryan-ZA/exynosfix

APK Download: https://github.com/Ryan-ZA/exynosfix/raw/master/exynosfix.apk

Ryan

MOD EDIT: Removed attached download, as it is out of date compared to the linked download
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
OK, we're getting into technicalities here, but I consider anything that can be exploited by a Market app without explicit user intervention beyond installing an app (reboot cycles, ADB, etc.) to be "remote". Adam covered how easy it is to bypass Bouncer at BABBQ, so relying on that is a bad idea.

Prior to this, all exploits (restoreRoot, mempodroid, etc) for ICS on Exynos4 devices required ADB to be involved. This doesn't.

And no, you can't cause permanent damage to an HTC with root. The example you provided isn't permanent damage, it can be repaired via JTAG at a service center. Superbrick is *permanent unrecoverable damage that requires a motherboard replacement - JTAG cannot bring a device that has been damaged back to operation*. That's a difference between 0 material costs and maybe 30 minutes of labor to repair at a service center and $200-300+ in material costs and significantly more labor.

And your "updates take considerable time" is bull****. Sprint FI27 was built on September 27 (check the kernel build date), 3 weeks after Samsung had the final version of their protection patch, and was deployed on Kies a matter of *days* later. They had an update scheduled, a patch ready to go for three weeks before the update was built, and they shipped without the patch. There's no excuse for that. At that time, it was an "open source problem" because it only affected custom firmwares, and any root exploits known required ADB. Their approach was dependent on an assumption that *an exploit like this would never happen* - which is a horrible assumption.

This exploit changes things - there is no a root exploit that can be used by an app straight from the market, in the background, with little to no user intervention.

As to the negative effects of 600 permissions on operation (such as killing camera) - as an interim, setting things to 660 instead of 666 makes things somewhat better protected but not as protected as they should be. I will run some tests later today to confirm that at least any old APK can't get privilege elevation if things are set so only the graphics group can diddle with the memory regions.
[Galaxy Note II, Galaxy S III Developer Discussion ] supercurio:
Yes what I also started writing allows to restore permissions on /dev/exynos-mem in case you need to use camera, I agree its useful!
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
The assumption of similar base code isn't a good one... You'd be shocked how many deltas there are between I9100/I777/N7000 stock firmware codebases that shouldn't be there given how similar the devices are.

In the region of the system we're dealing with here (graphics memory allocation), there are significant differences in operation between Exynos 4210 and 4412. There are also significant deltas between the implementations in all of Samsung Mobile's devices and the official public reference source, and frequently deltas between Samsung's implementations for various handsets/tablets that shouldn't be there as you've discovered.

For example, the official reference source does allocations from FIMC1 memory regions in gralloc to support various graphics items. Nearly all of Mobile's implementations allocate ION memory instead of FIMC1 memory even when FIMC1 memory is requested (and yes, this change affects camera operation more than anything else.)

Thanks for the headsup on N80xx, I'll def. have to do a rebuild on N8013. It's pretty frequent for us to have brokenness that doesn't exist on I9300 and vice versa.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Hmm, odd... even when chmodded 660 system.graphics, the exploit appears to succeed on CM10.1 from within an ADB shell...

I need to look more closely at this.

Seems like the shell user is a member of the graphics group...

I think AndreiLux's approach he's working on may be the best.

Has anyone tested to see what the effect of 0600 is on hwaccel video playback? (Seems to be none on CM10.1).

Looks like it's anything that wants FIMC memory that needs exynos-mem, I'll double check ION, that should have failed...

Edit: Yeah, gralloc only accesses exynos-mem when attempting to access FIMC1 memory. I think camera is the main other place where FIMC is used. Actually, in any shipped handset, gralloc should never actually access exynos-mem - gralloc will give ION memory when you ask it for FIMC1 memory, and ION memory allocation doesn't use exynos-mem (hmm, unless libsecion does... I need to check that...)
[Galaxy Note II, Galaxy S III Developer Discussion ] supercurio:
Because your shell is in graphics group.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
I was beginning to suspect that, thanks for confirming.

Right now older custom kernels will. CM's codebase was just patched earlier today to restrict that node to system.graphics 0660

It was done in the 10.1 branch, so it won't immediately affect all devices. We're working on transitioning all exynos4 devices over to 10.1 this week - it's about halfway done.
[Galaxy Note II, Galaxy S III Developer Discussion ] supercurio:
@alephzain, when running the exploit in an adb shell, sometimes the privilege escalation fails with:

[*] s_show->seq_printf format string found at: 0xC07A70A8

[*] sys_setresuid found at 0xC00945A0

[*] patching sys_setresuid at 0xC00945E4
[!] set user root failed: Operation not permitted

And it typically succeed after 1 or 2 more attempts.

Does it ring a bell?
[Galaxy Note II, Galaxy S III Developer Discussion ] Chainfire:
ExynosAbuse APK updated to v1.10

I've just updated the ExynosAbuse APK to v1.10 !

This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well. This is for people who actually *want* root. If you don't want root, you should use Supercurio's solution as it doesn't depend on being rooted it for dis/reenabling the exploit.

http://xdaforums.com/showthread.php?t=2050297
[Galaxy Note II, Galaxy S III Developer Discussion ] supercurio:
Voodoo Instant fix for Exynos Mem Abuse vulnerability released.

I'm glad I have a blog, because things tend to disappear here ^^

Edit: Please use the following thread to discuss this specific solution: http://xdaforums.com/showthread.php?t=2051290
[Galaxy Note II, Galaxy S III Developer Discussion ] RyanZA:
As per requests, I added in 'fix vulnerability on boot' functionality for those who like an open source fix.

Nice work on that app, curio. :)
[Galaxy Note II, Galaxy S III Developer Discussion ] julandroid:
First, thank you both for the hard work and quick release.

The main question here is, how efficient is the current implementation in both applications, regarding the protection at start up?

As long as I understand Chainfire somehow ensures that the fix will be applied before running any other (normal) application. Is it possible to install a new application, which to put itself on top of execution chain and exploit the hole, before your application is able to do a 0600 chmod?

If I understand correctly the supercurio's app doesn't promise anything on that matter?! If that is the case, then I guess the recommended app (for rooted phones) will be the Chainfire's solution, right?
[Galaxy Note II, Galaxy S III Developer Discussion ] Chainfire:
Correct.

At the moment, Supercurio's method relies on Android starting it at boot, using the same method any Android app uses to launch at boot. There is no guaranteed order of these apps being launched, and as such, a malicious app could be executing malicious code before the exploit is disabled.

RyanZA's method relies on the same mechanism as well and as such is still vulnerable. Furthermore, unlike Supercurio's and my own patch, RyanZA's patch chmod's to 0600 while ours chmod to 0400 or 0000. With 0600, system user can still run the exploit, so chaining a half-exploit that only gives system user followed by ExynosAbuse may still grant an attacker root access.

My method requires proper root and modifies /system, and disabling the exploit is done before any normal Android app (like those installed from the Play store) have a chance to execute their code. As long as you tell my app to disable the exploit at boot before you install a malicious app, and providing you do not grant a malicious app root (through SuperSU), this should protect against any exploit. Also note that after enabling applying the patch at boot, you can unroot in SuperSU again (SuperSU --> Settings --> Full Unroot) and the patch will keep working, but you'll be unrooted again (if you don't want root). On some devices it takes a reboot for SuperSU to truly disappear after that, by the way.

With my patch, I do advise testing the exploit was disabled after a reboot by running ExynosAbuse again, and verifying both checkboxes next to "Disable exploit" and "Disable exploit on boot" are enabled. These auto-detect the current state, and if the patch on boot was succesful both will be checked.
[Galaxy Note II, Galaxy S III Developer Discussion ] Yank555:
As a preliminary quick-fix the chmod could also be handled in ramfs to ensure it's applied as soon as possible in the boot process.

By the way chmodding to 600 didn't brake any of both cameras on a Samsung 4.1.2 based ROM using the old libs with an update 6 kernel on my dev. S3. Will check if it's also behaving like this on 4.1.1 later today.

JP.

Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3b Aroma (Linux 3.0.56) powered Galaxy S3 i9300 using Tapatalk 2
[Galaxy Note II, Galaxy S III Developer Discussion ] Chainfire:
Correct. Modifying it in initramfs would be even quicker, but a generic app can't do that. Also chmod to 0400, not 0600.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
This is already the current implementation in CM10.1 - exynos-mem is 660 system.graphics

So you need to be running in the graphics group to use the exploit. 660 system.graphics will block the easiest routes to abuse, but it may be possible for an app with camera permissions to do the privilege escalation. Not sure.

That is why I'll be working on getting Andrei's patches integrated into the smdk4210 kernel tree tonight. I think I just need to port his mach-midas changes over to mach-u1. Also on CM, I need to port his mach-midas changes to mach-p4notepq

Andrei, can you clarify your comment about CONFIG_CMA_DMA? Are you saying the fix is neutered if that config isn't used? The way I read your post, it sounds like you're saying the fix won't work on Note2 or Note10.1 (Exynos devices with 2GB RAM)?

That's odd. 0600 should block shell users from exploiting - 660 won't as the shell user has graphics privileges.
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
I meant that the whole mmap function is neutered if that configuration isn't set; it will always return -EINVAL. Currently only the 1GB S3 has that option enabled and the CMA framework is used for the camera (until now, somebody will still have to test HDMI). I tested the patch as it is on an N2 and everything works as it should.

So recap:

CMA_DMA enabled: filters through all the memory blocks and only lets through s3c-fimc. (S3, likely needed on the 4210 devices too)

CMA_DMA disabled: blocks everything, makes the device driver basically useless. (Currently all the 2GB devices)

The fix can actually just be just condensed to two lines checking the hard-coded memory addresses of the fimc device and denying access if it doesn't match, but I guess like this it's more dynamic to the other spaces in case they might be needed. I like to over-engineer (and I also think Samsung will expand the CMA-DMA framework for more device drivers in the future).
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
OK, thanks for the clarification.

Interesting, I wonder how N80xx libcamera sets up FIMC then. This might be useful in getting opensource gralloc/HWC working better on CM10.1, your discovery tells me there's some way to use FIMC without having the reserved FIMC regions... hmm...

Insignal's reference source relies heavily on multiple FIMC memory regions. Mobile's less so - gralloc never uses/provides FIMC memory itself, but camera use a second FIMC engine (FIMC2 I think) as an abstraction layer for camera data. It sounds like Mobile's newest implementations use the FIMC engine without any need for FIMC reserved memory, or at least not without any need of mapping it via exynos-mem.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Well, Samsungs have always been easily rootable *in a safe manner without exploits that make the system vulnerable to blackhats*. Rooting via flashing a system image in Odin pretty much can't be abused except if your device's physical security is compromised (someone grabs your device, flashes ??? to it, and returns it, a fairly unlikely attack scenario).

Doesn't surprise me... Samsung has changed their graphics architecture significantly (especially in terms of memory usage/allocation) at least 3-4 times in the past year (as evidenced by the wildly different reports of whether certain permissions changes break camera or not). Only one of those variations (that in new/old Insignal source and Hardkernel source) is documented, and that's so ancient that it predates any Samsung Mobile firmware release that ever shipped to users as far as I can tell.

I've backported Andrei's patch to Exynos 4210. It seems to be working:

shell@android:/data/local/tmp $ ./exynos-abuse
[!] Error mmap: Invalid argument|40067121
1|shell@android:/data/local/tmp $

This previously succeeded.

Camera seems to be as working as it was before - photos and video still work. hwaccel video decode also works other than Netflix, but Netflix was busted to begin with.

Patch is now under Gerrit review at: http://review.cyanogenmod.org/#/c/28568/
[Galaxy Note II, Galaxy S III Developer Discussion ] pongster:
On an N7100 4.1.2 ROM , I have observed that using Andrei's patch causes the camera to fail and not even show the green screen.

Changing permissions to 0400 or 0600 for /dev/exynos-mem stops the exploit, as posted by the OP, from gaining a root shell. However, these 2 permissions break the rear camera and give me a green screen on 4.1.2.

Setting the permissions to 0606 or rw for others is the only way I can get camera working on 4.1.2.

What workaround would allow me to have camera working while stopping the exploit from potentially causing any damage? I can use Chainfire's app (and let users toggle it for camera to work when they need it) but it could get cumbersome for users.

Using an older 4.1.1 camera .so might work as some have confirmed, so does that mean we need Samsung to update/revert to use a camera .so that doesn't need /dev/exynos-mem to have others with rw access so that restricting permissions on it fixes the exploit and gets camera working on 4.1.2 Samsung Stock ROM's?
[Galaxy Note II, Galaxy S III Developer Discussion ] Yank555:
Using the 4.1.1 camera .so (1 file) is all that is required on a 4.1.2 ROM to make camera work even if fileaccess to eynos-mem is 400 (on i9300 at least). Everything linked works, too, video recording, best face etc.

JP.

PS : I posted the libs here.

Sent from my custom Paranoid Android 2.54 / Yank555.lu CM10 kernel v1.3d Aroma (Linux 3.0.57) powered Galaxy S3 i9300 using Tapatalk 2
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
I'm confused... Since you maintain your own kernel, why not just pull in Andrei's patch?

Edit: Ooops, missed one of your posts. I'm guessing you need to make an alteration to your patch to do the cma_add_region_descriptor calls in specific locations. The 4210 patch might be of use to you - on 4210, mach-u1 contained a duplicate of the reserve_mem.c implementation for CMA stuff. I'm guessing the issues you encountered will also affect N80xx, which I plan on looking at tonight.