yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy S 4 Original Android Developme] akaimeridia:
Are there any custom recoveries or stock images available yet? I want to do this sooo badly but I'm so afraid my phone will break and $200 will be down the drain >.< I'm just new at this, I've always used iPhones and just switched to the Galaxy S4.
[AT&T Samsung Galaxy S 4 Original Android Developme] scott14719:
Nope, not for custom recoveries and the AT&T S4...well, one exists but can't be used because of the locked bootloader. It will be the end of the month (if not later) before a custom recovery can be tried by the general population. Stock ROM recoveries exist (Odin and Kies) to restore to stock but it is 100% not safe to try anything at this point if you don't know 100% about what it is you are doing. If you try, you will probably be the next, " Guys, please help, I bricked my phone" thread that will probably be posted in the wrong section.
[AT&T Samsung Galaxy S 4 Original Android Developme] akaimeridia:
Thank you!
[AT&T Samsung Galaxy S 4 Original Android Developme] StolenVW:
Looks like its time to frezze them ota update apps

This is said news for the verizon people with them not coming till end of month they might be getting the new kernel from the factory
[AT&T Samsung Galaxy S 4 Original Android Developme] ActorMike:
Which ones?
[AT&T Samsung Galaxy S 4 Original Android Developme] StolenVW:
AT&T Software update

FWUpgrade

LocalFOTA
[AT&T Samsung Galaxy S 4 Original Android Developme] David Dee:
I accepted the Canadian OTA, which I think was very similar to the Sprint one, and I was able root no problem with this method. I am running all of my root apps, all is working and I have yet to see an error. Maybe I need to check something else but so far so good.

I am speculating here, but I think the OTA in Europe was different as it had a larger file size. Anyway, AT&T is on a warpath here so who know what they will throw at you guys when they do an ota, so be careful.
[AT&T Samsung Galaxy S 4 Original Android Developme] StolenVW:
the Europe ota is on baseband version DN i think for last 2 digits

at&t on my phone is DB so pretty far behind them with the baseband versions
[AT&T Samsung Galaxy S 4 Original Android Developme] dbg11235:
I read this in a different thread but thought it somewhat relevant.

Since reading it I have made sure to also block FWUpgrade, LocalFOTA.
[AT&T Samsung Galaxy S 4 Original Android Developme] JJ5150:
Good to go, thanks to the OP
[AT&T Samsung Galaxy S 4 Original Android Developme] David Dee:
After the ota, we are DJ, so are different from Europe as well.
[AT&T Samsung Galaxy S 4 Original Android Developme] StolenVW:
You might be one away from the kernel root lock read somewhere it started with DK
[AT&T Samsung Galaxy S 4 Original Android Developme] Mittaa:
it started with DK ... I'm from Denmark. Does that mean that I can't root my S4 when I get it tomorrow ? :eek:
[AT&T Samsung Galaxy S 4 Original Android Developme] StolenVW:
DK I was talking about is the last two letters in baseband version on the phone nit the country
[AT&T Samsung Galaxy S 4 Original Android Developme] David Dee:
That ota was from Friday. Must be a reason Rogers and Sprint released an earlier kernel version than the i9505 update, especially a version with no lockdown.
[AT&T Samsung Galaxy S 4 Original Android Developme] bigworm50:
go into settings, phone settings, and tap on build number seven times to enable the dev options.
[AT&T Samsung Galaxy S 4 Original Android Developme] ericos123:
thank you i would not have figured that out for the life of me haha, my old phone didnt have it hidden
[AT&T Samsung Galaxy S 4 Original Android Developme] mattdm:
Haha so you quote me and click thanks for him? I see how it is... :p

JK. No problem.
[AT&T Samsung Galaxy S 4 Original Android Developme] ericos123:
ahhh wtf my computer bugged out on me another thanks sent hahaha
[AT&T Samsung Galaxy S 4 Original Android Developme] Baldilocks:
Feels great not to have all those Ads anymore. Thank goodness for ROOT and AdAway.
[AT&T Samsung Galaxy S 4 Original Android Developme] breakingspell:
+1 confirm! Updated su and busybox to test, now to clean off all the bloatware!
[AT&T Samsung Galaxy S 4 Original Android Developme] snakecharmer23:
Thanks.

