Database Develop

[BOOTLOADER BYPASS -WIP] EternityProject Kexec method for Motorola Olympus (Atrix 4G)

Welcome to Eternity Project!
So... as most of you know I'm working on the Atrix solution from TOO MUCH time.
With the collaboration of people on #moto-atrix I've stated that FUSES on Tegra2 are really OTP, so there isn't any way to CRACK the BL, but we can still BYPASS it.
So... what is it?:
kexec is a "fastreboot" that won't pass through the Moto Bootloader, so with it it's possible to use custom kernels and, with some other development, custom Android systems like CM7 and many others.
Where's the poop?
Okay, that's it: I've successfully compiled and ran kexec on the Atrix 4G, so that kexec works, but it needs a kernel that can boot with kexec. On x86 we can build a relocatable kernel so no problems... but not on ARM and obviously not on Tegra.
The thing that is missing is exactly... _the address of the boot params_!
And now?
I'm only searching for help for completing the project and make a kernel that is bootable from my god-it-is-really-working-kexec. Any devs around?
Downloads:
- Kexec pack V0.01: DOWNLOAD
Kexec pack contains:
- ATAGS for MB860 (ATRIX_atags.tar)
- ATAGS hack module (eternity_procfs.tar)
- kexec module (eternity_kexec.tar)
- kexec tools/binaries (kexec-tools.tar)
- Kernel....that doesn't work. (eternity_kexec_kernel.tar)
So, what does work and what does not?
- ATAGS hacky hack: WORKING
- kexec module: WORKING
- kexec tools/binaries WORKING
- Kernel ToDo
How to run it:
0. FLASH AT&T 1.2.6 SBF PRIOR DOING ANYTHING
1. Extract all the archives
2. Insert the procfs_rw.ko module
3. cat atags > /proc/atags
4. Insert the kexec module
5. Run kexec for loading the kernel and jumping to it.
6. Boot! :|
P.S.: I won't release detailed how-tos because at this state I only need a DEVELOPER that can help me to build the kernel.
Thanks to:
- PAulyHoffman (special thanks!)
- unknown
- Sogarth
- the2dcour
- cranch
- eval-
- and many, many others....!

Awesome, i can verify that this kexec is working and will continue testing until we succeed.

random boot animation I made for eternity project
http://diamantephoto.com/bootanimation_red.zip
Also: 1.2.6 without losing /data, in case you were wondering exactly why I made this
http://forum.xda-developers.com/showthread.php?t=1073439

kexec pack updated. now kexec-tools is included

@kholk: Hai;
so basically this is a port of the unix kexec to run on tegra based devices?
From my understanding the android system uses a boot image that has the ramdisk and kernel combined together and they are dependent on each other... so won't overwriting the kernel at runtime give you us some issues since the core initialization of the system is ran from the ramdisk???
wouldn't be a better idea to tackle this issue too? but then again the only reason we can't flash boot images is because of the bootloader but ofcourse this is definitely a step forward for the tegra users.
now about the kernel, theoretically if we build an aosp tegra kernel from http://android.git.kernel.org/?p=kernel/tegra.git;a=summary shouldn't it work?
I can try building us a kernel if that would work
PS: people let's keep this dev ONLY if you want us to get some progress we need able to read through the thread without useless posts.
edit: also found this https://opensource.motorola.com/sf/frs/do/listReleases/projects.atrix/frs.olympus I'm sure having the source for the kernel we are currently running is also helpful

I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was

Ratchet556 said:
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Click to expand...
Click to collapse
When a kernel that works will be deployed I'll personally port it to Bell Atrix. This will take only some seconds.

kholk, perhaps we can ask a defy developer (or any of the phones that have kexec working) to help us build the kernel.
it's too bad da_g isn't around, he did a custom kernel but wasn't able to boot it.

I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.

lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?

lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
thebeardedchild said:
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
Click to expand...
Click to collapse
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.

Jotokun said:
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Click to expand...
Click to collapse
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?

thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Boot time will be about twice as long. Other then that, everything will run about the same

Yes thank you very much for that explanation... though I do also have the question about stability. By replacing the current kernel in memory with the new modified kernel the phone state may get confused as you mentioned... could this cause instability as a whole or increase risk of kernel panics? Or once everything is loaded and complete does it stabilize with the modified kernel?
Again sorry for the questions. This topic intrigues me and I love learning how stuff works.

thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Only difference would be that it might take slightly longer to boot up. Once the phone is finished booting, there's no difference in terms of performance because by that point the Motorola kernel isnt running, or even loaded.

thebeardedchild said:
Haha yeah I'm checking every like 2 seconds now. What exactly do we wait for then? Someone to just create the custom kernel, and then of course wait for some Custom ROMs to be created? I hope we get CM7!
Click to expand...
Click to collapse
Kexec isn't fully operational yet, still need to find boot params. Then custom kernel.

How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?

Ratchet556 said:
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Click to expand...
Click to collapse
I imagine some of the preliminary stuff may need to be pushed with ADB but devs are always nice and give us very clear guides. And I'm sure either a dev or active member could easily create a batch script.
Even though I'm comfortable with ADB I always make scripts for myself because I regularly wipe me phone and whatnot. Because it's so engaging some people might want to wait until a few normal community members test this out so we can see if there are any glaring challenges with the instructions. Just remember to back things up, read instructions clearly and I'm sure we'll all be fine. We've got SBFs and all that good stuff to cover our asses too.

Would it be possible to bring fastboot off the htc to this? Then we won't have to worry about boot time at all. Even if it did double the boot time...
Sent from my MB860 using XDA App

PixoNova said:
This bypasses the bootloader
Swyped from my Motorola Atrix 4g using XDA Premium App
Click to expand...
Click to collapse
Correct this method has nothing to do with unlocking the bootloader and previous attempts at that proved it maybe impossible.

[Q] How does motofail work?

Hey all,
I have been Google'ing trying to figure out how Motofail works. I understand the .bat script, its very similar to how rageagainstthecage worked on the Droid OG:
push the file to /data/local
run the exploit
remount /system as rw
push su, SuperUser.apk, and busybox
remove exploit from /data/local
reboot
What exactly is the motofail exploit doing though? I know with rageagainstthecage it caused a race condition where it filled the process table while the adb server was restarting which caused the setuid in the adb server to fail to switch to user from root.
my question is what is happening when the following commands are run
Code:
adb shell "/data/local/motofail exploit"
adb shell "/data/local/motofail clean"
Thanks in advanced!
Hemmar

Ask Dan rosenburg or what ever his name is I believe it states this on his website
Sent from my XT875 using XDA App

He didn't describe the vulnerability.
It's not very hard to find out the underlaying idea by just running motofail exploit and see what files had been altered.
You need to be _very_ skilled to develop these kind of exploits. But it's funny to see that Guys like Dan will always find a way. Just read his latest blog entry: "OEMs: unlock your bootloaders, you are not going to win this one". Great!

Is this the right site?
Is vulnfactory the right site? I don't see any mention of OEMs and bootloaders on it.

hemmar said:
Is vulnfactory the right site? I don't see any mention of OEMs and bootloaders on it.
Click to expand...
Click to collapse
Yes Vulnfactory is the correct site. It has all of Dan's work. Bootloader not unlocked for the bionic so I see no reason to mention it.

If we had a unlocked bootloadwr what exactly would change for us other than possibly over clocked kernals
Sent from my XT875 using XDA App

Dan explained the inner workings of motofail at SOURCE Boston in April, 2012. For more details, and other great information, check out the slides on the SOURCE Boston website referenced below.
http://www.sourceconference.com/publications/bos12pubs/android-modding-source.pdf
Hope this helps,
jduck

Bfitz26 said:
If we had a unlocked bootloadwr what exactly would change for us other than possibly over clocked kernals
Sent from my XT875 using XDA App
Click to expand...
Click to collapse
You could do anything to the phone - replace the recovery, (not bootstrapped, completely replaced) and thus have custom ROMs with custom kernels, pre-rooted, no security checking, nothing to get in the way.
Think OG Droid.
Sent from my ASUS Transformer Infinity TF700 running Android JB (rooted) via Tapatalk HD

TWRP Port to TMO Note

Hi, I would like to port TWRP to the TMO Galaxy Note but since I don't have one I need help from people with the phone. I ported TWRP to the ATT Galaxy Note: http://forum.xda-developers.com/showthread.php?t=1647575.
If someone who has rooted can give me the output of the following commands as root in adb shell or a terminal on the phone:
cat /proc/partitions
cat /proc/emmc
busybox fdisk -l /dev/block/mmcblk0
Thanks!
If anyone is feeling frisky, they can dd this to their recovery partition (/dev/block/mmcblk0p22 at least on the att note)
Don't blame me for borking and make sure that this partition is the right partition. It looks like the cwm touch version in the dev section is a clone of braway's CWM touch so I am guessing they have the same partitions.
Good luck!

