Related
Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave
Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?
yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
Your not going to able to sign it without Samsung's signatures... and good luck finding those
yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.
just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days
So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.
For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage
Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.
DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...
{
"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"
}
In order to keep the Root Progress thread as clean as possible, I took Kenny's advice and created a new thread. So to bring others up to speed, the Galaxy Note 4 variants from AT&T and Verizon have a root, but it's only temporary and resets after a reboot. Also system write is inconsistent.
This thread is for people to share and discuss their ideas and theories of how to make our temp root into a permanent root. Don't be afraid to share or ask any questions you may have because this is the place for them here. Now let's get brainstorming!
Continuous "Custom padlock" on bootup
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Anything is worth mentioning. It's interesting. I've just got my Note 4 warranty replacement yesterday so I'm timid to tinkering with it just yet. On my previous Note 4 I wiped out the EFS while playing in one of those "secret menus' LoL.
My thoughts on how-to obtain permanent root: We'll obviously make use of the temp root from KingRoot, then my idea (if feasible/logical) is to find the flag/eFuse and modify the result or expected result to keep it from reverting back. Now if it's dependent on an eFuse it may not be feasible if it's blown from the factory to lock the bootloader, but if it's like Dan Rosenbergs @djrbliss findings then the eFuse may be blown to unlock the bootloader. It's been a while since I read his findings so I may not be 100% accurate but it makes more sense the first method from a security point-of-view.
Now this was all before dmverity was introduced into KitKat 4.4.4 I believe, so things probably have changed for the worse in our case. I wonder where the weakest link is? I say this because obviously Qualcomm is great at securing their high-level chain of commands lately, but with the Droid Turbo gaining root(same SoC) then I have to believe that a kernel exploit is possible permanently and our road block is Sammy's software. Now with that being said, how tough can their software really be if their flagship S6 (Exynos) was just rooted? BTW good job @idler1984 on that! So you see where I'm going with this right? There's got to be a hole somewhere in Sammy's software after the bootloader, I just don't have a full overview of the boot process as far as where the Qualcomm bootloader hands off to kernel, then to Samsung's KNOX or activation lock etc etc...
Speaking of KNOX (Just rambling here) but has anyone who has used KingRoot ensured that they have turned KNOX and Activation Lock off? That would be funny is that's all it took to retain root
CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Don't read too much into the custom message you can trip that a variety of ways even before now.
dagolith said:
Don't read too much into the custom message you can trip that a variety of ways even before now.
Click to expand...
Click to collapse
Well my main point here is that I edited the Factory Mode flag to enabled and was able to force the system to keep it set by editing the file permissions. While this don't work with all the files/folders this might be something to look at. I only wish I understood the file system more so I knew if we could possibly keep the system from restoring apps and removing root.
Here is a message I sent Droid.Ninja az I did not want to clog up the other thread with stupid ideas. But, that has been taken care of by others and their talking about off topic stuff. Any way here is a partial quote of what I sent him a few days ago. I hope that there is something useful here.
Jaytronics said:
Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me.
Click to expand...
Click to collapse
Jaytronics said:
1. Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
2. Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing
3. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me..
Click to expand...
Click to collapse
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:
ZPaul2Fresh8 said:
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
Click to expand...
Click to collapse
From what I understand we never get to touch the actual file system of the system. This explains the bootup process of Android http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html So upon bootup it copies the system data into RAM. Some how there must be a way to edit this and force the memory to write to the actual partition like how an update would have to do. This is why I was curious about my editing the /efs and making the changes stick by changing the file permissions.
ZPaul2Fresh8 said:
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:
Click to expand...
Click to collapse
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
I can guarentee you 100% you won't get they keys there is a reason the bootloader has not been crackdx since the note 2 these are not something that can be so easily obtained
Sent From The EDGE
Question. I am still on lolipop so i haven't tried but seeing as android is basically linux. When we obtain root even though its temp can we or has anyone tried mounting all the partitions in /dev to other location to see whats what and whats editable? I would think as root you could just mount and edit the system partition. Assuming you can find which partition is actually the system part.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app
cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
delete this if it does help with anything but i was listening to an podcast and they were talking about root and they used an camera app to help install su apk like i said just remember hearing something about it
keep up the good work guys!
CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.
Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
Your theory is sound and does (to some extent bare a little further research):
Now to explain what i mean by further research: I have been developing ROMS since the early days of Windows mobile (long before android or iPhones) the original process of packaging and pushing a "ROM" to the mobile device involved several binary edits as you had to move your custom ROM into the exact location within the install package, part of the other issue is that your ROM had to be the EXACT same number of bytes as the OEM thus preventing you from adding to stock unless you removed the exact same number of bytes from your build.
Now as far as the theory being sound here is my explanation for that:
IF (and it's a big IF) we were to compare for instance the BL from a Tmobile note4 to that of ours and determine exactly (and I mean EXACTLY) where the binary portion was that contained the "Keys" and that portion was EXACTLY the same byte size then "In Theory" we could insert the "Keys" from our BL into the Tmobile BL and flash it on our device which since the keys would be correct would not balk at doing so.
Now for the explanation as to why this wont work:
In order to insert our keys into the Tmo BL they litteraly would have to be byte for byte identical or every single byte in the entire BL would be offset and this would in turn cause the flash to fail. And in the event it didn't fail the BL memory space would be offset by the exact same number of bytes and would likely brick your device.
cstayton said:
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.
Click to expand...
Click to collapse
The strange thing is if you edit /efs/FactoryApp with permission 0775,which is default, pressing the power button causes the phone to completely shut off, no power menu is shown. Changing it to 0644 yields a working power menu, but selecting any of the files to edit shows each file is blank. But I don't understand the fs enough to know a lot so I was just throwing that piece of information out there.
CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.
jeepers007 said:
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.
Click to expand...
Click to collapse
this would definetly point to the initramfs scenario meaning in order for root to "Stick" we would need modifications to kingsroot or whatever perm root method is used to write directly to the mmcblkxx partition rather than the /system folder (which is nothing more than volatile RAM space.)
Same case for me, any changes made were reverted on reboot. I used King to temp root, removed all traces of knox, then actually attempted to convert and install SuperSu but it would not install. Just said that the install failed and to try again.
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.
Today, my phone got bricked after I installed Magisk, am i am looking for a way of sorting it out. The phone was running Android 9 DP3 when rooted, and I was following HighOnAndroids root guide on Youtube for reference,
I unlocked my bootloader and successfully installed TWRP. After this, I installed Magisk, which went throuygh perfectly fine. However, after rebooting the phone, I am stuck on the google splash screen, with a small progress bar that stays for the duration of the time on this screen. After about 2 minutes, the phone reboots into TWRP again.
Does anyone know how I could return to stock Android or at least escape this issue?
Many thanks
James
Jameswebb97 said:
Today, my phone got bricked after I installed Magisk, am i am looking for a way of sorting it out. The phone was running Android 9 DP3 when rooted, and I was following HighOnAndroids root guide on Youtube for reference,
I unlocked my bootloader and successfully installed TWRP. After this, I installed Magisk, which went throuygh perfectly fine. However, after rebooting the phone, I am stuck on the google splash screen, with a small progress bar that stays for the duration of the time on this screen. After about 2 minutes, the phone reboots into TWRP again.
Does anyone know how I could return to stock Android or at least escape this issue?
Many thanks
James
Click to expand...
Click to collapse
Use duces script to flash June google factory image.
jlokos said:
Use duces script to flash June google factory image.
Click to expand...
Click to collapse
I followed the guide on the DeucesScript XDA page but the command window keeps saying "'fastboot' is not recognized as an internal or external command, operable program or batch file."
Jameswebb97 said:
I followed the guide on the DeucesScript XDA page but the command window keeps saying "'fastboot' is not recognized as an internal or external command, operable program or batch file."
Click to expand...
Click to collapse
You need this information (the stuff I made bold + the hyperlink):
Code:
If you are having issues with this script:
Download the latest fastboot and adb Platform Tools UPDATED Dec. 22, 2017!!! This is the most common problem!!!
Download/Update Google USB Drivers
Video: Force-Installing the Android USB Drivers Fastboot & ADB
[B]Verify you have the [URL="https://wiki.lineageos.org/adb_fastboot_guide.html"]environment variable (path)[/URL] set for adb and fastboot[/B]
Try a different USB port
Try a different cable
Format Userdata in Stock Recovery
Try to boot stock before doing mods like Locking Bootloader / Kernel / TWRP / Magisk
Jameswebb97 said:
I followed the guide on the DeucesScript XDA page but the command window keeps saying "'fastboot' is not recognized as an internal or external command, operable program or batch file."
Click to expand...
Click to collapse
umph....hate to tell you, but you have a long way to go...
so before going on this "journey", I would suggest you booting into TWRP again, and try installing (not adb sideloading, just in case you're doing that) Magisk again. Also, be sure you are using the latest (might be considered "beta") 16.4 for taimen... I'm thinking your boot.img or dtbo.img simply may have gotten glitchy and repatching (by installing Magisk again) might fix it...
Also, if you want to go a step further, you might want to consider using the official Magisk uninstaller. Since Magisk makes a copy of your stock boot and dtbo image, it may put that back so you can get it in working order to get into the system (although without root), and then figure things out and/or reinstall Magisk (through TWRP is best) while all things Magisk was removed...
Good luck and hope this helps....
Make sure you are trying to open from the correct location, and put .\fastboot
EvilDobe said:
You need this information (the stuff I made bold + the hyperlink):
Code:
If you are having issues with this script:
Download the latest fastboot and adb Platform Tools UPDATED Dec. 22, 2017!!! This is the most common problem!!!
Download/Update Google USB Drivers
Video: Force-Installing the Android USB Drivers Fastboot & ADB
[B]Verify you have the [URL="https://wiki.lineageos.org/adb_fastboot_guide.html"]environment variable (path)[/URL] set for adb and fastboot[/B]
Try a different USB port
Try a different cable
Format Userdata in Stock Recovery
Try to boot stock before doing mods like Locking Bootloader / Kernel / TWRP / Magisk
Click to expand...
Click to collapse
Ive tried all of this now, i got the script working, but now the phne says it is corrupt and i cannot get into recovery. Is this game over do you think?
simplepinoi177 said:
umph....hate to tell you, but you have a long way to go...
so before going on this "journey", I would suggest you booting into TWRP again, and try installing (not adb sideloading, just in case you're doing that) Magisk again. Also, be sure you are using the latest (might be considered "beta") 16.4 for taimen... I'm thinking your boot.img or dtbo.img simply may have gotten glitchy and repatching (by installing Magisk again) might fix it...
Also, if you want to go a step further, you might want to consider using the official Magisk uninstaller. Since Magisk makes a copy of your stock boot and dtbo image, it may put that back so you can get it in working order to get into the system (although without root), and then figure things out and/or reinstall Magisk (through TWRP is best) while all things Magisk was removed...
Good luck and hope this helps....
Click to expand...
Click to collapse
This is good advice, thanks. i have a new problem (ugh), where i got the script working through changing the paths, but now the phone says that it is corrupt and i cannot access TWRP. Game over?
Jameswebb97 said:
Ive tried all of this now, i got the script working, but now the phne says it is corrupt and i cannot get into recovery. Is this game over do you think?
Click to expand...
Click to collapse
With the unlocked bootloader it'll always say the device is corrupt. Manually put the device into the bootloader & flash the DeucesScript. You're basically starting over at this point but it is possible to get up & going again.
Jameswebb97 said:
This is good advice, thanks. i have a new problem (ugh), where i got the script working through changing the paths, but now the phone says that it is corrupt and i cannot access TWRP. Game over?
Click to expand...
Click to collapse
EvilDobe said:
With the unlocked bootloader it'll always say the device is corrupt. Manually put the device into the bootloader & flash the DeucesScript. You're basically starting over at this point but it is possible to get up & going again.
Click to expand...
Click to collapse
EvilDobe might be right...but I have a bit to offer before maybe starting all over...
I doubt you needed to edit the script and "change the paths." Most likely you merely did not have the images (you extracted from the .zip of the Full Factory image you got from the Google Developers site) inside the "platform-tools" folder with the adb & fastboot .exe and all the other files and folders.
In any case, I suggest you get the TWRP image file [.img] (NOT the installer .zip necessarily), put the .img file "... inside the "platform-tools" folder with the adb & fastboot .exe and all the other files and folders." (I've seen some users simply cut and paste those 2 .exe files only to the extracted folder -- this is why I state it this way) Then, power down your device. After it's off, hold down the Volume Down button and press & hold the Power button (this is the manual way to get into the Bootloader Mode). Once there, plug your phone into your computer (USB-A to USB-C would be best) and open a command prompt/powershell ("run as administrator" or with administrative priveleges) and direct it to the platform-tools folder (i.e. if I put it on my desktop, it would be "C:\Users\MyName\Desktop\platform-tools"), you can temporarily boot into TWRP via command
Code:
fastboot boot twrp-3.2.1-2-taimen.img
When in TWRP (hopefully), I suggest trying to do what I advised before -- try either Magisk installer to repatch the boot and dtbo image, or Magisk Uninstaller to attempt to replace your boot and dtbo to stock.
*NOTE: Of course, this is assuming you are running Microsoft Windows (if not, you will need to input .\ as @naiku suggested) and also the whole "device is corrupt" is due to "funky" boot image issues. If not, I/we can guide you to flashing the Full Factory back onto the phone (hopefully without losing data and settings)...
Good luck and hope this helps...
simplepinoi177 said:
EvilDobe might be right...but I have a bit to offer before maybe starting all over...
I doubt you needed to edit the script and "change the paths." Most likely you merely did not have the images (you extracted from the .zip of the Full Factory image you got from the Google Developers site) inside the "platform-tools" folder with the adb & fastboot .exe and all the other files and folders.
In any case, I suggest you get the TWRP image file [.img] (NOT the installer .zip necessarily), put the .img file "... inside the "platform-tools" folder with the adb & fastboot .exe and all the other files and folders." (I've seen some users simply cut and paste those 2 .exe files only to the extracted folder -- this is why I state it this way) Then, power down your device. After it's off, hold down the Volume Down button and press & hold the Power button (this is the manual way to get into the Bootloader Mode). Once there, plug your phone into your computer (USB-A to USB-C would be best) and open a command prompt/powershell ("run as administrator" or with administrative priveleges) and direct it to the platform-tools folder (i.e. if I put it on my desktop, it would be "C:\Users\MyName\Desktop\platform-tools"), you can temporarily boot into TWRP via command
Code:
fastboot boot twrp-3.2.1-2-taimen.img
When in TWRP (hopefully), I suggest trying to do what I advised before -- try either Magisk installer to repatch the boot and dtbo image, or Magisk Uninstaller to attempt to replace your boot and dtbo to stock.
*NOTE: Of course, this is assuming you are running Microsoft Windows (if not, you will need to input .\ as @naiku suggested) and also the whole "device is corrupt" is due to "funky" boot image issues. If not, I/we can guide you to flashing the Full Factory back onto the phone (hopefully without losing data and settings)...
Good luck and hope this helps...
Click to expand...
Click to collapse
Pleased to be editing this comment; managed to get it working following your step by step. Think i'm going to stay away from rooting something this expensive in the future! Thanks so much!
Jameswebb97 said:
Pleased to be editing this comment; managed to get it working following your step by step. Think i'm going to stay away from rooting something this expensive in the future! Thanks so much!
Click to expand...
Click to collapse
I wouldn't go that far with staying away. When I come across people IRL that want to start doing this stuff I always tell them to read the instructions, step through them, read the instructions again, ask questions (as you did here) BEFORE you get started, read the instructions again, and only when you're confident start messing with your device. This is a fun, and at times stressful, hobby. It's great when everything goes according to plan but it's an omg omg omg omg omg omg moment when you mess something up.
Start with baby steps. The straight upgrade to P is fairly simple provided your device is unlocked. Get that working & you'll be set. I have root on my DP3 & the only thing I've done so far is delete some apps from system that I know I don't want/need. If your main goal is to just enjoy your phone, test out Android P, and maybe go back... root isn't needed. Once everything is squared away & you're running for a day or so you can always fastboot to recovery, make a backup, and then try to add root. I hope you don't shy away & get deeper into the hobby. It truly starts to get fun when you begin to understand more of what is going on.
Jameswebb97 said:
Pleased to be editing this comment; managed to get it working following your step by step. Think i'm going to stay away from rooting something this expensive in the future! Thanks so much!
Click to expand...
Click to collapse
Hey I'm so glad you got it working! Leave me a "Thanks!" would make it up to me ... I'm always happy to help out and get things figured out...yet I don't get the satisfaction of knowing if it does end up helping a lot of the time because a good number don't come back with their experience...so thanks for that! Glad you got it going...
EvilDobe said:
I wouldn't go that far with staying away. When I come across people IRL that want to start doing this stuff I always tell them to read the instructions, step through them, read the instructions again, ask questions (as you did here) BEFORE you get started, read the instructions again, and only when you're confident start messing with your device. This is a fun, and at times stressful, hobby. It's great when everything goes according to plan but it's an omg omg omg omg omg omg moment when you mess something up.
Start with baby steps. The straight upgrade to P is fairly simple provided your device is unlocked. Get that working & you'll be set. I have root on my DP3 & the only thing I've done so far is delete some apps from system that I know I don't want/need. If your main goal is to just enjoy your phone, test out Android P, and maybe go back... root isn't needed. Once everything is squared away & you're running for a day or so you can always fastboot to recovery, make a backup, and then try to add root. I hope you don't shy away & get deeper into the hobby. It truly starts to get fun when you begin to understand more of what is going on.
Click to expand...
Click to collapse
And it's as @EvilDobe means.....
I remember back in the days of the Motorola Droids (OG Droid1, Droid 3, & Droid 4) where you could really mess things up and come out with a big ol' "brick" "paperweight" as there were many instances where you could not come back from (i.e. updating to a certain point, then attempting to downgrade when Google/Motorola/Verizon put blocks that breaks it). But this isn't the case these days. @Jameswebb97, at least with the Pixel 2's, Oreo and/or P(Android OS 9), it's actually more difficult than easy to get that too far gone. The only reason why I can help so many troubleshooting their issues is because I, myself, have wrecked my current device in some serious ways! So I can relate and have experience in helping in the same situations. I've gotten it to where it says "device is corrupt," (which isn't all that uncommon), BUT with the added desperate troubleshooting where I had to wipe/erase, changing partition types, format several partitions, even go about "resizing" the partition to match the "target extraction size" of the Full Factory flash, and even as far as learning to manually flash the various system partitions and that there are two (system_a & system_b) but, in Google's infinite wisdom(?), one flashes to system_a and the other to system_other!!! And I haven't even started on reading others' issues when going after the Slot A and Slot B complications -- I didn't even attempt to touch this in that troubleshooting story.
My point is: I think I've broken my device farther than most people and got it so close to the brink, and yet I was able to bring it back and am still using that same device today (most people would usually, at that point, go and get a RMA replacement). Honestly, as long as you have access to Bootloader Mode (which Google, in their infinite wisdom, seems to have placed it in the main board memory or separate memory rather than storage as to make it always accessible which makes it hard to "lose"), you have a really good (seemingly perfect) "safety net" in which you can always flash back to a working, stock state -- which is why it's the best policy to just make good backups before experimenting so, if anything, you get back to this state and restore all your data. I'm not trying to convince you to root or to try custom ROMs or anything -- even though there are many great reasons and capabilities of rooting -- I am simply appealingl to your sense of curiosity and reassure you so you aren't held back and you don't restrict and limit yourself if you don't want to, but are to fearful to experiment.
I hope you don't take this post as "lecturing" or anything, just some thoughts I hope you consider...
Glad it worked out in the end for you!
Someone was "helping" me root my Mi Mix2. I can't be 100% sure what went wrong, but he managed to get it stuck in Fastboot mode, such that no matter what I do (i.e. any combination of power offs, or simultaneous button presses, or commands from terminal). I suspect he did not understand me when I said Magisk was tool best suited...he may have used some more familiar or standard tool like SuperSU or something to try and root.
Assuming I have sufficiently described my problem, is there anything I can do to get the phone back into a usable state?
Is your bootloader unlocked? If yes try to flash ROM using miflash tool.
I appreciate the response/suggestion.
fotocreaman said:
Is your bootloader unlocked?
Click to expand...
Click to collapse
Yes. I double checked with "fastboot oem device-info" commmand
fotocreaman said:
If yes try to flash ROM using miflash tool.
Click to expand...
Click to collapse
On your advice I did that, including downloading current (?) version and current(?) version of stock ROM. I received a message to effect that a flash script (.bat) file was missing (or at least not found).
Other threads regarding this error suggest unzipping something (?) twice but I didn't see a file inside the original zip file that could be additionally unzipped, and certainly nothing with a .bat extension.
Can you put here the exact error message and when it exactly occurs? Describe the steps you did to get to that point
Hi aa040371
1- download fastboot rom for your phone and unzip it twice , put folder in C:\ storage http://update.miui.com/updates/v1/fullromdownload.php?d=chiron_global&b=F&r=global&n=
2- Look at the tutorial to use miflashtool https://c.mi.com/thread-1857937-1-1.html
regards
I'm Still Here...
So, after more than a few detours and distractions, I have my phone (Mi Mix 2S, not the plain "2" I originally indicated!) basically back to stock...good frustration-tolerance building exercise.
I am currently in the process of trying to get TWRP to remain after booting to OS. I have researched/read numerous threads on this -- e.g. boot into TWRP, flash TWRP, reboot directly into TWRP again -- but somehow none of them do the trick. Every time I boot into the OS, the Recovery partition gets overwritten and I am back to the stock recovery tool. If I can trust/believe what at least one person has indicated online, this appears to be due to a script in /system/bin, but I can't get at that file to rename or delete it. In fact, I can't even see it in the file system as that area is completely locked down. I know it is there as a Find command executed via ADB shell lists it even though it indicates it is off-limits.
So I turned my attention to loading a rooting app/tool instead hoping that would let me get TWRP to hang around for long term...another excursion in futility. My phone model is M1803D5XA, so according to one more forum thread somewhere, I am supposed to be using SuperSU rather than Magisk? Whatever...it seems impossible: most of the zip files I located don't pass security/file-signing check. The one I found that at least starts to load/install (SR5-SuperSU-v2.82-SR5-20171001224502) works fine right up until it fails while trying to update "sepolicy" files. For some reason I have to sideload SuperSU from TWRP because I am not allowed to push a file even to my SDcard via ADB.
I just don't get why this all has to be so difficult, as in each and every step along the way. I feel like Sisyphus or Job or someone similar...sigh Any thoughts or suggestions still welcome...thanks.
aa040371 said:
So, after more than a few detours and distractions, I have my phone (Mi Mix 2S, not the plain "2" I originally indicated!) basically back to stock...good frustration-tolerance building exercise.
I am currently in the process of trying to get TWRP to remain after booting to OS. I have researched/read numerous threads on this -- e.g. boot into TWRP, flash TWRP, reboot directly into TWRP again -- but somehow none of them do the trick. Every time I boot into the OS, the Recovery partition gets overwritten and I am back to the stock recovery tool. If I can trust/believe what at least one person has indicated online, this appears to be due to a script in /system/bin, but I can't get at that file to rename or delete it. In fact, I can't even see it in the file system as that area is completely locked down. I know it is there as a Find command executed via ADB shell lists it even though it indicates it is off-limits.
So I turned my attention to loading a rooting app/tool instead hoping that would let me get TWRP to hang around for long term...another excursion in futility. My phone model is M1803D5XA, so according to one more forum thread somewhere, I am supposed to be using SuperSU rather than Magisk? Whatever...it seems impossible: most of the zip files I located don't pass security/file-signing check. The one I found that at least starts to load/install (SR5-SuperSU-v2.82-SR5-20171001224502) works fine right up until it fails while trying to update "sepolicy" files. For some reason I have to sideload SuperSU from TWRP because I am not allowed to push a file even to my SDcard via ADB.
I just don't get why this all has to be so difficult, as in each and every step along the way. I feel like Sisyphus or Job or someone similar...sigh Any thoughts or suggestions still welcome...thanks.
Click to expand...
Click to collapse
Recovery will get overwritten by dm-verity, you have to flash either magisk or another mod that disables dm-verity, but personally I suggest to use a custom rom if you don't care about miui
HrX said:
Recovery will get overwritten by dm-verity, you have to flash either magisk or another mod that disables dm-verity, but personally I suggest to use a custom rom if you don't care about miui
Click to expand...
Click to collapse
Hello...thanks. I definitely don't care about MIUI...in fact the whole exercise I am struggling through is so I can get LineageOS onto my phone. I've probably read 50+ threads/posts on 6-7 different forums regarding unbricking/unlocking/rooting/TWRPing/customROMing my particular phone, but this is the first time I've seen mention of DM-Verity. I'll look into it...not really hopeful, though. But anyway...thanks again.