Database Develop

[DEV] Coburn's Tattoo Hacking Corner - Mount Points, Fastboot and more - Take a peek!

Before I start, can we please keep the n00bish comments away from this thread. I have experience in doing this, and if I/we find a solution to this rooting drama, I'll post a how-to. A simple "Thanks, this will keep my fingers crossed" post is all that's enough to spark a chain reaction and fuel the fire knowing that we've got a strong user base that can help us test out our hacks.
Let's get down to business, shall we?
Mount Points:
This is the list of mount points that can be retrieved by issuing a simple 'mount' command on the adb shell, while your device is in USB Debugging (Settings > Applications > Development). Or in a terminal emulator.
rootfs / rootfs ro 0 0
[X]tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
[!] tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
[!!]/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
Click to expand...
Click to collapse
I've added [X], [!] and [!!] to point out what we can do. The one with the cross is a no-go, despite being a tmpfs (TeMPorary File System), we can't write to it, and /dev/shm doesn't exist either. /dev/shm is commonly on Linux systems, a ram drive - anything written there goes bye-byes on reboot.
The second one, /sqlite_stmt_journals, which is mounted as RW, aka Read Write. Yes, we can run shell scripts, you do 'sh myscript.sh' from a terminal emulator or the adb shell to get them to run. Surpise - No noexec (no executables) flag, we can *possibly* run some custom non-root software! Downside? Only 4MB to play with. Shoot.
The second one, is the main target. /system is where Android is held, locked up in a RO filesystem. RO is Read Only. In other words, we can look but can't touch. (Bummer.) This is where we try to get into (with superuser apk and such), but it restricts us. If we can remount this sucker RW... Well, I did try:
$ mkdir /sdcard/test && mount -t yaffs2 -o rw /dev/block/mtdblock /sdcard/test
mkdir failed for /sdcard/test, File exists
$ mount -t yaffs2 -o rw /dev/block/mtdblock3 /sdcard/test
mount -t yaffs2 -o rw /dev/block/mtdblock3 /sdcard/test
mount: Operation not permitted
$ mount -t yaffs2 -o ro /dev/block/mtdblock3 /sdcard/test
mount -t yaffs2 -o ro /dev/block/mtdblock3 /sdcard/test
mount: Operation not permitted
$
Click to expand...
Click to collapse
...But it failed. /sdcard/test was the mount point on my sdcard that I wanted it to be accessed from, so I could just simply go "bang bang bang woot! GOLD! ". But no. Silly HTC.
Teh fastboot way of life:
Power off your HTC Tattoo and hold VOL Down while pressing the End Call/Power Button to enter the bootloader menu. Let the device scan for some DIAG ramdisk images (Test/Diagnostics mode?). After that, press the back button to enter the fastboot USB menu. While there, open a command prompt (on PC), change to the path where you downloaded fastboot (you can nab the said tool by downloading modaco's superboot 1.2 zip file in a thread in this category). Replace fastboot-windows with fastboot-linux, etc.
C:\Users\Coburn\Downloads\Tattoo>fastboot-windows oem boot tattoo.superboot.img
... INFOsetup_tag addr=0xA0000100 cmdline add=0x8D05E538
INFOTAG:Ramdisk OK
INFOTAG:smi ok, size = 0
INFOTAG:hwid 0x1
INFOTAG:skuid 0x1FC04
INFOTAG:hero panel = 0x0
INFOTAG:engineerid = 0x0
INFOMCP dual-die
INFOMCP dual-die
INFOTAG:mono-die = 0x0
INFODevice CID is not super CID
INFOCID is VODAP001
INFOsetting.cid::VODAP001
INFOserial number: HT99SLG03779
INFOcommandline from head: no_console_suspend=1 console=null
INFOcommand line length =404
INFOactive commandline: board_bahamas.disable_uart3=0 board_baha
INFOmas.usb_h2w_sw=0 board_bahamas.disable_sdcard=0 diag.enabled
INFO=0 board_bahamas.debug_uart=0 smisize=0 androidboot.baseban
INFOd=3.35.07.20 androidboot.cid=VODAP001 androidboot.carrier=VO
INFODA-UK androidboot.mid=CLIC10000 androidboot.keycaps=qwerty a
INFOndroidboot.mode=normal androidboot.serialno=HT99SLG03779 and
INFOroidboot.bootloader=0.52.0001 no_console_suspend=1 console=n
INFOull
INFOaARM_Partion[0].name=misc
INFOaARM_Partion[1].name=recovery
INFOaARM_Partion[2].name=boot
INFOaARM_Partion[3].name=system
INFOaARM_Partion[4].name=cache
INFOaARM_Partion[5].name=userdata
INFOpartition number=6
INFOValid partition num=6
INFO0
INFO0
INFO69466957
INFO69784520
INFO69007473
INFO7473
INFO0
INFO0
INFO0
INFO0
INFO0
INFO0
[....]
FAILED (status read failed (Too many links))
Click to expand...
Click to collapse
Oh my! Look at that! Did I just get a kernel parameter dump?! I tried the oem boot method using paul's superboot boot.img, and that's the data that it spat back. When it rebooted, it did the vibration like it would do on a cold boot. There was a lot of INFO0s though... Then it died with "Too many links". Aww. A Misc Partition?! WHAT?! Who knows what's there... (HTC, what are you hiding from us that you shouldn't be?)
Also, if we can force a custom kernel parameter with the "fastboot -c <something to make kernel remount system rw> oem boot" command, we may have a idea.
reboot-bootloader doesn't seem to work... "FAILED: remote (not allow)."
See below:
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot + recovery + system
flash <partition> [ <filename> ] write a file to a flash partition
erase <partition> erase a flash partition
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
reboot reboot device normally
reboot-bootloader reboot device into bootloader
options:
-w erase userdata and cache
-s <serial number> specify device serial number
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
Click to expand...
Click to collapse
I'm tapped. I hope this helps us in any way, it took about an hour to type (and copy/paste from CMD on Windows 7).
Remember: It's our phone, not theirs. We're breaking free - if Android is open source, why isn't the hardware?
Cheers (and please don't forget to buy me a coffee! ),
Coburn64.

Thanks coburn and f..k HTC

Good investigative work!
One point tho...
Coburn64 said:
The second one, /sqlite_stmt_journals, which is mounted as RW, aka Read Write. Yes, we can run shell scripts, you do 'sh myscript.sh' from a terminal emulator or the adb shell to get them to run. Surpise - No noexec (no executables) flag, we can *possibly* run some custom non-root software! Downside? Only 4MB to play with. Shoot.
Click to expand...
Click to collapse
What does this allow that we can't already do on /data? We can already push executables to /data/local and chmod and execute them... I believe this approach has already been tried for trying asroot2, try3 etc. exploits and the like.
The Tattoo seems pretty tight (altho of course nothing is impenetrable), our best bet is likely to be a leak of a S-OFF bootloader or an as yet unpatched kernel exploit?
P

List of options for "fastboot oem":
Code:
$ ./fastboot.exe oem h
... INFOcommand list
INFOkeytest
INFOheap
INFOboot
INFOreset
INFOpowerdown
INFOrebootRUU
INFOenableqxdm
INFOrtask
INFOtask
OKAY
rebootRUU is particulary usefull, it enables RUU mode without having to go through "adb shell reboot oem-78".

@modaco: Every time I tried to write something in /data/local, I kept getting the message "Permission Denied" like I didn't have write permissions or anything. How did you manage to do this?
@mainfram3: Nice work! I know 'fastboot oem boot' reboots the phone to flashed ROM (even if you try to force a custom image down it's throat) but this is rather interesting.
I wonder what 'fastboot oem enableqxdm' does? I'll try it out tonight...
EDIT: Looking at some exploits, there's a 2.4/2.6 kernel "sock_sendpage() NULL pointer dereference" exploit here on milw0rm.com. Does anyone know what kernel source version on HTC's Dev site is?

enable qxdm enables support for the Qualcomm qxdm debug tool.
Hmmm, like I say, I don't have a tattoo yet, but you can normally write to /data/local. Strange!
P

Coburn64 said:
EDIT: Looking at some exploits, there's a 2.4/2.6 kernel "sock_sendpage() NULL pointer dereference" exploit here on milw0rm.com. Does anyone know what kernel source version on HTC's Dev site is?
Click to expand...
Click to collapse
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S

mainfram3 said:
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S
Click to expand...
Click to collapse
Confirmed, we're running 2.6.29 on the offical ROMs. This looks promising.

mainfram3 said:
That's a very nice find! From the source, Linux kernel versions from 2.4.4 to 2.4.37.4, and from 2.6.0 to 2.6.30.4 are vulnerable. Our Tattoos are running 2.6.29
We need a skilled kernel developer to port this to the Android, since the exploit relies on low level assembly code :S
Click to expand...
Click to collapse
I wrote to author of FlashRec. Waiting for answer)

5[Strogino] said:
I wrote to author of FlashRec. Waiting for answer)
Click to expand...
Click to collapse
Awesome. What's flashrec anyway?
I was feeling adventous and decided to try some other rooting attempts that have succeeded on other phones. The fun thing was, I could get so close to the finishing line, when the Tattoo would kill the process (asroot2, try3, etc).
Damn. However, we can't give up - the goal is just in sight, we'll get there - we need to reroute the plan.

