Database Info

How to flash the G1

WARNING: Following these instructions may brick your phone, void your warranty and kill your dog. You don't want your dog to die do you?
Once I got root access on my G1, I've been messing around with trying to build reflash the recovery partition. That project is still in progress, but I have learned a bit about how to flash the various partitions on the G1.
First things first, you have to have root access. See this thread.
There are 6 mtd devices or partitions on the G1, mtd0-mtd5. They are located at /dev/mtd. You can use the /system/bin/flash_image tool to flash an image to any of these.
The syntax for the flash_image tool is:
Code:
# flash_image
usage: flash_image partition file.img
#
You can see a list of partition names and which device they are associated with by doing a "cat /proc/mtd".
Code:
#cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
#
These should all be self explanatory, except maybe "misc", which just appears to have a few string values.. Not really sure what it's used for..
Before you do any erasing or writing, it's a "really good idea" (tm) to make backups of each of these. Even if you don't plan on writing to them. I had accidentally erased the bootloader partition (typed mtd0 instead of mtd1), which I'm fairly sure would have bricked my phone if I had tried to reboot it. Ugh! Luckily, I had created a backup earlier, so I was able to restore it. (And then was nervous as heck when I tried to reboot it... "Please boot up! Please boot up!")
To create the backups:
Code:
# cat /dev/mtd/mtd0 > /sdcard/mtd0.img
# cat /dev/mtd/mtd1 > /sdcard/mtd1.img
# cat /dev/mtd/mtd2 > /sdcard/mtd2.img
# cat /dev/mtd/mtd3 > /sdcard/mtd3.img
# cat /dev/mtd/mtd4 > /sdcard/mtd4.img
# cat /dev/mtd/mtd5 > /sdcard/mtd4.img
#
Now you can use flash_image to write the new image.
Code:
#flash_image recovery /system/recovery.img
#
And that's how it's done.
Update: You normally don't need to erase the flash before you write, as long as you don't corrupt the flash first, by trying to "cat" an image directly to the mtd device, like I did . If you get a lot of ECC errors when you use flash_image then you need to erase it
Code:
# cat /dev/zero > /dev/mtd/mtd1
write: No space left on device
#
On a related note, Based on my experience so far, the recovery partition is not critical to booting the G1. When I first tried this, I used flash_image to write a new image without erasing the partition first, and it corrupted it pretty good. When I tried to boot the G1 into recovery mode (power+home), it would go to the bootloader screen instead. But it would boot into normal mode just fine.
Additionally, I've verified that the device will boot into recovery mode if you screw up the boot partition (mtd2). So as long as you at least have a good recovery image *or* a good boot image, you should be able to get back in business. Just don't try to update both at the same time.
Even so.. be careful, and don't come crying to me when you brick your phone. Or if your dog dies. You don't want your dog to die do you?

Excellent work!
So if misc is the boot loader, it looks like it is roughly 266k. If you can dump it, have you tried to "open" the image and see if you can see files?
Now you have given me more ideas

readonly sdcard?
When I run: cat /dev/mtd/mtd1 > /sdcard/mtd1.img
I got this:
cannot create /sdcard/mtd1.img: read-only file system
I know I am root...

staulkor said:
So if misc is the boot loader, it looks like it is roughly 266k. If you can dump it, have you tried to "open" the image and see if you can see files?
Click to expand...
Click to collapse
Actually, now that I look at it.. I'm not positive that mtd0 is the bootloader. There's not much data there at all. Just a few strings in the beginning, then lots of nothing. Mostly all FFs, with a few blocks of 00s thrown in. It doesn't look like there's any code at all, so it can't be the bootloader.

Nice work. How about the signing? Does the image you flash have to be correctly signed this way?