I can do this when I get back in for the night. Anything to help move along the development section of this device!!

is there any added benefit in doing this?
i've been using twrp 2.2.1 on my TMO note since day one. I used odin flash CWM then CWM to flash the ATT twrp from teamwins website and have experienced no issues at all.
not trying to discourage development in anyway but if it already exists and works correctly what would be the advantage?

pxldtz said:
is there any added benefit in doing this?
i've been using twrp 2.2.1 on my TMO note since day one. I used odin flash CWM then CWM to flash the ATT twrp from teamwins website and have experienced no issues at all.
not trying to discourage development in anyway but if it already exists and works correctly what would be the advantage?
Click to expand...
Click to collapse
Odds are the devices are identical, but this build will give a device name of "quincytmo" instead of "quincyatt" which may be important for zip files. Most ROMs do a check before installing called an assert where they check the device name to ensure that you're installing the correct ROM for your device.
Still, glad to hear that you've been using TWRP without issue.

Really dont have to port it just use twrp in the at&t dev section i been using for a week works flawlessly and im on a native tmobile note
Didnt read prior post my bad
Sent from my SAMSUNG-SGH-I717 using xda premium

Dees_Troy said:
Odds are the devices are identical, but this build will give a device name of "quincytmo" instead of "quincyatt" which may be important for zip files. Most ROMs do a check before installing called an assert where they check the device name to ensure that you're installing the correct ROM for your device.
Still, glad to hear that you've been using TWRP without issue.
Click to expand...
Click to collapse
that's a valid point. like i said i'm not trying to hinder development, but thanks for answering

bigbiff said:
Hi, I would like to port TWRP to the TMO Galaxy Note but since I don't have one I need help from people with the phone. I ported TWRP to the ATT Galaxy Note: http://forum.xda-developers.com/showthread.php?t=1647575.
If someone who has rooted can give me the output of the following commands as root in adb shell or a terminal on the phone:
cat /proc/partitions
cat /proc/emmc
busybox fdisk -l /dev/block/mmcblk0
Thanks!
If anyone is feeling frisky, they can dd this to their recovery partition (/dev/block/mmcblk0p22 at least on the att note)
Don't blame me for borking and make sure that this partition is the right partition. It looks like the cwm touch version in the dev section is a clone of braway's CWM touch so I am guessing they have the same partitions.
Good luck!
Click to expand...
Click to collapse
Here is the result for /partitions
- For /emmc, result is "no such file or directory"
- For busybox, apparently I didn't have that installed, downloading and installing now, but will take a few minutes because I'm throttled. Will update post with results from that after.
While as others have stated, it's not "necessary" to port over since the ATT version works, I'm more than happy to help to have a version for THIS model, as there are obviously differences between the i717 and the T879. This is apparent because not all ROMS for the i717 work on the T879. Having our own version of TWRP just solidifies the 879 as it's own entity, not just an "also ran"

Android Revolution said:
Here is the result for /partitions
- For /emmc, result is "no such file or directory"
- For busybox, apparently I didn't have that installed, downloading and installing now, but will take a few minutes because I'm throttled. Will update post with results from that after.
While as others have stated, it's not "necessary" to port over since the ATT version works, I'm more than happy to help to have a version for THIS model, as there are obviously differences between the i717 and the T879. This is apparent because not all ROMS for the i717 work on the T879. Having our own version of TWRP just solidifies the 879 as it's own entity, not just an "also ran"
Click to expand...
Click to collapse
I went ahead and posted a t879 friendly image in Development forum. I also added it to goo manager. If you guys could test and report back that would be great.

[WIP] Building CM 10.1

Granted, it has been a while since I've built CM, and never ported it to a new device, but figure this might give some smarter people a head start or at least provide a place for others to collaborate.
I've not gotten very far past the initial vendor setup per http://wiki.cyanogenmod.org/w/Doc:_porting_intro.
A lot of the work is based off the similar ASUS TF700T, https://github.com/CyanogenMod/android_device_asus_tf700t.
I've not messed with the kernel at all at this point, https://github.com/ouya/ouya_1_1-kernel.
I've uploaded everything so far to github, https://github.com/vinny75/android_device_ouya_ouya_1_1