Coburn64 said:
Awesome. What's flashrec anyway?
I was feeling adventous and decided to try some other rooting attempts that have succeeded on other phones. The fun thing was, I could get so close to the finishing line, when the Tattoo would kill the process (asroot2, try3, etc).
Damn. However, we can't give up - the goal is just in sight, we'll get there - we need to reroute the plan.
Click to expand...
Click to collapse
FlashRec it's application for HTC Magic with exploit inside, to install custom recovery on systems with old Cupcake ROMs.
http://zenthought.org/content/project/flashrec
When HTC closed down a hole, that flashrec has been used, it become out-of-use
But mainfram3 found a new hope. Not only Tattoo users, Magic users (who stucked at new Hboot 1.76.00XX) have this hope too)

5[Strogino] said:
But mainfram3 found a new hope.
Click to expand...
Click to collapse
You meant Coburn64
And also let's not forget Droid Eris users, they're stuck in the same place we are, and they seem to be a much larger group.

this is personal now!!
i know that they just have added support for the sprint hero in flashrec i think it's on version 1.4 now!
all we need is just to find a small hole in the system making us able to write directly to the device and passing all the security sh*t
i have been in contact with htc tech center but have not been able to come through yet
i will request a eng S-off and matching radio!
i will also take take a look at the exploit code for the 2.6.29 kernel
I really hope we will get this working as i already have made custom ROM and recovery.img for it! hehe...