blues said:
When I run: cat /dev/mtd/mtd1 > /sdcard/mtd1.img
I got this:
cannot create /sdcard/mtd1.img: read-only file system
I know I am root...
Click to expand...
Click to collapse
Do you have the sdcard mounted for USB access? If so, just unplug the usb cable and plug it back in. (don't select "mount" in the usb notification thingy that pops up)

Chainfire said:
Nice work. How about the signing? Does the image you flash have to be correctly signed this way?
Click to expand...
Click to collapse
Nope. This is a raw write directly to the flash device. The whole signing thing is only applicable to the OTA updates (or Update.zip style update).
But the other project I'm working on is to rebuild the recovery mode and disable the signature check for OTA/update.zip updates.

If you check out the SDK and build the open-source version for the phone, it builds a custom recovery-image that accepts only things signed with the testkeys - which is cool. Since the test keys are in the directory, you can easily resign the images yourself.
I know a guy who has done this now. I'll do it when I get a chance.
There are two proprietary files that you have to suck off the device in addition to the ones that the "extract_files" script in the android build pulls off - I sent in a patch to fix this but who knows if they'll apply it or not (I thnk they think that the crap in the msm7k dir will do something)
What I'm wondering is if we can write an update mode that will backup the contents of the /cache and /data to the SDCard - then erase the three partitions - then recreate /data as a huge partition and leave only 10 or 15 megs for /cache - because... well.. /cache is worthless since OTA updates aren't gonna happen to our phones anymore anyway. It would be nice to get an extra 40 megs for app storage.

JesusFreke said:
Actually, now that I look at it.. I'm not positive that mtd0 is the bootloader. There's not much data there at all. Just a few strings in the beginning, then lots of nothing. Mostly all FFs, with a few blocks of 00s thrown in. It doesn't look like there's any code at all, so it can't be the bootloader.
Click to expand...
Click to collapse
I just looked at my dumped mtd0.img and I see a few interesting strings:
T-MOB010
DeviceWarmBoot
CE Serial InUse
Debug Cable Ena
CE USB InUse
ClearAutoImage
And then a mountain of FFs, lol

You are right. I am on XP machine. So I disabled the usb storage, and it works fine
JesusFreke said:
Nope. This is a raw write directly to the flash device. The whole signing thing is only applicable to the OTA updates (or Update.zip style update).
But the other project I'm working on is to rebuild the recovery mode and disable the signature check for OTA/update.zip updates.
Click to expand...
Click to collapse
It works for me now.

RyeBrye said:
If you check out the SDK and build the open-source version for the phone, it builds a custom recovery-image that accepts only things signed with the testkeys - which is cool. Since the test keys are in the directory, you can easily resign the images yourself.
Click to expand...
Click to collapse
Yep, that's exactly what I'm doing. I'm planning on posting a recovery.img for others to use, since trying to build the thing from scratch is a pain, and takes forever.
RyeBrye said:
There are two proprietary files that you have to suck off the device in addition to the ones that the "extract_files" script in the android build pulls off - I sent in a patch to fix this but who knows if they'll apply it or not (I thnk they think that the crap in the msm7k dir will do something)
Click to expand...
Click to collapse
I assume you're talking about libaudio.so and librpc.so?
RyeBrye said:
What I'm wondering is if we can write an update mode that will backup the contents of the /cache and /data to the SDCard - then erase the three partitions - then recreate /data as a huge partition and leave only 10 or 15 megs for /cache - because... well.. /cache is worthless since OTA updates aren't gonna happen to our phones anymore anyway. It would be nice to get an extra 40 megs for app storage.
Click to expand...
Click to collapse
Good idea. Even better would be if we could put the installed apps and all data on the sdcard.. But that would probably be a harder modification than just resizing the partitions.

staulkor said:
I just looked at my dumped mtd0.img and I see a few interesting strings:
T-MOB010
DeviceWarmBoot
CE Serial InUse
Debug Cable Ena
CE USB InUse
ClearAutoImage
And then a mountain of FFs, lol
Click to expand...
Click to collapse
that partition is the config partition, standard HTC stuff.
T-MOB010 is your CID (carrier ID, spl checks this when flashing NBH), but it is only a backup copy of it, the real CID is in radio part of nand (protected!).
and the rest is just config stuff for SPL and radio. (yes HTC uses strings to set these configs - SPL reads the strings from specific nand addresses and decides what to do)

JesusFreke said:
On a related note, Based on my experience so far, the recovery partition is not critical to booting the G1. When I first tried this, I used flash_image to write a new image without erasing the partition first, and it corrupted it pretty good. When I tried to boot the G1 into recovery mode (power+home), it would go to the bootloader screen instead. But it would boot into normal mode just fine.
Click to expand...
Click to collapse
very nice stuff! have you been able to reflash a recovery.img then to fix the corruption?
and you are right about the boot order... it's : radio bootloader -> SPL (that tricolour screen is SPL mode) -> boot.img or recovery.img.
(if boot.img then the OS loads)

cmonex said:
very nice stuff! have you been able to reflash a recovery.img then to fix the corruption?
Click to expand...
Click to collapse
Yep. I screwed up the recovery partition and rebooted, and wasn't able to boot into recovery mode. It just went into SPL mode when I tried. Then I normal booted and re-flashed with the original recovery.img and rebooted, and was able to boot into recovery mode.
Thanks for the info on the boot order. I didn't realize the radio image was used for booting, I figured it was just firmware for the 3G chip or something.
I'm getting close to being able to apply my own update.zip style update. I've been able to reflash the recovery partition with a custom built recovery image that skips the signature verification. I'm having a touch of trouble getting it to actually install an update.zip though. It keeps saying "update script not found", even though there is a "META-INF/com/google/android/update-script" file in the zip. Arg! Anyways.. I'm in the process of tracking the issue down. More to come!

cmonex said:
that partition is the config partition, standard HTC stuff.
T-MOB010 is your CID (carrier ID, spl checks this when flashing NBH), but it is only a backup copy of it, the real CID is in radio part of nand (protected!).
and the rest is just config stuff for SPL and radio. (yes HTC uses strings to set these configs - SPL reads the strings from specific nand addresses and decides what to do)
Click to expand...
Click to collapse
Ah! Excellent info.

I was finally able to get the rebuilt recovery tool to work. The problem with the update.zip was due to the fact that the zip was built in windows, so it had the wrong path separators. It was looking for META-INF/com/google/android/update-script, but the zip file contained META-INF\com\google\android\update-script
After switching the slashes around in a hex editor, it installed the update no problem.
Next, I was tempted to try to flash the boot partition. I was somewhat sure that I would be able to recover from a bad boot flash, with my nifty new recovery tool. But after reading about the guy that bricked his phone (over in the root thread), I was a bit scared.
But I finally went ahead and decided to give it a try. You only live once, right?
So I opened up a root console, and just wiped the boot partition clean. "cat /dev/zero > /dev/mtd/mtd2" and rebooted. Palms sweaty.. breathing hard.. shaking.. Powered the phone on (without holding down home), and it comes up to the recovery tool. So far so good. Then I ran the update on the sdcard - it was a smallish update I had created before hand that just flashed the original boot image back to mtd2. Update runs fine.. phone reboots....
And it boots up normally.
yes!
*takes a big sigh of relief*
So now I can mess around with the boot partition, and know that I have that recovery tool safety net.
And now. It's time to sleep. *head hits the keyboard*

very cinematic good job mate!

Very nice work

Congrats on the successful flash!

strings in mda1.img include:
Code:
ANDROID!
no_console_suspend=1
-- System halted
ran out of input data
Malloc error
Memory error
Out of memory
incomplete literal tree
incomplete distance tree
bad gzip magic numbers
internal error, invalid method
Input is encrypted
Multi part input
Input has invalid flags
invalid compressed format (err=1)
invalid compressed format (err=2)
out of memory
invalid compressed format (other)
crc error
length error
Uncompressing Linux...
done, booting the kernel.
What are these images? Are they filesystem images that you could theoretically mount? If so, what filesystem (I haven't gotten anything to work).

[Q] Flashing stock via fastboot error message

Hi, I want to (re-)flash the stock 4.1.2 rom on my Photon Q, because I recently run into some problems of the phone sending messages to the number 8737 even after I had removed the stock sms app.
This should be the right rsd file:
Code:
asanti_c_sprint-user-4.1.2-9.8.2Q-122_XT897_FFW-5-6-release-keys-cid9.xml.zip (MD5: 88f43a03d313bbcc262db78f15ac957c)
I'm on linux and I don't have any Windows system I could install and run RSDLite on. So I decided to take the fastboot way: I unzipped the above file and tried flashing the rom manually. But I always run in to the following error output:
Code:
# fastboot flash cdrom cdrom
(bootloader) Variable not supported!
target reported max download size of 31457280 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 22923264 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:143: write_all_blocks: Assertion `pad >= 0' failed.
Note that "fastboot devices" lists the Photon Q as "T069503UAP fastboot". The same or a similar error messages applies to "fastboot flash system system.img" etc. I use fastboot from the Fedora 20 "android-tools" package (version 20130123git98d0789-2).
Any ideas what's the problem here? Solution?
Thanks in advance!

It's dangerous to try and fastboot the items yourself. Would be better to borrow a Windows PC or something to use RSD (virtual machines are also NOT recommended for this).
But perhaps you should just try to fastboot the other partitions. Not sure 'cdrom' is needed. Either way, I strongly, STRONGLY advise against doing what you are doing.

Okay, thanks for your advice!
The same or similar error messages appear when flashing the other partitions (as already mentioned in the first post). Unfortunately, it's really hard to find somebody with a Windows system, at the moment. I thought RSDLite uses fastboot internally anyway.

I'm not sure if the FXZ images can be flashed as they are, via fastboot.
I believe they should be converted to the standard ext4 format via the simg2img.py pytoon script, before being usable.
I repeat I'm not sure, but I believe that hardly motorola's own format is handled correctly by the fastboot command.
Whatever, for your convenience, I attach the mentioned converter script.
Aside fastboot, can be used for a variety of other purposes, the ext4 images can be mounted straight in Linux via loopback device or extracted in windows with a bunch of tools, personally I use Ftk Imager.

Thanks, that tool is great! After conversion, I was indeed able to mount the system partition as follows:
Code:
# mount -o ro,loop system_converted.img /some/mnt/path
But it doesn't help with the other files (cdrom, boot.img, recovery.img), because they seem to have a different format. However, the system partition was all I wanted. Now, instead of reflashing, I'm going to compare the system partition's files (especially in the "app" folder) and see what might have caused my problem.

tuxor1337 said:
But it doesn't help with the other files (cdrom, boot.img, recovery.img),
Click to expand...
Click to collapse
The boot, recovery and similar partitions aren't written on top of a filesystem like /system or /data.
they are written as they are on top of the physical media.
you can safely flash them in any way: fastboot, restore by recovery and so on.
unlike the filesystem based partitions, they are always in the same format.
If you need to edit the boot or recovery content you need a special script to unpack and repack them, many android kitchens have it

I was just wondering whether flashing on Linux will work when using "moto fastboot" like this one: http://forum.xda-developers.com/showthread.php?t=1138092
I don't really need this functionality anymore. But out of curiosity: What do you think?

My photon has a broken USB connector, so I can't test it in first person.
Btw, I believe that testing is the only way to understand what is flashable and what not, obviously taking handy a good full nandroid backup.

Need to flash a TWRP backup with fastboot

Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks

eReader Fan said:
Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks
Click to expand...
Click to collapse
You would probably have better luck flashing the stock firmware or have someone with the same device create an adb backup then restore it via adb.
Or if you know which individual .img files you need, have them pull a copy of whichever individual .img files you need(for example: system, boot, etc) then fastboot flash them or use adb shell to dd the .imgs back onto your device in the partitions they belong in.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?

eReader Fan said:
@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?
Click to expand...
Click to collapse
Is USB debugging enabled?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Yes, debuggind mode is on. In PTP mode, adb sees my device correctly, in MTP mode appears like ???????

I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!

eReader Fan said:
I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!
Click to expand...
Click to collapse
This command in adb shell or Terminal Emulator should give you your partitions and names(obviously you'd type "su" then press enter then run this command)
ls -l /dev/block/platform/msm_sdcc.1/by-name/
The part with "msm.sdcc.1" might be different for your device. If that command doesn't work I'll help you find what needs to go in that part of the command for your device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

su is not found inside the adb shell, and I found this is cause is not rooted. I have to do it through TWRP in android 6.
As I said, I have two devices of my model so I hope I find time tomorrow for doing it. I also hope to can flashing it to the other device in fastboot mode or some way it doesn't need the main screen (remember I have a LCD screen and a eInk)
I will say something when I do the root. Thanks

Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?

eReader Fan said:
Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?
Click to expand...
Click to collapse
adb shell should work to dd, you just need to make absolutely certain that you are dd-ing the correct .img to the correct partition(mmcblk0xx), the partition number would go where the xx is.
For example, my recovery.img would be flashed to mmcblk018(the number of my recovery partition.
If you dd an .img to the wrong partition, you'll brick the device, the command has to be exactly correct, no margin for error or easy fix if you get it wrong.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

I know all this stuff, but first I need to make the .img of each partition, and I though with adb shell I could do a dd to outside the phone. The TWRP backup I have isn't .img files, they are .win files.
I searched again if its possible to do that and all I found is the xda thread about doing a workaround with adb forward and busybox. If there is no more options I will do that.
What I thought to do is create a backup of the needed partitions and save them in the userdata free space. I think this have to be possible, but as I cannot use the LCD screen I have to do the backup where I do not have to pass thorugh the first boot configuration, cause it is did in the LCD screen. Which partitions have I to backup? Only system and boot? Or there is another tool for creating .img backups?
EDIT: Also found the twrp adb possibilities (http://www.pocketables.com/2014/10/using-twrps-new-adb-interface.html) but have the same problems than with dd

I frequently modify boot and recovery partitions from within terminal app. Here's what I do to grab the boot partition for example(you likely want BusyBox installed first)
cat /dev/block/bootdevice/by-name/boot >boot.img
or
dd if=/dev/block/bootdevice/by-name/boot of=boot.img
Make changes, then reverse the commands to write back. I think cat gives you a more verbatim copy for initially cloning a partition. I have had success with both.
The question that brought me here is what happens if i flash all partitions from a firmware archive and attempt to upgrade a whole system this way from twrp recovery.....

Need help pulling boot and recovery images.

I have a device that has not been officially released yet so no images are available. I am trying to pull the boot and recovery images from the device so I can root and build twrp for it. That way when it is officially released it will be available. From there I would like to build a custom ROM or GSI.
I have read a lot of information and cannot seam to locate the correct location of the boot or recovery images. I have a prerooted GSI so I have root access to pull the images. The GSI with root has problems on my device. I have found a working GSI but I need my boot image to root it.
If someone could help me out pulling the boot and recovery images I would be greatly appreciative. I mostly figure out a lot of things on my own by searching and trying. I just cannot seam to figure this one out. Location of the images is the biggest problem.

Well, the boot and recovery partitions aren't mounted when Android is actually running.
The location of both the recovery.img and the boot.img is partition-layout dependent: possible partiton layouts are MTD ( read: Memory Technology Device ), EMMC ( read: Embedded Multimedia Card ) and MMC ( read: Multimedia Card ).

jwoegerbauer said:
Well, the boot and recovery partitions aren't mounted when Android is actually running.
The location of both the recovery.img and the boot.img is partition-layout dependent: possible partiton layouts are MTD ( read: Memory Technology Device ), EMMC ( read: Embedded Multimedia Card ) and MMC ( read: Multimedia Card ).
Click to expand...
Click to collapse
Thanks for your reply. I believe I have read about payload dumpers that can do this? I have not been able to figure it out though. What would be the easiest way to pull them?

Can anyone explain how to go about this?

Never have occupied with payload ...
FYI:
A phone's NAND-flash chip is parted into physical blocks what are called block devices: hence you have to find out the name of the block device where recovery and/or boot is located. Take note these names ( e.g. /dev/block/XXX ) are different on phones.
Once you got the names, and IF PHONE IS ROOTED, and phone's internal memory got mounted as RW, then you can extract these to your computer utilizing ADB commands:
Code:
adb devices
adb exec-out "dd if=/dev/block/<BOOT> of=C:\COPY-of-BOOT.img bs=4096"

jwoegerbauer said:
Never have occupied with payload ...
FYI:
A phone's NAND-flash chip is parted into physical blocks what are called block devices: hence you have to find out the name of the block device where recovery and/or boot is located. Take note these names ( e.g. /dev/block/XXX ) are different on phones.
Once you got the names, and IF PHONE IS ROOTED, and phone's internal memory got mounted as RW, then you can extract these to your computer utilizing ADB commands:
Code:
adb devices
adb exec-out "dd if=/dev/block/<BOOT> of=C:\COPY-of-BOOT.img bs=4096"
[/cod
[/QUOTE]
Click to expand...
Click to collapse
jwoegerbauer said:
Never have occupied with payload ...
FYI:
A phone's NAND-flash chip is parted into physical blocks what are called block devices: hence you have to find out the name of the block device where recovery and/or boot is located. Take note these names ( e.g. /dev/block/XXX ) are different on phones.
Once you got the names, and IF PHONE IS ROOTED, and phone's internal memory got mounted as RW, then you can extract these to your computer utilizing ADB commands:
Code:
adb devices
adb exec-out "dd if=/dev/block/<BOOT> of=C:\COPY-of-BOOT.img bs=4096"
Click to expand...
Click to collapse
Awesome thank you. When I installed a roasted gsi I seen them. I just did not know which one was recovery and which was the boot img. If I reinstall the rooted gsi and take a screenshot of the directory can you help me with the proper commands to copy them? This is just above my knowledge. Once I get them I can figure out how to use them.

Look also inside here:
[Guide] Dumping boot.img & recovery.img using dd (for complicated partitions)
Hi there! i am new to forums as well as in developing. i have recently taken interest in making cyanogenmod for my device. So, i have been searching web for hours to dump boot.img and recovery.img for my device. As my device is a mediatek device...
forum.xda-developers.com

jwoegerbauer said:
Look also inside here:
[Guide] Dumping boot.img & recovery.img using dd (for complicated partitions)
Hi there! i am new to forums as well as in developing. i have recently taken interest in making cyanogenmod for my device. So, i have been searching web for hours to dump boot.img and recovery.img for my device. As my device is a mediatek device...
forum.xda-developers.com
Click to expand...
Click to collapse
Thank you for all your help. I will give this a try and see if I can figure it out. I appreciate you taking the time to show me and help me.

[SOLVED] Help to mount userdata in linux or repair userdata.img

After an Update of Two magisk modules, my Ulefone Armor 11 5G staied stucked on boot logo, I can only enter in recovery or fastboot.
I try to build a TWRP, but it is not able to mount userdata.
I was able to download with the help of mtkclient all the partition on my phone, even userdata , it took 7 hours.
I wanted to load the image in linux but using mount disk imag or using the command sudo mount -o loop userdata.img ~/Armor_11_5G doesn't do anything not even an error message.
I'm wondering if the filesystem was corrupted during the update.
Is it possible to repair the fylesystem like in Windows?
Thanks

did you previously disable encryption and factory reset long time before the modules updates failed?
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.

I didn't disable encryption before updating the modules, I already updated this modules many times.
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.
Click to expand...
Click to collapse
That is the problem, it doesn't succed and I don't have an error message. The file is 256 Gbyte big, I don't know if it plays a role. I'm using Ubuntu 22

if phone is encrypted that's just 256G garbage. post the output of
Code:
$ parted <file> unit B print

Here are the results of parted
Code:
Error: /home/*****/Public/userdata.bin.img: unrecognised disk label
Model: (file)
Disk /home/osboxes/Public/userdata.bin.img: 249208733696B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Thanks

You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.

sorry thought it's whole disk, but it's only 232G file therefore parted won't print partition table
does apply to FDE only
assuming this file is dump of single userdata partition, open with HxD editor. if the partition image is not encrypted, you will see lot zeros within first 1024 bytes.
in that case you can check for file system type is ext4 or f2fs.
Code:
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
But most likely the userdata partition is encrypted, therefore no way to recover data offline.
The easiest way not to load Magisk modules is, not to load Magisk. Flashing stock boot.img will solve it.
Beware, in case you disabled encryption beforehand, booting stock boot.img will force encryption. This may take long time without notice.

I never disabled encryption, I don't know if Magisk do it without informing. I used this phone for an year without a problem.
After the update I left the phone on for one night but nothing happens. I tried to reflash the stock boot image, and again a whole night wait, but again nothing happens.
Reading the fstab the file system should be ext4.
The file is the dump of the whole userdata partition of my Ulefone Armor 11 5G.
I did a backup of the whole system before doing any experiment so if the partition table is corrupted maybe if I reflash back the userdata partition with a working partition table I have again access to the datas.

there is no partition table in userdata partition, I just gave you wrong advise. because the phones total storage is 256G, I made wrong assumptions (you can view partition table from file pgpt.bin)
full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
fstab doesn't tell you what file you just have dumped. if you can't find ext4 super magic (#7) it's impossible to loop mount that file (and impossible to decrypt on linux PC)
if you can't fix boot-loop by stock boot.img then it's unrelated to magisk modules. you can however enable adb in default.prop and capture adb logcat during boot-loop for further analysis. you could also inject own script that deletes some files (only DE encrypted files, CE encrypted files requires lock screen credentials aka pin/pattern)

boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html

full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
Click to expand...
Click to collapse
With mtk client I was able to do the backup of tee1 and tee2 and also of gpt_backup and gpt_main.
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
Click to expand...
Click to collapse
Doesn't produce any results.
I have immediately the command prompt.
you can however enable adb in default.prop
Click to expand...
Click to collapse
How can I do that? Which value should I change in default.prop?

so your "backup" is encrypted. please note Trustonic Kinibi is TEE OS running in secure memory one can't access or backup with mtkclient. the tee partitions in phone storage do not contain any encryption key (none of the partitions does, secure memory is not even a partition). the only crypto related partition is metadata used for keydirectory of metadata encryption (on top of FBE encryption) but it is useless for backup purposes.
yes you can modify default.prop in boot.img, ro.secure=0 should give root access.
https://forum.xda-developers.com/t/...hone-with-broken-screen.2965462/post-85905033
Code:
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
in case the default.prop modification is not sufficient, you need additional command to be executed as root.
Code:
# settings put global adb_enabled 1
as you installed magisk, you could use magisk overlay.d/sbin/ for running startup script.
https://forum.xda-developers.com/t/...ithout-losing-your-data.4383255/post-86934375
aIecxs said:
boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html
Click to expand...
Click to collapse
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log

Until tomorrow I cannot do a logcat and I cannot find my view logcat on my laptop.
I unpacked boot.img with Carliv Image Kitchen and there is no default.prop, that is present in the recovery as prop.default.
Is there a way to backup secure memory of Trustonic?
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log
Click to expand...
Click to collapse
I already tried that version but it cannot decrypt, that' why I'm trying to build my own version of TWRp with the help of the creator of that version of TWRP, but I'm stucked.

oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
regarding default.prop in boot.img (it's a symlink to system unfortunately) you can do it the other way
use magisk overlay.d/sbin/
create a boot script that does the thing with resetprop -n <prop_name> <prop_value>
don't use outdated Carliv Image Kitchen! use osm0sis AIK from link above.

oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
Click to expand...
Click to collapse
I'm learning.
I try to integrate the decryption service following the suggestion of ADeadTrouser on Github, but the service doesn't want to start and I don't understand why.
I never checked Oppo, I will take a look at them also, thanks for the suggestion.

I think I figured out now the adb logcat at least. hope that helps
https://forum.xda-developers.com/t/accessing-my-phone-with-a-dead-screen.4542763/post-88016019

I tried your script butr nothing happens, the telephone is not listed when I type
Code:
adb devices
and if I type
Code:
adb logcat
I receive the message waiting for device

you might follow the thread

wenyendev said:
You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.
Click to expand...
Click to collapse
I run the software on the image and it identify the contents and can read the encrypted and not encrypted part, that means that all the files are there, but I cannot mount in Linux or in TWRP

The fact that I cannot mount in Linux or TWRP the userdata image/partition can be that is corrupted the partition or the file index?
That would also explain why the script for Magisk provided by aIecxs is not able to copy the adb_key from the cache in the data partition.