I can't wait to try this Monday when I get my phone. Root access will make it much easier for me to tame the beast known as TouchWiz while I patiently wait for CyanogenMod to come to this phone.
[AT&T Samsung Galaxy S 4 Original Android Developme] rsmolen:
Confirmed working here as well. Thanks!
[AT&T Samsung Galaxy S 4 Original Android Developme] highaltitude:
Its stuck at Daemon started successfully. Now what?
[AT&T Samsung Galaxy S 4 Original Android Developme] antde201:
The dev noticed this in an earlier post. I believe if you re-download the file provided that an updating adb will be delivered to you. Otherwise it may just be your drivers. Make sure your samsung mobile drivers are up to date.
[AT&T Samsung Galaxy S 4 Original Android Developme] sgs22012:
Any word on whether this works on T-Mobile S4. Planning to pick mine up next weekend....TIA
[AT&T Samsung Galaxy S 4 Original Android Developme] garwynn:
Going to have someone test on Sprint and report back. But looks promising!
[AT&T Samsung Galaxy S 4 Original Android Developme] mu3g:
You sir are a genius!! Worked well :)
[AT&T Samsung Galaxy S 4 Original Android Developme] rawintellect:
Will this work on the Sprint version?
[AT&T Samsung Galaxy S 4 Original Android Developme] highaltitude:
woot! its alive! Awesome! Thanks!
[AT&T Samsung Galaxy S 4 Original Android Developme] droidguru:
delete
[AT&T Samsung Galaxy S 4 Original Android Developme] silkshocker:
How do you turn on debugging mode? I can't 'developer mode' on my ATT S4 it's not there.

---------- Post added at 11:07 PM ---------- Previous post was at 11:05 PM ----------

never mind. Got it! Had to turn it on like I did with Nexus 7.
[AT&T Samsung Galaxy S 4 Original Android Developme] RoscoeDpG:
hope works this well on verizon version lol
[AT&T Samsung Galaxy S 4 Original Android Developme] antde201:
Go to your device settings -> scroll down to where you see your build number then tap it seven times. This will unlock developer options for the phone.
[AT&T Samsung Galaxy S 4 Original Android Developme] rawintellect:
Confirmed. It works for the Sprint version as well. You might want to sprinkle this over in the SG4 section and state it works with AT&T and Sprint. :) I am rooted and loving my phone :)
[AT&T Samsung Galaxy S 4 Original Android Developme] Mittaa:
LOL for a second I was convinced that Danish firmware was the first one locked :laugh:
[AT&T Samsung Galaxy S 4 Original Android Developme] manicmethod:
This isn't an isolated example. See http://www.selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf for many other vulnerabilities mitigated.

Note, I am not advocating locking down devices from their owners. I'd advocate for owners using unlocked bootloaders to put what they want onto the device. What I'm advocating for is using MAC to reduce the attack surface area, of the kernel, privileged userspace components and apps containing private data. The bottom line is, if the owner can root the device through a vulnerability so can an attacker (or malware).
[AT&T Samsung Galaxy S 4 Original Android Developme] gorgy76:
thanks.......this just works with at&t s4 :D:good:
[AT&T Samsung Galaxy S 4 Original Android Developme] SW686:
There's a political/social question (should device makers lock down their phones from end users?) and a technical question (if somebody wants to lock down a phone from the user, what is the most effective way to do so?).

Let's stick to the latter question.

Often that is true, but as we saw with motochopper, shell has DAC permissions that most/all applications lack. I'd wager that most of the adb-related holes wouldn't be exploitable from a Market app.

As the physical possesser of the device, the user would also be able to pop it open to attach a JTAG probe, tamper with the flash memory interface, fool with the USB signals, inject bogus replies from the radio to the host, and mount a number of other attacks that are likely impossible for malware to do.

Smalley lists a number of items that are normally allowed on Android but are prohibited under his SELinux policy:

read /proc/pid/cmdline

read /system/bin/vold

read /dev/log/main

create netlink socket

execute non-system binary

remount of /data by root (he probably means /system here?)

chown/chmod of "su" binary by root

root (actually, various daemons) have full superuser capabilities (CAP_*)

root writing to /proc/sys/kernel/hotplug

signaling an adbd process owned by the shell user

unspecified mprotect() restrictions

writing to tmpfs

The first question to ask is whether it's actually a good idea to impose all of these new restrictions on the apps and users. How many existing apps might break on such a system? Is such a system still suitable for software development?

