Hi
I've done a bit of searching but can't find anything too specific to what I'm trying to do. Basically we have 10 Android tablets, and I want to make them all standardised e.g. have the same Apps on, configured in the same way (e.g. enterprise wireless network added).
Now the thing is if anyone messes around with them I want a really easy way to restore them to the original config which I've done.
One way I thought was to configure one fully, install Titanium Backup on it, do a full backup of apps/system data etc, and put the backup onto an SD card. Then I already have the base ROM on an SD card so if theres any problems, I can just flash the ROM over it again, install TB, and restore all the data. Would this be suitable to do to duplicate the data onto 10 tablets, and also restore the data if required?
The other thing I looked into was customising a ROM myself, don't want to do anything too tricky it'll just be a case of removing all the preinstalled crap I don't want, preloading the Apps we do want, and if possible preloading the wireless key and getting rid of the first boot initial set up wizard.
PS I've looked at installing CWM and doing whole image backups, but supposedly the tablet isnt supported (its an Ainol Novo 7 Elf 2)
Any advice would be great, hopefully theres some fairly straight forward way of managing this
Thanks
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
kuisma said:
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
Click to expand...
Click to collapse
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
fro5tie said:
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
Click to expand...
Click to collapse
Ok, I see. Compile the image to you likings (boot image and system partition), and then flash it using fastboot onto you devices.
Hi
Does anyone have any more thoughts on this?
I have experimented with Titanium Backup and this seems to work quite well. I have installed a ROM, and customised it e.g. installed the apps I need and configured the apps, wireless settings and home screens etc. Then I do a full apps + system backup in TB to my SD card.
Then the plan is, I can reflash the ROM onto the other device, install TB and then restore this backup. This saves my user state and wireless settings etc.
Only problems is when I flash the ROM, I have to go through all the initial set up again and also remove some preinstalled apps which I dont want. Any ways around this?
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
kuisma said:
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
Click to expand...
Click to collapse
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
fro5tie said:
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
Click to expand...
Click to collapse
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
kuisma said:
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
Click to expand...
Click to collapse
Hi
Thanks for the quick reply, much appreciated.
Unfortunately you've lost me a bit here!
Yes the device is rooted, I dont have a linux machine though.
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
fro5tie said:
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
Click to expand...
Click to collapse
I can provide you specific answers to specific questions, but I have no experience of the tablet in question, so you'll have to do some digging yourself first. Make sure it supports fastboot, investigate what the proprietary bootloader is capable of, see how/if you can obtain an original image etc.
One maybe easier solution, especially if you plan to restore the tablets on a regular basis, is to only make a new boot image to reflash the devices with. The only modification done is that you change the /init.rc script to mount /data and /system from the SDcard instead of from the internal nand disk device.
Once this is done, you'll power up and run the installation wizard and everything on your master tablet. Then power it down, and clone the SDcard. This SDcard now contains everything, so you'll simply restore a device by replacing its SDcard with a copy of this master card. I guess it's easier to clone a SDcard than reflashing several internal partitions. Easier to make the master as well - you don't need to dd or tar them, they are already in "image" format. If you can get hold of the original firmware, this should be quite easy without the need to preserving data from the device itself.
fro5tie said:
Any chance you'd be able to provide some more specific instructions?
Click to expand...
Click to collapse
Issue the commands "cat /proc/mtd" and "mount" on your device at command prompt (e.g. via "adb shell" or the "ConnectBot" terminal app). This shows you if the device allows you to copy the boot image from it. Paste in the output into this thread. If you believe the "clone the tablet via the SDcard" is a good solution for you, the process is in short terms something as below;
Copy the boot image to the sdcard:
# dd if=/dev/mtd/mtd2ro of=/mnt/sdcard/boot.img bs=2048 (device dependent of contents of /proc/mtd)
Remove the sdcard, insert into a computer, split the boot image info kernel + initramfs. Read http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images for instructions about how to work with the boot.img file. I really recommend a GNU/Linux environment for this.
Then edit /init.rc replacing the "mount yaffs2 [email protected] /system" with "mount ext3 /dev/block/mmcblk0p2 /system" for system and data (use p3 for data partition, the device name may be different on your tablet, see mount output).
Create an SDcard with three partitions: #1 vfat (standard), #2 and #3 ext3. Insert into you device and boot it up again.
# mount -t ext3 /dev/block/mmcblk0p2 /root
# cd /system
# tar cf - . | (cd /root ; tar xf - )
# umount /root
# mount -t ext3 /dev/block/mmcblk0p3 /root
# cd /data
# tar cf - . | (cd /root ; tar xf - )
# umount /root
This copies your partitions to the SDcard. Shutdown the tablet again.
Make a new boot.img using the instructions in the link above, using the edited init.rc script.
Now you can non-destrutive give this a try.
Place you tablet in fastboot mode (often vol-up (or vol-down) during power on).
$ fastboot devices
This vill verify the tablet is in fastboot mode. It should be listed. Then:
$ fastboot boot boot.img
Note here, only BOOT the tablet, do NOT use the "flash" keyword. This in case of the image isn't working, you'll just have to restart you tablet, and no harm's done.
Look around. Do a "mount" command. Everything works? Mount shows /data and /system from sdcard? Perfect. Now you can reflash it. Shutdown and flash:
$ fastboot flash boot boot.img
Now the device will use /data and /system from the SDcard every time. Customize your device, and then clone your SDcard and try it in tablet #2 you'll booting with your new boot.img and the cloned SDcard. Verify that #tablet #2 is a perfect clone of tablet #1. It is? Now you can flash the boot,img into all your tablets.
--------------------
But don't forget, there may be other solutions as well, maybe more suitable. This you'll have to investigate yourself.
And the usual disclaimer - you can probably not follow above by the letter. There sure is some obstacle you'll have to overcome, something non-standard, etc.
Also keep the original boot.img file for safekeeping in the case you want to restore the device's boot image some day.
Wow! Thanks for the info! This is really helpful, I need to set aside a bit of time to work through this and have a look. Thanks again its really appreciated, I'll be back with info once I've had chance to give it a go!
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
tweeny80 said:
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
Click to expand...
Click to collapse
Hi
Yes that was my first thought as well, tablets are rooted yes but there is no CWM for the tablet. Its an obscure Chinese branded tablet.
Unless there is another way to do nandroid backups?
hmm tricky situation. Catch 22 ! From what I know, your best bet is to backup all possible things through Titanium Backup given that you don't have the use of Nandroid backups. You can include wifi settings, messages etc but it's modular & not systemic.
I did a quick google search with no luck - time to upgrade your fleet dude :-0
Best of luck.
Hi everyone and Happy New Year,
I am trying to open ROM_0 file created with SP Flash tool. I have tried ROM explorer 0.9.1, I have tried various option converting with simg2img and opening with 7zip but nothing has worked so far.
The file is about 100GB and it is a SP Flash tool backup of my userdata on which I have a lot of images which i need to save.
I was using Dot OS 5.2 general image and a message popped up about trying Android 12 and I have clicked on it just to get rid of it but I assume it has triggered a download. My phone crashed yesterday evening when I started the cmera app and once restarted it was in a boot loop mode stuck on the dot os logo.
So far I have tried various options unsuccessful - I have reflashed the image which I originally flashed, I have set the partitions active - a and b and reverted to the initial active one which was "a".
I have also flashed system.img (with the treble general image) but still it is in a boot loop mode.
I have just decided to flash back the super.img image from the stock and guess what - still stuck.
Flashed the stock boot.img again thinking there might be an issue with the kernel but that didn't help.
I understand that it is the case of fully flashing back the stock ROM which will lock the bootloader and delete all my userdata in order to have the phone back.
However the phone IS NOT important, the ONLY IMPORTANT thing are the images in the userdata.
I have created the backup of it straight after the boot loop appeared. Tried to read here on XDA but it is not clear what format is that file and how I can access the data on it.
Looked for a recovery partition but there is none. Potentially hidden as you can get into stock recovery via fastbootd. But the options there are only to wipe the partitions/reset.
The phone is Umidigi Bison Pro and I have been having all but troubles with it.
Any help greatly appreciated it.
Regards
s80_gad said:
Hi everyone and Happy New Year,
I am trying to open ROM_0 file created with SP Flash tool. I have tried ROM explorer 0.9.1, I have tried various option converting with simg2img and opening with 7zip but nothing has worked so far.
The file is about 100GB and it is a SP Flash tool backup of my userdata on which I have a lot of images which i need to save.
I was using Dot OS 5.2 general image and a message popped up about trying Android 12 and I have clicked on it just to get rid of it but I assume it has triggered a download. My phone crashed yesterday evening when I started the cmera app and once restarted it was in a boot loop mode stuck on the dot os logo.
So far I have tried various options unsuccessful - I have reflashed the image which I originally flashed, I have set the partitions active - a and b and reverted to the initial active one which was "a".
I have also flashed system.img (with the treble general image) but still it is in a boot loop mode.
I have just decided to flash back the super.img image from the stock and guess what - still stuck.
Flashed the stock boot.img again thinking there might be an issue with the kernel but that didn't help.
I understand that it is the case of fully flashing back the stock ROM which will lock the bootloader and delete all my userdata in order to have the phone back.
However the phone IS NOT important, the ONLY IMPORTANT thing are the images in the userdata.
I have created the backup of it straight after the boot loop appeared. Tried to read here on XDA but it is not clear what format is that file and how I can access the data on it.
Looked for a recovery partition but there is none. Potentially hidden as you can get into stock recovery via fastbootd. But the options there are only to wipe the partitions/reset.
The phone is Umidigi Bison Pro and I have been having all but troubles with it.
Any help greatly appreciated it.
Regards
Click to expand...
Click to collapse
May I'm wrong, but I guess that if you didn't give it an extension then the file doesn't have a format; when you make a backup of a partition using SP Flash tool you should give it an extension, for example userdata_backup.img will work, in some devices, for some partition the .bin extension is used.
And to restore the device to a working state without losing data you could flash the stock ROM unchecking the userdata partition and using Download only option won't re-lock your bootloader.
If actually your userdata was not overwritten you still can try a second attempt to preserve it using mtk-client, search for it in GitHub, also consider what I stated about re-flash your original ROM preserving the userdata partition.
Thanks SubwayChamp, I appreciate your comment.
I have tried .img, .bin, ext4 etc but cannot open it - I am not sure if there is another application that can convert it in a readable format or maybe if we can mount it and access the files.
I had the impression that if you flash the stock rom the bootloader is locked and you loose everything.
But thanks for your advice - I will flash everything apart from the userdata partition which is last in the order anyway. Should I select or deselect the preloader partition- will that make a difference?
Regards
Just flashed the full stock rom without the userdata partition - still stuck on the logo in a boot loop . I really need to open the userdata backup file from SP flash tool as I feel I have to do a full reset/wipe.
Any other suggestions about explorer for the sp flash dump file, please?
Regards
s80_gad said:
Just flashed the full stock rom without the userdata partition - still stuck on the logo in a boot loop . I really need to open the userdata backup file from SP flash tool as I feel I have to do a full reset/wipe.
Any other suggestions about explorer for the sp flash dump file, please?
Regards
Click to expand...
Click to collapse
No, I didn't say to change the extension now and try it in various format, unfortunately I feel that if you didn't give you the extension at the time to make a backup then the file is unreadable, what I mean is that when you make the dump through SP Flash tool you have to give to the file a name and an extension, not letting it as is offered by SP Flash tool, for example you did see the name ROM_0 or similar, but you have to give it a name and an extension, in this case userdata_backup.img would work.
Did you check mtk-client?, you can read (dump) the userdata partition through this CLI tool, and after that you can restore it at any time.
Using the download option (only) you never re-lock your bootloader.
But wait a minute, keep in mind that your device is A/b, so you have to double-try all the things, for example, if you want to flash a specific partition like boot you have to be sure in which partition you are right now BUT unfortunately you don't know which partition is the working one, so better use fastboot to flash the missed partition, target to both slots.
And what about the option to get to a custom recovery? (I guess you had it previously to flash CR Droid) either taking a backup of userdata or re-flashing the same CR Droid that was functional previously.
Thanks SubwayChamp for your reply.
So I will try to dump the userdata again then - I still haven't touched it so I hope the partition and the data on it is fine.
I assume it is that mtkclient you are referring to. Will see if I can get some time today to try the live cd first as I am on Windows at this moment.
So my device is indeed A/B - the system is on "a" and I have flashed dot os using fastbootd and overwriting the system.img within the super.img. It worked fine for about 20 days until that crash (I only assume it is due to the update - nothing else has happened that could create trouble).
Also tried to set the b partition active but didn't help so switched back to "a".
Unfortunately there is no recovery partition, from what I learned the recovery is within the boot img. I have tried to load temporary unofficial twrp - fastboot boot twrp.img - and the first step is ok, but then it crashes. so no luck to load custom recovery even temporary in order to save the userdata on sdcard.
Tried to get to the contents trough adb shell but while some directories are listed, I get access denied to the userdata - I think maybe the links are broken?
I will try with the mtk to see if I can back it up - and what I'll do is I'll flash the full stock rom including the userdata and potentially will try to flash the old userdata through fastboot or sp flash or mtk.
TBH I don't understand why the phone is still in a bootloop - can't be only because I haven't cleared the userdata?
Regards
s80_gad said:
Thanks SubwayChamp for your reply.
So I will try to dump the userdata again then - I still haven't touched it so I hope the partition and the data on it is fine.
I assume it is that mtkclient you are referring to. Will see if I can get some time today to try the live cd first as I am on Windows at this moment.
Click to expand...
Click to collapse
It works on Windows though.
s80_gad said:
So my device is indeed A/B - the system is on "a" and I have flashed dot os using fastbootd and overwriting the system.img within the super.img. It worked fine for about 20 days until that crash (I only assume it is due to the update - nothing else has happened that could create trouble).
Click to expand...
Click to collapse
The issue was originated due to the lack of the other system files that also occupy this space; vendor, odm, product (may vary depending on the device), can be fixed flashing the super.img using fastbootd again.
s80_gad said:
Also tried to set the b partition active but didn't help so switched back to "a".
Unfortunately there is no recovery partition, from what I learned the recovery is within the boot img. I have tried to load temporary unofficial twrp - fastboot boot twrp.img - and the first step is ok, but then it crashes. so no luck to load custom recovery even temporary in order to save the userdata on sdcard.
Click to expand...
Click to collapse
Yes, this device doesn't have a dedicated recovery partition, but it is placed in a tiny portion of the boot image (usually the ramdisk) you can try by flashing the TWRP image onto the boot partition (flashing, not booting only) then boot to it, do the stuff you need through TWRP, from there you could solve the bootloop. To can boot to Android again you should need to flash a boot image.
s80_gad said:
Tried to get to the contents trough adb shell but while some directories are listed, I get access denied to the userdata - I think maybe the links are broken?
Click to expand...
Click to collapse
No, it's encrypted.
s80_gad said:
I will try with the mtk to see if I can back it up - and what I'll do is I'll flash the full stock rom including the userdata and potentially will try to flash the old userdata through fastboot or sp flash or mtk.
TBH I don't understand why the phone is still in a bootloop - can't be only because I haven't cleared the userdata?
Regards
Click to expand...
Click to collapse
When you flashed a system image onto the super partition the other partitions that are set dynamically didn't find a place to be recreated or couldn't play its role, added to this, a different system image that which is contained in the super image can differ in sizes either logical and/or dynamical (virtual sized).
SubwayChamp said:
The issue was originated due to the lack of the other system files that also occupy this space; vendor, odm, product (may vary depending on the device), can be fixed flashing the super.img using fastbootd again.
Click to expand...
Click to collapse
Flashed already the original stock rom super. img and everything else apart from userdata - it doesn't work.
see below
{
"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"
}
SubwayChamp said:
Yes, this device doesn't have a dedicated recovery partition, but it is placed in a tiny portion of the boot image (usually the ramdisk) you can try by flashing the TWRP image onto the boot partition (flashing, not booting only) then boot to it, do the stuff you need through TWRP, from there you could solve the bootloop. To can boot to Android again you should need to flash a boot image.
Click to expand...
Click to collapse
Tried to flash it - it just restarts the phone straight away - in fact replaced it with sp flash tool as well which recognises only the "a" partition and flashes it there.
SubwayChamp said:
No, it's encrypted.
Click to expand...
Click to collapse
I see
SubwayChamp said:
When you flashed a system image onto the super partition the other partitions that are set dynamically didn't find a place to be recreated or couldn't play its role, added to this, a different system image that which is contained in the super image can differ in sizes either logical and/or dynamical (virtual sized).
Click to expand...
Click to collapse
I am guessing this is why I have to reflash the whole rom incl userdata in order to make the phone usable.
What I'll do is I'll try to dump userdata with mtk and then will reflash everything with the stock rom ()hopefully the phone will boot) and then will flash the dumped userdata with mtk. Hopefully that will work.
I'll see if I can somehow mount the mtk .bin file to see if I can get to the contents of it
Will have to use the live dvd as I have win 7 and python 3.9 cannot run on win 7.
EDIT: Can't start anything through the live dvd - is there any workaround for win 7 or is there a direct executable file which I can get to start the mtkclient?
Regards
Hello,
I also have an Umidigi Bison Pro that I am going to use as a daily driver. (It's a pity that it's unpopular it would be a great device for modding, it's cheap, rugged and has source code availability of the official ROM and kernel). I created a Telegram group about this phone if you want to join is https://t.me/UmidigiBisonPro
About your problem you can read this guide (it describes how to backup and extract from the file created by SP Flash Tool even the partitions that not visible such as the b slots) https://www.hovatek.com/forum/thread-21970.html
To give you an idea on my Bison Pro a total of 52 partitions were extracted.
If you have the full backup from before the bootloop (before the upgrade, when it was still working) my advice is to restore all partitions.
I consider myself a novice regarding modding but it is likely that after the upgrade the userdata partition is no longer readable.
I have read that you should not update the GSI ROMs but repeat the whole flash sequence.
I also recommend removing the forced encryption of the userdata partition (you can do this when rooting) to avoid exactly these problems where you have the partition backup but not the decryption key.
s80_gad said:
Flashed already the original stock rom super. img and everything else apart from userdata - it doesn't work.
see below
View attachment 5499133
Tried to flash it - it just restarts the phone straight away - in fact replaced it with sp flash tool as well which recognises only the "a" partition and flashes it there.
I see
I am guessing this is why I have to reflash the whole rom incl userdata in order to make the phone usable.
What I'll do is I'll try to dump userdata with mtk and then will reflash everything with the stock rom ()hopefully the phone will boot) and then will flash the dumped userdata with mtk. Hopefully that will work.
I'll see if I can somehow mount the mtk .bin file to see if I can get to the contents of it
Will have to use the live dvd as I have win 7 and python 3.9 cannot run on win 7.
EDIT: Can't start anything through the live dvd - is there any workaround for win 7 or is there a direct executable file which I can get to start the mtkclient?
Regards
Click to expand...
Click to collapse
Sorry for delay, I didn't receive any notification on this (or I didn't notice it), I hope you sorted out your issue, if not, let me know.
SubwayChamp said:
Sorry for delay, I didn't receive any notification on this (or I didn't notice it), I hope you sorted out your issue, if not, let me know.
Click to expand...
Click to collapse
I didn't received notification too on your message and I found out on profile account that the notification for new message on a thread are default disabled.
I recently had some problems and experimented with partitions.
Reducing the possible cases I think the decryption key for the userdata partition might be in these partitions: super , misc , nvdata , nvcfg , md_udc
and I noticed that if one of them is corrupted/different version the dm-verity check fails (in my case it is written on the screen) and it was necessary to reflash all partitions except userdata (I don't know if there is a faster combination, from the few tests done in this case I didn't find any)
Do you have more information about where the decryption key might be between those partitions?
I have made a brief description of the role of all the partitions encountered but I still don't know some of them:
boot_para
gz_a (/ gz_b)
md_udc
otp
spmfw_a (/ spmfw_b)
sspm_a (/ sspm_b)
teksunhw_a (/ teksunhw_b)
Werve said:
I didn't received notification too on your message and I found out on profile account that the notification for new message on a thread are default disabled.
I recently had some problems and experimented with partitions.
Reducing the possible cases I think the decryption key for the userdata partition might be in these partitions: super , misc , nvdata , nvcfg , md_udc
and I noticed that if one of them is corrupted/different version the dm-verity check fails (in my case it is written on the screen) and it was necessary to reflash all partitions except userdata (I don't know if there is a faster combination, from the few tests done in this case I didn't find any)
Do you have more information about where the decryption key might be between those partitions?
I have made a brief description of the role of all the partitions encountered but I still don't know some of them:
boot_para
gz_a (/ gz_b)
md_udc
otp
spmfw_a (/ spmfw_b)
sspm_a (/ sspm_b)
teksunhw_a (/ teksunhw_b)
Click to expand...
Click to collapse
Why do you think userdata has a decryption key? Unless the user set it in a backup done through a custom recovery or through the device itself, I don't think so, may I'm wrong, but which is your scenario?
SubwayChamp said:
Why do you think userdata has a decryption key? Unless the user set it in a backup done through a custom recovery or through the device itself, I don't think so, may I'm wrong, but which is your scenario?
Click to expand...
Click to collapse
Since the userdata partition is now usually encrypted either with FBE or FDE but once the system loads the files are readable and moveable even externally then it is clear that somehow the data has been decrypted precisely using the relevant decryption key, AES encryption usually.
So if the user has not specified any key this must be derived from the information already in the partitions from the factory.
Then by restoring the right combination of partitions the system can boot correctly by decrypting the userdata partition. Hence the tests and the report I wrote in my last post.
At the moment I was able to remove the forced encryption of the userdata partition by modifying super (specifically fstab present in the /vendor sub partition) but I would like to achieve the same systemless modification using Magisk (to be OTA compatible). Unfortunately, the options to remove dm-verity and forceencrypt have been hidden in the latest versions of Magisk to avoid problems with inexperienced uses.
Since I don't have a custom recovery on the Umidigi Bison Pro I can't force flag those options in the .magisk file so I have to find another way.
Werve said:
Since the userdata partition is now usually encrypted either with FBE or FDE but once the system loads the files are readable and moveable even externally then it is clear that somehow the data has been decrypted precisely using the relevant decryption key, AES encryption usually.
So if the user has not specified any key this must be derived from the information already in the partitions from the factory.
Then by restoring the right combination of partitions the system can boot correctly by decrypting the userdata partition. Hence the tests and the report I wrote in my last post.
At the moment I was able to remove the forced encryption of the userdata partition by modifying syper (specifically fstab present in the /vendor sub partition) but I would like to achieve the same systemless modification using Magisk (to be OTA compatible). Unfortunately, the options to remove dm-verity and forceencrypt have been hidden in the latest versions of Magisk to avoid problems with inexperienced uses.
Since I don't have a custom recovery on the Umidigi Bison Pro I can't force flag those options in the .magisk file so I have to find another way
Click to expand...
Click to collapse
Well, what I said is a different thing, the other user had a different interest than this. They did want to access to some data from a backup in a non-booting device, I referred to that, the userdata image backed up doesn't have an encryption by default, unless the user set one through a custom recovery, suppose that someone did take a backup from the userdata partition, this userdata image can be opened/readable for anyone with minimum skills and the appropriate tool.
In regard to your issue, I don't think, the userdata partition has any kind of restrictions to take OTA updates, most likely this resides in the bootloader, kernel or even a "silent/hidden" partition with no more functions than that.
As a side note, you should check some custom recoveries, specially in Xiaomi devices that easily allow taking OTA updates, for example I always can take OTA, when I use Orange Fox recovery, although I'm not interested, so I make updates manually, to be sure that all run fine.
SubwayChamp said:
Well, what I said is a different thing, the other user had a different interest than this. They did want to access to some data from a backup in a non-booting device, I referred to that, the userdata image backed up doesn't have an encryption by default, unless the user set one through a custom recovery, suppose that someone did take a backup from the userdata partition, this userdata image can be opened/readable for anyone with minimum skills and the appropriate tool.
In regard to your issue, I don't think, the userdata partition has any kind of restrictions to take OTA updates, most likely this resides in the bootloader, kernel or even a "silent/hidden" partition with no more functions than that.
As a side note, you should check some custom recoveries, specially in Xiaomi devices that easily allow taking OTA updates, for example I always can take OTA, when I use Orange Fox recovery, although I'm not interested, so I make updates manually, to be sure that all run fine.
Click to expand...
Click to collapse
The methodology I was referring to that is not OTA supported is to modify the super partition (the dynamic partition that from Android 8? contains system, vendor, product--for Project Treble) to disable the forced encryption of the userdata partition. In my case FBE (File Based Encryption) Android 11 encryption.
Even having disabled the dm-verity if you apply an OTA update the super partition is replaced with the one that does not have the modification to remove the forced encryption and from the tests I have done this refuses to read unencrypted partitions and asks to do a factory reset.
So, the userdata partition makes the OTA update problematic (it doesn't block it, but you lose your personal data).
I am sure that instead of modifying the super partition to disable encryption you can achieve the same result via Magisk and a modified boot partition.
Unfortunately despite many trials due to my inexperience with Magisk I could not do it.
I wanted to do all this to avoid problems as described in the case of this thread that is, have the userdata partition intact but not the rest to be able to describe it. But seems I must let the encryption and do a backup after every OTA update.
Werve said:
The methodology I was referring to that is not OTA supported is to modify the super partition (the dynamic partition that from Android 8? contains system, vendor, product--for Project Treble) to disable the forced encryption of the userdata partition. In my case FBE (File Based Encryption) Android 11 encryption.
Even having disabled the dm-verity if you apply an OTA update the super partition is replaced with the one that does not have the modification to remove the forced encryption and from the tests I have done this refuses to read unencrypted partitions and asks to do a factory reset.
So, the userdata partition makes the OTA update problematic (it doesn't block it, but you lose your personal data).
I am sure that instead of modifying the super partition to disable encryption you can achieve the same result via Magisk and a modified boot partition.
Unfortunately despite many trials due to my inexperience with Magisk I could not do it.
I wanted to do all this to avoid problems as described in the case of this thread that is, have the userdata partition intact but not the rest to be able to describe it. But seems I must let the encryption and do a backup after every OTA update.
Click to expand...
Click to collapse
If you want to apply an OEM vendor stock update then it is a restriction from the OEM itself, and if you want to apply a GSI based update, it's a different approach, not sure if the restriction is FBE related or if the userdata is encrypted or not but probably related to AVB.
There are some tools/scripts you should search for, that can unpack and repack super partition, maybe you find something in the ODM or product image, this is assuming that the super partition it is the culprit.
Just know that it's a nonsense that an order (script) to restore a specific partition, be placed just there, but in other partition.
You should check what the OTA update contains, try to catch the OTA update through some ADB script, then unpack it, and see inside.
Also, you can try backing up every partition, and restoring them one by one, seeing if it boots.
SubwayChamp said:
If you want to apply an OEM vendor stock update then it is a restriction from the OEM itself, and if you want to apply a GSI based update, it's a different approach, not sure if the restriction is FBE related or if the userdata is encrypted or not but probably related to AVB.
There are some tools/scripts you should search for, that can unpack and repack super partition, maybe you find something in the ODM or product image, this is assuming that the super partition it is the culprit.
Just know that it's a nonsense that an order (script) to restore a specific partition, be placed just there, but in other partition.
You should check what the OTA update contains, try to catch the OTA update through some ADB script, then unpack it, and see inside.
Also, you can try backing up every partition, and restoring them one by one, seeing if it boots.
Click to expand...
Click to collapse
I have already done these tests, not with an OTA update but with a different version of the firmware for all partitions, and set out the conclusions.
Obviously it's an OEM restriction since it left the forced FBE encryption on and the way it was created (so I guess also from AOSP) it refuses to read the userdata partition if it doesn't find it encrypted.