Database Develop

[TOOL] redbend modification

I hacked on redbend_ua to make it a better phone hacking tool
first thing that has to go was the rebooting after any command
and the second thing was the stupid installing software splash screens
the first mod will probably segfault if used to batch install delta files
as I suspect there is some more code to update the progress bar on
the now NOP'ed installing software splash screen.
the second mod has batch mode NOP'ed so it wont do anything unless
you pass the dump,restore or compare commands which is fine for scripting
zImage and modem.bin installs.
/* This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The **** You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details. */
Click to expand...
Click to collapse

Nice thanks
Sent from my vibrant

untermensch said:
I hacked on redbend_ua to make it a better phone hacking tool
first thing that has to go was the rebooting after any command
and the second thing was the stupid installing software splash screens
the first mod will probably segfault if used to batch install delta files
as I suspect there is some more code to update the progress bar on
the now NOP'ed installing software splash screen.
the second mod has batch mode NOP'ed so it wont do anything unless
you pass the dump,restore or compare commands which is fine for scripting
zImage and modem.bin installs.
Click to expand...
Click to collapse
sorry if this is dead info but how is this a tool? i need as many tools as possible. and i do not understand is there a place for specific knowledge on this that may go into a bit more detail?

justlovejoy said:
sorry if this is dead info but how is this a tool? i need as many tools as possible. and i do not understand is there a place for specific knowledge on this that may go into a bit more detail?
Click to expand...
Click to collapse
redbend_ua is used for installing OTA updates, but it also has other functions.
RedBend Update Agent %s
commands:
img [partition name] [delta file] [device node] [temp path]
fs [partition name] [delta file] [mount point] [temp path]
all
dump <source dev> <dest file>
restore <source file> <dest dev>
compare <dev1> <dev2>
png [png file name]
all
Click to expand...
Click to collapse
normally when you run a command it will take over the screen with a "Installing Software"
splash, and then reboot. you can get around the reboot by unlinking reboot but that is kinda
a kludge and the splash usually just scrambles the screen.
the mod does away with the splash and the reboot making redbend_ua less annoying to use.
you could even probably install kernels and modems without rebooting into recovery, though
you will have to reboot to use the new code.
for example if you want to install a kernel the command might look something like this
Code:
/data/local/redbend_ua restore /sdcard/zImage /dev/block/bml7

So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.

Whitehawkx said:
So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.
Click to expand...
Click to collapse
Whitehawk, dude, kick some butt doing this! It would be very convenient
Sent from the helm of Vibrant Territory!

Whitehawkx said:
So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.
Click to expand...
Click to collapse
Guess what i already did: SGS kernel flasher
Btw: Thanks untermensch.

neldar said:
Guess what i already did: SGS kernel flasher
Btw: Thanks untermensch.
Click to expand...
Click to collapse
I saw that and briefly hacked into it to pack it with vibrant kernels - gave it 1 try which failed and I moved on because I assume you have a check in place that didnt let me replace the kernel. Like to see this for us though.
Edit - reading your signature, I must have been working from an early or I9000 version at the time.

[HOW-TO/INFO] Bell FAQ [9-25-2011]