A couple of these look like they'd break Droidwall and most VPNs right off the bat.

If the end user is prohibited from basic operations like running logcat, will the system even pass CTS?

If he's working for the NSA I.T. department figuring out how to securely deploy Android to a highly sensitive organization, he has a different set of requirements from a manufacturer who wants to sell 50 million phones to unsophisticated teeny boppers who just want their Facebook to work.

Another question is whether MAC is the right way to enforce the new restrictions. Traditionally, the 'M' in MAC implied that the objective was to keep e.g. Top Secret processes from leaking data to Confidential processes, even if they both wanted to do it. This is a different goal from keeping vold and ueventd from tripping over themselves when somebody feeds them bad data. MAC seems like the most obvious fit for the Skype example; the others are still unclear to me.

The last question is: in what situations are these restrictions effective? Hiding /proc/pid/cmdline and program binaries may thwart general purpose malware that's trying to easily compromise a large number of systems, but can they stand up to an intelligent, organized, adaptive attack from the hobbyists on the forums?
[AT&T Samsung Galaxy S 4 Original Android Developme] wdouglass:
Did you reinstall motochopper at all? when i unistalled superuser (step 2) and then installed supersu, i lost root.
[AT&T Samsung Galaxy S 4 Original Android Developme] bongoz:
sorry guys...

i follow the root procedure and it's ok, then when i try to open supersu it says me supersu not found.

Can you help me please??

thank you
[AT&T Samsung Galaxy S 4 Original Android Developme] Uhu911:
Which firmware do you have ...MDM?

It does not work (yet) with MDM firmware?

Are there plans for it to work with MDM?
[AT&T Samsung Galaxy S 4 Original Android Developme] topcat07:
Will this work with MDM firmware uk? i9505 model

would be greatful if anyone could confirm thanks

---------- Post added at 03:07 PM ---------- Previous post was at 02:57 PM ----------

Hi there are you UK based? Thanks for posting results I am on same version and looking for a easy root method not found anything yet.. Everything seems very daunting
[AT&T Samsung Galaxy S 4 Original Android Developme] manicmethod:
Possibly, many vulnerabilities these days are exploited through multiple jumps, see the Chrome hacks where 6 vulnerabilities are chained together. If the last step is getting adb to do something, you already know the destination, just find the way

Yes, or they could build their own phone, but that isn't what we are talking about here.

Probably a very good idea, as these restrictions can prevent malware from rooting your device and spying on you. The most recent policies can pass CTS, which is what is required for app compatibility. If CTS passes and an app breaks it is the apps fault for doing things outside of spec. Software development isn't altered, you can deploy and run apps just the same, you just can't do crazy things that you shouldn't have been able to do in the first place.

root-requiring apps would obviously break. root isn't part of CTS, hence those apps are out of spec. VPN apps on > ICS use a supported API that works fine (the frameworks allocate a tun device, set up routing tables and give the VPN app a handle to the tun, this is all supported in the current policy)

This is NSA R&D. Teeny boppers that don't want their sext pictures pulled off their phones by the smileys they downloaded would benefit from this as well. SELinux, and by extension SE Android is a flexible MAC system, the NSA will have a much more restrictive policy than the one that ships by default on Samsung devices.

_Flexible_ MAC is easily the right way to enforce restrictions. It lets, e.g., BYOD policies be very restrictive about corporate apps and data while leaving facebook alone (aside from not letting it access corporate data), or lets the government separate secret and top secret data. It can implement many security models. Software will always have bugs, you need something the software can't control as your first line of defense. There is a huge philosophical debate over defensive coding vs. MAC, see many OpenBSD threads as an example

SELinux has been used in government systems to prevent attacks for a very long time. These are typically specialized policies rather than general purpose ones though. For general purpose you can only get so much protection but there is plenty of evidence that SELinux has protected Red Hat/Fedora systems in the many years it has been on by default. Most examples center around browser plugins, one recent was a renderer bug in the thumbnailer for nautilus. Without SELinux an infected thumb drive could exfiltrate all your personal data, MAC isn't just for preventing escalation to root, remember that the most important stuff on your phone is your private data.
[AT&T Samsung Galaxy S 4 Original Android Developme] mattdm:
You have to install SuperSU, grant it root access, and then uninstall SuperUser. Did you not read the instructions?
[AT&T Samsung Galaxy S 4 Original Android Developme] sumnerm1:
And you approve adb connection on phone from pc?
[AT&T Samsung Galaxy S 4 Original Android Developme] JusTeN_:
not working for mee ..