/data/local is writable, so is /sqlite_stmt_journals. The latter is restricted to 4MB, while the first has a lot of space (the rest of the /data partition).
Oh, and I can write to the data/local directory, I have to use adb push to get files on there.
Oddly enough, it allowed me to install a Hero super user APK on my Tattoo. Now, this is getting fun. Could someone disguise asroot2 or something inside an app, package it up as a APK and get android to install it?
I tried the asroot2, try3 and such but I got:
[1] Killed /data/local/asroot2
Click to expand...
Click to collapse
...like there's some watchdog feature inside the kernel or something. :-/

UPDATE: I'm working on a busybox hack for the tattoo. The aim of this is to get busybox installed on the device, so I can dump the NAND chip partitions and get that SPL.
Fingers crossed, and we also have found the debugging ROM for the Tattoo! So yeah, hehe...

Coburn64 said:
UPDATE: I'm working on a busybox hack for the tattoo. The aim of this is to get busybox installed on the device, so I can dump the NAND chip partitions and get that SPL.
Fingers crossed, and we also have found the debugging ROM for the Tattoo! So yeah, hehe...
Click to expand...
Click to collapse
Respect!! Hope for success, thanks for your effort

Thank you for your hard work!
I thought the rooting of tattoo died when benham ceased to exist in another tattoo-related forum and now i stumble upon this!
Crossing fingers!^^

Musenkishi said:
Thank you for your hard work!
I thought the rooting of tattoo died when benham ceased to exist in another tattoo-related forum and now i stumble upon this!
Crossing fingers!^^
Click to expand...
Click to collapse
Heh.
BUMP: My Busybox Hack is now live! Get it and install the sucker on your phone!

[ROOTING] Finding a hole in Tattoos kernel to get root

This little gem of a phone is a tough little thing to custom install apps on, but that didn't stop the Coburn from being able to get busybox installed.
Therefore, introducing Busybox for your HTC Click/Tattoo!
FOLLOW THIS TUTORIAL CAREFULLY. This guide may brick or NOT brick your Tattoo (most likely the latter), however I cannot assure you that it's 100% fail proof. I have installed it successfully. IN OTHER WORDS: THIS IS NOT FOR THE FAINT HEARTED! IF YOU DO NOT KNOW WHAT 'FLASH','ADB' OR 'HACK' MEANS, PLEASE DO NOT CONTINUE.
Requirements:
1 HTC Tattoo (The Victim)
1 MS Windows Powered Computer (I used Win7 64Bit)
1 HTC Tattoo -> USB Cable (Included with phone... Well, it was in the box).
Download the package attached to this post. Extract all files to a directory like C:\BUSYCLICK . (Actually, please extract them there).
Installation
Connect your Tattoo to your phone, make sure USB Debugging is enabled (Settings -> Applications -> Development) and sit back. Windows should say "New Hardware! OMG!" and ask "What is this piece of tech?" (aka New Hardware Install Wizard). On XP, allow to search Windows Update. On Vista/7, I'm going to have to get back to you on that. The installed driver will be like "HTC Dream blah blah blah ADB Interface" or something. Odd why it says it's a HTC Dream...
Anyway, go to the folder where you extracted the files, and run the Installation.bat file. It's the one that says "Installation" With the cogs icon.
You'll get a DOS Prompt and some text, PAY ATTENTION! My installer will hold your hand and explain what's happening. Should any errors occur, you may be out of space on your Tattoo's internal memory or something. If you do get errors, please post them here! I'll try to fix them for you guys and girls.
Post-install tasks
When complete, run the TestBusybox.bat script in the same folder where you extracted the BusyBox files, and you should get some output. If not, busybox failed to install... Let me know what the error is and I'll try to fix it.
Notes:
You can use the busybox commands in /data/local/bin from "adb shell" or a terminal emulator on the phone itself... /data/local/bin/sh DOES NOT work from adb shell, I don't know why. It will work using a terminal emulator. Try "/data/local/bin/free" and such for some memory read outs, etc, etc.
Feel free to love/like/hate/kill/shoot my work, you can expect to see ROMs and the like in the near future as I love hacking devices.
Cheers,
Coburn64

What about this one?
I have no experiences in Android-Developing, I'm just a normal long-term Linux-User.
What is about that?
http://www.milw0rm.com/exploits/8678
It's an exploit for Kernel 2.6.29 - my be this could work for us or is it patched in Tattoos 2.6.29?
I wish I would find the time to dive in the Android-SDK and cross-compiling a little bit but it won't happen until April :-(
So just for your personal motivation: There are thousands of people out there watching this forum and crossing fingers! So keep up your work and don't stop trying!
Good luck!
Bastian
Moderatoredit: Link repaired - have a nice day

My fingers are crossed

+1 Can't wait till the Tattoo gets rooted.

Yeah, crossing fingers for you - nothing more cool than wifi tethering

Wooh, how fast it can be april...
But until now I'm even unable to sucsessfully compile the exploit. I set up a cross-compile-environment on my laptop, but all I get is:
[email protected]:~/Desktop> /opt/cross/bin/arm-linux-gnueabi-gcc -static -o shoryuken shoryuken.c
shoryuken.c:49:24: error: linux/user.h: No such file or directory
I don't get it, there is a user.h in the cross-compile-environment in gnueeabi's searchpath. Sorry, semes to be a job for real developers if I already got my problems before real problems begin.
And my girlfriend has innumerable methods in killing me in cruel ways if I don't pay her more attention in exactly 2 minutes. Strange. "I want to root my tattoo! Thats very important!" doesn't seem to make any differences, she arguments that I could not even have a tattoo, she sees me naked periodically and she had never seen one...
So real experts, the fields of war belongs to you!
Bastian

