This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
edit the android img file before flashing
#1
Was wondering if I could edit the image file before flashing as the title of the post suggests.
Have managed to find three ext4 sparse partitions with testdisk in linux which I can browse the files inside, I could also extract those partitions with the offsets provided by testdisk, but that are not all there is in the file and without a partition table it is hard to find these parts.
Was wondering if I could find some sort of partition table to extract them, or the files to merge them by my self if possible.
Reply
#2
You should understand how to mount an image on a linux system.
fdisk will help you to find the offset for the partition, inside the image. Maybe my writeup will give some figure.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#3
(03-09-2019, 12:53 AM)Im4Tinker Wrote: You should understand how to mount an image on a linux system.
fdisk will help you to find the offset for the partition, inside the image. Maybe my writeup will give some figure.

I do not think you understood the original post.
There is no partition table, fdisk and parted will not find the partitions without a partition table.
And this post is not about the Linaro image as it has proper partition table, it is about the Android image, which does not have a valid partition table in proper location for the above mentioned programs to work.
Reply
#4
(03-09-2019, 08:00 AM)ngiannakas Wrote: I do not think you understood the original post.
There is no partition table, fdisk and parted will not find the partitions without a partition table.
And this post is not about the Linaro image as it has proper partition table, it is about the Android image, which does not have a valid partition table in proper location for the above mentioned programs to work.
Yes ,  it's like that. And specially on Rockchip devices you have a probitary partion table in form of parameters.txt. You can see here how to find the right offsets for partitions: https://tinkerboarding.co.uk/forum/threa...ml#pid8632
But I don't know how to use this information to mount them in linux.
Reply
#5
(03-09-2019, 08:00 AM)ngiannakas Wrote: There is no partition table, fdisk and parted will not find the partitions without a partition table.
Sorry, I assumed there was a simple image file, but Google prefers some complications.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#6
Indeed searched the img file for all strings and grepped for CMDLINE which returned the internal partition but seems comparing output with testdisk there is an 8192 blocks (4MiB) offset.

so far after tinkering around on the board managed to
sudo mount -o loop,offset=381681664 -t ext4 20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img /mnt/android-system
now on to the recovery
Reply
#7
The 4 Mb offset is usually left to set the u-boot allocation.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#8
(03-10-2019, 11:50 AM)ngiannakas Wrote: so far after tinkering around on the board managed to
sudo mount -o loop,offset=381681664 -t ext4 20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img /mnt/android-system
now on to the recovery

How did you come up with this number ?. What is the offset and size for kernel.img and boot.img ?
I wish ASUS would also provide an update.img which is easier to unpack and modify.

Vasant
Reply
#9
(03-10-2019, 09:03 PM)Vasant1234 Wrote: How did you come up with this number ?. What is the offset and size for kernel.img and boot.img ?
I wish ASUS would also provide an update.img which is easier to unpack and modify.

Vasant

I used TestDisk linux console application which I scanned the file for lost partitions with "None" partition table.

Code:
Disk 20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img - 2650 MB / 2528 MiB - CHS 323 255 63
     Partition               Start        End    Size in sectors
>P ext4                    46 102 57   307 124  9    4194304 [system]

then using the formula (C x TH x TS) + (H x TS) + (S - 1) we can find the LBA address within the file.
Where 
C is current cylinder
H is current head
S is current sector
TH is total heads
TS is total sectors

Now comparing with the output of:
Code:
strings 20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img | grep 'CMDLINE'
which should provide the kernel command line early on and you can use ctrl+c to stop it after you get it.

we find the system size and location in sectors HEX and we convert to DEC

from 0x00400000@0x000B4000(system) to 4194304@737280 

we see that the size in sectors is the same both in testdisk and in the cmdline but the location is different by 8192 blocks (each sectors being 512bytes when counting byte offsets)
if we take that offset into account we can try get the boot.img

from 0x00010000@0x0001C000(boot) to 65536@114688 + 8192 (122880 with offset)



Code:
$ dd count=65536 skip=122880 bs=512 ibs=512 if=20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img of=boot.img
$ file boot.img
boot.img: Android bootimg, kernel (0x60408000), ramdisk (0x62000000), second stage (0x60f00000), page size: 16384, cmdline (buildvariant=userdebug)

after you edit the file with abootimg or magisk you can put it back like

Code:
dd count=65536 seek=122880 bs=512 obs=512 conv=notrunc if=patched_boot.img of=20190103-tinker-board-android-nougat-userdebug-v14.2.2.73.img

also did a zeroing of the area before sending it by replacing the input file with /dev/zero just to make sure there is nothing else on the write area but it is optional and can do without doing this
Reply
#10
Thanks for your detailed information. I have never used TestDisk, seems like a nice tool for this purpose. I will give it a try.

Vasant
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)