updated drivers

turned on usb debugging

tried the motochopper and got a lot of errors.

Error : more than one device and emulator

Error : more than one device and emulator

Error : more than one device and emulator

Error : more than one device and emulator

Error : more than one device and emulator

error : protocol fault (status read)

- waiting for device -

tried from other USB ..

what to do??

Im from Israel in Orange
[AT&T Samsung Galaxy S 4 Original Android Developme] SW686:
Well, this is fine for rooting, but it's a no-go for any self-respecting malware author. Only a tiny percentage of Android users ever enable adb on their phones.

We're talking about two very different threats here.

If the only way to root your phone involves popping it open and shorting a couple of testpoints (for example), the hobbyists will do it. This needs to be factored into the threat model for whatever you are trying to protect against.

Maybe

MAC can help prevent unintentional data sharing due to misconfigured permissions, but the Android platform in general is practically designed to accommodate harvesting private data. Authorized sharing is so pervasive that unauthorized sharing should be the least of your privacy worries.

That may be so, but if non-spec-compliant Popular App X works on a Samsung phone but breaks on an HTC phone, HTC will have a problem.

Losing the ability to read files under /system and use basic diagnostic functions (/proc, logcat) WILL hinder software development, especially when diagnosing compatibility problems on non-trivial apps. Hackers aren't the only people who benefit from having good visibility into system internals.

Plausible, but in many use cases Samsung can't ask the user to give up any flexibility in exchange for data security. Most users don't want to think about security, or make concessions for it, until they have a serious breach.

In general, shared data storage under /sdcard, including /sdcard/DCIM, is a serious data leakage risk on Android. Good luck fixing that without breaking the apps.

Although MAC could enable fancy new compartmentalization features, the fact remains that Android's security policy isn't MAC-based. It isn't clear whether MAC adds much value in enforcing the standard Android policies, especially if there are other ways to accomplish similar goals, e.g. grsecurity

Proper usage of DAC permissions can also protect against thumbnailer bugs. Either scheme can be used to implement an effective least privilege scheme.
[AT&T Samsung Galaxy S 4 Original Android Developme] peoples_flip:
Worked beautifully on my i337m on Rogers (Canada)

Thanks OP!
[AT&T Samsung Galaxy S 4 Original Android Developme] manicmethod:
s/adb/anything else that can access the framebuffer/g

Yes, that will always be there, it requires a different type of defense (something like Iron Key with tamper self-destruct). Securing the software platform is what I'm talking about here.

misconfigured permissions and vulnerabilities. You are right about authorized sharing though. The BYOD use case uses MAC to separate authorized sharing between different containers, which is something that MAM/MDM guys are fond of, though they are using hacks like rewriting dex. I blogged about that, too.

[/QUOTE]

Therefore no one should start securing these crazy insecure devices... got it...

logcat is available to adb, which is all most developers need. Recent Android releases don't let apps use logcat or dmesg either (and dmesg is only available to root on JB)

They can, Apple does, iPhones are inflexible and people are fine with them. Most people don't actually understand the difference. We aren't talking hobbyists here, we are talking teeny boppers that probably wanted an iPhone anyway and their parents bought a Samsung.

Right, MAC and compartments for the BYOD use case. Again, iPhone doesn't have a shared storage model and people are fine with it.

grsec, etc don't give you a flexible security policy suitable to different environments (e.g., gov, medical, banking, BYOD, standard users) whereas SE Android does. Don't assume that the policy Smalley used in his slides is the one that would end up on a device. *Do* assume that the policy wouldn't let anything except what needs to mmap() and write to the framebuffer. The policy can allow even non-spec apps to work and still reduce attack surface area, if that is the desire.

Not true. DAC can't stop something running as you from exfiltrating data owned by you, that is the main issue behind DAC, it treats applications (including helpers like thumbnailers) as user surrogates, if you can do it so can they. SELinux allows applications to run in limited privilege ways, even if part of your user environment.
[AT&T Samsung Galaxy S 4 Original Android Developme] mpsrent:
Works on Bell Mobility Canada i337m. Thanks Op for the great work.