The first step is finding the patch that closes this bug. Then, verify if has been aplied in the source that HTC released a couple days ago (very likely, since the exploit is dated from April and our kernel was compiled in November).
If it is not patched, we would need some ARM shellcode, but that is probably easily obtainable in the usual places. Worst case, we would need a ARM dev to write it.

I did my best to help. Because as i already said I'm not a developer I will describe what I did to prevent starting someone to work on something that could never work.
I searched for the patch that closes this hole:
Code:
CVE-2009-1527 :
Race condition in the ptrace_attach function in kernel/ptrace.c in
the Linux kernel before 2.6.30-rc4 allows local users to gain
privileges via a PTRACE_ATTACH ptrace call during an exec system call
that is launching a setuid application, related to locking an
incorrect cred_exec_mutex object.
---------
and in the Changelog for Kernel 2.6.29.3
Code:
commit 2c9ca2baf3f368a2b747124d39bf31b779eb7571
Author: Oleg Nesterov
Date: Mon Apr 27 01:41:34 2009 +0200
ptrace: ptrace_attach: fix the usage of ->cred_exec_mutex
commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb upstream.
ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex.
Signed-off-by: Oleg Nesterov
Acked-by: Roland McGrath
Acked-by: David Howells
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman
So I looked for commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb and there is the .diff:
Code:
kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -186,7 +186,7 @@ int ptrace_attach(struct task_struct *ta
/* Protect exec's credential calculations against our interference;
* SUID, SGID and LSM creds get determined differently under ptrace.
*/
- retval = mutex_lock_interruptible(&current->cred_exec_mutex);
+ retval = mutex_lock_interruptible(&task->cred_exec_mutex);
if (retval < 0)
goto out;
@@ -230,7 +230,7 @@ repeat:
bad:
write_unlock_irqrestore(&tasklist_lock, flags);
task_unlock(task);
- mutex_unlock(&current->cred_exec_mutex);
+ mutex_unlock(&task->cred_exec_mutex);
out:
return retval;
}
Then I downloaded and extracted the Tattoo-Kernel-Source from HTCs Website. The patch is small so I looked into ptrace.c by myself. And what should I say, I think HTC missed to close that hole. From HTC's ptrace.c:
Code:
retval = mutex_lock_interruptible(&current->cred_exec_mutex);
if (retval < 0)
goto out;
and:
Code:
bad:
write_unlock_irqrestore(&tasklist_lock, flags);
task_unlock(task);
mutex_unlock(&current->cred_exec_mutex);
out:
return retval;
}
If the patch would have been applied, it should be &task->cred_exec_mutex but it is still &current->cred_exec_mutex.
Am I right? Could that realy be our chance? If yes, it is on you or someone else to go one, I could only help testing things later one.
Bastian

The implementation is full of mutex ... The problem is that they function as a lock if a process is in a mutex, other processes can not enter.
If the root process closes a mutex (mutex_lock), the rest of the processes are kept waiting has to open the mutex (mutex_unlock). Just why we can not access to root processes with another process.And we can not get the root of the tattoo
thx

-bm- said:
I did my best to help. Because as i already said I'm not a developer I will describe what I did to prevent starting someone to work on something that could never work.
Click to expand...
Click to collapse
Well, I think you did a wonderfull job I also confirm your findings, I've checked ptrace.c in the HTC released source and the patch that you refer to as not been applied.
I've long forgotten allmost everything I knew about writing shellcode and x86 asm and never had any experience with arm, but I'll try to take a closer look at this during the weekend. I hope someone else will look into it too

@loen1984
That is over my technical horizon... ;-)
In my limited understanding, for the exploit we need a process that already runs with root-privileges to channel in, right?
I don't know anything about Androids architecture, is there nothing running with root-privileges in the background, no process, no daemon?
@mainframe3
I don't know anybody who's firm with arm developing, I hope you do
we would need some ARM shellcode, but that is probably easily obtainable in the usual places
Click to expand...
Click to collapse
And I think we should move this in a separate thread, it has not so much to do with Coburns BusyBox hack!

I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
thx
PD:Sorry for my english I'm Spanish ..

leon1984 said:
I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
Click to expand...
Click to collapse
I think that is what happens after the posted security patch is applied, but HTC didn't do that. But I will leave that field for the experts and cross fingers...
PD:Sorry for my english I'm Spanish ..
Click to expand...
Click to collapse
I'm german, mine won't be much better ;-)
Bastian

leon1984 said:
I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
thx
PD:Sorry for my english I'm Spanish ..
Click to expand...
Click to collapse
I really can't spend any more time with this, or my boss will probably fire me
Quick look at the exploit, we need a setuid program for this to work. Guess what ?
Code:
$ ls -l /system/bin/pppd
ls -l /system/bin/pppd
-rwsr-xr-x root shell 147648 2009-10-14 10:39 pppd
Also, someone else has already ported this to arm:
http://forum.xda-developers.com/showthread.php?t=619003
I couldn't download the modified code, because of permission problems, but I contacted the author to see if he will send it to me
PS - Yes, we should move this discussion out of this thread