Packages included with official build:
OUYA Framework, Launcher, and Store
Code:
app\OUYAKeyboard.apk
app\OUYALauncher.apk
app\OUYAOOBE.apk
app\OUYAWallpaper.apk
app\ouya-framework.apk
note: some media files I haven't list
CWiid for Android: http://cvpcs.org/projects/android/cwiid4android and https://github.com/cvpcs/android_external_cwiid[.
Code:
bin\wminput
lib\libcwiid.so
etc\acc_led
etc\acc_ptr
etc\buttons
etc\gamepad
etc\ir_ptr
etc\neverball
etc\nunchuk_acc_ptr
etc\nunchuk_stick2btn
Sixpair for PS3 controllers http://www.blog.kaiserapps.com/2012/10/setting-up-sixaxis-controller-android.html.
Code:
/bin/ps3service
/bin/sixpair

I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Sent from my Nexus 7 using xda premium

mybook4 said:
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Click to expand...
Click to collapse
Thanks, appreciate the help, hopefully, we'll have a working build soonish

If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!

Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"

mybook4 said:
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
Click to expand...
Click to collapse
I started out with Method 1 then moved over files and settings from the ASUS TF700T.

professorpoptart said:
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Click to expand...
Click to collapse
Yes, building the new device tree has been... uhm... educational... and I am still learning. If I don't make any headway on 10.1, I might drop back to 10 - at least most of the legwork will be done.

Ok, so I'm in the middle of a build
Have a vendor tree on my git and I forked Vinny75's device tree, modified it some
Also a kernel tree up there, which is required for my device tree (prefer to build the kernel myself =) I've booted a custom-built kernel on it already, so that shouldn't be an issue)
I'm nervous to flash this though. I did a bit of searching but couldn't come up with a way to get back into recovery should this thing not boot. You guys know of anything?

Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium

mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Yea, that's what I'm seeing.
So here's my 'solution'
Since we have fastboot, we can boot a boot.img without having to worry about flashing it.
I've successfully booted my cm boot.img, with ro.secure=0 and ro.adb.secure=0, I can adb reboot it when it fails miserably to boot
Quick and dirty script to unsecure a boot.img:
http://pastie.org/8033076
It assume that unpackbootimg and mkbootimg are in your path, you can get them here: http://invisiblek.org/mkbootfs_tools.zip
Getting closer...

THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?

dibblebill said:
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
Click to expand...
Click to collapse
Yeah, I think that is the same solution posted earlier:
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Click to expand...
Click to collapse
THis might be another option too:
tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.
Click to expand...
Click to collapse

Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium

mybook4 said:
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
Click to expand...
Click to collapse
ah he makes it sound like it puts you in USB recovery mode fo you could ADB in to push an update.

Just wanted to say I'm totally stoked on this guys! Can't wait to see what you do with this. Wish I could help, but I'm really not a developer.

i agree with rebel! but when you guys have it readyish ill test flash it and tell you what happens!!

