Related
THIS IS FOR TESTING ONLY. DO NOT ATTEMPT TO INSTALL THIS IF YOU DON'T KNOW HOW TO GET INTO BOOTLOADER MODE AND FLASH A ROM FROM THE SD CARD.
Announcements
We are currently replacing Tinboot with LK for boot. This will give us fastboot and many other enhancements and fixes to make our device more like a native Android device. This has already fixed some issues with GSM phones, sleep modes, and a few other things. The current issue being worked on is the power button not working (possible GPIO issue).
Introduction
This thread tracks the most recent NAND development. A huge thanks to [ACL] and WoZZeR999 for dedicating time to NAND development for us, and again, thanks to Jonpry, PHH, stinebd, and the rest of #htc-linux for their contributions. It's truly amazing what these guys have done for us, so be sure to show them your appreciation :wink:
The original NAND boot testing thread can be found here:
http://forum.ppcgeeks.com/tp2-andro...und-test-7-single-nbh-serialno-tilt2-fix.html
File Repository
Autobuild files can be found here: Index of /files/
The LK directory will contain the latest LK Bootloader and boot image code.
The rhodium_nand directory contains the latest kernels
The XDAndroid directory contains the latest OS files and updates (including the root update)
Note: We often disable autobuild when extremely experimental code is submitted, so this may not always be up to date but should be more stable than content we post in the threads.
Latest Files
LK Bootloader: http://htcdevs.wirelesstcp.net/files/LK/RHODIMG_NORECOVERY.NBH
Recovery Image: http://htcdevs.wirelesstcp.net/files/LK/recovery.img
05-22 Kernel: http://htcdevs.wirelesstcp.net/files/rhodium_nand/20110522_175721-kernel-update.zip
FRX06 OS Files: http://htcdevs.wirelesstcp.net/files/xdandroid/FRX6/update.zip
Optional - FRX06 Root: http://htcdevs.wirelesstcp.net/files/xdandroid/opt_updates/Root-Update.zip
Installation Procedure
Obtain Install Files
You need 4 files to get NAND up and running:
LK Bootloader NBH
Recovery.img
Kernel
OS Files
Install Directions
1) Set up your computer to use fastboot: http://forum.xda-developers.com/showthread.php?t=532719
2) Flash your phone with the LK Bootloader NBH
3) Copy recovery.img to your fastboot/adb folder
4) Open bash/command prompt and run fastboot flash recovery recovery.img
5) If successful, type fastboot reboot, and hold the Power Button as your phone boots
6) Your phone should boot into recovery, and there you can apply the various update.zip files in this order:
- FRX06 Update.zip
- Kernel-Update.zip
- Root-Update.zip
To navigate in recovery, use volume up/down (or up/down on keyboard) to change selection, then use End Call key (or Enter on keyboard) to make a selection.
Here's a video from ACL
http://www.youtube.com/watch?v=4r4o2CCKwvU
Work in Progress
Panel init/power down
No data on first boot
Youtube app has issues
GSM can boot with no rild arguments (no data)
Not Working at all
Camera
No bluetooth
No 3.5mm headphone jack
Frequently Asked Questions
What is NAND booting?
NAND booting uses code on the NAND to boot directly into Android without having Windows Mobile on the device. Currently, zImage and initrd.gz are stored on the internal NAND while the modules, rootfs, ext2, and data are stored on the SD card.
How do I setup NAND boot?
First, you need to download the Update Utility (CustomRUU) and the latest package. Extract the NBH to the same folder as the Update Utility and flash like you would a custom ROM. Put the included modules on the SD card (modules must be from the same package as the NBH) along with the modified rootfs.img (see first post) and system.ext2 from http://xdandroid.com/wiki/Main_Page (you can use system.ext2 from BLAZN, but XDAndroid will be better for testing)
Why don't my changes to Startup.txt work/How do I change boot options?
Because we are booting without Haret, Startup.txt is not used. Any changes to Startup.txt will have no effect. If there is a boot option you need enabled, you can either compile a new tinboot with those changes or let me know and I can compile one for you.
Where are the Android files stored and how do I update them?
Modules, rootfs.img, and system.ext2 must be stored under /andboot on the SD card. Every update will require flashing a new NBH (contains zImage) and replace the old modules file with the new one. Sometimes deleting the data.img file is necessary between builds if you experience major problems.
Wifi or other devices aren't working after an update...
The modules and zImage are a pair and must always be updated together. If you only flash the NBH but don't replace the modules file on the SD card, you will get a mismatch on the modules preventing the drivers from loading.
My battery drained and now my phone is stuck in a boot cycle! AHHHHHH!
Don't worry about it. You have two quick and easy options. First, unplug the USB cable, then remove the battery, then put the battery back in, and plug the USB cable back in. Now let it charge for 5 minutes, then turn it on, and you should be good to go. If it still does not work, unplug the USB cable, then remove the battery, then put the battery back in, attempt to enter bootloader mode and plug the USB cable back in as soon as the bootloader screen comes up. Now you can charge it for 5 minutes and restart back into Android (where you should continue charging).
Project Status
What is currently being worked on?
Battery life (up to about 9 hours now)
Backlight control (Dimming works and backlight can be turned off, but re-initializing is causing issues)
What is working?
Phone
Data
Sound
GPS
Keyboard
Wifi
Hardware 3d
What is NOT working?
Camera
Bluetooth
3.5mm headphone jack
Heh, only a matter of time before this thread made it over onto XDA. Thanks Nate
testing
has anybody here tested yet and if so... please note the outcome of the testing i would like to test but i would need more elaborate install instructions so that it is done right the first time ...also a couple of links are not working
ksper6986 said:
has anybody here tested yet and if so... please note the outcome of the testing i would like to test but i would need more elaborate install instructions so that it is done right the first time ...also a couple of links are not working
Click to expand...
Click to collapse
Thanks for the heads up. The copy/paste from PPCG killed some of the links. They should be working now
And this does work great. You can find the thread over at PPCGeeks here: http://forum.ppcgeeks.com/tp2-andro...esting-12-11-panel-power-off-now-working.html
First of all i want to thank all devs who are involved in the NAND Booting Section. I think i will test this in the next days but i must ask some questions first to do it .
1. So, do i need to do the Task 29 or is it just in case of problems.
2. Am i able to flash WinMob back if i'm failing?
yes u can go back to windows. infortunately i have been following all the steps correctly and it loads up the with letters showing its working and then i get a black screen so i think im stuck at boot any help. can someone tell me what im doing wrong. the files are in sd card/ andboot
Bieka said:
First of all i want to thank all devs who are involved in the NAND Booting Section. I think i will test this in the next days but i must ask some questions first to do it .
1. So, do i need to do the Task 29 or is it just in case of problems.
2. Am i able to flash WinMob back if i'm failing?
Click to expand...
Click to collapse
Task29 is just recommended to make sure everything is nice and clean. It makes troubleshooting much easier because it ensures nothing weird is being read from the internal nand.
You can easily flash back to WinMo by starting the phone in bootloader mode and flashing. Unfortunately, you will not be able to do the ActiveSync connection through USB and flash that way.
kabu said:
yes u can go back to windows. infortunately i have been following all the steps correctly and it loads up the with letters showing its working and then i get a black screen so i think im stuck at boot any help. can someone tell me what im doing wrong. the files are in sd card/ andboot
Click to expand...
Click to collapse
You should have three files in /sdcard/andboot: rootfs.img, system.ext2, and modules (don't rename the modules). Now flash the NBH and it should generate the data.img, and you should be good to go. It should be loaded in under 10 minutes, so if it isn't, I would check the contents of the memory card. Also note the card must be FAT32 formatted and have not be partitioned.
The panel power on/down is apparently fixed for some panels but not others. ACL and bzo have been working together on this and found that there are several different panels being used in our phones, and ACL is working on a patch to fix up the panels that aren't functioning perfectly.
mcnutty said:
RootFS
A custom rootfs.img is required to automatically configure the keyboard. You can override the automatic keyboard by creating a .kb file in your andboot folder. Accepted inputs are: rhod500.kb, rhod400.kb, rhod210.kb, and tilt2.kb
Click to expand...
Click to collapse
What about the rhod100? I have a modified rootfs.img for correct german keylayout in haret version of xdandroid. Can i use that too or do i need to delete all other .kb's? And is it even possible to get a working rhod100 keyboard? I know many questions but i think this should be BEFORE i get lost .
Bieka said:
What about the rhod100? I have a modified rootfs.img for correct german keylayout in haret version of xdandroid. Can i use that too or do i need to delete all other .kb's? And is it even possible to get a working rhod100 keyboard? I know many questions but i think this should be BEFORE i get lost .
Click to expand...
Click to collapse
Ahh yess the custom keyboard and how to create it. This threw me for a bit too and when i realized that all I had to do was open up notepad and then do a saveas rhod400.kb, I laughed at myself.
yep that easy a blank text file with the correct name and you are good to go
Well now that the thread is over on xda I tried again but still to no avail even tried two different SD cards both end with it booting but freezing at SMD: ch 0 OPENING -> OPENED. Pretty sure I have everything setup correctly three files in andboot folder on sdcard renamed rootfs to just rootfs.img but left the other two files. By the way this is on a tilt2.
Thordim said:
Ahh yess the custom keyboard and how to create it. This threw me for a bit too and when i realized that all I had to do was open up notepad and then do a saveas rhod400.kb, I laughed at myself.
yep that easy a blank text file with the correct name and you are good to go
Click to expand...
Click to collapse
Does that mean i just had to rename my rhod100_de.kb file to a rhod400 or something? That would be TO Easy ... ok i always think around corners ))
Bieka said:
Does that mean i just had to rename my rhod100_de.kb file to a rhod400 or something? That would be TO Easy ... ok i always think around corners ))
Click to expand...
Click to collapse
Actually, I didn't account for the non-US variants when creating the rootfs. I have some other modifications that I'm testing for the rootfs at the moment, so I will be sure to add the other variants back in for at least the KB overrides. I will need help with a variable for the automatic detection to work properly.
If anyone has any of the non-US variants, it would be extremely helpful for you to flash to NAND, hook up to ADB, and run "cat /sys/class/htc_hw/machine_variant" and let me know what yours is.
wifi
i want to start off by saying this is an amazing project.
But my problem is that wifi is not working for me. When i try to start wifi, it immediately says "error." I have done many flashes and used task29. i was just wondering if anyone else had this issue.
mcnutty said:
Actually, I didn't account for the non-US variants when creating the rootfs. I have some other modifications that I'm testing for the rootfs at the moment, so I will be sure to add the other variants back in for at least the KB overrides. I will need help with a variable for the automatic detection to work properly.
If anyone has any of the non-US variants, it would be extremely helpful for you to flash to NAND, hook up to ADB, and run "cat /sys/class/htc_hw/machine_variant" and let me know what yours is.
Click to expand...
Click to collapse
I will do that for you in the next days. Before Christmas it's a turbulent time for me. As soon as i can get the Time for it i will flash to nand and follow your instructions. If i need help, can i PM you?
Cheers
I'm using Neopeek's rom instead..how can i set it up? since this rom doesnt use the system.ext2 file
getting calibration without visible points to touch aka the boxes. also, boot ani glitches out on screen with a "solid" animation, and video glitchs on the bottom half of the screen. sits here indefinately.... still waiting..... haha
update: loads to lockscreen, so far can't get screen to stay on??? strange
update2: got it working, but keeps turning screen off immediately... any ideas>?
hmm, i have been trying this and i feel like i have everything right
tilt2.kb, rootfs.img, modules, and system.ext in an andboot folder in my storage card and then, a nbh with the same name as the module in a folder with customRUU.exe. I flash and then it gets to the linux boot screen, after a couple lines go by, the screen fades out and dies and restarts. My battery says 88 percent when i flash back to windows, anybody know what could be going wrong?
HTC Sense
will it only recognize only an ext2 or will it recognize squashfs.
blitzer320 said:
Well now that the thread is over on xda I tried again but still to no avail even tried two different SD cards both end with it booting but freezing at SMD: ch 0 OPENING -> OPENED. Pretty sure I have everything setup correctly three files in andboot folder on sdcard renamed rootfs to just rootfs.img but left the other two files. By the way this is on a tilt2.
Click to expand...
Click to collapse
I'm on the rhod210 (T-Mobile), and I've been having this exact issue. Any ideas?
btw, this is my first post here, but I've been reading and following this project for quite a long time. You guys are great! Thanks for all the work you do!
On Samsung phones I guess you can turn root on/off by changing the variable in default.prop, but I have my phone rooted and it says ro.secure=1. How would I modify the bootloader? What would I look for to find out what I'm talking about?
I would like to try compiling my own kernel too. XDA University has information about compiling the kernel, but it is kind of unclear about how to put the actual package together though, or at least confusing. It says just zip the image and .ko files together and then it is good to flash, but then gives a file structure tree with unknown files? I downloaded a kernel to test from this site and the file structure was different, and it also reset the whole phone to get the job done.
LG Pro Lite D680
{
"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"
}
Boot On Charge
Non-generic feature for commercial purposes
URGENT NEED! - WILL DONATE
What we need:
I am looking for an urgent solution to boot-on-charge LG D680 cell phone, I am asking for help to developers who have experience on this area. The subject is related to unlock the bootlaoder, fastboot and custom rom. I understand the task is not simple, I am looking forward to donate whoever hacks the non generic feature.
What we do:
We provide video service through LG D680 cell phone (Also known as LG Pro Lite D680), the phone has 3G connection and is plugged to the power supply when is working.
Problem:
Most of the day the phone is plugged and working properly, however when the weekend comes the cell phone is unplugged and the energy is completely consumed. Currently, when the power is back to the cell phone we need to start the cell phone MANUALLY by pressing the power on button.
Goal:
We need the phone to be booted into the OS automatically when is plugged into the power USB cable (the phone initial status is powered off).
Possible Solutions / Alternatives:
Unlock the bootloader and run fastboot command fastboot oem off-mode-charge 0.
Continue our research, based on the steps described below (see LG D680 experience)
Replace charge animation with boot file command /system/bin/reboot (see Huawei experience below replacing ipod file).
Finding a custom ROM that already contains a Boot on Charge behaviour.
Finding a custom ROM that at least has “Power On Schedule” feature (AOSP certificate permissions level).
Finding a generic Android vestion with “Power On Schedule”.
Cellphone specifications:
PLATFORM
OS - Android OS, v4.1.2 (Jelly Bean), upgradаble to v4.4.2 (KitKat)
Chipset - Mediatek MT6577
CPU - Dual-core 1 GHz Cortex-A9
GPU - PowerVR SGX531
Previous work and research:
We did this "boot on charge" research in two types of cell phones. One is HUAWEI G730 and the other is LG D680. Fortunately, it worked fine in G730, but we haven’t the same results up to now on LG D680.
In Huawei G730, we replaced charging animation located at /system/bin/ipod with an ipod file containing “/system/bin/reboot” and worked like charm!
LG D680, we could not find the animation file, but we found that it might be inside the boot image. We did some research in order to modify it, but we got blocked (someone might continue our steps if useful).
HUAWEI G730 Extended Procedure:
Since this phone has a Mediatek chipset, the “battery animation” app is running on /system/bin folder. Is running with the filename ipod. The main task is to exchange ipod content (which is originally binary) to an ipod file with this content: /system/bin/reboot.
So, create a brand new file called ipod, and wrote the line in there. We transferred the file to the phone via adb push, as shown in next steps below.
Copy procedure: So, we set our phone to USB Debugging Mode, then we connected it to the PC, and run the following script:
adb shell mkdir /storage/sdcard0/carga/ (We created a folder to store files being pushed from the PC to the phone)
adb push ipod /storage/sdcard0/carga/ (We are pushing the file to the storage folder within the phone)
adb shell "su -c 'mount -o rw,remount -t ext4 /dev/block/mmcblk0p5 /system'" (This step is very important, here we remount the /system folder with read-write permissions. Only doing this we will be able to copy programmatically the “hacked” file ipod to /system/app. Look out that we used mmcblk0p5 because the system folder is mapped there in this phone. You can check this running cat /proc/dumchar_info)
adb shell "su -c 'chattr -i /system/bin/ipod'" (doing this we took out immutability to the original file ipod)
adb shell "su -c 'cp /system/bin/ipod /storage/sdcard0/carga/ipod.old'" (just creating a backup file from the original ipod)
adb shell "su -c 'rm /system/bin/ipod'" (here we are removing original ipod file)
adb shell "su -c 'cp /storage/sdcard0/carga/ipod /system/bin/'" (now we copy the new file ipod to the destination folder)
adb shell "su -c 'chmod 755 /system/bin/ipod'" (change the permission ro rwx-rx-rx)
adb shell "su -c 'mount -o ro,remount -t ext4 /dev/block/mmcblk0p5 /system'" (we remount the /system folder with read-only permissions)
adb shell "su -c 'reboot'" (Finally we reboot the phone)
RESULT: Whenever you plug in the phone to the charger when it is off, it will try to boot on the battery animation, but instead, it will be redirected to a “reboot” command, which in turn will be redirecting execution to the O.S.
LG D680 Procedure:
We found that this phone also has a Mediatek chipset. Moreover, it also has a file called ipod within /system/bin. But in this case, the bootloader image doesn’t call ipod whenever it displays the battery animation. So we had to check where is mapped the boot image on the phone by executing adb shell "cat /proc/dumchar_info". As the picture shows, the boot image (bootimg) is mapped in /dev/block/mmcblk0, from offset 0x1200000, and with size 0x900000.
We tried the following steps, in order to test if we were able to download / upload booting without bricking the phone:
We copy bootimg partition to boot.img by doing adb shell "su -c dd if=/dev/block/mmcblk0 of=/storage/sdcard0/boot.img bs=1024 skip=18432 count=9216’. (Skip and Count are measured on KBytes, and those values are offset and size translated from hexa to dec).
Then we did the inverse operation by executing: adb shell "su -c dd if=/storage/sdcard0/boot.img of=/dev/block/mmcblk0 bs=1024 seek=18432”
RESULT: The phone WASN’T bricked, and reboot normally (obviously without any change on bootimg).
Because these steps worked, we went even further, this time by unpacking and repacking boot.img file. The steps done were:
Same as (b)
We pulled boot.img file from the phone to a folder within the PC, and then we unpacked the image with bootimg.exe as the picture shows below. One interesting fact is that the pulled file sized almost 9MB.
Then we repacked it without any change inside the image, as the picture shows below. The “repacked” image is now on file “boot-new.img”, but its size is almost 7.4MB. We don’t know why we have this difference.
Same as step (ii) on (b).
RESULT: The phone resulted in a SECURITY_ERROR. It is weird because we didn’t change anything. We didn’t tried further since we are not able to unpack-repack the same image, and loading it successfully.
Edited: The security error can be avoided please follow the just below instructions.
Avoid Security Error:
In order to avoid the security error above mentioned, you need to edit the default.prop file (located at /bootimg/initrd)
Change the value from 1 to 0.
FastBoot Note LG:
Fastboot is a solution performing these commands, the problem is that the bootloader is locked for these operations on the generic vesion:
fastboot oem unlock
fastboot oem off-mode-charge 0
fastboot oem lock
fastboot reboot
The command "adb reboot bootloader" does not enter on fastboot upon reboot. There seems to be an opened option while booting on "Download Mode". What I did find out is that when you go into "Download Mode" a new ADB Device is detected on my computer however no driver matched the device. I assume fastboot could be avilable on Download Mode. I have been suggested by romulocarlos to Install the drivers on LG's website however did not work out.
Files:
For making the tests your will need the system.img, boot.img images files. If you brick your phone and want to un-brick the phone please follow this guide [Guide] LG G PRO LITE- Unroot/Unbrick - flash official factory firmware. Currently we are using this kdz image.
Forum:
G Pro Lite D680 Android Development at Android General.
XDA considered the case and opened a new forum for the phone. Thanks very much laufersteppenwolf (aka Wolf), MikeChannon (forum moderator) and svetius.
Conclusion:
We have reached this spot and need help from more advanced hackers. As you guys can see, we have been working hard to trying to hack the boot-on-charge feature on the D680 however has not been yet possible. There is no precedent on this phone on custom CWM & TWRP and custom roms yet therefore the is no out of the box solution as on many other phones (i.e. cyanogen list). We have also tried XDA University practices with no results.
I am ready to donate whoever would help us in solving this problem, its an urgent matter that needs to be solved as soon as possible. I will reward a developer by making a donation.
Appreciate very much the help in advance and reading.
Best,
Jose
Well, it's not that easy without having the actual device, but it'd help quite a bit if you could upload a system dump as well as the boot.img
laufersteppenwolf said:
Well, it's not that easy without having the actual device, but it'd help quite a bit if you could upload a system dump as well as the boot.img
Click to expand...
Click to collapse
Hi laufersteppenwolf,
Congratulations for your achievements and career, amazing.
I am hereby sharing two link resoruces to download what you have asked for, system.html containing the system.img and boot.html containing boot.img. Please let me know if you have problems downloading.
I understand the side effects of not having the cellphone by your side, hope we can mitigate it with the image files you are asking. As extended solution I can open a vnc session or whatever remote tool you can consider.
Thanks so much for the answer and support.
Best,
Jose
JoseVigil said:
Hi laufersteppenwolf,
Congratulations for your achievements and career, amazing.
I am hereby sharing two link resoruces to download what you have asked for, system.html containing the system.img and boot.html containing boot.img. Please let me know if you have problems downloading.
I understand the side effects of not having the cellphone by your side, hope we can mitigate it with the image files you are asking. As extended solution I can open a vnc session or whatever remote tool you can consider.
Thanks so much for the answer and support.
Best,
Jose
Click to expand...
Click to collapse
I am DL'ing the files now, but please use another hoster, as 4shared is not allowed on XDA
laufersteppenwolf said:
I am DL'ing the files now, but please use another hoster, as 4shared is not allowed on XDA
Click to expand...
Click to collapse
Hi laufersteppenwolf,
Thanks for clarifying, I was not aware 4shared was not allowed. I am changing the hosting and updating the link.
Cheers,
Jose
Alright, what I have done so far is I have unpacked the boot image and the ramdisk, edited the ramdisk so it shoud execute /system/bin/reboot when the phone boots because of the charger. Then I repacked both and signed the boot.img again so the bootloader would accept it.
The result, however, is a bootloop. I am just not yet sure whether it is caused by a "false alarm" (the ramdisk always thinking the phone is being booted because of a plugged in charger) or caused by either the bootloader or other low-level security checks. But I also doubt that, as the bootloader seems to accept the repacked image (doesn't show the security error screen).
But I currently do not have any logs, which is why all this is wild guessing. So the highest priority now is to get some proper logs so I know what's going on
laufersteppenwolf said:
Alright, what I have done so far is I have unpacked the boot image and the ramdisk, edited the ramdisk so it shoud execute /system/bin/reboot when the phone boots because of the charger. Then I repacked both and signed the boot.img again so the bootloader would accept it.
The result, however, is a bootloop. I am just not yet sure whether it is caused by a "false alarm" (the ramdisk always thinking the phone is being booted because of a plugged in charger) or caused by either the bootloader or other low-level security checks. But I also doubt that, as the bootloader seems to accept the repacked image (doesn't show the security error screen).
But I currently do not have any logs, which is why all this is wild guessing. So the highest priority now is to get some proper logs so I know what's going on
Click to expand...
Click to collapse
Hi Wolf,
Great advance! Keep the great work up .
I have made some modifications on the original post. Yes you are right, the bootloader friendly accepts the original image and we have figured out the security error. We have found on our end that you need to edit the default.prop file (located at /bootimg/initrd) and set ro.secure to value 0. I also added the files to the post (yet to change the server origin on the boot.image though), added the kdz image to unbrick. Also appended the new forum for the phone.
I appreciate that you have favored to create the forum for the G Pro Lite D680 Android Development. Its great that we can help the community with our achievements.
Best,
Jose
JoseVigil said:
Hi Wolf,
Great advance! Keep the great work up .
I have made some modifications on the original post. Yes you are right, the bootloader friendly accepts the original image and we have figured out the security error. We have found on our end that you need to edit the default.prop file (located at /bootimg/initrd) and set ro.secure to value 0. I also added the files to the post (yet to change the server origin on the boot.image though), added the kdz image to unbrick. Also appended the new forum for the phone.
I appreciate that you have favored to create the forum for the G Pro Lite D680 Android Development. Its great that we can help the community with our achievements.
Best,
Jose
Click to expand...
Click to collapse
ro.secure doesn't trigger the security checks, this prop is only for other things like adb on early boot, enabling adb remount, adb as root by default,...
I also set ro.secure to 0 in the builds I sent you, so that's not the cause of the issue
@JoseVigil
I have some pretty good news The phone now does exactly what you want it to do, as soon as you plug in the charger, the phone boots into offline charging mode, but then directly reboots again into the normal system.
The reboot is not that nice, but it's by far the easiest, as well as safest, way to do it.
Turns out, LG did a pretty sloppy job, giving me adb access to the device when in offline charging mode, giving me the chance to read which process is running and patching the binary to run my hack before actually executing the binary. And that's it. A few lines of bash code and you're good to go
Now my question, do you want me to write a tiny script to do all the work patching the system, or shall I just explain what to do?
laufersteppenwolf said:
@JoseVigil
I have some pretty good news The phone now does exactly what you want it to do, as soon as you plug in the charger, the phone boots into offline charging mode, but then directly reboots again into the normal system.
The reboot is not that nice, but it's by far the easiest, as well as safest, way to do it.
Turns out, LG did a pretty sloppy job, giving me adb access to the device when in offline charging mode, giving me the chance to read which process is running and patching the binary to run my hack before actually executing the binary. And that's it. A few lines of bash code and you're good to go
Now my question, do you want me to write a tiny script to do all the work patching the system, or shall I just explain what to do?
Click to expand...
Click to collapse
You are the man Wolf!
Its great that you have been able to find a workaround.
Yes, ideally both. I would appreciate if you can write the script so we can run it on our rooted phones pragmatically and a brief description of what it does (comprehensive from reading the script too) with implementation steps to reproduce too.
With the script I will do the proper test on my end and provide you feedback in case we have an issue. I will place the donation the coming week early on right after the test, I will be pleased that you get your reaward .
Once that, I think It would be pertinent though that we can expose how far we have reached with our research. If you agree, we can set the ground for someone (either me or you or anyone) to get a bootable customized boot image and unlock the door for CM.
I would love to see this running on CM. But I also know we have to be realistic, as you mentioned, this could be a hell of a work to have a working custom recovery, the device tree and blobs with kernel (almost XDA University I have not been able to deal with too).
It has been a lot of fun and a pleasure to know you and interact with you. I hope this is our first experience.
Thanks very much for the great work.
Best,
Jose
JoseVigil said:
You are the man Wolf!
Its great that you have been able to find a workaround.
Yes, ideally both. I would appreciate if you can write the script so we can run it on our rooted phones pragmatically and a brief description of what it does (comprehensive from reading the script too) with implementation steps to reproduce too.
With the script I will do the proper test on my end and provide you feedback in case we have an issue. I will place the donation the coming week early on right after the test, I will be pleased that you get your reaward .
Once that, I think It would be pertinent though that we can expose how far we have reached with our research. If you agree, we can set the ground for someone (either me or you or anyone) to get a bootable customized boot image and unlock the door for CM.
I would love to see this running on CM. But I also know we have to be realistic, as you mentioned, this could be a hell of a work to have a working custom recovery, the device tree and blobs with kernel (almost XDA University I have not been able to deal with too).
It has been a lot of fun and a pleasure to know you and interact with you. I hope this is our first experience.
Thanks very much for the great work.
Best,
Jose
Click to expand...
Click to collapse
Alright, in the attachment I have uploaded the script, including all needed files in order to execute it. The script will also tell you what it's about to do before doing it, so in case you run into issues, you know where to look into
So, what the installer script is going to do:
It will first of all push a script temporarily to the internal sdcard, then it will back up /system/bin/rtcd to /system/bin/rtcd_original, as we need to execute it later again. Next it will copy the script over from the sdcard to /system/bin/rtcd, replacing the original binary (and setting the correct permissions to both modified files). As the last step it will delete the temp file from the sdcard again.
That's all the installer script does.
The actual "magic" is inside the script being pushed to /system. It gets executed before starting chargemon and reads out the devices boot mode. If the boot mode is charger, it executes /system/bin/reboot. Otherwise it executes the original binary in /system/bin/rtcd_original.
And that's about it As simple as it could only be
Regarding further development, up until now, every device I own received a werewolf kernel, and I'm not planning on making an exception for this phone
I will definitely keep on looking into it, though it will not be as high on my priorities list as this workaround was
I will most likely open a new thread in the next couple of days, stating my findings regarding the phone/boot image/bootloader.
@JoseVigil @laufersteppenwolf
I'm New In Rom Developing . But I Think This Can Help You To Find Security Checks
I need lg g pro lite dual d686 custom twrp recovery i cant find anywhere plz provide working recovery link for d686 as iam new it seems custom recovery for specific d686 dosnt exits so share tested link for d686
Sent from my LG-D686 using xda Forums PRO
Hello I need boot on charge on my LG E460 with MTK. I done ipod change, rctd replace from laufersteppenwolf file without results. I can't went into fastboot mode of course to set oem mode charge for 0
Phone have root, bootloader unlock, busybox and supersu. Any suggestions?
Maxjimme said:
I need lg g pro lite dual d686 custom twrp recovery i cant find anywhere plz provide working recovery link for d686 as iam new it seems custom recovery for specific d686 dosnt exits so share tested link for d686
Sent from my LG-D686 using xda Forums PRO
Click to expand...
Click to collapse
TWRP RECOVERY
http://forum.xda-developers.com/optimus-g-pro/d680-development/d686-unsecured-boot-img-twrp-2-8-7-x-t3163144
Same Problem here with LG E460. Is there a solution for fastboot mode with this device?
hi, do you think this script could work on a LG G Pro 2 ?
hi guys, any chance i could get this working on a chinese mediatek device running kitkat 4.4.2 ??
Greetings!
First of all, I am sorry if this is on the wrong section of the forum. Nevertheless i've tried few rooting applications which are stated to be compatible with this ME103K model, but with no results.. Also many fake sites trying to lure you to purchase something.
Is there anyone who could provide me information on how to root my ASUS ME103K tablet? Should I also try every rooting application available out there or is this useless? Can I verify if they are compatible without all the way installing and running them on the device? (Sorry don't know much about this stuff =)! )
Thank you very much in advance
I rooted ME103K on my own - by compiling a custom kernel
Executive summary: Go to youtube and watch video with ID "gqubgQjqfHw" (I can't post links yet, sorry! ) - or search Youtube for "Rooting MemoPAD10 (ME103K) with my custom compiled kernel"
Analysis:
I hated the fact that my recently purchased MemoPAD10 (ME103K) tablet had no open process to allow me to become root. I don't trust the closed-source one-click root apps that use various exploits, and require communicating with servers in.... China. Why would they need to do that? I wonder...
I therefore decided this was a good opportunity for me to study the relevant documentation and follow the steps necessary to build an Android kernel for my tablet. I then packaged my custom-compiled kernel into my custom boot image, and the video shows how I boot from it and become root in the process.
Note that I didn't burn anything in my tablet - it's a 'tethered' root, it has no side-effects.
If you are a developer, you can read in detail about the steps I had to take to modify the kernel (and su.c) and become root - by reading the questions (and answers!) that I posted in the Android StackExchange forum ( can't post links yet, see the video description in Youtube ).
If you are not a developer, you can download my custom boot image from the link below - but note that this means you are trusting me to not do evil things to your tablet as my kernel boots and my /sbin/su is run
Honestly, I haven't done anything weird - I just wanted to run a debootstrapped Debian in my tablet, and succeeded in doing so. But I am also worried about the cavalier attitude I see on the web about rooting your devices - if you want to be truly safe, you must either do what I did (and recompile the kernel yourself) or absolutely trust the person that gives it to you. I do wish Google had forced a UI-accessible "become root" option in Android, just as Cyanogen does (sigh).
The image I created and used in the video to boot in rooted mode, is available from the link show in the Youtube video details.
Enjoy!
ttsiodras said:
Executive summary: Go to youtube and watch video with ID "gqubgQjqfHw" (I can't post links yet, sorry! ) - or search Youtube for "Rooting MemoPAD10 (ME103K) with my custom compiled kernel"
Analysis:
I hated the fact that my recently purchased MemoPAD10 (ME103K) tablet had no open process to allow me to become root. I don't trust the closed-source one-click root apps that use various exploits, and require communicating with servers in.... China. Why would they need to do that? I wonder...
I therefore decided this was a good opportunity for me to study the relevant documentation and follow the steps necessary to build an Android kernel for my tablet. I then packaged my custom-compiled kernel into my custom boot image, and the video shows how I boot from it and become root in the process.
Note that I didn't burn anything in my tablet - it's a 'tethered' root, it has no side-effects.
If you are a developer, you can read in detail about the steps I had to take to modify the kernel (and su.c) and become root - by reading the questions (and answers!) that I posted in the Android StackExchange forum ( can't post links yet, see the video description in Youtube ).
If you are not a developer, you can download my custom boot image from the link below - but note that this means you are trusting me to not do evil things to your tablet as my kernel boots and my /sbin/su is run
Honestly, I haven't done anything - I just wanted to run a deboot-strapped Debian in my tablet. But I am also worried about the cavalier attitude I see on the web about rooting your devices - if you want to be truly safe, you must either do what I did (and recompile the kernel yourself) or absolutely trust the person that gives it to you. I do wish Google had forced a UI-accessible "become root" option in Android, just as Cyanogen does (sigh).
The image I created and used in the video to boot in rooted mode, is available from the link show in the Youtube video details.
Enjoy!
Click to expand...
Click to collapse
Hello ttsiodras,
I had the same problem as OP and didn't want to go the "chinese route" either, especially since there seem to be conflicting reports on whether it works on the ME103k or not so I tried your solution - with mixed results...
Disclaimer: I'm totally new to Android (colour me unpleasantly surprised) and have little experience in Linux, so for further reference I would consider myself an advanced noob. Please keep this in mind when evaluating my claims or judging what I have done so far or am capable of doing by myself in the future.
What I did:
- become developer in the ME103k by tapping the system build repeatedly, then allowing debugging via USB
- use ADB to boot into the bootloader
- use fastboot to boot your boot.rooted.img
What happened:
- I did get root access
- the tab now always boots into the bootloader, even when told via ADB or fastboot to boot normally or into recovery. Pushing buttons etc doesn't seem to work either
- my attempts to do a recovery via the vanilla Asus method has failed due to the same fact that boot never gets past fastboot
Since you claimed in your description that there would be no side-effects since it is a tethered root I am somewhat puzzled as to what exactly happened. From what I understand - which admittedly isn't a lot - what should have happened is that your boot image is loaded, giving me root access until the next reboot without changing anything about the default boot process or image. I read somewhere else that this is how people test out different kernels with fastboot before deciding on which one they want to use on their devices. The whole boot process being changed and corrupted in a way that makes the tablet non-rebootable without having the cable and an adb- and fastboot-capable machine nearby is not really what I would have expected going by your description.
Of course it is entirely possible (and probably even rather likely) that I got something wrong along the way or there is a simple fix to my problem I am not aware of.
As for possible steps maybe you or someone else in the forum could point me to a way to return my tablet to factory settings before risking damaging it beyond repair. I'm assuming that it should be possible and rather straightforward to recover the original setup with the firmware provided by Asus (downloaded the newest version from the homepage) but to be honest I'm a bit scared to go ahead with it before knowing for sure how to do this safely.
One thing seems certain: I won't be able to do it the way Asus says I should unless I can somehow get into normal or recovery boot modes again. I do however still have root access and am able to run fastboot and ADB including shell on the tablet, so it should be possible.
I would certainly appreciate any help very much
Thanks
drsiegberterne said:
. . . From what I understand - which admittedly isn't a lot - what should have happened is that your boot image is loaded, giving me root access until the next reboot without changing anything about the default boot process or image. I read somewhere else that this is how people test out different kernels with fastboot before deciding on which one they want to use on their devices.
Click to expand...
Click to collapse
Your understanding is correct - that's exactly what should have happened.
I can assure you that the kernel I compiled is formed from the Asus sources with the 2 patches I made that have *nothing* to do with the bootloader - they patch the way that the kernel allows dropping privileges and thus allowing root level access.
Something else must have happened - did you by any chance "burn" the image? i.e. `(DONT DO THIS) fastboot flash boot boot.rooted.img` instead of `fastboot boot boot.rooted.img`?
I did not advocate for burning precisely because it is unpredictable - manufactures sometimes require signing images with their private keys before allowing a boot image to boot (AKA "locked bootloaders") which means that any attempt to burn may lead to weird configurations. . .
If you did burn it, maybe you can try burning the original "boot.img" from the Asus OTA (Over the Air) update .zip file (avaible as a big download at the ASUS site - "UL-K01E-WW-12.16.1.12-user.zip" )
I know of no way to help you with the current state of your tablet, except to "ease the pain" by saying that rebooting to fastboot is always "recoverable" - you can always boot into my own (rooted) kernel or the original (from the ASUS .zip file) with `fastboot boot <whatever_image>`. No "harm" can happen from this - as you correctly said, it's the way to try new kernels and images.
UPDATE - after more reverse engineering:
I had a look into the contents of the boot loader running inside the ME103K, and I am pretty sure that if you execute this at fastboot...
# fastboot oem reset-dev_info
# fastboot reboot
... you will get back to normal, un-tethered bootings of your ME103K.
Thanassis.
ttsiodras said:
Your understanding is correct - that's exactly what should have happened.
I can assure you that the kernel I compiled is formed from the Asus sources with the 2 patches I made that have *nothing* to do with the bootloader - they patch the way that the kernel allows dropping privileges and thus allowing root level access.
Something else must have happened - did you by any chance "burn" the image? i.e. `(DONT DO THIS) fastboot flash boot boot.rooted.img` instead of `fastboot boot boot.rooted.img`?
I did not advocate for burning precisely because it is unpredictable - manufactures sometimes require signing images with their private keys before allowing a boot image to boot (AKA "locked bootloaders") which means that any attempt to burn may lead to weird configurations. . .
If you did burn it, maybe you can try burning the original "boot.img" from the Asus OTA (Over the Air) update .zip file (avaible as a big download at the ASUS site - "UL-K01E-WW-12.16.1.12-user.zip" )
I know of no way to help you with the current state of your tablet, except to "ease the pain" by saying that rebooting to fastboot is always "recoverable" - you can always boot into my own (rooted) kernel or the original (from the ASUS .zip file) with `fastboot boot <whatever_image>`. No "harm" can happen from this - as you correctly said, it's the way to try new kernels and images.
Thanassis.
Click to expand...
Click to collapse
Hi Thanassis,
thanks for your quick reply and your efforts. I'm actually around 85% sure I did not flash the image but since I had no Linux on my computer at the time (I know shame on me) I used a Mac and the command line was a bit different. Since I had never used ADB or fastboot I relied on some guide that explained how to even get into the bootloader and might have gotten something wrong.
On the other hand I later read out the commands I used in the Mac shell and couldn't find anything other than the things I should have done and described earlier, so as far as I can tell this all should never have happened. It may be interesting to point out here that the "stuck in fastboot" mode happened immediately after the first time I loaded your kernel and I most definitely just wrote fastboot boot boot.rooted.img at that point.
As for fixing the problem now it's not only about the inconvenience of the whole thing. I also later (after I was already stuck in fastboot mode) installed some apps for helping me manage privileges of different apps (xposed framework and xprivacy) which turned out to not be compatible in some way or another. So now not only is my tablet not booteable in a normal way but its also cluttered with even more useless stuff than before and I would really like to just reset it before thinking about any other possibilities.
If I flash boot the original ASUS boot image found in the file you described and which i dowloaded already, shouldn't that fix the problem if I accidentally did flash your boot image? Or will there be even more trouble?
Alternatively isn't there a manual way to flash the whole zipped recovery image or am I misunderstanding what this ASUS file actually contains?
And which of the two options is safer to try first or in other words - which one might break the tablet once and for all?
Thanks again and sorry for my incompetence
drsiegberterne said:
Hi Thanassis,
If I flash boot the original ASUS boot image found in the file you described and which i dowloaded already, shouldn't that fix the problem if I accidentally did flash your boot image? Or will there be even more trouble?
. . .
Alternatively isn't there a manual way to flash the whole zipped recovery image or am I misunderstanding what this ASUS file actually contains?
. . .
Thanks again and sorry for my incompetence
Click to expand...
Click to collapse
No, don't be sorry We are all either choosing to learn in this world (i.e. make mistakes and learn from them), or choose to remain stuck in ignorance. I applaud your efforts in properly rooting the tablet. . .
To the point - remember, you are root now ; whatever apps you installed, you can definitely uninstall them. You don't necessarily need to wipe it.
If you do want to, I'd suggest booting in recovery and doing it the normal way that Asus recommends. Since you said "buttons don't work", you may want to try using the original recovery .img - i.e. "fastboot boot recovery.img". I'd love to suggest a link from ASUS, but they don't host it (which is bad - they really should) - so instead go to "goo" dot "gl" slash "noegkY" - this will point you to a discussion where a kind soul is sharing his ME103K recovery.img.
Booting from the recovery will allow you to install the ASUS OTA update - and probably try cleaning cache partition, etc
Good luck!
ttsiodras said:
No, don't be sorry We are all either choosing to learn in this world (i.e. make mistakes and learn from them), or choose to remain stuck in ignorance. I applaud your efforts in properly rooting the tablet. . .
To the point - remember, you are root now ; whatever apps you installed, you can definitely uninstall them. You don't necessarily need to wipe it.
If you do want to, I'd suggest booting in recovery and doing it the normal way that Asus recommends. Since you said "buttons don't work", you may want to try using the original recovery .img - i.e. "fastboot boot recovery.img". I'd love to suggest a link from ASUS, but they don't host it (which is bad - they really should) - so instead go to "goo" dot "gl" slash "noegkY" - this will point you to a discussion where a kind soul is sharing his ME103K recovery.img.
Booting from the recovery will allow you to install the ASUS OTA update - and probably try cleaning cache partition, etc
Good luck!
Click to expand...
Click to collapse
The problem here is that he doesn't seem to have the same version as on my tablet. I have the newest version with Lollipop while this seems to be at least a couple of patches earlier with a completely different version of Android. Won't I risk breaking things even more if I try to apply this - as in trying to recover a recovery that is not on my tablet since certainly the recovery.img doesn't contain all the information needed since it's only 10 MB.
As you can probably guess the whole discussion in your link about what part of the system is broken and how to fix it goes right over my head. It also seems like they did not find a satisfactory solution in the end (short of sending the tablet to ASUS). As you can imagine I'm at quite a loss what to try and what not out of fear to make things worse. At least for now I can still use the tablet to do the things I need it to do.
Thanks for your help anyway, I will try to read up more on the topic and decide what to do next.
drsiegberterne said:
The problem here is that he doesn't seem to have the same version as on my tablet. I have the newest version with Lollipop while this seems to be at least a couple of patches earlier with a completely different version of Android. Won't I risk breaking things even more if I try to apply this - as in trying to recover a recovery that is not on my tablet since certainly the recovery.img doesn't contain all the information needed since it's only 10 MB.
Thanks for your help anyway, I will try to read up more on the topic and decide what to do next.
Click to expand...
Click to collapse
I understand how you feel - your tablet is operational now (OK, with the annoyance that you need to boot it in "tethered mode") - so you rightfully fear that you may mess things up with further steps.
Just to clarify something - the recovery img is something that works on its own ; it has no dependency on what kind of Android image is installed in the /system partition.
If you do decide to do it, "fastboot boot recovery.img" will bring you to a spartan menu, showing options that allow you to apply an update (i.e. the ASUS update you downloaded!), clean the /cache partition, etc.
Choose "install update from SD card" (use volume up/down to choose, power btn to select), and navigate to your SD card, where you will have placed the big .zip file from ASUS.
The recovery process will begin, and your tablet will be "wiped" with the image from ASUS. Reboot, and be patient while the tablet boots up - it will be just like the first time you started it (i.e. install from scratch).
Whatever you decide - good luck!
ttsiodras said:
I understand how you feel - your tablet is operational now (OK, with the annoyance that you need to boot it in "tethered mode") - so you rightfully fear that you may mess things up with further steps.
Just to clarify something - the recovery img is something that works on its own ; it has no dependency on what kind of Android image is installed in the /system partition.
If you do decide to do it, "fastboot boot recovery.img" will bring you to a spartan menu, showing options that allow you to apply an update (i.e. the ASUS update you downloaded!), clean the /cache partition, etc.
Choose "install update from SD card" (use volume up/down to choose, power btn to select), and navigate to your SD card, where you will have placed the big .zip file from ASUS.
The recovery process will begin, and your tablet will be "wiped" with the image from ASUS. Reboot, and be patient while the tablet boots up - it will be just like the first time you started it (i.e. install from scratch).
Whatever you decide - good luck!
Click to expand...
Click to collapse
Okay, a little update from the battlefront:
I tried the recovery image and did get into the menu, however the recovery failed with the same two error messages as in your earlier link ("footer is wrong" and "signature verification failed"). My output from fastboot getvar all is also very similar to the one from that guy except I have a different bootloader version than him (3.03).
Another thing I noticed is that if I boot the standard boot.img found in the ASUS zip it will recognize the internal sdcard normally, however when I boot your rooted image the internal memory doesn't seem to be recognized, at least not through the pre-installed file manager. Downloading a file to the internal storage also failed while rooted but all the apps and the OS itself so far seem totally unaffected otherwise.
My last resort at the moment is the fastboot flash boot boot.img but I have little hope it would change anything since in the thread you linked they proposed just that and if it had worked they probably would have mentioned it.
Can it theoretically break the tablet even more? I would hate to have to send it in because I completely bricked it...
drsiegberterne said:
Okay, a little update from the battlefront:
Another thing I noticed is that if I boot the standard boot.img found in the ASUS zip it will recognize the internal sdcard normally, however when I boot your rooted image the internal memory doesn't seem to be recognized.
Click to expand...
Click to collapse
Not the case for me - everything works fine (including internal and external sdcard), so it's definitely not my kernel causing this.
drsiegberterne said:
My last resort at the moment is the fastboot flash boot boot.img but I have little hope it would change anything since in the thread you linked they proposed just that and if it had worked they probably would have mentioned it.
Can it theoretically break the tablet even more? I would hate to have to send it in because I completely bricked it...
Click to expand...
Click to collapse
Flashing is always dangerous (from what you've said, I actually theorize that you did, actually, flash already...)
I doubt this will solve the boot issue, to be honest - if I were you, I'd continue to boot tethered (with my image when you need root access, and (maybe) the Asus image when you don't). Myself, I always boot my own bootimage, since I have zero problems with it, and it allows me to run a complete Debian distro in a chroot (thus making my tablet a full-blown UNIX server - e.g. I run privoxy on it to filter all stupid ads in all apps on the tablet, etc).
No matter what you decide, good luck!
Thanassis.
ttsiodras said:
Not the case for me - everything works fine (including internal and external sdcard), so it's definitely not my kernel causing this.
Flashing is always dangerous (from what you've said, I actually theorize that you did, actually, flash already...)
I doubt this will solve the boot issue, to be honest - if I were you, I'd continue to boot tethered (with my image when I need root access, and (maybe) the Asus image when I don't). Myself, I always boot my own bootimage, since I have zero problems with it, and it allows me to run a complete Debian distro in a chroot (thus making my tablet a full-blown UNIX server - e.g. I run privoxy on it to filter all stupid ads in all apps on the tablet, etc).
No matter what you decide, good luck!
Thanassis.
Click to expand...
Click to collapse
I already tried to flash the original boot.img yesterday but it didn't change anything as you correctly assumed so I guess for now there is nothing more to do. I might write to the Asus support and maybe send the tablet in if it is free of charge for me (which I doubt). The only other option is to spend the next months to get sufficiently versed in Android to actually fix the problems myself but even for that I would probably need some files or source code from Asus. I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to.
Getting these Android devices like buying a hammer that can't hammer things in on Sundays.
drsiegberterne said:
I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to
Click to expand...
Click to collapse
I share the sentiment - it's really sad.
Undoing the tethered root
drsiegberterne said:
I already tried to flash the original boot.img yesterday but it didn't change anything as you correctly assumed so I guess for now there is nothing more to do. I might write to the Asus support and maybe send the tablet in if it is free of charge for me (which I doubt). The only other option is to spend the next months to get sufficiently versed in Android to actually fix the problems myself but even for that I would probably need some files or source code from Asus. I find it rather disappointing the way these "closed" systems work nowadays, with the advancement of Linux and Open Source I really would have expected the opposite to be true but apparently people care more about convenience than actually being able to use the tools they buy in the way they want to.
Getting these Android devices like buying a hammer that can't hammer things in on Sundays.
Click to expand...
Click to collapse
Hi drsiegberterne - I had a look into the contents of the boot loader running inside the ME103K, and I am pretty sure that if you execute this at fastboot...
# fastboot oem reset-dev_info
# fastboot reboot
... you will get back to normal, un-tethered bootings of your ME103K.
Hope this solves your problem!
Kind regards,
Thanassis.
I've seen a lot of people asking about this in various threads, so I decided to release a version modded to run under Android. First things first:
1. This is not a support thread. I'm not even providing compiled binaries. I am providing code that will compile under CyanogenMod and should work once compiled.
2. I will answer legitimate questions about compiling or use, but not generic "will this work on xyz phone". I expect posts to state what attempts you have already made and where you got stuck. All other requests will be mocked mercilessly.
MODS TAKE NOTE: I already have two suspensions for mocking n00bs.
What is CVE-2016-0728? It is an overflow bug in the Sysv IPC interface. You can read the technical write-up here http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/
What does it do for you? It allows a userspace program to grab a root token, and execute an arbitrary command. In the example code provided, it opens a root shell. This will provide temporary root on your phone.
Why a special version for Android? Two reasons: 1st, Android's Bionic lacks Keyutils needed to compile this successfully. You can cross-compile it using regular tools, but the provided code will compile under Android (using the NDK or CyanogenMod). 2nd, my makefile uses static linking to avoid problems with missing symbols. On my test device, a dynamically linked compiled version failed to find some libc symbols.
How do I patch my device to avoid the same problem: Here is the upstream fix: https://github.com/torvalds/linux/commit/23567fd052a9abb6d67fe8e7a9ccdd9800a540f2
How do I use it?
1. This exploit only works under kernel version 3.8 or higher on kernels with Sysv enabled. The execution may also be blocked by selinux. Google recently removed Sysv from the recommended Android kernel configs, and Linux has a patch for this problem, so expect devices to begin patching against this. Note this excludes the vast majority of older Android devices on kernel versions 3.4 and earlier.
2. I will assume you already know how to set up your build environment and sync CyanogenMod. Breakfast a device with a similar or the same processor and sync it. For example, my test device is arm64, so I breakfasted h815, LG G4, and then modified this line in the make file to say "generic" instead of cortex-a53. The resulting binary should work on any arm64 device.
3. Grab the exploit code (download zip) and place in your device folder (G4-common in our example).
4. "mka rootz"
5. The resulting binary is quite large (300 kb) due to static linking. You can pare it down by using dynamic linking if you think your device has compatible libc.
6. The exploit takes some time to run (6 hours plus on a phone). Due to it's nature it is reported to only have a 1 in 3 chance of success (you have to intentionally overflow the keyring while other processes are also using the keyring, so there is another chance a different process could cause it to overflow before you do).
7. Most modern Android devices do not let you execute arbitrary code from user accessible locations anymore. If you are attempting to root a device with this, you have to place the binary in a location that will let you execute it. This location or availability of it may vary by device. "/data/local/tmp" may be available. There are various programs that install command line tools in a location a non-root user can access them as well. You can use Better Terminal Emulator Pro for instance. It lets you open up a shell on your device, and it has a bin directory at "/data/data/com.magicandroidapps.bettertermpro/bin" you can copy the executable to. Make sure you chmod 777 the executable after copying it. Better Term Pro also comes with busybox, so you can potentially remount your system r/w after getting temporary root for more permanent root
8. Usage is something like "./rootz PP1" where PP1 is the name of the key you want to use. That's name should work for you.
9. Wait 6 hours and enjoy
Phones known to not be affected (I am only listing phones that meet the basic critieria, ie kernel version 3.8 and up. Also only stock firmwares. So your crappy Galaxy S III is not going on this list. And neither is your already rooted phone):
1. BlackBerry Priv (/proc/keys node missing)
2. LG G4 (/proc/keys node missing)
Phones known to be affected
1. NONE. (It appears very few devices ship with CONFIG_KEYS on Android OEM builds, although CyanogenMod has it turned on.)
If the /proc/keys is missing this exploit will fail, yes?
[email protected]:/data/local/tmp $ ./rootz PP1
uid=2000, euid=2000
msgget: Function not implemented
I do have /proc/keys kernel version 3.18 6.01 marshmellow
Guess I lack SysV.... I have /proc/keys in the filesystem, but the actual file is empty when I cat it.
I have /proc/sysvipc present on this device.
I don't think this exploit can actually work for android. It requires the adresses of symbols (like commit_creds). These adresses can only be taken from /proc/kallsyms but if you are not a root user the output will be 0's.
Also many devices luck SysV IPC. Though we can still replace msgget with sendmmsg or something equivalent and then bypass ASLR. I saw you have written a fucntion get_symbols but it actually return something like: 000000000.
rm
rm
symbols
First sorry for my bad writing!
I also see only 0x000... in /proc/kallsyms
Could we extract the adresses of symbols directly from a kernel image an then use that list instead /proc/kallsyms?
Cynob