Then you should really get back to work
Mod is already contacted!

So here you are, dudes. Dunno why the first post remains, but it does.

Here is the arm port, I could download the file with bubisch's help. I also uploaded it here:
http://www.fileuploadx.de/673586

I could'n get my fingers completly of from this (even there is many other work to do...) that day so I set up and compiled a local Android-SDK on my Laptop and crosscompiled the exploid for the Tattoo (I hope). This should be a ready-to-run binary:
http://www.fileuploadx.de/755003
Even if I want to satisfy my curiosity there is no time for me left to do it today. I will get on it again later, but if anybody wants to give it an early try feel free. Instructions how to push it on your phone in an executable directory you will find here in the second half of the first post: http://forum.xda-developers.com/showthread.php?t=619003
In the sourcecode of the exploid there is the explanation on how to use it:
Code:
[email protected]:~$ while `/bin/true/`;do ./shoryuken;done
* [... much scroll removed, go make coffee, get a job, do something while running ...]
* /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
* proc on /proc type proc (rw,noexec,nosuid,nodev)
* /sys on /sys type sysfs (rw,noexec,nosuid,nodev)
* varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
* varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
* udev on /dev type tmpfs (rw,mode=0755)
* devshm on /dev/shm type tmpfs (rw)
* devpts on /dev/pts type devpts (rw,gid=5,mode=620)
* securityfs on /sys/kernel/security type securityfs (rw)
* gvfs-fuse-daemon on /home/matthew/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=matthew)
* [ WIN! 18281
* [ Overwritten 0xb8097430
* # id
* uid=0(root) gid=1000(matthew) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),
* 44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),1000(matthew)
* #
As mainframe3 posted, pppd ist setuid. Maybe we have to do something to make pppd doing something to be running if it doesn't already.
So cross fingers again everybody - this could break the wall or make us sitting back in tears.
I hope some experts could use this, I will also give it a try later on.
Bastian

No questions about where I got the time an what about my motivation about the books I have to read.
Just some short lines about how far I get for the rest to go further.
I pushed my posted binary to the tattoo:
Code:
adb push shoryuken /data/local/shoryuken
In that location it is executable! The rest I don't understand realy. In general: I'm able to run the program in a shell:
Code:
$ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$ ./shoryuken
[ WIN! 3347
Wrote shellcode 9148 line 0
Wrote shellcode 914c line 4
Wrote shellcode 9150 line 8
[ Overwritten 0xb001049c
$ rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
$id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$
When I start shoryuken it returns what you see above without any delay. I'm not sure but shouldn't he say "WIN" when the exploit was successful? As you can see my priviliges didn't change. In his sourcecode shoryuken is run with "while `/bin/true/`;do ./shoryuken;done" That generates an endless loop, doesn't it? Or am I getting something wrong? I wonder how it might terminate somehow...
/bin/true doesn't exist on tattoo, so I generated an endless loop with "while i=1; do ./shoryuken; done"
As expected much text scrolls by on the screen, after a minute the output freezes. I hit ^C and got my prompt back, but when I ran "id" it shows that nothing changed.
So do I understand shoryukens function totaly wrong? What's going wrong and does that mean shoryuken is not working as it should because it says "WIN" every time I run it?
I already said it 5 times, but now I realy can't do anything more with my simple homeuser knowledge and will leave the field for the developers.
Good night!
Bastian

I've been searching... and pppd is on /system/bin/pppd
But now... I've no idea... what I can test? I have to run pppd in order to get xploited?

The CWM for Ouya project

Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.
The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.
I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.
Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:
./flash_image recovery recovery.img
error scanning partitions: No such file or directory
Mount reveals the following info:
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
but I can't make any sense of it. If anyone can help out i'd much appreciate it...

sonofskywalker3 said:
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Click to expand...
Click to collapse
This seems to be the magic lines in the update script:
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
Click to expand...
Click to collapse
I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.
UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts
UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).
UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).
Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line
package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");
where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).
You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.
WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.
You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
Sent from my Nexus 7 using xda premium

Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...

sonofskywalker3 said:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
Click to expand...
Click to collapse
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).

Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.

sonofskywalker3 said:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
Click to expand...
Click to collapse
It probably doesn't work because the update.zip we're using is signed.
Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.
1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"
6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)
This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.
For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.
Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.
Click to expand...
Click to collapse
There are two big unknowns here:
1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery
I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS
---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------
/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1
So far, it appears that the layout is the following:
Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3
Sent from my SCH-I535 using xda premium
---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------
I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
Sent from my SCH-I535 using xda premium

Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.

mybook4 said:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Click to expand...
Click to collapse
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.

rayman said:
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
Click to expand...
Click to collapse
I did the following with skywalker's recovery.
1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)
The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)
5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.
When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.
Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.

Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.

sonofskywalker3 said:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
Click to expand...
Click to collapse
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.
If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
Sent from my SCH-I535 using xda premium

I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?

sonofskywalker3 said:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
Click to expand...
Click to collapse
I'm still new at making a recovery.fstab, but I noticed the following:
From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"
lrwxrwxrwx root root 2013-05-25 02:23 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-05-25 02:23 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-05-25 02:23 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-05-25 02:23 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-05-25 02:23 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-05-25 02:23 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-05-25 02:23 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-05-25 02:23 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-05-25 02:23 USP -> /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?
We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.
P.S. So far, I think we are fairly certain that
APP is the system partition
CAC is the cache partition
LNX is kernel boot.img
SOS is the recovery partition
I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?

Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Update:
Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.