So, OUYA isn't really as interested in being an open console as they suggest.
I'm keeping a track of how many requests we get relating custom firmware, and from what I'm seeing the user base is not as interested in custom firmware as you might think, which is echoed by this thread (we've shipped 60,000+ units, and less than 10 people have commented in the last month in this thread about getting access to recovery mode).
That doesn't mean that we're shooting the idea down, you need to keep in mind that in terms of priorities this is way down the list as you'd expect from any feature where it's being requested by less than one tenth of one percent of the user-base.
I'm sure @Wajeemba is familiar with CM requests that a very small minority of the user-base are very passionate about, so hopefully you can understand why we're not rushing to work on this.
Click to expand...
Click to collapse
Go to this thread and let them know we want support:
http://forums.ouya.tv/discussion/1380/recovery-mode

That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...

sonofskywalker3 said:
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
Click to expand...
Click to collapse
I'd check with invisiblek about how to avoid bricking the OUYA. Apparently his is bricked. It's stuck in nvflash mode. I think it was a kernel written with a bad init.rc that did it. not sure though.
Sent from my Nexus 7 using xda premium

AT&T Samsung Galaxy S5 DeBloating

Hello to all the fans of less programs/apps forced on the user.
To begin I'm listing what I have disabled/turned off from the stock rom, and I'm getting a better battery life and see less junk.
ANT Radio
ANT+ Plugins
AT&T FamilyMap
AT&T Hot Spots
AT&T Locker
AT&T Messages
AT&T Mobile Locate
AT&T Navigator
Beats Music
BlurbCheckout
Business card recognition
Caller Name ID
ChatON
Device Help
DriveMode
Flipboard
Google Play Books
Google Play Games
Google Play Movies & TV
Google Play Music
Google Play Newsstand
HP Print Service Plugin
Keeper
Mobile TV
MobilePrintSvc_CUPS
MobilePrintSvc_CUPS_Backend
My Magazine
myAT&T
Print Spooler
S Voice
Samsung Account
Samsung Apps
Samsung Galaxy
Samsung GALAXY Apps Widget
Samsung Link Platform
Samsung Print Service Plugin
Samsung Push Service
Travel wallpaper
Wallet (Isis)
Note: I'm not using any of the apps/services listed above, and I have not run into any problems. If you are going to use them then don't disable them.
Battery life has increased enough to be noticed, but not dramatically.
Next Project: Make an Odin flashable DeBloated stock ROM in both rooted and unrooted versions.
I got a full Stock ROM download from Samsung Kies to start Debloating and adding Root using Android Kitchen.
This file contains four files:
AP_G900AUCU1ANCE_964333_REV00_user_low_ship_MULTI_CERT.tar.md5
CP_G900AUCU1ANCE_964333_REV00_user_low_ship_MULTI_CERT.tar.md5
CSC_ATT_G900AUCU1ANCE_964333_REV00_user_low_ship_MULTI_CERT.tar.md5
BL_G900AUCU1ANCE_964333_REV00_user_low_ship_MULTI_CERT.tar.md5
Accomplished:
System folder is located and the apps listed above deleted from "AP_G900AUCU1ANCE_964333_REV00_user_low_ship_MULTI_CERT.tar.md5"
Also ran this through the Kitchen and got it rooted, signed, zipaligned, ... (Choosing the lazy option for now) and got my output .Zip
Stuck on:
1- the Android kitchen .Zip file is flashable using a custom recovery mod. e.g. CWM or it's PhilZ version, which isn't currently available for this phone.
I don't have previous experience that these .Zip files can be flashed through Odin. So I assume it won't work.
2- Cannot put the System folder I Debloated back together to get accepted and read by Odin.

Can u share the odin file that has been rooted. Without thw debloating
Sent from my SAMSUNG-SM-G900A using xda app-developers app

blkghost22 said:
Can u share the odin file that has been rooted. Without thw debloating
Sent from my SAMSUNG-SM-G900A using xda app-developers app
Click to expand...
Click to collapse
I'm sharing my Android Kitchen's Cygwin window screenshot of the file information.

Thx... i was askig so a dev or someone more knowledgable can take a look.
Sent from my SAMSUNG-SM-G900A using xda app-developers app

so what needs to happen now is the content inside that zip file need to get converted to "system.img.ext4" file, then I will put that file back into the tar ball "AP_G900AUCU1ANCE_.... .tar.md5" and load it up in the PDA section of Odin.
So that is where i'm stuck; in re-packing all those files back into "system.img.ext4" file. There is a delicate way to do this, also discussed in parts somewhere on the XDA forums. One has to know the final partition size to include it in the command used to pack those in to a "system.img.ext4" file.

That is awesome. I can't wait to see this finished. Seems you found a way to root it. Are you going to make it so that a "noob" like me can do it?
Sent from my iPad using Tapatalk

Commodore 64 said:
so what needs to happen now is the content inside that zip file need to get converted to "system.img.ext4" file, then I will put that file back into the tar ball "AP_G900AUCU1ANCE_.... .tar.md5" and load it up in the PDA section of Odin.
So that is where i'm stuck; in re-packing all those files back into "system.img.ext4" file. There is a delicate way to do this, also discussed in parts somewhere on the XDA forums. One has to know the final partition size to include it in the command used to pack those in to a "system.img.ext4" file.
Click to expand...
Click to collapse
even if you get it back in the tar your not going to flash it in odin, the AT&T bootloader is locked odin will not flash a file once you have rebuilt it because it does not contain the samsung signatures. i have already got a fully built flashable ROM for the AT&T just waiting for root and BL unlock.
your on the right path, so dont get discouraged but it just isnt that simple.
P.S. Before you even ask, yes i have tried multiple iterations of building the system.img.ext4 file and signing it.
P.P.S if you really want the best experience from building a rom build a linux box (either linuxmint or ubuntu) the kitchen is a great tool
but running under cygwin in windows there are many limitations including not being able to create a system.img.ext4 file or generate the correct md5sum.

Thanks cstayton for giving me a glimpse of what i'm dealing with here. From your comments a I searched further and found
http://autoroot.chainfire.eu/
Standing by for SM-G900A root release. I'm taking down my DropBox Dl link above since it is no use any more.

No root = No dev on the ATT or VZW versions of the S5 this is because of the locked BL. Likely that there won't be a BL unlock or bypass like Loki. Eventually a root exploit will be found just a matter of time, but no one knows how long that will be. There likely down the road after root will be safestrap which will allow custom TW roms based on the stock TW kernel. What likely won't happen is AOSP.
CF-Root does not work and never will as long as the bootloader is locked due to how it obtains root (modified stock recovery to push root). /System cannot be modified to root the ATT/VZW S5, this has already been cofirmed by Chainfire. An exploit on Kit Kat has to be found. Sadly anyone who got the ATT S5 expecting great Dev support right out the gate picked the wrong variant.

Has anyone tried safestrape?

daraj said:
Has anyone tried safestrape?
Click to expand...
Click to collapse
I don't believe that the S5 is on his supported device list as of yet, and even then Safestrap requires root.

cstayton said:
I don't believe that the S5 is on his supported device list as of yet, and even then Safestrap requires root.
Click to expand...
Click to collapse
Duh Thats true. So first step is ROOT!

A friend of mine mentioned that the note 3 has a locked BL and Knox but is still able to be rooted. I am wondering if the root for the note 3 would work on the s5. Has it been considered or tried? I would try it but I do not have the knowledge necessary to undo it if something goes wrong. It seems like something that could really mess up the device if you don't know what your doing.
Sent from my iPad using Tapatalk

Don't try it @TheSheibs. Just wait for root to be announced. It'll be a big deal if and when it does.

@TheSheibs Try it! if it works youll be the man!
Just be aware of the issues.

I have the rom cooked and ready and it was ready to go in odin 3.07. Well the thing is if I'm willing to part with the one year warranty since it will advance the knox counter and at the end of the day that shouldn't matter anyways because even if a root solution/exploit is released, flashing it by odin will still advance the counter ...
Sent from my SAMSUNG-SM-G900A using xda app-developers app

Commodore 64 said:
I have the rom cooked and ready and it was ready to go in odin 3.07. Well the thing is if I'm willing to part with the one year warranty since it will advance the knox counter and at the end of the day that shouldn't matter anyways because even if a root solution/exploit is released, flashing it by odin will still advance the counter ...
Sent from my SAMSUNG-SM-G900A using xda app-developers app
Click to expand...
Click to collapse
Once root is achieved (hopefully soon-ish) will we see prior AT&T devs flocking to the device for things such as SafeStrap and TriangleAway. I assume once we have root we will have a way to trip the knox shortly after. Root is key.

My s5 is coming in a matter of hours! I'm looking forward to root but I don't mind staying stock for a while as long as I can disable apps! The part I'll have to get used to is no more "Greenify" app but oh well
Sent from my Nexus 5

So what at&t and verizon did was not only lock the phone's bootloaders but encrypt them. The encryption part is problematic for now.
If we can't flash with odin then we can't load custom recoveries like cwm/twrp then this phones becomes less attractive for developers. I have made a rooted version of stock ready with android kitchen but currently I don't have a way to load it on my device to test it.
I tried and Odin crashed, knox counter did not advance.
Sent from my SAMSUNG-SM-G900A using xda app-developers app

Commodore 64 said:
So what at&t and verizon did was not only lock the phone's bootloaders but encrypt them. The encryption part is problematic for now.
If we can't flash with odin then we can't load custom recoveries like cwm/twrp then this phones becomes less attractive for developers. I have made a rooted version of stock ready with android kitchen but currently I don't have a way to load it on my device to test it.
I tried and Odin crashed, knox counter did not advance.
Sent from my SAMSUNG-SM-G900A using xda app-developers app
Click to expand...
Click to collapse
Well your right, Odin will not flash any custom rom with locked bootloader, once you touch the stock img.ext4 you break the samsung signatures, nothing you can do will flash that file.
If it was as simple as re-creating the system.img.ext4 and flashing with Odin we wouldn't have to worry about locked BL.