This is my attempt at a Bell FAQ, it is a work in progress.
Q. Why don't the instructions I found on how to do X not work?A. This is a development forum, sometimes things are written in shorthand assuming you know things you don't. At lot of things are specific to one carrier's phone or another. Sometimes things change and are now obsolete, something new was found, a better way of doing things, if you were not following it all along you are likely to be lost. Read between the lines, you are a human being with reasoning abilities, figure it out. ​Q. What should I do first?
A. Backup your phone. That means everything, especially your pds partition. Nandroid won't cut it and you have already modified your phone beyond the ability to get back if you can run it.
Ex. dd if=/dev/block/mmcblk0p3 of=/sdcard/backup/mmcblk0p3
Save your backup on your computer, create a zip of all the files, burn it off on cd/dvd, put it in a safety deposit box at your bank. Be prepared for bricking your phone. A lot of things mentioned in threads here are developed and tested for ATT phones, they may not work 100% on your phone.​Q. What is ADB?A. It stands for Android Debug Bridge or something like that. It is a program that runs on your computer that lets you talk to your phone using special commands. Your phone has to have adb enabled, it's a setting under application/development.
Ex. adb shell
This opens a linux shell connected to your phone. Linux is an operating system for computers, it is also used as the base for android phones.
Ex. adb install file.apk
Ex. adb push file /tmp
Ex. adb pull /tmp/file .​
Q. What is CWM recovery?A. Android phones come with a special boot configuration that allows for changes to the android system from a place outside the system. It is very corporate and does the job for official signed updates, but only Motorola and it's oems can sign the updates. Not much fun for us. CWM recovery is a replacement for the official recovery system that doesn't require signed updates.
You install CWM recovery using fastboot or moto-fastboot.​Q. What is unlocking the bootloader all about?A. It is the means of putting CWM recovery on your phone so you can install roms and other packages. It allows you to flash a partition with mods and have the phone not soft brick when you reboot. When the unlocked versions of the atrix bootloader were found it started a new round of mods. A lot of the threads prior to that are now obsolete.​Q. How do I unlock the bootloader?A. There is a huge thread already about this, see here.
WARNING: this is a permanent change to your phone.
Summary:
1. Download the archive
2. Extract the sbf inside, whatever it's called, that is the one to use.
3. Use linux sbf_flash or rsdlite from windows to install it.
3. fastboot oem unlock
4. Copy code fastboot spits out.
5. fastboot oem unlock code
6. fastboot reboot
You will see unlocked while booting and when you get into android you will have ~300MB of ram. This will need to be fixed. Also, you will lose all your data during the process, do a backup first.​Q. What is fastboot/moto-fastboot?A. It's a program to access the phone and do stuff, write phone partition images mostly. The stock one can only handle tiny system images, pretty useless for the Atrix, xda member eval- compiled the motorola version for us that can handle larger system images, do a search for moto-fastboot.
Ex. moto-fastboot flash recovery recovery.img.​Q. How do I fix the ram problem?A. I did up a CWM recovery zip to update the boot and recovery partitions to contain a kernel command line with the missing bit "[email protected]" added. See here.
There are other means of doing this, some boot images come prepackaged with the command line already embedded. There are ATT compiled kernels with a patch inside the kernel itself to do the same thing. You can search for those when you are ready to try things like custom ATT kernels on your phone.​Q. How do I root the phone?A. If you are unlocked and you have fastboot flashed a version of CWM recovery, it is trivial. By that I mean almost impossible for newbies to figure out.
It would go something like this:
1. Boot into CWM recovery.
2. use adb shell
3. adb push a su binary to the phone.
4. mount system as read write as /system
5. copy su binary to /system/bin
6. make sure it has the right permissions, 06755 mode , user root, group root.
7. unmount -l /system
8. when in android look on the market for Superuser.apk, install.
Every rooting method out there is all about putting su into /system/bin with 06755 permissions, most don't work anymore since Gingerbread. If you are looking for a simple, no brain involved solution, you are likely to get something working and also something else you didn't want like a replaced preinstall partition or an installed busybox with different functionality for some important system commands. (Busybox may be more up to date even, but if it doesn't do what is expected of the older version, it's still not good.)
Another way would be to create a CWM zip that simply puts the linux su binary in system with the correct permissions. Some info about creating your own can be found here. Doing this is more involved that just doing it manually, but it would be a good practice for getting into creating CWM updates.
Here is a link to a exploit someone did up to root the phone when running GB. Haven't tested it, and with an unlocked phone it is totally redundant, but it's nice that some found yet another security hole in the OS, seems similar in result to psneuter, so be sure to reboot the phone to fix the exploited system.
Seriously, if you are going to be reading or posting in the development section of xda for an android phone, take the 5 minutes to become familiar with adb and a few linux shell commands, it will save you hours of confusion and aggravation. If you fly blind trying things on your phone without understanding what you are doing you are eventually going to get into a place you can't get out of and need a new phone or REALLY have to struggle to understand things. You were warned. ​Q. How do I get back to stock?
A. You can't unless you have a backup of all your phone partitions and can update your radio and bootloader to be stock. Once you unlock your phone, it is recorded that you did so by blowing a physical fuse on the phone. This cannot be restored, you will need a new phone.
What does stock mean to you? When I bought my phone it had a certain radio, the bootloader couldn't be unlocked, the android system files had certain versions, etc. Beyond the android system there are 18 partitions that I know of on the phone, most phones do with 5-6. Every ota update or sbf files take the normal files and change them to something else, non android partitions get modified or replaced.
I have some solutions for getting close to stock, do a search for Gobstopper. There is one for Bell 2.2.2 and Bell 2.3.4, use one or the other. These attempt a full back to stock operation, that means the radio and bootloader will be stock, recovery will be stock as well. (All the partitions that are on the phone are written over with the ones that were on my phone when I bought it, with the exception of partitions 3 (pds), 15 (cache), 16 (data), and 18 (userdata or internal memory), factory reset clears cache and data, you don't want pds touched or internal memory.) Unlocked will no longer be displayed when you boot and you will no longer have CWM recovery installed. You will need to install the unlocked bootloader again and fastboot flash recovery again if stock is not what you wanted. (Your pds partition is not involved in this operation, so if you made changes to it, either directly or indirectly via a sbf this will not restore it, your pds partition contains individual phone information.)
More about sbf format here.​Q. What does the pds partition taste like?A. It's not really fit to eat. Now you know.
It is mmcblk0p3, a partition on your phone, it is mounted as /pds when android boots and contains a bunch of folders and files that nobody really understands fully but Motorola. Having a look at some of the files you will see things like your network physical address, bluetooth physical address. You will find threads where the display is all arsed up, cpu running at half speed, touch screen not working right, etc, all due to something going wrong with /pds. It is best to back it up and not mess with it. Restore it in an emergency. Maybe one day everything in there will be figured out, take a stab at it yourself.
See this thread by edgan for how to back up your pds partition.
See this thread by KeRmiT80 about attempting to fix your pds partition. Good motivation to see previous link.
​Q. I lost network data access after flashing X.
A. Check your APN list, if it's not a Bell firmware you are using, it probably doesn't have Bell's APN list. Scratch that, you don't know what that is or how to check it.
It stands for Access Point Name and a big list of them is stored on your phone in one big file (/system/etc/apns-conf.xml), each firmware has it's own version of it. Your phone will get two numbers from your carrier's phone network to do a look up in this list to figure out what configuration to use. So say it gets mcc 302, mcn 610, it will check the phone and look up 302, 610 in the file and read what it says there and use that config to try to connect. Now, another thing is that the phone knows what the home network is by these two numbers, embedded somewhere in the system. A foreign, non Bell carrier won't have Bell's numbers in there so your phone will think it's roaming. If you have roaming disabled, guess what, no data connection. Your carrier should be smart enough not to charge you for roaming, never had a problem with that, but you never know.
Here are the apn settings you can enter manually for your phone, see Bell's support link.
​Q. How do I get webtop over HDMI to work?
A. There are several threads on getting this to work on ATT phones and others, they are specific to the firmware being run on the phone. They involve copying two deodexed files to your system/app folder and replacing the ones already there. You will also need to clear your dalvik cache to get the new code recognized. They are DockService.apk and PortalApp.apk. If you are not deodexed then you also have to remove the .odex files for both.
Here is one thread for Gingerbread, in the zip there is one for ORFR that will get you to viewing the webtop on Bell GB, but applications don't load.
Here is another thread for Froyo that works, see the Bell specific bit in the OP. This does not work from Bell Gingerbread.​ To be continued...

Hoping the Mods sticky this
A link should be attached to the wiki as well. I will try to when I get home if it isn't done already.

shouldn't this be in general? or q&a?

Magnetox said:
shouldn't this be in general? or q&a?
Click to expand...
Click to collapse
Probably both. Most things referenced are in development.
Cheers!
Sent from my MB860 using xda premium

y2whisper said:
Hoping the Mods sticky this
A link should be attached to the wiki as well. I will try to when I get home if it isn't done already.
Click to expand...
Click to collapse
+1 this should be a sticky on either or both general or development...
cheers for this...this thread is going to help me with my youtube viewers BIG TIME!!

Very nice!
Keep it up NFHimself!

NFHimself said:
This is my attempt at a Bell FAQ, it is a work in progress.
Q. How do I root the phone?A. If you are unlocked and you have fastboot flashed a version of CWM recovery, it is trivial. By that I mean almost impossible for newbies to figure out.
It would go something like this:
1. Boot into CWM recovery.
2. use adb shell
3. adb push a su binary to the phone.
4. mount system as read write as /system
5. copy su binary to /system/bin
6. make sure it has the right permissions, 06755 mode , user root, group root.
7. unmount -l /system
8. when in android look on the market for Superuser.apk, install.
Every rooting method out there is all about putting su into /system/bin with 06755 permissions, most don't work anymore since Gingerbread. If you are looking for a simple, no brain involved solution, you are likely to get something working and also something else you didn't want like a replaced preinstall partition or an installed busybox with different functionality for some important system commands. (Busybox may be more up to date even, but if it doesn't do what is expected of the older version, it's still not good.)​ To be continued...
Click to expand...
Click to collapse
I used this method to root the stock Bell Gingerbread ROM. Works on an Atrix too. It's a quick download and easy for those people who may not be comfortable with the adb command line.
http://www.psouza4.com/Bionic/

thx
useful for newbies
but can you put some more details about returning to stock and explain the pds partition in details plz?

papakilo10 said:
I used this method to root the stock Bell Gingerbread ROM. Works on an Atrix too. It's a quick download and easy for those people who may not be comfortable with the adb command line.
http://www.psouza4.com/Bionic/
Click to expand...
Click to collapse
Had a look at the script in that one, should be fine, doesn't install a busybox or anything like that. I don't care for Superuser.apk in /system/app myself, but it won't harm anything having it there.
Cheers!

ytwytw said:
thx
useful for newbies
but can you put some more details about returning to stock and explain the pds partition in details plz?
Click to expand...
Click to collapse
I added a few things, anything in particular you wanted?
I am trying to avoid step by step tutorials or spoon feeding everything, so people who are lazy/careless will have to attempt to think for themselves. It just leads to more questions, more laziness, and bricked phones, and I don't have the time these days.
Cheers!

[DUAL-BOOT][RECOVERY] Ouya Boot Menu for Support of Kernel Image Chain-loading

Hello everyone! Just like others here, I've been somewhat spooked by our inability to enter Ouya's Recovery partition at the earliest stage of booting, meaning a bad flash of the Boot partition would leave the device inoperable. When I heard that Ouya's stock firmware updates were possibly bricking a few units out there, I decided to block updates on mine and see if I could transform the Boot partition such that it would become a logical extension of the bootloader. What I ended up with is something close to the "Ouya Safe Recovery" project, where a user should only need to flash Boot one additional time, along with chain-loading support as well.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.

Wow, really great. Thanks a lot for your effort
Gesendet von meinem One X+ mit Tapatalk

nchantmnt said:
Wow, really great. Thanks a lot for your effort
Click to expand...
Click to collapse
My pleasure, nchantmnt. Hope your new Ouya is helping you feel at home!

Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Gesendet von meinem One X+ mit Tapatalk

nchantmnt said:
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Click to expand...
Click to collapse
Gosh, I'm very sorry to hear that. Do think ahead to the upcoming holiday season, and may it be a time to reflect and anticipate a fruitful 2014.

@Hal9k+1 - THANK YOU!
I was so nervous flashing CWM and StockPlus as there is no real way to fix things if something goes wrong. This should give people more confidence when flashing their Ouya.
I understand the process using ADB...my question is: can this be used from CWM somehow?
PS. I assume new kernel will always be flashable from CWM, the hack does not require 561 specifically.

Ipse_Tase said:
I understand the process using ADB...my question is: can this be used from CWM somehow?
Click to expand...
Click to collapse
Hi Ipse_Tase - I do hope the feature will be helpful to you and others.
As I think about your question, I suppose I could have have created a ZIP that would have been installed by CWM. Similarly I could have worked through some form of installation shell script. But for an important operation such as flashing, I prefer the one-at-a-time approach of the interactive shell.
Note that CWM does have an ADB service running with it. Your Ouya would show up as a different device while in CWM, so you'd need to enter Device Manager (Windows) and point the unknown device to the same ADB driver as used for the main ROM.
Alternatively you could skip ADB for this Ouya Boot Menu installation and set up an SSH server on your main ROM. I personally have installed "SSH Server" (Ice Cold Apps). I recall two screens to set up (does require the trackpad in cases), where I enabled automatic start on both, and also set the port number to 2222. After an Ouya reboot I had SSH/SCP capability and could use PuTTY/pscp from Windows.

Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
For a developer, I'm sure it's easier and more familiar to run ADB commands - for people like me (5%-over-the average-user) a CVM option to flash a zip and do all this would be more in-line with the abilities to hack.
I have rooted 4-5 devices so far and the only time I type any ADB commands is at root/unlock time - sometimes not even then (Nexus 4 and the Root Toolkit).
So if you ever consider creating a recovery flashable file, it would help many. Probably not me, as by then I would have done the ADB trick

Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)
I will definitely take a look at your work when I have time!
~Troop