sonofskywalker3 said:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/systemext4/dev/block/platform/sdhci-tegra.3/by-name/APP
/cacheext4/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dataext4/dev/block/platform/sdhci-tegra.3/by-name/UDAlength=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/bootemmc/dev/block/platform/sdhci-tegra.3/by-name/LNX
/recoveryemmc/dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Click to expand...
Click to collapse
Good stuff.
Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab
length= field is probably not needed, as the stock recovery doesn't list it.
Sent from my SCH-I535 using xda premium

Here's the recovery.fstab from my Ouya's recovery partition.
# mount point fstype device
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard vfat /dev/block/platform/sdhci-tegra.0/by-num/p1
Click to expand...
Click to collapse
I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.
Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).
I tweaked the recovery.fstab to the following:
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard datamedia /dev/null
Click to expand...
Click to collapse
This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.
I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.
I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.

well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Update!
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!

sonofskywalker3 said:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Click to expand...
Click to collapse
I edited the comment right above yours.
Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.
1) adb shell
2) su
3) cd /dev/block/platform/sdhci-tegra.3/by-name
4) dd if=SOS of=/sdcard/stockRecovery.img
5) exit
6) adb pull /sdcard/stockRecovery.img .
I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:
I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.
Here's what I did step by step:
1) split_bootimg.pl stockRecovery.img
2) mkdir ramdisk
3) cd ramdisk
4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i
in the ramdisk directory is etc/recovery.fstab
I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.

sonofskywalker3 said:
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
Click to expand...
Click to collapse
Awesome! Let us know how the backup/restore and zip flashing goes.
Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):
1) adb reboot bootloader
2) wait 30 seconds (blank screen is normal)
3) fastboot flash recovery recovery.img
4) fastboot reboot recovery (need a usb keyboard to navigate CWM)
5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)
6) profit
Most of this could potentially be automated into a root/install CWM script.

Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...
Update:
The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.
It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.
Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.
Edit: removed non working zip

twrp mounting wrong /system?

