Related
Right, I'm currently working on a project which involves imaging Android phones - specifically, the program I've written is mean to automate identifying the memory block containing the userdata and then using the following sequence of commands (using Android Debug Bridge) to copy it to the computer that the phone is connected to:
Code:
adb forward tcp:5555 tcp:5555
adb shell
busybox nc –l –p 5555 –e dd if=/dev/mtd/mtd[mtd block number] bs=4096
This is done in command prompt and then you have to manually open another command prompt and type in:
Code:
adb forward tcp:5555 tcp:5555
nc 127.0.0.1 5555 | dd of=[chosen file name].bin bs=4096 -- progress
This copies the memory block over without any problems when done manually and even shows you in real time how much data has been transferred.
The problem I have is with automating the process in C#. Specifically, I can get every stage of it to work through using a process to write the commands to standard input and using a tcp listening port to receive the data. Apart from this crucial element of the process:
Code:
adb shell "busybox nc –l –p 5555 –e dd if=/dev/mtd/mtd[mtd block number] bs=4096"
For some reason, no matter how I try to phrase it or do it, C# hates that command and won't execute it. I can manually type the exact same thing into the command prompt and it works fine but trying to do it in C# just leads to busybox acting as though I typed the command in incorrectly - this is what it gives me:
Code:
BusyBox v1.15.2 <2009-11-27 10:38:30 GMT> multi-call binary
Usage: nc [-in] [-wN] [-l] [-p Port] [-f FILENAME|PADDR PORT] [-e PROG]
Open a pipe to IP:port or file
Options:
-e PROG Run prog after connect
-i SEC Delay interval for lines sent
-w SEC Timeout for connect
-f FILE Use file <ala /dev/ttyS0> instead of network
-l Listen mode, for inbound connects
<use -l twice with -e for persistent server>
-p PORT Local port
The problem appears to be particularly with the use of bs=[bytes] but I've no idea why - and I've spent several hours searching all over the web for solutions.
So basically, I was wondering whether anyone else might have encountered this issue before and if anyone has any ideas to get around it? At the moment I'm using a script to send the commands to the command prompt but that's a kludge that I'd really prefer not to have to use.
Thanks in advance for any suggestions or comments and apologies if I've posted this in the wrong place.
Probably has to do with syntax.
In the first instance you don't have it in quotes.
Code:
busybox nc –l –p 5555 –e dd if=/dev/mtd/mtd[mtd block number] bs=4096
Then you do have quotes the second time.
Code:
adb shell "busybox nc –l –p 5555 –e dd if=/dev/mtd/mtd[mtd block number] bs=4096"
Sometimes, using a newer busybox helps too... 1.15.2 is kinda old
The first time is meant to show that it's being done on two different lines though I probably should have made that clearer.
Thanks for the suggestion - I just upgraded to the latest version of busybox and also altered my code so it would open cmd.exe and then run adb.exe rather than skipping straight to running adb.exe. This seems to have fixed the problem some of the time so there's probably a timing issue as well.
So I don't know whether it was the busybox version or the adb.exe/cmd.exe thing but, either way, the problem seems to have disappeared so I'm not going to change anything else in case I break it again.
Thanks very much for your help
Yep I find that there is always 2 or 3 ways to do something and usually only 1 way works all the time (lowest common denominator etc...)
@Antonine May I ask you what's the project you're talking about? I'm interested...
I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.
Hello XDA-Devs,
I have to admit that I am not an Android or other smartphone OS developer but merely a dimwitted device user who struggles to get data off and onto his Android device.
First I thought that one could simply plug the device into one of my laptop's USB ports and mount it like any mass storage device.
But I had to learn that this simple mode has disappeared in Android versions higher than 2.X.
After several rather dissatisfying other attempts to transfer data, like e.g. via an OpenSSH server app on my (not yet rooted device), I finally came across a seemingly more appealing solution via the ADB USB mode, where the necessary steps were described in blog's posting whose link I not yet allowed to place here (i.e. <10 posts).
After a bit of fiddling I managed to get my device connected via USB and the ADB daemon.
Now I am still struggling how to efficiently get a bulk of e..g camera images from my device.
So far adb pull seems to be the appropriate command.
But somehow I can only download/pull single image files, and my loop isn't working.
Sadly the pull command doesn't have a bulk match option like an ftp client's mget.housand
Also I can't work out if shell globbing works the same as in an e.g. Bash.
See, while I can fetch a list of files, the loop expansion doesn't work, for what reason ever, and I would have to pull every file separately.
That looks strange. Maybe I only fell prey to some shell glob syntax issue here?
So bear with me.
Code:
[[email protected]:~/Pictures]
$ for f in $(adb shell ls /storage/sdcard0/DCIM/Camera/);do echo adb pull "/storage/sdcard0/DCIM/Camera/$f";done|tail
adb pull /storage/sdcard0/DCIM/Camera/20131111_192956.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193008.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193018.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193028.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193036.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193048.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131111_193114_1.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131113_005357.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131113_005418.jpg
adb pull /storage/sdcard0/DCIM/Camera/20131113_005526.jpg
But when I remove the echo
Code:
[[email protected]:~/Pictures]
$ for f in $(adb shell ls /storage/sdcard0/DCIM/Camera/);do adb pull "/storage/sdcard0/DCIM/Camera/$f";done 2>&1|tail
' does not existstorage/sdcard0/DCIM/Camera/20131111_192956.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193008.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193018.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193028.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193036.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193048.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131111_193114_1.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131113_005357.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131113_005418.jpg
' does not existstorage/sdcard0/DCIM/Camera/20131113_005526.jpg
But on a single file invocation I can pull it.
Code:
[[email protected]:~/Pictures]
$ adb pull -p /storage/sdcard0/DCIM/Camera/20131113_005526.jpg
Transferring: 569030/569030 (100%)
1966 KB/s (569030 bytes in 0.282s)
[[email protected]:~/Pictures]
$ identify 20131113_005526.jpg
20131113_005526.jpg JPEG 1920x1080 1920x1080+0+0 8-bit DirectClass 556kb
Strange.
I am convinced that there must be a more efficient way to bulk pull files from my device.
Is there a way to mount my device via ADB?
Having read the help screen of the adb command I only found a remount sub command which would remount the device's system FS as it seems.
Would I have to tinker with the udev rule to have my device mounted when plugged in?
[[email protected]:~/Pictures]
$ adb help 2>&1|grep mount
adb remount - remounts the /system partition on the device read-write
[[email protected]:~/Pictures]
$ lsusb|grep -i samsung
Bus 002 Device 006: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II], GT-I9300 Phone [Galaxy S III], GT-P7500 [Galaxy Tab 10.1]
[[email protected]:~/Pictures]
$ cat /etc/udev/rules.d/*android.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0666", GROUP="adbandy"
[[email protected]:~/Pictures]
$ groups
fiddle wheel adbandy
[[email protected]:~/Pictures]
$ adb devices -l
List of devices attached
3b086527 device usb:2-1 product:jfltexx model:GT_I9505 device:jflte
Click to expand...
Click to collapse
My Android phones and tablets auto-mount as removable drives when I connect them to my Linux (Mint 17 Cinnamon) computers. Connection to PC is set on the devices as MTP.
I guess these MTP automounts use a FUSE driver?
Being on a RHEL 6.4 binary compatible distro (i.e. SL) I could only find libmtp pre-built RPMs.
But I suspect that the libs alone wouldn't suffice.
If I knew what parts are required to make a working MTP mount I could get all sources and patches, tinker up an RPM spec file and build my own RPM, I suppose.
Thanks for the hint.
Hi, I've recently acquired a Trekstor Surftab breeze 10.1 quad and my first (admittedly inexperienced) attempts at rooting it have failed miserably.
The tablet is a 10.1 inch 8GB device with a Mediatek MT8127 running Android 4.4.2 (Kernel 3.4.67 [email protected] #1). I tried first with Towelroot (including the various advanced modes), which did nothing, not even the temporary root option. Kingo Root and iRoot (former vRoot) are able to connect to the tablet in debug mode, but after trying several scripts and rebooting the device a few times they ultimately failed.
I'd rather not change the recovery without a having a backup, but I tried MTK Tools to at least get some useful information. I couldn't get a scatter file because the button was greyed out (I don't think the program is fully compatible with the MT8127), but the partitioning info was slightly different from other MT8127-based devices (I checked the Cube U27GT MT8127 tablet). Getting a scatter file from an existing ROM (or just modifying a ROM to add the su binary) seems to be out of the question, because I couldn't find one on the Trekstor site and a quick Google search gave me nothing. I also tried to get temporary root but it failed with a suggestion to install CWM recovery.
Also, just in case I was being an idiot and the tablet came with the su binary already installed (other Trekstor devices do), I tried installing SuperSU directly, but I had no such luck.
If I find anything else I'll post it here, but for the time being I've run out of ideas. Any suggestions?
I've finally cracked it and been able to put together some notes. They are intended for the Surftab Quad 10.1, but they might be useful with some modifications for other devices based on a Mediatek SOC that can't be rooted using the usual tools (or if you don't trust the usual tools). I've tried to attach the programs I've used, but I've been having a lot of trouble because some files are too large. You can get everything from these Mega links instead:
ext4_utils_new_cygwin_fixed.tar.gz: https://mega.co.nz/#!YIkhFTRJ!uemCzV5fTlXoyK61Vr3Ib-sPXYlzmrffYG7YwUxXaU0
MT6577 USB VCOM drivers.rar: https://mega.co.nz/#!dcNx2QBC!eHyKtnwbVc2Gj5hCUQXQIlQsv9G3dGXWvPEvrB15mNw
MT8127_Android_scatter_surftab_quad_101.txt: https://mega.co.nz/#!Yd0nnRoL!s5ztQIwwZLa3i89zVU9vFJL0xZXg5LKqIDSkRAdj45k
MtkDroidTools v2.5.3.zip: https://mega.co.nz/#!0FVxjILC!0-FOlPfT_OIRETYj_MsJofmse7zBeRMsSumJLicj5sM
spflash_5.14.16.zip: https://mega.co.nz/#!hcE0HKBJ!mkcdVjXBOUs7W1GhTF_qssgO14GNGs7kSWaOE9FJx2o
UPDATE-SuperSU-v2.45.zip: https://mega.co.nz/#!BUMzRaaR!R7_kGU7UN3SchcaEDCxKW7Oehfoi0PDsD-OeX9gJh0M
1) Make (or in this case check) the scatter file with MTK Droid Tools.
a) Turn on the device.
b) Enable USB debug.
c) Connect it to the PC.
d) Open MTK Droid Tools.
e) Check that the device information is correct, view block map, compare with scatter file and modify if needed.Alternatively, you can use the ADB terminal (it can be opened from MTK Droid Tools) and use the command “adb pull /proc/dumchar_info”. The resulting text file should contain the same information.
2) Install the VCOM drivers (I provide the Win7 version)
http://forum.xda-developers.com/showthread.php?t=2206421
http://forum.xda-developers.com/general/rooting-roms/guide-mediatek-spflashtool-failure-t2936933
The gist of it is, use USBDeview to remove any old VCOM drivers, install, reboot and plug in the switched off tablet. A new COM port-type device should flash for an instant in the device admin. Some guides recommend to change the preloader driver for DA, but in this case I found it not to be necessary. That said, the connection is a bit finicky and the USB cable that comes with the device and the port in the device itself seem to be pretty crappy, so in later steps it gave repeated COM errors unless I kept pressing on the micro USB connector or used a different cable altogether (the one belonging to my Kindle, to be precise). After a bit of trial and error, I also had a bit of trouble if the COM port assigned to the device was above port 9. That can be set in the device properties dialog, under the “Port configuration” tab and in “Advanced options”.
USBDeview might be necessary.
http://www.nirsoft.net/utils/usb_devices_view.html
3) Extract the system image (and make a full backup, just in case) with SP Flash Tools.
a) With the device unplugged and turned off, start SP Flash Tool.
b) Load the scatter file.
c) Under the Readback tab, click on “Add” and double click on the new field. I recommend to back up the entire device first, so name the file “full_dump.img” or somesuch and save from 0x00000000 to 0x4db00000, which would be everything but the user data and BMTPOOL. Then we add a second dump, named “system.img” starting on 0x5d00000 and with size 0x40000000. Those values come from the scatter file. They shouldn’t change if the device is the same, but if they do modify them as fit.
c) With the device turned off, plug the micro-usb side of the cable first (it’s more convenient that way), click “read back” and insert the cable into the pc. As mentioned before, the process can fail for many reasons. Sometimes unplugging the device, pressing briefly the tablet’s reset button and trying again helps.
4) Now prepare to continue working on Linux, a virtual machine like VirtualBox running Ubuntu should be enough. A bit over 2GB of free space will be needed.
a) Create a work directory, copy the system.img, ext4 utils and SuperSU files into it and open a terminal there.
b) If they aren't installed already, install compression and compilation tools (I might have been left out a few packages, I didn't have a clean setup to test it; if something isn't installed by default, finding the package shouldn't be hard). Assuming you are using Ubuntu:
Code:
sudo apt-get install unzip build-essential
c) Extract everything and compile the ext4 utils.
Code:
tar -xf ext4_utils_new_cygwin_fixed.tar.gz
unzip -d supersu UPDATE-SuperSU-v2.45.zip
cd ext4_utils_new; make; cd ..
d) Mount the original system image and copy everything it contains to a new directory.
Code:
mkdir system_old system_root
sudo mount -t ext4 -o loop system.img ./system_old
sudo cp -a system_old/* system_root
4) Install the SuperSU binaries and app.
The package I've included is intended to be installed automatically by the recovery menu, but we are going to do it manually by following the steps described in the setup script (supersu/META-INF/com/google/android/update-binary):
Code:
# API source target chmod chcon required
#
# 7-19 common/Superuser.apk /system/app/Superuser.apk 0644 u:object_r:system_file:s0 gui
# 20+ common/Superuser.apk /system/app/SuperSU/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 17+ common/install-recovery.sh /system/etc/install-recovery.sh 0755 *1 required
# 17+ /system/bin/install-recovery.sh (symlink to /system/etc/...) required
# *1: same as /system/bin/toolbox: u:object_r:system_file:s0 if API < 20, u:object_r:toolbox_exec:s0 if API >= 20
#
# 7+ ARCH/su /system/xbin/su *2 u:object_r:system_file:s0 required
# 7+ /system/bin/.ext/.su *2 u:object_r:system_file:s0 gui
# 17+ /system/xbin/daemonsu 0755 u:object_r:system_file:s0 required
# 17+ /system/xbin/sugote 0755 u:object_r:zygote_exec:s0 required
# *2: 06755 if API < 18, 0755 if API >= 18
#
# 19+ ARCH/supolicy /system/xbin/supolicy 0755 u:object_r:system_file:s0 required
# 19+ ARCH/libsupol.so /system/lib(64)/libsupol.so 0644 u:object_r:system_file:s0 required
#
# 17+ /system/bin/sh or mksh *3 /system/xbin/sugote-mksh 0755 u:object_r:system_file:s0 required
# *3: which one (or both) are available depends on API
#
# 21+ /system/bin/app_process32 *4 /system/bin/app_process32_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_process64 *4 /system/bin/app_process64_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_processXX *4 /system/bin/app_process_init 0755 u:object_r:system_file:s0 required
# 21+ /system/bin/app_process (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process32 (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process64 (symlink to /system/xbin/daemonsu) required
# *4: Only do this for the relevant bits. On a 64 bits system, leave the 32 bits files alone, or dynamic linker errors
# will prevent the system from fully working in subtle ways. The bits of the su binary must also match!
#
# 17+ common/99SuperSUDaemon *5 /system/etc/init.d/99SuperSUDaemon 0755 u:object_r:system_file:s0 optional
# *5: only place this file if /system/etc/init.d is present
#
# 17+ 'echo 1 >' or 'touch' *6 /system/etc/.installed_su_daemon 0644 u:object_r:system_file:s0 optional
# *6: the file just needs to exist or some recoveries will nag you. Even with it there, it may still happen.
#
# It may seem some files are installed multiple times needlessly, but
# it only seems that way. Installing files differently or symlinking
# instead of copying (unless specified) will lead to issues eventually.
#
# The following su binary versions are included in the full package. Each
# should be installed only if the system has the same or newer API level
# as listed. The script may fall back to a different binary on older API
# levels. supolicy are all ndk/pie/19+ for 32 bit, ndk/pie/20+ for 64 bit.
#
# binary ARCH/path build type API
#
# arm-v5te arm aosp static 7+
# x86 x86 aosp static 7+
#
# arm-v7a armv7 ndk pie 17+
# mips mips ndk pie 17+
#
# arm64-v8a arm64 ndk pie 20+
# mips64 mips64 ndk pie 20+
# x86_64 x64 ndk pie 20+
#
# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# or app_process) from u:r:init:s0 or u:r:kernel:s0 contexts. Depending
# on the current policies, it can also deal with u:r:init_shell:s0 and
# u:r:toolbox:s0 contexts. Any other context will lead to issues eventually.
#
# After installation, run '/system/xbin/su --install', which may need to
# perform some additional installation steps. Ideally, at one point,
# a lot of this script will be moved there.
#
# The included chattr(.pie) binaries are used to remove ext2's immutable
# flag on some files. This flag is no longer set by SuperSU's OTA
# survival since API level 18, so there is no need for the 64 bit versions.
# Note that chattr does not need to be installed to the system, it's just
# used by this script, and not supported by the busybox used in older
# recoveries.
#
# Non-static binaries are supported to be PIE (Position Independent
# Executable) from API level 16, and required from API level 20 (which will
# refuse to execute non-static non-PIE).
#
# The script performs serveral actions in various ways, sometimes
# multiple times, due to different recoveries and firmwares behaving
# differently, and it thus being required for the correct result.
What the script is supposed to do depends on the API version, which can be identified by doing:
Code:
cat system_root/build.prop | grep "ro.build.version.sdk="
We should have API version 19, but at one point the instructions are misleading. When adjusting the security context of install-recovery.sh it states that it should match that of toolbox, which is correct, but next gives values for different API versions which do not match our case. We shouldn't trust them and use
Code:
ls -Z system_root/bin/toolbox
to obtain the right value, in our case ubject_r:toolbox_exec:s0 (as in API version higher than 20).
Next I give all the commands, so assuming the directory names are the same I used they can just be copied and pasted into the terminal:
Code:
sudo cp supersu/common/Superuser.apk system_root/app/
sudo chmod 0664 system_root/app/Superuser.apk
sudo chcon u:object_r:system_file:s0 system_root/app/SuperSU/SuperSU.apk
sudo cp supersu/common/install-recovery.sh system_root/etc/
sudo chmod 0755 system_root/etc/install-recovery.sh
#we have to copy the chcon of system_root/bin/toolbox: ls -Z system_root/bin/toolbox, the original script is misleading or our android setup isn't standard.
sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
sudo ln -s /system/etc/install-recovery.sh system_root/bin/install-recovery.sh
sudo cp supersu/armv7/su system_root/xbin/
sudo mkdir system_root/bin/.ext
sudo cp supersu/armv7/su system_root/bin/.ext/.su
sudo chmod 0755 system_root/xbin/su system_root/bin/.ext/.su
sudo chcon u:object_r:system_file:s0 system_root/xbin/su system_root/bin/.ext/.su
sudo cp supersu/armv7/su system_root/xbin/daemonsu
sudo cp supersu/armv7/su system_root/xbin/sugote
sudo chmod 0755 system_root/xbin/daemonsu system_root/xbin/sugote
sudo chcon u:object_r:system_file:s0 system_root/xbin/daemonsu
sudo chcon u:object_r:zygote_exec:s0 system_root/xbin/sugote
sudo cp supersu/armv7/supolicy system_root/xbin/
sudo cp supersu/armv7/libsupol.so system_root/lib/
sudo chmod 755 system_root/xbin/supolicy
sudo chmod 0755 system_root/xbin/supolicy
sudo chmod 0644 system_root/lib/libsupol.so
sudo chcon u:object_r:system_file:s0 system_root/xbin/supolicy
sudo chcon u:object_r:system_file:s0 system_root/lib/libsupol.so
sudo cp system_root/bin/mksh system_root/xbin/sugote-mksh
sudo chmod 0755 system_root/xbin/sugote-mksh
sudo chcon u:object_r:system_file:s0 system_root/xbin/sugote-mksh
6) Generate a new image file with make_ext4fs.
Code:
./ext4_utils_new/make_ext4fs -a system -l 1G system_root.img system_root/
We can now mount it and verify that the files are in place and with the right permissions.
Code:
mkdir system_test
sudo mount -t ext4 -o loop system_root.img ./system_test
ls -la system_test/app/SuperSU.apk
ls -Z system_test/app/SuperSU.apk
ls -la system_test/xbin/su
ls -Z system_test/xbin/su
And finally unmount everything
Code:
sudo umount system_root
sudo umount system_test
7) Return to Windows and flash our rooted system image.
a) Open the flash tool, checking that we have loaded the right scatter file.
b) Select “download only” in the drop-down menu, make sure only “ANDROID” is checked in the list and, double-clicking that entry, pick the system_rooted.img file we have just created.
c) Just as when we extracted the image, we press “Download” and plug in the USB cable with the device turned off. Note: If you have been using a virtual machine, at some point mounted the rooted image to check that all the files were in place and forgot to unmount it, the file will be locked and the flash tool can spit out an error message. It took me a few tries to notice and shut down the VM completely. Don’t be me.
8) After it has finished flashing, unplug the device and boot it again. The first time it boots it should show a boot message saying that it’s updating one app, and once it’s finished we should have a working rooted tablet.
Same here with the trekstor surftab breeze 7.0 quad (ST70408-2).
I have tried everything with no results...
did you try rootgenius? (shuame.com/en/root/)
Y es. I have tried with no results.
Sent from my XT1032 using xda premium
I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.
I would really appreciate if you could find the time to add a description.
I have a Surftab Breeze 7.0 quad and I am struggeling with backing it up and rooting it.
Looking forward to reading your notes.
sdfsdfgdhshxzv said:
I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.
Click to expand...
Click to collapse
can u attach your scatterfile plz?
mr9to5 said:
can u attach your scatterfile plz?
Click to expand...
Click to collapse
Sure. This is for my MT8127-based Trekstor Surftab Quad 10.1.
Sorry about the rest of my notes, I've just changed jobs and I'm having a few horribly busy weeks so I've had no time to make them presentable. But once you have the utilities to mount the image on linux, it's just a matter of extracting the supersu archive and looking into the setup script to see where every file goes, where to create links and which permissions to set for the right Android version.
I've finally added my step by step notes to the first post. I hope someone finds them useful.
sdfsdfgdhshxzv said:
I've finally added my step by step notes to the first post. I hope someone finds them useful.
Click to expand...
Click to collapse
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?
mr9to5 said:
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?
Click to expand...
Click to collapse
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox
sdfsdfgdhshxzv said:
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox
Click to expand...
Click to collapse
it works, but this errormessages are from selinux, the copied files have no content so we can´t change this.
Sucefull startet CWM recovery
not perfect but runs, incl adb root shell in recovery mode.
la solución al root de esta tablet esta aquí w w w . m g y u n . c o m /
100% efectiva.
---------- Post added at 12:47 PM ---------- Previous post was at 12:11 PM ----------
¿algun propietario de la surftab brisa 10.1 quad, me podría enviar las apk de bluetooth ?
es que manipulando un explorador root he borrado por equivocación estos archivos y no me funciona el bluetooth de la tablet.
gracias.
Hacking android, got "system" user, but not root, how to escalate privilege?
Hello, i am new to XDA. I am trying to jail-break my android device:
Android 5.1.1, Linux 3.10.49
This device is a rare brand and have no any unlock & flash mechanism.
Currently i have successfully got "system" user (UID 1000) by using a preinstalled DEBUGGABLE system app.
This user can only change /data directory etc, it can not change any file owned by root.
So any help to escalate "system" user to root user will be very appreciate.
the result of command "id":
Code:
uid=1000(system)
gid=1000(system)
groups=1000(system)
1007(log)
1010(wifi)
1015(sdcard_rw)
1021(gps)
1023(media_rw)
1028(sdcard_r)
3001(net_bt_admin)
3002(net_bt)
3003(inet)
3004(net_raw)
3005(net_admin)
3006(net_bw_stats)
3009(qcom_diag)
9997(everybody)
41000(u0_a31000)
context=u:r:system_app:s0
This account can change /data/system/packages.xml etc, but can not change /system/*, nor chown/mount.....
It's CapBound is 0, too strict. And also can not disable SELinux.
Can anyone help me?
----------------------- PS: share how i get system user privilege, maybe helpful to others -----------------------
In a word, just use jdb to attache to the app then print new java.lang.Runtime().exec("sh /sdcard/my.sh").
First, i found a package appeared in Android Device Monitor's debuggable app list, e.x. com.example.app.
Then i use
Code:
pm dump com.example.app
got confirmed it use system UID, then
Code:
run-as com.example.app
but failed due to "Package not found", i don't know why.
Then i try to use JDWP way.
Get the debuggable process ID:
Code:
$ adb jdwp
9424
$ adb forward tcp:8600 jdwp:9424
$ jdb -attach localhost:8600
> threads
group system:
(java.lang.Thread)0x2a86 Signal Catcher ...
(java.lang.Thread)0x2a87 FinalizerWatchdogDaemon ...
...
group main:
(java.lang.Thread)0x2a8d main ...
(java.lang.Thread)0x2a8e Binder_1 ...
...
> thread 0x2a8d
main[1] stepi
>
stepi completed: "thread=main", android.os.MessageQueue.next()、row=145 bci=22
main[1] > print new java.lang.Runtime().exec("sh /sdcard/qj.sh")
There are some files need be upload(adb push .... ) before run the last command.
/sdcard/qj.sh:
Code:
date > /sdcard/log
cp -f /sdcard/busybox /data/ 2>> /sdcard/log || exit 1
chmod 4777 /data/busybox 2>> /sdcard/log || exit 1
(while true; do /data/busybox nc -l -p 7777 -e sh; done) >> /sdcard/log 2>&1 &
echo server OK >> /sdcard/log
/sdcard/busybox:
this file can be found at busybox.net/downloads/binaries/latest, choose ARM7v.
The above jdb command "print new java.lang.Runtime().exec("sh /sdcard/qj.sh")" will create a shell server listening at 7777 port, bridge input/output to sh.
So, to connect to the shell server,
Code:
adb forward tcp:7777 tcp:7777
nc localhost 7777
then in this connection, input shell command.
Sorry: i forgot a very important step: to run the "print new ...." statement, i have to turn on screen, even touch the app so can be trapped into jdb.
---------That's all------------