Ipse_Tase said:
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
Click to expand...
Click to collapse
You got it! You don't need to worry about booting to the other partition prior to flashing. That is a given partition (LNX/SOS) is no longer being accessed once the image is booted. For CWM's ADB, you'd simply point Windows to the same INF file that you originally used. Hope this helps.

StockPlus Installation
Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).
(You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)
The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.

Still haven't tried this out yet, but I hope to soon.
I missed out on news over the holidays though and just noticed this:
Announcing Ubuntu and Android dual boot developer preview
http://developer.ubuntu.com/2013/12/announcing-ubuntu-and-android-dual-boot-developer-preview/
I'm curious of their dual boot implementation and how it compares and if we can synergize with their approach, but haven't looked into the details of how theirs works yet (its sounds like it uses a custom recovery image, and they have the ability to trigger it to reboot into Ubuntu from an Android app and vice versa, which is cool)
It'd be awesome to be able to multi-boot an Ouya ROM, an Android ROM (CyanogenMod), and Ubuntu with that kind of ease.
EDIT: This may be more our speed though: (MultiROM)
http://forum.xda-developers.com/showthread.php?t=2011403
(did you pull anything from there? Sounds like they have a modified TWRP that can flash zips to the other ROM slots, which is something I was also hoping to implement)
~Troop

Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.
I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.
I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.
Best of luck, and hope you'll have a chance to try it all!