Hi,
I'll try and give as many details as possible. between me trying to get a root method to pass safteynet and updating to Nougat.
I manually updated to nougat as to not lose my data... ie: flashed radio, firmware, system, etc. First oddity was that twrp (twrp-3.0.2-0-shamu.img) would not stick unless i was rooted....weird. I also read I needed to rename recovery-from-boot.p to recovery-from-boot.bak and it would stick, though this made no difference, which i figured out why (coming up later). Ok, so i'm now rooted twrp and twrp is sticking. This is where i went to install the new pixel launcher as i was using nexus launcher before the update and was quite fond of it. I would flash the zip through twrp, but it would never show up as a system app. i tried and tried to get it there, to no avail. Ok, so i need to boot to recovery to access /system... sure, lets try that. I mount /system in twrp, flash the zip, use the file manager to check it out. It is showing in /system/priv-app. Cool. Boot phone, not there. Some weirdness is happening....
Twrp and /system are doing strange things...
While booted (truncated):
Code:
shamu:/ $ mount
/dev/block/dm-0 on /system type ext4 (ro,seclabel,relatime,data=ordered)
While in twrp:
Code:
~ # mount
/dev/block/mmcblk0p41 on /system type ext4 (rw,seclabel,relatime,data=ordered)
Why is one dm-0 and the other mmcblk0p41? Lets keep looking...
While booted:
Code:
shamu:/ $ ls /system/
app build.prop fake-libs framework lost+found priv-app usr xbin
bin etc fonts lib media recovery-from-boot.p vendor
While in twrp:
Code:
~ # ls /system/
app fonts priv-app
bin framework recovery-from-boot.bak
build.prop lib usr
etc lost+found vendor
fake-libs media xbin
Ah! i knew i changed the recovery-from-boot.p file! But.... why is it changed in the twrp /system and not the booted /system? That would explain why twrp kept getting overwritten. But whats going on here? Its like twrp is not mounting the right /system.... yet i can figure out how to mount the proper one.
While booted:
Code:
shamu:/data/data # mount -o rw,remount,rw /system
mount: '/dev/block/dm-0'->'/system': Device or resource busy
While in twrp:
Code:
~ # mount -o rw,remount,rw /system
mount: can't find /system in /proc/mounts
~ # mount /system
~ # mount
rootfs on / type rootfs (rw,seclabel)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1506976k,nr_inodes=172637,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime,size=1506976k,nr_inodes=172637)
pstore on /sys/fs/pstore type pstore (rw,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/mmcblk0p38 on /cache type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/dm-0 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/dm-0 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p41 on /system type ext4 (rw,seclabel,relatime,data=ordered)
I'm at a loss about what to do. I thought twrp was not decrypting properly, so i removed exchange and removed my pin code in case that was causing it. No change. Any help or advice would be appreciated. I really would like Pixel launcher and tethering
Specs:
Nexus 6 32gb
Android 7.0, Oct 5,2016
twrp-3.0.2-0-shamu.img
Phone is encrypted, no pin code to boot.
rooted with superuser-r266-hidesu, systemless with phh superuser gui

Bump. No one?

have you changed the option in twrp, to mount system? and the file recovery-from-boot i delete right away, after first boot, so its never an issue, ever.

Subscribed. I have the same problem since I flashed Nougat and so I cannot flash lights-shamu-so-cm13.zip. Well, it flashed, but not to the "right" /system partition...

@simms22 Read over my problem again. There were two seperate /system partitions. One mounted by twrp and one mounted by the actual system. So any changes made to the twrp system had no effect on the actual booted /system.
@dcoulombe I finally gave up... I installed this rom: [ROM][Stock+][NBD90Z]Prerooted-Debloated-Deoxeded-Busybox-Fast & Stable . I pulled the root stuff out of the zip before flashing as to not trip safetynet. With root taken out, it passes. And now i can mount /system as expected. Tethering works and pixel launcher installed. I can help with removing root if you need me to.
Phone is snappy now too.

extremx said:
@simms22 Read over my problem again. There were two seperate /system partitions. One mounted by twrp and one mounted by the actual system. So any changes made to the twrp system had no effect on the actual booted /system.
@dcoulombe I finally gave up... I installed this rom: [ROM][Stock+][NBD90Z]Prerooted-Debloated-Deoxeded-Busybox-Fast & Stable . I pulled the root stuff out of the zip before flashing as to not trip safetynet. With root taken out, it passes. And now i can mount /system as expected. Tethering works and pixel launcher installed. I can help with removing root if you need me to.
Phone is snappy now too.
Click to expand...
Click to collapse
Hi , I have exact same issue with my honor 8...
twrp /system is not the same as nougat /system
when nougat boot up I cannot remount Read write FS.
I believe dm0-5 are lvm and not physical partition but no proof.
if someone have a solution I would be very interested.
Thanks

I found this thread by google searching my phone's problem.
My phone is Honor 8 lite ( PRA series), with exactly the same problem,
bloatware deleted from cust partition at TWRP mode still show up when system boots.
I solved my problem by rooting according to :
https://forum.xda-developers.com/p8...-to-root-huawei-p8-lite-2017-android-t3582179
I guess (not sure) DM is the culprit, the rooting modifies boot image, and disabled dm-verity.

flash recovery partition from android system/userland

I'm having trouble with fastboot (see my thread here: https://forum.xda-developers.com/xperia-xz1-compact/help/issues-fastboot-t3971227, maybe you can help). However, I can seem to flash sony signed software in sony-service mode using newflasher. That's nice, but I haven't used stock android in years. I am very used to lineageos without gapps---nice and clean. So, for me, until I get rid of stock and get a clean flash of lineage, I'm really not happy.
Given my state of affairs, I'm wondering about flashing one of the exploitable sony stocks and to get root, then flashing the recovery partition with twrp from userland. Then, potentially, i could boot to that recovery and maybe (idk) flash a new system ROM. Does anyone have any tips or suggestions?

It should work as you outlined.
Still having BL unlocked and not usable fastboot seems like a major disadvantage to me.
Did you try with different PC to see if it is not due to usb chipset or something?
Preferably using usb 2.0 only chipset?
Maybe trying that from different OSes too - linux vs win?

Thanks for the reply. I got the exploitable firmware downloaded and flashed as well as your renosploit kit. Hasn't found a root shell yet although I'm hopeful it will eventually (I haven't read the details but I understand that the underlying vuln is a race condition).
One question: I suppose that given that tmp root status, it should be possible to copy a su binary over and make root permanent, that would make experimentation easier, I think. And if whatever I try fails the first time I wouldn't want to have to wait for the race condition exploit every time I wanted to reboot. Am I on the right track? If so, I suppose I need to either compile or download a su binary and possibly a supersu.apk in order to manage it. Are those already available for the xz1 compact?

@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.

j4nn said:
@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.
Click to expand...
Click to collapse
Got it. Thank you for this detail. So you think my best bet is to just use the root shell to `dd` the twrp image directly to some /dev? And then I would just `adb reboot recovery` and in theory I'm good to go.

Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.

apexofservice said:
Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.
Click to expand...
Click to collapse
1 - The TA partition contains significant amounts of other information as well. So it won't be empty.
The standard way of dealing with it is to not mess with it at all.
2 - The FOTAkernel is the recovery.
2a - The partition layout can be found from the stock firmware image in the "partition-image-LUNZ_X-FLASH-ALL-C93B.sin" file where "Z" is the LUN number. Once you extract the SIN file, you're left with an EFI partition header.
I've attached a CSV file that contains the layout as specified in the "partition-image-LUN0_X-FLASH-ALL-C93B.sin" file.
The layout for LUNs 1 and 2 both contain a single 4MB partition for "xbl" and "xblbak" respectively, so they're not as interesting.

@pbarrette, thanks! I tried the naive approach:
Code:
d if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel <
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.100 secs (14659779 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # reboot recovery
Alas, it just rebooted back to system. It did seem to take a bit longer, so it's possible that it tried to boot from FOTAKernel and failed then fell back to system. I've just got a new root shell so I can look in startup logs from dmesg to see if there's anything of interest.
Also, I'm probably missing something really obvious. Thanks for any insight!
Reading dmesg now, this seems quite relevant (I recall booting to recovery on my z3 compact by touching a file in /cache/recovery). I'll post it here but I'm still reading the dmesg.
Code:
[ 7.406109] bs_roots: recovery filesystem table
[ 7.406120] bs_roots: =========================
[ 7.406125] bs_roots: 0 /data ext4 /dev/block/bootdevice/by-name/userdata
[ 7.406130] bs_roots: 1 /oem ext4 /dev/block/bootdevice/by-name/oem
[ 7.406134] bs_roots: 2 /cache ext4 /dev/block/bootdevice/by-name/cache
[ 7.406139] bs_roots: 3 /rca ext4 /dev/block/bootdevice/by-name/appslog
[ 7.406143] bs_roots: 4 /idd ext4 /dev/block/bootdevice/by-name/diag
[ 7.406148] bs_roots: 5 /storage/sdcard1 vfat /devices/soc/c0a4900.sdhci/mmc_host*
[ 7.406153] bs_roots: 6 none swap /dev/block/zram0
[ 7.406157] bs_roots: 7 /persistent emmc /dev/block/bootdevice/by-name/frp
[ 7.406162] bs_roots: 8 /misc emmc /dev/block/bootdevice/by-name/misc
[ 7.406167] bs_roots: 9 /firmware vfat /dev/block/bootdevice/by-name/modem
[ 7.406172] bs_roots: 10 /bt_firmware vfat /dev/block/bootdevice/by-name/bluetooth
[ 7.406177] bs_roots: 11 /dsp ext4 /dev/block/bootdevice/by-name/dsp
[ 7.406182] bs_roots: 12 /persist ext4 /dev/block/bootdevice/by-name/persist
[ 7.406187] bs_roots: 13 /boot/modem_fs1 emmc /dev/block/bootdevice/by-name/modemst1
[ 7.406191] bs_roots: 14 /boot/modem_fs2 emmc /dev/block/bootdevice/by-name/modemst2
[ 7.406195] bs_roots: 15 auto auto /devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb*
[ 7.406199] bs_roots: 16 /qns ext4 /dev/block/bootdevice/by-name/Qnovo
[ 7.406203] bs_roots: 17 /tmp ramdisk ramdisk
[ 7.406206] bs_roots:
[ 7.408585] MR: Mounting /cache ourselves
[ 7.412318] EXT4-fs (sda53): recovery complete
[ 7.412666] EXT4-fs (sda53): mounted filesystem with ordered data mode. Opts:
[ 7.413213] MR: fopen() failed -/cache/recovery/command (No such file or directory)
[ 7.413219] MR: Unmounting /cache
[ 7.413959] MR: Fail to get command from /cache/recovery/command, trying /misc
[ 7.414272] MR: Unknown wipe command
[ 7.414280] MR: Buffer is empty from /dev/block/bootdevice/by-name/misc with command 0
[ 7.417568] MR: TA_MASTER_RESET value = 0
[ 7.418475] init: Service 'exec 3 (/sbin/mr)' (pid 605) exited with status 0 waiting took 0.022997 se
conds
[ 7.418513] init: starting service 'exec 4 (/sbin/ffu)'...
[ 7.418846] init: SVC_EXEC pid 609 (uid 0 gid 0+0 context u:r:recovery:s0) started; waiting...
[ 7.419833] init: Service 'exec 4 (/sbin/ffu)' (pid 609) exited with status 255 waiting took 0.001316
seconds
------
One more update, I did a sanity check that that dd command is actually overwriting FOTAkernel. It doesn't look like it's working:
Code:
G8441:/data/local/tmp # dd if=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted.img
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.812 secs (82646384 bytes/sec)
G8441:/data/local/tmp # chown shell:shell FOTAKernel-extracted.img
G8441:/data/local/tmp # dd if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.037 secs (15113174 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted-2.img <
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.846 secs (79324898 bytes/sec)
And there's no `diff` on the device, so I pulled the files back to a laptop then:
Code:
$ diff FOTAKernel-extracted-2.img FOTAKernel-extracted.img
$ diff FOTAKernel-extracted.img twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img
Binary files FOTAKernel-extracted.img and twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img differ

@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.

Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.

pbarrette said:
Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.
Click to expand...
Click to collapse
Hot damn. Thanks, I'm booted to twrp!
Note: i was using the older version for android 8 since I'm currently on the android 8 exploitable rom!

apexofservice said:
@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.
Click to expand...
Click to collapse
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?

j4nn said:
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?
Click to expand...
Click to collapse
I haven't yet. Well, I have sorta. When I first ran into issues, I tried it with a different laptop, got the same result. Now that laptop was also a thinkpad (although a newer model) and was also running debian linux. I don't have any computers with Windows. I was going to reboot this laptop with usb3.0 kernel mod blacklisted and only using hci but I didn't get around to it yet (especially once I got twrp flashed and working, then I mainly wanted to get started actually using the phone i bought ). However, if it were a usb thing, wouldn't we expect that newflasher would fail too? Still, it is very curious about the fastboot thing, however, so I'm willing to keep playing with it.

@apexofservice, I am not sure if blacklisting usb3 drivers would help. Sometime there may be present multiple usb ports, some connected to usb 3.0 host controller, others just usb 2.0 controller.
Even if newflasher works, it is not that simple, that fastboot should work too.
Fastboot (including it's usb support) is implemented in UEFI bootloader, the ABL component of it (Android Boot Loader).
So usb stack is implemented by UEFI fw.
While newflasher uses flash mode, which is running XFL - a linux (bare bone android) kernel, running the lilo/loader userspace application. So there is in my opinion quite good usb stack implemented by linux kernel.
So it can easily be some incompatibility within UEFI usb stack implementation used with fastboot.