Related
Ok, first of all: I used the search button and Google a lot before coming here to post this.
My question is totally noob: can I make a NAND backup of my mobile, *before* rooting it, *before* installing custom recovery?
I'd like to do it because I'd really like to install a custom firmware (I'm oriented towards Prime or Megatron) on my O1, but I really want to have an opportunity to come back to the original firmware in case I need to repair my phone.
I've seen a large number of ways for doing backup of a phone *after* the custom recovery, but no one before.
Another question is: is it necessary to install the Android SDK for installing custom recovery, or can I run the adb commands from my mobile?
Thanks everyone in advance for the help!
The answer to your question "can I make a NAND backup of my mobile, *before* rooting it, *before* installing custom recovery?" is no. The custom recovery is the software that provides the nandroid backup facility. Without that custom recovery, you can't make a NAND backup (yet another good reason to do it).
What you can do is to backup the existing recovery image. From http://forum.xda-developers.com/showpost.php?p=9377725&postcount=9, you can do
Code:
dd if=/dev/mtd/mtd2 of=/sdcard/recovery-dump-T.img bs=4096
which will save off the stock recovery image to your sdcard. If you want to restore to the stock recovery, you can do
Code:
flash_image recovery /sdcard/recovery-dump-T.img
after you have installed the flash_image program. (Installing the flash_image program is a completely reversible step that needs root permissions, but can be completely undone.)
For your second question, all of the commands can be run from the Terminal on your phone. Note that your phone will need to be rooted and you will have to do "su" before you start typing commands. Having done "su", your prompt should turn to # instead of $.
Thank you very much for your detailed answer.
Now the question is: do I really need to do all of this stuff, or there's a way to bring back to the phone to original recovery/original OS without doing a backup myself, i.e. there is some image available from LG that restores the phone as out-of-the box?
There is only one tool from LG - LG update which updates whole your phone. It rewrite everything, also custom recovery.
Same "work" can be done with tool called KDZ_FW_UPD but, I didn't recommend it if it is not necessary.
For more information about KDZ_FW_UP take look on http://forum.xda-developers.com/showthread.php?t=875881
This doesn’t relate to the EVO LTE directly but hoping you guys can help.
Background:
I have a Tablet, that has very little Development support. There are no recoveries currently available for it. I followed a number of guides and managed to get latest version of TWRP compiled, I also followed the steps to boot the recovery image on a virtual device and so far things seem good.
Questions:
1. If the recovery I compiled doesn’t work, I am guessing that the device will still boot, so I can flash the backup image of the stock recovery , Is that correct.?
2. The TWRP recovery I compiled is 7 mb, and the Stock one is 16mb is it normal for such a size difference?
3. I attempted to flash the recovery image with the following commands from adb shell:
Su
flash_image recovery /sdcard/flex_tab/twrp/recovery.img
I am getting flash_image not found. I am guessing I need to add the Flash_image binary to the device. The little bit of searching has led me to a couple different versions and none with very current timestamps. I need one that will work on a 4.1.1 device. How would I go about getting the binary and just to double check I would copy it to /system/bin and fix permissions and owner
I tried flashing the image with fastboot as well and kept getting waiting for device, so I think something isn’t quite right with fastboot.
4. Any one familiar with porting recoveries do you have any gottcha’s that I should check before flashing, I really don’t want to brick the tablet.
Thanks,
Bump, wish I could help. I hope you got it. If not, hopefully someone who knows will see this.
Sent from my EVO 4G LTE using XDA Premium 4 mobile app
Hi devs,
I've started to port CM11 4.4 to my beloved Original Padfone (A66).
The first step was to compile the kernel sources that ASUS made available (Kernel 3.4), which as far as I understand will work with KitKat.
Am I correct to assume this?
Also, if the kernel compiled correctly what will be the next steps to test it (flash) in my device? The bootloader is unlocked, but I'm still with the original recovery. I think I will have to flash CWM or simmilar, right?
Thanks!
rafatz said:
Hi devs,
I've started to port CM11 4.4 to my beloved Original Padfone (A66).
The first step was to compile the kernel sources that ASUS made available (Kernel 3.4), which as far as I understand will work with KitKat.
Am I correct to assume this?
Also, if the kernel compiled correctly what will be the next steps to test it (flash) in my device? The bootloader is unlocked, but I'm still with the original recovery. I think I will have to flash CWM or simmilar, right?
Thanks!
Click to expand...
Click to collapse
The 3.4 kernel should work with KitKat. In order to properly test any CM11 builds you'll have to compile Clockworkmod Recovery for your device first by pulling your stock recovery.img and then compiling Clockworkmod Recovery using that. Additionally to test your kernel the best way is to take the zimage that's produced from compiling the kernel and make a boot.img out of it and boot it using fastboot. Let me know if you still have questions I'll be happy to answer them.
Sent from my SCH-I535 using XDA Premium 4 mobile app
shimp208 said:
The 3.4 kernel should work with KitKat. In order to properly test any CM11 builds you'll have to compile Clockworkmod Recovery for your device first by pulling your stock recovery.img and then compiling Clockworkmod Recovery using that. Additionally to test your kernel the best way is to take the zimage that's produced from compiling the kernel and make a boot.img out of it and boot it using fastboot. Let me know if you still have questions I'll be happy to answer them.
Sent from my SCH-I535 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've follow the XDA University guide for building CWM, at http://xda-university.com/as-a-developer/porting-clockworkmod-recovery-to-a-new-device
But the second step is failing:
Step 2 : Now that the otatools are ready, we need to get a dump of our current boot.img. To do this, use ‘adb shell’ and launch this command
“ dump_image boot /sdcard/boot.img “
This command do not exist in my phone.
Do you have any tip on this?
Thanks in advance!
rafatz said:
I've follow the XDA University guide for building CWM, at http://xda-university.com/as-a-developer/porting-clockworkmod-recovery-to-a-new-device
But the second step is failing:
Step 2 : Now that the otatools are ready, we need to get a dump of our current boot.img. To do this, use ‘adb shell’ and launch this command
“ dump_image boot /sdcard/boot.img “
This command do not exist in my phone.
Do you have any tip on this?
Thanks in advance!
Click to expand...
Click to collapse
You have a couple of options of obtaining your stock recovery image (It's better to use your stock recovery.img rather then boot.img when compiling recovery as the recovery.img has more information in it that will make process of building an actual working recovery image easier) the easiest way is to boot into stock recovery, wipe cache in recovery, then reboot the phone. Then from adb run the following command:
Code:
cat /cache/recovery/last_log
This should give you an output, if you read the logfile you will see that one of the partition blocks is called /recovery. Record the name of the recovery partition block and then run the following command:
Code:
su
cat /dev/block/{name=of-recovery-partition-block} > /mnt/sdcard/recovery.img
This will dump a copy of your stock recovery.img to your internal storage. That you can then use to continue in the CWMR compiling process. By all means if you still have questions let me know I'm here to help.
shimp208 said:
You have a couple of options of obtaining your stock recovery image (It's better to use your stock recovery.img rather then boot.img when compiling recovery as the recovery.img has more information in it that will make process of building an actual working recovery image easier) the easiest way is to boot into stock recovery, wipe cache in recovery, then reboot the phone. Then from adb run the following command:
Code:
cat /cache/recovery/last_log
This should give you an output, if you read the logfile you will see that one of the partition blocks is called /recovery. Record the name of the recovery partition block and then run the following command:
Code:
su
cat /dev/block/{name=of-recovery-partition-block} > /mnt/sdcard/recovery.img
This will dump a copy of your stock recovery.img to your internal storage. That you can then use to continue in the CWMR compiling process. By all means if you still have questions let me know I'm here to help.
Click to expand...
Click to collapse
OK, I was able to successfully compile CWMR, but when booting to recovery I only get a blank screen and the devices reboots to Android. Is there a way to find any information on the error?
I know that TWRP works in padfone, but I'm not sure if they are compatible.
rafatz said:
OK, I was able to successfully compile CWMR, but when booting to recovery I only get a blank screen and the devices reboots to Android. Is there a way to find any information on the error?
I know that TWRP works in padfone, but I'm not sure if they are compatible.
Click to expand...
Click to collapse
It's possible that something is wrong with your recovery's graphics. Try taking the zimage of the kernel sources you compiled and swapping that zimage with the one in your CWMR recovery.img (Replace the zimage in your CWMR .img with the one you obtained when compiling the kernel source from ASUS). You could also try compiling TWRP and seeing that results in the same problem there are times on devices TWRP has been working before CWMR was working properly.
shimp208 said:
It's possible that something is wrong with your recovery's graphics. Try taking the zimage of the kernel sources you compiled and swapping that zimage with the one in your CWMR recovery.img (Replace the zimage in your CWMR .img with the one you obtained when compiling the kernel source from ASUS). You could also try compiling TWRP and seeing that results in the same problem there are times on devices TWRP has been working before CWMR was working properly.
Click to expand...
Click to collapse
No way Simply not working
But TWRP is 100%
I've tested the original recovery back and it is perfect as well.
Only CWMR is not working
I've even used the builder tool without success.
I've followed this guide:
http://www.imajeenyus.com/computer/20130301_android_tablet/android/unpack_repack_recovery_image.html
and this
http://forum.xda-developers.com/showthread.php?t=1877807
Anyway, do you think that TWRP will work to flash my CM11 (if I ever build one)?
I think that the next problem is related on how to get the proprietary binaries from the phone to place in the vendor/asus/padfone folder.
rafatz said:
No way Simply not working
But TWRP is 100%
I've tested the original recovery back and it is perfect as well.
Only CWMR is not working
I've even used the builder tool without success.
I've followed this guide:
http://www.imajeenyus.com/computer/20130301_android_tablet/android/unpack_repack_recovery_image.html
and this
http://forum.xda-developers.com/showthread.php?t=1877807
Anyway, do you think that TWRP will work to flash my CM11 (if I ever build one)?
I think that the next problem is related on how to get the proprietary binaries from the phone to place in the vendor/asus/padfone folder.
Click to expand...
Click to collapse
The CWMR builder tool has been not working for a while now. If you were able to compile the latest version of TWRP and you said it was working 100% then that will be fine to test your CM11 test builds. For getting the vendor files I would take a look at this guide on the Cyanogenmod wiki regarding porting and pull vendor files. A extract-files.sh script for a pre-existing device such as the Sprint Galaxy Nexus is a decent place to start for getting an idea how to setup extract-files.sh.
shimp208 said:
The CWMR builder tool has been not working for a while now. If you were able to compile the latest version of TWRP and you said it was working 100% then that will be fine to test your CM11 test builds. For getting the vendor files I would take a look at this guide on the Cyanogenmod wiki regarding porting and pull vendor files. A extract-files.sh script for a pre-existing device such as the Sprint Galaxy Nexus is a decent place to start for getting an idea how to setup extract-files.sh.
Click to expand...
Click to collapse
Yes, TWRP is 100% working
I've checked the extract scripts but my main problem is to identify in the filesystem which files I should pull.
Anyway, I tried to use the "chipset" method and "guess" based on the system information which files/drivers I would need, but that was not very helpfull (http://specdevice.com/showspec.php?id=0429-3576-ffff-ffffa98be330).
Well, I'll continue my studies on this
rafatz said:
Yes, TWRP is 100% working
I've checked the extract scripts but my main problem is to identify in the filesystem which files I should pull.
Anyway, I tried to use the "chipset" method and "guess" based on the system information which files/drivers I would need, but that was not very helpfull (http://specdevice.com/showspec.php?id=0429-3576-ffff-ffffa98be330).
Well, I'll continue my studies on this
Click to expand...
Click to collapse
Another suggestion would be to take a look in the /vendor folder on your device to extract the proprietary files and use that as a starting point to build off. Then you could try and compile a test build using that. Studying other devices device tree's is like you said another way to gain hints about what to do for your own device.
shimp208 said:
Another suggestion would be to take a look in the /vendor folder on your device to extract the proprietary files and use that as a starting point to build off. Then you could try and compile a test build using that. Studying other devices device tree's is like you said another way to gain hints about what to do for your own device.
Click to expand...
Click to collapse
HURRAY!
This saved the day
https://www.codeaurora.org/cgit/qui...tree/proprietary-blobs.txt?h=aosp-new/idea133
It is not for Padfone, but it is close enough.
rafatz said:
HURRAY!
This saved the day
https://www.codeaurora.org/cgit/qui...tree/proprietary-blobs.txt?h=aosp-new/idea133
It is not for Padfone, but it is close enough.
Click to expand...
Click to collapse
Awesome! Glad you could find a very similar device, best of luck on your CM11 builds :good:.
shimp208 said:
Awesome! Glad you could find a very similar device, best of luck on your CM11 builds :good:.
Click to expand...
Click to collapse
After a few attempts I was able to finish a build for CM 10.2, but it will not boot
I found that maybe I did something wrong with the fstab.padfone, using the new standards with 5 settings instead of only 3.
Well, in order to eliminate these kind of problems, I will make a CM10.1 building, which still uses the old standards.
rafatz said:
After a few attempts I was able to finish a build for CM 10.2, but it will not boot
I found that maybe I did something wrong with the fstab.padfone, using the new standards with 5 settings instead of only 3.
Well, in order to eliminate these kind of problems, I will make a CM10.1 building, which still uses the old standards.
Click to expand...
Click to collapse
Does it not boot at all or does it get to the boot-animation at least? Did you try pulling a log to see if you could get any information on the problem? But best of luck on your building :good:.
shimp208 said:
Does it not boot at all or does it get to the boot-animation at least? Did you try pulling a log to see if you could get any information on the problem? But best of luck on your building :good:.
Click to expand...
Click to collapse
SO far I couldn't even flash the ROM
TWRP is build with name A66, and the ROM is based on padfone.
I tried to change it, but the build fails
I think that I need to continue my efforts to make a working CWMR. So far the issue is the same, I can build and flash the recovery, but it simply do not enter the recovery. I get a flash on the screen and the phone automatically reboots to enter android.
I wonder if there's any way to get logs or more information from this error, so I can at least start to understand why CWMR is not booting.
fastboot boot recovery.img fails as well.
Bad day
rafatz said:
SO far I couldn't even flash the ROM
TWRP is build with name A66, and the ROM is based on padfone.
I tried to change it, but the build fails
I think that I need to continue my efforts to make a working CWMR. So far the issue is the same, I can build and flash the recovery, but it simply do not enter the recovery. I get a flash on the screen and the phone automatically reboots to enter android.
I wonder if there's any way to get logs or more information from this error, so I can at least start to understand why CWMR is not booting.
fastboot boot recovery.img fails as well.
Bad day
Click to expand...
Click to collapse
To clarify the ROM fails to flash in recovery what is the error it gives you when it fails to flash? To get ADB working on your CWMR build so you can pull log information add these lines in the correct place to your init.rc file in your recovery ramdisk:
Code:
service adbd /sbin/adbd recovery
disabled
socket adbd stream 660 system system
# Always start adbd on userdebug and eng builds
on property:ro.debuggable=1
#write /sys/class/android_usb/android0/enable 1
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
shimp208 said:
To clarify the ROM fails to flash in recovery what is the error it gives you when it fails to flash? To get ADB working on your CWMR build so you can pull log information add these lines in the correct place to your init.rc file in your recovery ramdisk:
Code:
service adbd /sbin/adbd recovery
disabled
socket adbd stream 660 system system
# Always start adbd on userdebug and eng builds
on property:ro.debuggable=1
#write /sys/class/android_usb/android0/enable 1
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
Click to expand...
Click to collapse
Thanks man! I was able to get a working CWMR.
The GITHUB I created for the device is at:
https://github.com/rafatzbr/android_device_asus_A66
I was able to build CM10.1 to Padfone, but it simply wont boot
stucked in the initial screen (not the bootanimation).
Any help is much appreciated.
Thanks!
** UPDATE **
Still stucked in boot screen
Any ideas?
rafatz said:
** UPDATE **
Still stucked in boot screen
Any ideas?
Click to expand...
Click to collapse
The ROM build? If it's still stuck pull a log file and post the upload of the log here.
shimp208 said:
The ROM build? If it's still stuck pull a log file and post the upload of the log here.
Click to expand...
Click to collapse
Thanks!
The problems is that the device is not in a bootloop. It is stucked in the first screen (on nexus devices it's the first google screen).
How I can get any logs from there, and which logs I would need?
Feel free to haze me for what I'm sure is a stupid question.
After flashing the factory 5.1.1 image, is the Chainfire root method still the correct way to root? The 'fastboot flash boot' part made me wonder if it needs to be updated for the bootloader that shipped with the 5.1.1 image.
funkybside said:
Feel free to haze me for what I'm sure is a stupid question.
After flashing the factory 5.1.1 image, is the Chainfire root method still the correct way to root? The 'fastboot flash boot' part made me wonder if it needs to be updated for the bootloader that shipped with the 5.1.1 image.
Click to expand...
Click to collapse
Wrong question.
There is no "correct" or "incorrect" method. FWIW, it's a Nexus device. You don't need these automated tools. Just fastboot flash the TWRP image, boot to recovery and flash the latest SuperSU zip from recovery. Done.
cam30era said:
Wrong question.
There is no "correct" or "incorrect" method. FWIW, it's a Nexus device. You don't need these automated tools. Just fastboot flash the TWRP image, boot to recovery and flash the latest SuperSU zip from recovery. Done.
Click to expand...
Click to collapse
Thanks but that wasn't really my question and I hadn't planned to use the auto-root CF version. To clarify what I'm confused about: The manual CF Root process involves a step "fastboot flash boot {img}", and when checking the CF repository I see that this boot image was based on 5.0.x. From other threads I had understood the 5.1.1 factory image includes a new bootloader image, and this made me wonder if flashing the bootloader that ships with the chainfire root package would be a potential problem. I'm still curious about this, but now also:
Your response suggests I could avoid CF altogether if I'm willing to flash a non-stock recovery. Is that correct?
yeah I would skip CF and just do it the manual way. copy SuperSU to your device first.
@funkybside,
No. Flash all of the stock .img files except recovery. Fastboot flash TWRP.img instead. Then boot to recovery from fastboot on your device and flash the SuperSU.zip.
Alternatively, if you want to keep the stock recovery, you can
fastboot boot recovery "name of TWRP.img". Then flash the SuperSU.zip.
y2whisper said:
yeah I would skip CF and just do it the manual way. copy SuperSU to your device first.
Click to expand...
Click to collapse
That's the part that generated my question. Inside the SuperSU.zip are inject.img and patched.img. The readme states patched.img needs flashed with 'fastboot flash boot patched.img', and the package was made before the 5.1.1 drop. For all I know it's fine to do this, but since it's flashing a boot image I figured better safe than sorry and decided to post. I have searched here and all root threads/links seem pointed to videos using toolkits/CF-AutoRoot so I wasn't comfortable with following them. FWIW - At the moment I'm stock factory 5.1.1 image, stock recover, unlocked BL, not rooted.
Trying to be a self sufficient as I can...quickly becoming 'that guy'. ugh. The core question is does the patched.img inside SuperSU.zip cause any problems with a factory 5.1.1 unlocked device, due to potential differences between the factory 5.1.1 boot image and the one included in SuperSU.zip.
No you're just learning. I rooted my after without problems but I wonder if a new version will be done now that 5.1.1 is done for the N9
funkybside said:
That's the part that generated my question. Inside the SuperSU.zip are inject.img and patched.img. The readme states patched.img needs flashed with 'fastboot flash boot patched.img', and the package was made before the 5.1.1 drop. For all I know it's fine to do this, but since it's flashing a boot image I figured better safe than sorry and decided to post. I have searched here and all root threads/links seem pointed to videos using toolkits/CF-AutoRoot so I wasn't comfortable with following them. FWIW - At the moment I'm stock factory 5.1.1 image, stock recover, unlocked BL, not rooted.
Trying to be a self sufficient as I can...quickly becoming 'that guy'. ugh. The core question is does the patched.img inside SuperSU.zip cause any problems with a factory 5.1.1 unlocked device, due to potential differences between the factory 5.1.1 boot image and the one included in SuperSU.zip.
Click to expand...
Click to collapse
SuperSU is not device specific. 2.46 works fine on 5.1 on Nexus 6. I doubt the changes between 5.1 and 5.1.1 are significant enough to require a new version.
i use CF SuperSU Root Tool
1. Extract the earlier downloaded CF Auto zip folder on your computer.
2. Enable Developer Options on Nexus 9: in the About Device > tap Build Number multiple times until you see the new tab Developer Options. In here, check Enable OEM Unlock and USB Debugging.
3. Enter the Bootloader mode from your computer by running this command (open command prompt with Shift + Right Click > Open the command window here), adb reboot bootloader
4. Execute the root file,
Windows: run root-windows-bat
OS X: chmod +x root-mac.sh
run root-mac.sh
Linux: chmod +x root-linux.sh
run root-linux.sh
Once the command window finishes executing, your Nexus 9 will reboot.
Thanks to all of you. I guess I stop worrying and just give it a go. It seems like anyone who's had experience rooting 5.1.1 has not had any concerns or problems related to SuperSU.zip's patched.img being listed with a 5.0.x version on the CF site.
/me crosses fingers.
Edit: IT'S ALIVE! Thanks again folks.
In case anybody stumbles onto this thread, you might as well go with the "autoroot" method. Autoroot is smart enough to adapt to new boot images, and does not require installation of a custom recovery. What it is essentially, IS a custom recovery bundled with the root bits.
You "fastboot boot autoroot.img" the device. It loads the autoroot.img to memory, and executes it, and installs the internal root bits to the /system partition.
Also note: With a Nexus device, it is NEVER necessary to INSTALL a custom recovery image, since you can RUN a custom recovery image without actually installing it.
fastboot boot bootable.img
doitright said:
In case anybody stumbles onto this thread, you might as well go with the "autoroot" method. Autoroot is smart enough to adapt to new boot images, and does not require installation of a custom recovery. What it is essentially, IS a custom recovery bundled with the root bits.
You "fastboot boot autoroot.img" the device. It loads the autoroot.img to memory, and executes it, and installs the internal root bits to the /system partition.
Also note: With a Nexus device, it is NEVER necessary to INSTALL a custom recovery image, since you can RUN a custom recovery image without actually installing it.
fastboot boot bootable.img
Click to expand...
Click to collapse
I would only disagree on one point. This is fine as long as the user understands how to use ADB and fastboot, and how to get out of trouble if something goes wrong. We've seen too many inexperienced users get into trouble with automated tools who don't have the SDK installed on their PC and don't understand how to install drivers.
Looking out for help
I need to edit the boot.img but my problem is that every time i unpack the img and repack it the phone doesnt boot anymore (even w/o modifyng the boot.img only unpacking and repacking) it enters into a bootloop
is this bcs the boot.img are signed ? or that theyre in a different fromat like ext4?
Im flashing the boot.img with SPFlash tools
I got the Custom Rom and the boot.img from this thread https://forum.xda-developers.com/t/...om-firmware-root-playstore-certified.4405615/
Some boot images are AVB0 signed. Hard to tell if that's even checked.
You've got to tell us how new/old, how fancy your boot image is.
My best advice (as always) is don't take apart a boot image if you don't need to.
You can always use my ImgUtil.
At the very least you can use it to see what you're dealing with.
Code:
C:\>imgutil.exe /v /l myboot.img
Renate said:
Some boot images are AVB0 signed. Hard to tell if that's even checked.
You've got to tell us how new/old, how fancy your boot image is.
My best advice (as always) is don't take apart a boot image if you don't need to.
You can always use my ImgUtil.
At the very least you can use it to see what you're dealing with.
Code:
C:\>imgutil.exe /v /l myboot.img
Click to expand...
Click to collapse
Thanks for your fast reply. is it possible to repack with the imgUtil tool?
what im trying to achieve is to block the access to the recovery menu on the phone
Just do the imgutil command above. It won't affect anything but it will tell us what we're dealing with.
I don't know why/what you want to do to recovery.
@Renate Oh my goodness, thank you! This is precisely where I left off last night I finally learned how to unpack the boot image (using linux wahh) and now you share such a cool tool! GOSH AND ITS WINDOWS TOO. Thank you! There's literally so much junk tools out there it held me up a year x.x Miss Renate do you have tools for the system images too? TBH I just used superrs kitchen to unpack my stock image, but i'm not sure the tool will work for repacks bc I tried in the past and kept getting boot loop but i suspect that's something to do with whatever is stored in the kernel and ram disk? Sorry last question, have you wrote up something somewhere that I could read about what to do with the ramdisk or kernel?? Thank you for always being on here
Renate said:
Just do the imgutil command above. It won't affect anything but it will tell us what we're dealing with.
I don't know why/what you want to do to recovery.
Click to expand...
Click to collapse
I did imgutil /i and worked !!! thanks a lot this is a great tool
how can I modify the recovery menu this is the file I get (attached) I tried with Hex and notepad++ but couldnt find the entries of the menu
What Im looking here is to remove the option to wipe and format the phone from the recovery menu
Or maybe I should modify the init.rc ? to create a reboot command when entering recovery
but how can I send this command ?
this is my init.rc
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Renate said:
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Click to expand...
Click to collapse
The point of this project is to prevents employees of a company to wipe their phones.. this phones are locked to some spcecific apps and nothing else, the company doesnt want their employees to have another apps on the phone.
How is it possible to disable the recovery from ADB?
I tried removing the recovery file but when accesing the recovery via adb reboot recovery the phones gets stucked at the boot logo and needs flashing back the boot.img to turn back on the system.
That is why I wanted to insert a reboot command in the init.rc from the ramdisk.
Please tell me what do you think is the best option and how can I achieve this.
The phone Im dealing with its a Xiaomi Qin F21 Pro
Thanks
Well, security is not my field of expertise (or passion), but:
Make sure ADB works in recovery
Set ro.adb.secure=1 to enforce ADB authentication
Generate some ADB keys and make sure that you have a safe copy
Put the public key in /adb_keys
Make sure that it all works
In init.rc under the recovery service add "disabled"
Now you've got a recovery that shows as a blank screen. ADB is present but will only work on your authorized keys. If you have a need for the recovery menu just type start recovery in ADB.
Now, there may be a problem that people can get to recovery but it keeps on going back to recovery. That may depend on who/what is supposed to wipe the BCB or /misc. When testing you can start recovery and exit that way. You may need to have a script or something wipe the BCB or /misc.
While ro.adb.secure=1 is no security in the regular system, in recovery it should be a guarantee as there is no confirm dialog possible. But check.
Renate said:
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Click to expand...
Click to collapse
This is what I get:
imgutil.exe boot.img /v
Header2: 1,660 (0000067c)
Kernel: 11,291,051 (00ac49ab) 00000800
Ramdisk: 7,875,739 (00782c9b) 00ac5800 2022-11-09 17:08
DTB: 98,837 (00018215) 01248800
Signature: 1,600 (00000640) 01261000
Command: bootopt=64S3,32N2,64N2 buildvariant=user
Renate said:
Well, security is not my field of expertise (or passion), but:
Make sure ADB works in recovery
Set ro.adb.secure=1 to enforce ADB authentication
Generate some ADB keys and make sure that you have a safe copy
Put the public key in /adb_keys
Make sure that it all works
In init.rc under the recovery service add "disabled"
Now you've got a recovery that shows as a blank screen. ADB is present but will only work on your authorized keys. If you have a need for the recovery menu just type start recovery in ADB.
Now, there may be a problem that people can get to recovery but it keeps on going back to recovery. That may depend on who/what is supposed to wipe the BCB or /misc. When testing you can start recovery and exit that way. You may need to have a script or something wipe the BCB or /misc.
While ro.adb.secure=1 is no security in the regular system, in recovery it should be a guarantee as there is no confirm dialog possible. But check.
Click to expand...
Click to collapse
When I add disabled in the init.rc under recovery If the phone gets into recovery with adb it gets stucked a the boot logo.
Also I had some trouble creating the keys
Anyway I would like to say Thank you for all of your help
isach59 said:
When I add disabled in the init.rc under recovery If the phone gets into recovery with adb it gets stucked a the boot logo.
Click to expand...
Click to collapse
If you disable recovery the screen when it boots will be whatever. The important thing is if you have ADB running correctly. Moreover, if you get lonesome you only need to start recovery
isach59 said:
Also I had some trouble creating the keys
Click to expand...
Click to collapse
Recovery has a ramdisk. You need to add the adb_keys to that. If you're having trouble don't set ro.android.secure until you resolve it.
isach59 said:
Looking out for help
I need to edit the boot.img but my problem is that every time i unpack the img and repack it the phone doesnt boot anymore (even w/o modifyng the boot.img only unpacking and repacking) it enters into a bootloop
is this bcs the boot.img are signed ? or that theyre in a different fromat like ext4?
Im flashing the boot.img with SPFlash tools
I got the Custom Rom and the boot.img from this thread https://forum.xda-developers.com/t/...om-firmware-root-playstore-certified.4405615/
Click to expand...
Click to collapse
Hello and good morning, @isach59
Welcome to XDA. I hope you'll always get the support you require.
However, prior to your next posting please read the guidances that are stuck on top of every forum like
[ATTN] : Read before posting - Any questions posted here will be MOVED or CLOSED
Please read the below before posting. Any questions not development related will be moved or closed. Forum Searching | Posting | The Basics: (Make sure you've read them before starting a new thread) Forum Rules Forum Search Google Forum...
forum.xda-developers.com
and the others. I've moved your thread to Android Q&A.
Thanks for your cooperation!
Regards
Oswald Boelcke
Senior Moderator