accidental post please delete

[Q] Android 4.4 + damaged internal storage : how to permanently modify fstab ?

Hi everybody,
I'm trying to bring back to life a GT-P1000 that had a damaged internal storage. After physically removing the damaged chip, I managed to install CyanogenMod 11 (Android 4.4) on a partitioned external SD card. However, though the device runs fine, I can't save/download any file, as there's no writable partition set up.
I've read many things about modifying a vold.fstab file for that matter… but all those guides/howtos regard previous Android versions. But starting with Android 4.4, such file no longer exists.
From what I've understood, there is now an etc/fstab file that is recreated/generated at boot from "some place", but I've yet to discover where and how to manipulate it.
Any idea ?

Android has different services e.g. vold for managing different storage types. These have also different places where they are configured. E.g in init scripts or storage_list.xml.
And even worse this differs between Android versions.
/etc/fstab is just the result where all this is thrown together. And as you noticed it's regenerated on every reboot.
As a starting point you can find an overview where the configuration is actually coming from depending on the Android version at
https://source.android.com/devices/storage/config.html
https://source.android.com/devices/storage/config-example.html

Hello u42671,
Thank you for those pointers, they are very interesting indeed and I now understand much better how it all wraps up (though there's no storage_list.xml file on my device).
However, I still don't know how/where the different init scripts are generated on reboot. Do you have any idea ?

The init scripts should be stable and not be regenerated in every reboot. Android init system is a bit different to what you might know from other Linux distributions .
See http://elinux.org/Android_Booting
I don't have my Galaxy Tab at hand now in order to check but device specific mounts are probably setup in the init.p1.rc script located directly in the root directory.
Actually the init scripts might also come from boot.img. So you should also check this. See
http://android-dls.com/wiki/index.p..._Images#Structure_of_boot_and_recovery_images

/init.rc calls /init.p1.rc that in turn does "mount_all /fstab.p1"
However, all those 3 files seem to be recreated at boot.
I'm still reading your links and trying to put it all together… but that looks about right so far.

That's why I added the comment about boot.img. boot.img does also contain the init files. After all,
the stuff inside boot.img is supposed to do the basic tasks before filesystems are mounted. I suspect that you have to extract boot.img, change the init scripts there and then repack and reflash boot img if you want the changes to survive a reboot.

Thread necromancy here !
I tried for months to unpack that boot.img, to no avail… I actually think I understood that the GT-P1000 uses zImage, but still : no tool I've found so far managed to unpack the bloody thing. Most seem to be outdated.
So, I'm gonna try feroxxx's CM13 beta (http://forum.xda-developers.com/galaxy-tab/development/rombeta-cyanogenmod-13-0-t3356495) and pray really really hard that it works…

Good news : @feroxxx's CM13 (and TWRP !) both install as intended ! See http://forum.xda-developers.com/showpost.php?p=68697664&postcount=93
Bad news : CM still does not understand to use the FAT32 partition of the external SD card as /sdcard. Needs more work…

G925v Analysis, Rooting, Dev Files & Implications

So it happened day before yesterday, 8-22-17 @ ~5:50 PM, my Verizon S6 Edge (G925VZKE [64GB]) bricked out. No LED Light, nothing on Screen, nothing as if actually Hard Bricked. No booting, No download Mode, nothing. But it's not fully hard bricked actually. When I plug the device into my PC, Windows will either pop and say the device malfunctioned or it will read as "Exynos7420". I'm not quite sure what to do about it at the moment, I've read [a little] about what to do with phones in this mode using a "USB_Down_Load_32bit"/Multidownloader. I believe it to be stuck in a Diagnostic Mode I'm not versed in. This all happened while I was in the ADB Root Shell (su:s0) while the device was powered off and charging.
I am making this thread here for any devs you would want to use the knowledge and files here, to take the project further. As I cannot currently use my device at all. And I won't be getting a replacement S6 Edge for at least a month, maybe two. I love the S6, and will still choose it over most devices. I've been dedicated to researching and posting about the Samsung Exynos7420 Hardware since September 2016. That was when I came up with the plan for The Greyhat Root Project. You may recall my other thread once in the Original Development Forum & now in General. If you search "Greyhat Root" in google. My thread will be the first result. It gained a lot of traction, very very quickly. But is now dead, and the mods probably hate me for making a new thread. But I'm not trying to put new news out there this time.
It focused on how to use Kali Linux and Metasploit. It also focused on the articles at the time that was new exploit & malware research, that boasted of the possibilities we've now come to know as the Vault7 leaks. There's probably a reason I was a victim of the malware myself and I took down most of the posts. Most of the good file and resources I posted to that thread were either flagged by end users or removed by google. The real treasure of that thread is lost to the internet now, as that was the only backup I had of some of the critical files needed for the process. If you actually look through my individual posts all over, you will find some juicy tidbits of knowledge spread around this site that I've not compiled into one. A lot of it is still over my head as it was then, and partly why I took it down then. But I've been chipping away at that knowledge base everday for 10 months going on a year now. It's possible to root this device if One can take the knowledge of how to leverage the news worthy exploits from the past 2 years into a single repo/application. "Android-InsecureBankv2" is one example of such a platform. But as a teaching platform, it is not configured to provide a SuperSu Root Solution out of the box. It would still require modification of someone else's codebase w/Learning Curve.
No I have not managed to find a way to unlock the bootloader because I do not have a copy of IDA Pro or the Hex Rays Decompiler, and if I did, I still wouldn't know to use them fully. But I have managed to find quite a number of very possible attack vectors, if I can get some serious developers to take my sentiments seriously. I proved that when the posts about dirtycow were largely ignored due to device interest, and then @droidvoider helped make some of my ideas possible with the "Greyhat Root Console" he made. Realistically at this point I only wish I were an Assembler. I'm only one guy trying to poke at a Hardware/Software Package created by multiple departments of people in a conglomerate corporation. I only bring people together. I do know that in order to disassemble the Exynos7420 sboot, you're going to need to understand U-Boot on Arm64. A Uboot version dating back to either January 2016 or August 2015. I say those two dates because, The 4BOG7 files on my device date to August 2015, the 4AOJ1 files, to January 2016. Project Zero (who does a lot of tests on the G925v btw), posted in February 2017 about they found a way to bypass the KASLR feature of the stock kernel. A Kernel I do believe we can still flash to the device. It didn't gain much attention I don't think at the time because it was only one piece to the puzzle. That exploit wasn't patched until January. I know it sounds bad when I say it like this but, what this device truly needs is a friendly Botnet-C&C-Style rootkit that has it's client and server controlled by a User-Controlled, SuperSu-Style management application. Yes, it would be a rootkit you would never want to have someone else in control of. But if SuperSu were controlled by someone else other than the end user at the time, it would be just as bad. It's just a different approach to a yet unpublished methodology.
*
** The Device I refer to is currently flashed with:
******
** Full 4 File Firmware: COMBINATION_VZW_FA50_G925VVRU4AOJ1_VZW4AOJ1_CL5133452_QB6486176_REV02_user_mid_noship.tar
** BL: G925VVRU4AOJ1 ENG sboot.bin
** AP Kernel: G925VVRU4BOG7 ENG Kernel
** TrustZone Type: t-base-tui (Filenames suggesting Mobicore present as well)
******
Trying to enter Recovery Mode with the Combo firmware, in my experience, typically sends the device into a Panic and boots into "Upload Mode" if it does not simply reboot. The combination firmware does not supply a recovery.img that I've found. And inorder to recover the ENG Combination Recovery, you would have to disassemble the OJ1 ENG sboot.bin in IDA Pro and pull it out.
During the initial boot the device will enter its own recovery mode for a moment while it does its erasing stage. I used "nand erase all, re-partition, F.Reset Time, Phone Bootloader Update options in ODIN. During this breif moment with the "Erasing..." text on-screen, the phone is available in ADB Devices and shows up in recovery mode. Meaning ADB Shell should be accesible in recovery. If that's possible that means the device keystore should be accessible as well. The Recovery images tend to be bigger because the signatures are stored in the recovery from what I've read. Can't dirtycow patch anything it can see if your shell can't change it?
Using those files, I have full su authority anytime I am in ADB Shell, the shell runs within the "su:s0" context, and not the "shell:s0" context. Any and All changes are possible through the shell. Writing a new partition Table to '/dev/block/platform/15570000.ufs/sdb' using the "partx" tool, is probably what broke my phone. So in theory installing SuperSu in System Mode should work much the same as it did on G95x S8/Plus I'm gathering. @dragoodwael was correct in supposing "sdb" to be the bootloader overall, as I do now too. Once the reboot command was issued, I lost the ability to do anything at all. All thats possible now, is to find a tool that will communicate with the driver my PC's Device Manager loaded for my phone.
Every boot.img I've unpacked using Android Image Kitchen specified that a signature of "SEAndroid Type was found". BUT, the only boot.img/Kernel that did not specify that it was an "SEAndroid Type" while being unpacked, is the Stock boot.img from the 4AOJ1 Combination Firmware. Out of the 7 boot images I've unpacked, AIK determined the OJ1 Combination boot.img did NOT have an SEAndroid Signature on it.
boot.imgs I've unpacked:
1. N920A - PB2 Eng boot.img
2. N920A - FA51 Combi - PH1 boot.img
3. N920A - FA51 Combi - PL1 boot.img
4. G925V - FA50 Combi - OG2 boot.img
5. G925V - FA50 Combi - OJ1 boot.img
6. G925V - OG7 Stock boot.img
7. G925V - OG7 ENG boot.img
I'm not quite sure what that means yet, but I do know that the zip file I have that contains the 4AOJ1 factory Binary is not a tar.md5 like usual, it is just a normal .tar. What I'd LOVE to know is, can the 4AOJ1 stock boot.img be unpacked, then repacked, and retain its flashable characteristic. Because AIK does not register a standard signature. Does that mean the Oj1 boot.img uses a different mechanism for signature verification than a standard user binary, or is it simply signed with publicly available signing keys? It's a good question, what is different about its signature compared to other stock signatures. Even if we don't understand the signatures fully.
I'm also aware of the fact, that the Combination firmware doesn't actually contain a recovery.img to flash. Probably why the Device goes into Upload Mode and Panics when trying to boot recovery after using "nand flash all" and/or "re-partition" in ODIN. But if there were a Recovery Image for the OJ1 firmware, I imagine it would not have an SEAndroid signature on it as well. So there must be something to that.
I wonder what would happen if you tried to flash the OJ1 boot.img to the recovery partition as recovery.img like in the "EasyRecowvery" project, while using the full factory binary.
Is it possible that the newer "ustar" tar format used by Samsung in ODIN packages, could be using the custom fields available in a ustar header block to hold at least part of the signing mechanism? I believe so. And I say it because on my Device, it runs the Odin3 Engine (v1.1203), which looks an aweful lot like ODIN v1.12.3. Besides the naming conventions used there, ODIN expects to send/receive images within tar archives. Specifically USTAR format tar archives. So if the ODIN Engine on the phone is anything like the PC Client application, it expects USTAR format Tar archives as well. If it expects to read in a USTAR Header block, there are custom fields possible in known locations of the official tar files. Which when parsed correctly, should lead to finding the extra data after the payload 7-Zip refers to when the tar.md5 files are extracted. I'm of the mind the "Star" utility and not the the "Tar" utility is what we should be using to create and modify ODIN firmware the way our OEM's do. That is hypothesis on my part yes, but I don't think I'm very far off base.
Here is a man page on the "ustar" utility I found interesting and extremely in-depth: ustar(1) - unique standard tape archiver - Linux man page
If you want to see a list of files involved in all of this research, please refer to this folder here: https://drive.google.com/open?id=0B_EcHdXbjhT_dDRneE56WUg3Mlk
It contains all the files I've mentioned except for the OJ1 Firmware itself. This is all I'm posting for today, it's a sad day indeed. But I have to gather the bookmarks again to post the links to articles.