I added a little more detail to the Instructions for any novices after reading some of the installation issues:

1.Extract the entire contents of the zip file.

2.If you are using Windows, ensure you have installed the latest Samsung USB drivers available for your phone.

3. Enable "Developer Mode" by going to Settings/About Device and click on "Build Number" multiple times.

3.Ensure USB Debugging mode is enabled (check box) on your device under Settings/More/Developer Options.

4.Connect your device to your PC via USB.

5.If you are using Windows, navigate to the extracted directory and execute "run.bat". If you are using Linux or OS X, navigate to the extracted directory in a terminal and execute "./run.sh".

6. Once you hit enter to start the process, Approve the ADB connection from your PC on your device screen.
[AT&T Samsung Galaxy S 4 Original Android Developme] SW686:
For motochopper, sure

For RageAgainstTheCage or Jcase, how would an app exploit the vulnerability?

The two pertinent questions:

1) How many apps and platform features are manufacturers willing to break in order to guard against malware and unintentional data leaks?

2) How many apps and platform features are manufacturers willing to break in order to guard against advanced users who just want r00t?

My own personal suspicion is that going forward, Android security will look more like Windows + McAfee, and less like Orange Book. This saddens me, but that's reality.

Apps don't need to see logcat, but Smalley highlighted the logcat restrictions in the Gingerbreak slides. This is an area where malware could be at a significant disadvantage, but a determined human operator would be able to find the information he needs to perform the exploit.

But the existing base of 700,000+ Android applications weren't designed to work that way. At a certain point it starts getting really hard to make sweeping changes to the model, even if they carry long-term benefits.

DAC can accomplish this by switching groups and/or users, the same way named switches to a non-root user after binding to port 53. I will concede that dropping privilege is more "natural" in a MAC based system, if for no other reason than the fact that more knobs are available.

One could also make a good argument for the use of namespaces and containers, but again, aggressively denying access to parts of the filesystem could break some percentage of apps that work fine today.
[AT&T Samsung Galaxy S 4 Original Android Developme] Suzook1:
done in under 30 seconds. THANK YOU
[AT&T Samsung Galaxy S 4 Original Android Developme] mcmb03:
FOR THOSE WHO DO THE AT&T OTA:

I can confirm that this method still works perfectly after the OTA. Voodoo OTA Root Keeper didn't restore for me, so I ran this again and am happily rooted with all of my root apps running just fine
[AT&T Samsung Galaxy S 4 Original Android Developme] nakedninja42:
I verified this as well. I am rooted again (didn't try the VoodooOTA), and debloated after the ATT update.
[AT&T Samsung Galaxy S 4 Original Android Developme] s2dh:
Not that I want to right now, but how do you unroot motochopper?
[AT&T Samsung Galaxy S 4 Original Android Developme] spectrumfox:
Confirmed.
[AT&T Samsung Galaxy S 4 Original Android Developme] MikeC4510:
Searching is your best friend. Trust me.

http://xdaforums.com/showthread.php?t=2257058

Sent from my I337 SGS 4 using Xparent Skyblue Tapatalk 2
[AT&T Samsung Galaxy S 4 Original Android Developme] peaster3:
Nope. Didn't have to. I have a root checker app that confirmed that I still had root access plus used greenify, which requires root.
[AT&T Samsung Galaxy S 4 Original Android Developme] bizal05:
I just got my at&t galaxy s4 two days ago I did the root method and now when i turn it on the first screen says Samsung custom and there is a unlocked "lock" icon..what dies that mean is that bootloader unlocked? Sorry noob question this is my first Samsung phone....HTC man since the NEXUS ONE
[AT&T Samsung Galaxy S 4 Original Android Developme] stevehkim:
bootloader is not unlocked on at&t until dan releases the exploit.
[AT&T Samsung Galaxy S 4 Original Android Developme] hamzer11:
This means you have modified the device, aka rooted it. Use the following instruction to get rid of the notification.

http://androidtechy.com/index.php/2013-04-28-19-55-53/how-to-diy/48
[AT&T Samsung Galaxy S 4 Original Android Developme] nakedninja42:
Doesn't work... it did after I did the OTA (using the instructions) but after another dozen reboots (modifying system stuff) the custom screen came back. I don't have superuser installed or busybox... Weird thing is that the status under the about screen still says official....