yashsingh1/xdaforums huggingface dataset:
[Android Software Development] osm0sis:
AK2 pretty much = AIK, so sounds like something's amiss on your end somehow.

On most platforms (AIK-Linux and AIK-mobile) the tool needs root because the ramdisk is root:root, and sometimes, on OEMs boot.imgs, other user:groups that can't be preserved without using root to dump them with their actual UID:GID. On AIK-Linux you can opt out of this on the command-line with `unpackimg.sh --nosudo` which unpacks as current user then forces all to root:root on repack.

On Windows repack can only be done by forcing all to root:root (like --nosudo above) because of the platform limitations, but Windows Administrator privileges (i.e. "root") still must be used only if a user tries to unpack an img with .hidden/000 permissions properties which otherwise couldn't be accessed or traversed. So if you don't want it to ask on Windows, basically stop trying to unpack rooted boot.imgs.

You haven't really provided any information yet. Device? Platform you're using AIK on? Uploaded device img?
[Android Software Development] HassanMirza01:
ahh, sorry about that, am on Ubuntu 18.04.1 and device is Poco F1, Oreo 8.1, and i have all dependencies fulfilled, i downloaded latest AIK for linux, i think its 3.4, i used your previous version, the one which dont need root for a long time, but this one is not perfect one... i will try to upload boot.img if you still didn't understood the issue, this happens with every boot.img unpacked... the boot.img-zImage is archive when unpacked but its binary type file when built as kernel, so when i replace it, it became binary file instead of archive type....
[Android Software Development] osm0sis:
Just gzip or whatever your built kernel.
[Android Software Development] HassanMirza01:
there you go.. https://drive.google.com/open?id=1AEFlZghltywIO81fb8oUNDubLNX7oUCM
[Android Software Development] osm0sis:
No, from your descriptions that's what you needed to do to replace the Image.gz or Image.lz4 in your unpacked boot.img so that it'll boot. It might also need dtb added.
[Android Software Development] ashyx:
That's not an AIK issue.

Your device source code make file script should gzip the kernel as part of the build process.

If it doesn't then you will either have to add it to your make file or as [MENTION=4544860]osm0sis[/MENTION] pointed out gzip it manually before repacking.
[Android Software Development] HassanMirza01:
you means boot.img uses gzipped zImage format ?? i don't think so, its been an year now am working on kernels but may be Oreo's signed boot.img files are cause of it... actually Huawei's kernels were not an issue when replaced but oreo ones are... atleast for me... i just analyzed Makefile and it generate 3 output files, 1.) Image(the pure kernel) 2.) Image.gz(gzipped Image file), 3.) Image.gz-dtb i dont know about this -dtb file as i never able to unpack it with unzip, but when i used this file using anykernel's zip, it works and thats only way i get my kernel work...
[Android Software Development] osm0sis:
No, zImage gets the z from gzip. It's always used gzip. zImage was the output name on arm, now it's Image.gz on arm64. More recently some devices use lz4 instead of gzip, but from what you've said yours is gzip.

Your kernel build outputs those files because they're steps in the process to create the Image.gz-dtb needed for your device to boot. You seem to recognize that AK2 needs the Image.gz-dtb to produce a working image, so why would you think AIK is different? It's not, they're basically the same.

So when you unpack your device's boot.img, first remember to use `unpackimg.sh --nosudo` since it sounds like you're having issues with root on your Ubuntu box, next replace the -zImage file with your build's Image.gz-dtb (i.e. delete the unpacked -zImage file and copy then rename yours to "mybuild-zImage" or whatever, as long as it ends in -zImage), then repack and you'll have manually done what AK2 does.
[Android Software Development] HassanMirza01:
ahh, now its clear to me... thanks bro... so that zImage is in gzip and -dtb is also a gzip formatted, well, hope so all will work now...

good day :)
[Android Software Development] ashyx:
Just to be clear Image.gz-dtb is a gzipped kernel concatenated with the the dtb.

AIK doesn't split this dtb from from the kernel as its combined as one, so you won't see a separate dtb when unpacking the boot image.

As long as you swap like for like in AIK you should be good.
[Android Software Development] GreenVillage:
Error unpacking LG Optimus 3D GB 'U-Boot' type image

For LG Optimus 3D, using AIK v3.4, I unpacked successfully the ICS(4.0.4) original 'boot.img' (Image type: AOSP) but I get an error trying unpacking the GB(2.3.5) original 'boot.img' (Image type: U-Boot) and no files are produced.

I tried unpack other boot.img's of type U-Boot and also get an error.

Can someone help me to unpack the GB(2.3.5) 'boot.img' ?

----------

Results:

----------

Android Image Kitchen - UnpackImg Script

by osm0sis @ xda-developers

Supplied image: ICS_boot.img

Setting up work folders . . .

Image type: AOSP

Splitting image to "split_img/" . . .

BOARD_KERNEL_CMDLINE

BOARD_KERNEL_BASE 80000000

BOARD_NAME

BOARD_PAGE_SIZE 2048

BOARD_HASH_TYPE sha1

BOARD_KERNEL_OFFSET 00008000

BOARD_RAMDISK_OFFSET 01000000

BOARD_SECOND_OFFSET 00f00000

BOARD_TAGS_OFFSET 00000100

BOARD_HEADER_VERSION 0

Unpacking ramdisk to "ramdisk/" . . .

Compression used: gzip

5303 blocks

Done!

--------

Android Image Kitchen - UnpackImg Script

by osm0sis @ xda-developers

Supplied image: GB_boot.img

Removing old work folders and files . . .

Setting up work folders . . .

Image type: U-Boot

Splitting image to "split_img/" . . .

GP Header: Size 27051956 LoadAddr 6116d3f2

Error!

--------

note: I can't put a link yet to boot.img file but I can send it if required
[Android Software Development] ashyx:
As far as I can remember GB uses the YAFFS2 file system.

So you need an extractor such as unyaffs:

https://github.com/ehlers/unyaffs

I'm rusty on this stuff so you may need to do a bit more researching.

Here we go, just did a quick search to jog my memory. This should help.

http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
[Android Software Development] osm0sis:
Send me all the Android U-Boot images you've got that don't work, please. Only way I can fix it.

Ahah! Good to know! I wasn't aware of that, so I'll see about adding it. Thanks!
[Android Software Development] GreenVillage:
Here four different boot.img files that produce 'Error', all of U-Boot type, and one AOSP type that produce 'done'.

Two U-Boot are GB (2.3.5), two are JB (4.1.2) and last one, 'done', ICS (4.0.4).

All for LG Optimus 3D.

Thanks !

bit.ly/2rKFqb7
[Android Software Development] Invisan:
Hi [MENTION=4544860]osm0sis[/MENTION] i tried to unpack the boot.img of the Xiaomi Black Shark. Unfortunately i get the not recognized format error. I guess this is caused by the missing Android Magic in the boot.img

Could you have a look at it?

Files can be found in my google Drive Folder here.

Thanks in Advance and Merry Christmas.

Kind Regards,

Invi
[Android Software Development] osm0sis:
That's not a boot.img, that's a boot.img.p file meant to binary patch the existing partition (note the BSDIFF40 magic in the header).
[Android Software Development] Invisan:
Hi osm0sis,

thanks for the fast response. Hmm alright that changes everything.

Do you know of a way to convert the img.p to a normal boot.img?

Kind Regards,

Invi
[Android Software Development] osm0sis:
You have to apply it to the boot.img of the partition of the ROM version it was meant to patch. This can be done using the bspatch utility.

It's clearly from an incremental OTA, so you're probably better off applying the OTA after unrooting the boot partition, then dumping the result.
[Android Software Development] svbarbosa:
I have used AIK a lot to unpack/repack 32-bit kernels. Never had any problems.

Now I tried with a 64-bit pie kernel and can't figure out how to unpack/repack the Image.gz-dtb file.

Could not find anything clear searching the thread. Am I missing something?

Would someone point me in the right direction? No need to spoon-feed me, but any tip will be really appreciated. :)
[Android Software Development] ashyx:
You can't not with AIK at the moment. It's concatenated to the kernel image.

There is more than one way to obtain separate kernel and dtbs from the Image.gz-dtb, however the simplest and I find most reliable way is using Magiskboot to unpack and repack the boot.img.

I then use AIK to unpack make mods to the ramdisk and repack as normal.

Alternatively there are Linux tools, but it's a bit more faffing unpacking and repacking.
[Android Software Development] osm0sis:
Happy New Year!

Interestingly, there are a couple of things going on with these images, and none of it is yaffs2, thankfully(?). ;)

ICS_boot.img extracts fine because it's using the proper Android bootimg format. (Glad that LG eventually came to their senses and stopped using U-Boot at some point on this device. :silly:)

Looking at your other files, the first thing I noticed is that Blue_boot.img is exactly the same as the previous bluekernel image file I had been given to add U-Boot support, except the size is different because yours has a whole lot of extra stuff on the end, some of which appears to be a certificate or signature and then just a large amount of empty space.

CM10_boot.img and MIUIv5_boot.img both also have this exact same extra data, all 1461103 bytes of it. Removing that from the Blue_boot.img allows it to be recognized properly by the U-Boot dumpimage binary and unpack, but oddly CM10_boot.img and MIUIv5_boot.img still fail with it removed.

GB_boot.img does NOT have this extra certificate/signature data, but IS padded with empty space. Trimming off all but the first 00 (which is how my working bluekernel image also was), allowed that to unpack without issue. :good:

So it seems what we've come across is an ad-hoc signing method on top of the standard U-Boot dumpimage/mkimage format, which ostensibly breaks the unpacking since the official U-Boot dumpimage binary can't recognize it anymore. Also somewhat of a limitation in dumpimage that it can't tolerate even a single extra 00 byte beyond what the header reports the end of the file should be. :rolleyes:

I'm not yet entirely sure how the MIUIv5 and CM10 images need to be altered to allow them to unpack, but likely their sizes are still incorrect like the GB_boot.img and so dumpimage sees them as non-standard-conforming and refuses to unpack; some extra trimming beyond removing the certificate/signature should hopefully also allow them to unpack..

Honestly I'm not sure how to support this... I could try to detect and strip out the extra certificate/signature and add it back upon repack, of course pending figuring out what else needs to be chopped out of the CM10 and MIUIv5 images, but more important would be where the hell it all came from and why/how it's being added.. :eek::confused:

Edit

: The additional data only in the CM10 and MIUIv5 is another matching 671593 bytes, beyond the 1461103 matching between all three of the (possibly) signed images you sent. The MIUIv5 one also weirdly has another 4 bytes between the correct end of the file and the beginning of the 671593 bytes, which for some reason is the final 4 bytes of the correct ending repeated... Removing all of this then they are able to be unpacked.

The repeated bytes has me starting to wonder if these are just remnants of old images layered over top of one another since perhaps the partition wasn't zeroed before being flashed? If so, the proper solution is to take more care when you flash... :cyclops:

Point me to the actual ROMs these came from please so I can check out this theory.
[Android Software Development] GreenVillage:
Happy new year !

thank you osm0sis by your time looking for that.

Actually you are right :D there are garbage data from previous installations in each file that need to be removed.

All files were made by doing a dump of the entire boot partition, 10 MiB, after installing ROMs , without wipe the partition with all 0's.

The AOSP type 'by luck' worked, but all U-Boot failed because of that.

I repeated all steps you done, with the hex editor FlexHEX, identified the repeated data, removed/trimmed the files of all garbage data and I unpacked successfully all 4 U-Boot files.

Thanks you ! :good:
[Android Software Development] osm0sis:
Glad it worked! Obviously it's pretty weak of the U-Boot dumpimage binary to not be able to handle even additional 00 padding. I'll see if I can figure out how to patch it to be more forgiving and/or workaround it in AIK by trimming U-Boot images to the correct size before unpacking.

I'd also still like you to point me at the ROMs you got those from so I can have the original boot.img files from them for testing.
[Android Software Development] osm0sis:
This is the appropriate thread for your AIK questions, so I will answer you here.

If it's broken in MiXplorer then it's a bug in MiXplorer. I am using /system/bin/sh which is mksh and I am intentionally using a |& which is allowed in mksh. Report the bug to them, and tell them they shouldn't be using busybox ash to run scripts in their file explorer, they should be using the system shell.

I will not be adding those firmware binaries because they don't apply to boot images, only system images and that is not the purpose of AIK. What you're talking about already exists and it's called [MENTION=5787964]SuperR.[/MENTION]'s ROM Kitchen. Go have a read in his threads please, read the OP here so you understand what AIK is for, and please search before posting in the future.
[Android Software Development] osm0sis:
This is the appropriate thread for your AIK questions, so I will answer you here.

If it's broken in MiXplorer then it's likely a bug in MiXplorer. I am explicitly using /system/bin/sh in my shebang (#!), which is mksh, and I am intentionally using a |& which is allowed in mksh. Report the bug to them, and tell them they shouldn't be using busybox ash to run scripts in their file explorer, they should be using the system shell.

I will not be adding those firmware binaries because they don't apply to boot images, only system images and that is not the purpose of AIK. What you're talking about already exists and it's called [MENTION=5787964]SuperR.[/MENTION]'s ROM Kitchen (which in turn uses AIK for boot.img support). Go have a read in his threads please, read the OP here so you understand what AIK is for, and please search before posting in the future.
[Android Software Development] GreenVillage:
Yes, if you have in header the actual/expected size of file I think the workaround you refer to trim the file before unpacking will be the best option. Because often the only way we have to get a boot.img is dumping the entire partition.

So if you can create a boot.img file with the actual/correct size, this new correct file will be a good sub product that AIK will generate.

the roms each boot.img came are,

CM10 nightly:

drive.google.com/open?id=1tfOUR-YLcimCkp9PQKr-JifH6oMPAVc6

MIUI v5:

drive.google.com/open?id=13faIVyey-Lp6KoVETbHup2GtxNuV99Fz

xdaforums.com/showthread.php?t=2238052

Blue Kernel:

xdaforums.com/optimus-3d/development/aroma-official-criskelo-rom-3d-o3dp920-t3361580

The GB and ICS are the stock LG roms in kdz format flashed with LG tool.
[Android Software Development] osm0sis:
Perfect, so if you look in each of those zips you'll see boot.img in there. Those unpack without issue in AIK because they're following the format correctly. If I can't fix dumpimage myself, I'll report it to U-Boot and definitely add a workaround for dumps to trim to unpack correctly until they get around to it.

This works with all your dumps, for example:

bb=busybox;
trim_uboot() {
local size=$($bb printf '%d\n' 0x$($bb hexdump -n 4 -s 12 -e '16/1 "%02x""\n"' "$1"));
$bb dd bs=$((size + 64)) count=1 conv=notrunc if="$1" of="$1-trimmed.img";
}

The usual pain in the ass will be supporting it in Windows. :rolleyes:
[Android Software Development] osm0sis:
I've got support for trimming U-Boot dumps before unpacking added for AIK v3.5. :)

I have reported the dumpimage flaw to both the #u-boot channel on Freenode and the official U-Boot mailinglist: https://lists.denx.de/pipermail/u-boot/2019-January/355670.html

Hopefully it gets a little more attention than my last posts to the mailinglist.. :rolleyes:: https://lists.denx.de/pipermail/u-boot/2017-May/292495.html

Also, with the awesome help and testing of [MENTION=1813976]shakalaca[/MENTION], I've completed updating Intel's internal mboot.py script for all variants of the Intel OSIP/OSII "$OS$" header boot.img/recovery.img format from older Android x86 devices like the ASUS Zenfone, ASUS Transformer, Moto Razr, Dell v, and Lenovo K. So the next step will be for me to rewrite it in C for inclusion in AIK: https://xdaforums.com/showthread.php?p=78665916#post78665916

All previous tools for the Intel OS format have been closed-source, Windows-only and don't support all 3 variants signed/unsigned. :cowboy:
[Android Software Development] lehmancurtis:
I have been using this tool for quite some time now (I love the flexibility and simplicity of AIKA). I've been trying to port a twrp.img file and have used several different images during this endeavor, but have been unable to gain touch functionality. At this point every other function seems to be completely functional. For example, I used Root Essentials App to flash SuperSU via TWRP and the process has been smooth as silk. I am using a Qualcomm MSM8909 device and plan to compile from source (for just-in-case reasons), but would still like to know if, by using AIK, is it feasible to troubleshoot/add touchscreen functionality?
[Android Software Development] osm0sis:
That's a kernel driver thing presumably. So I imagine it's hard to just take another device's TWRP and make it work with a different chipset/board/hardware config. Not really what AIK is for, so good luck!
[Android Software Development] rejinarudo:
I have a HTC Desire 626s and when I use the tool to rebuild the boot image, all I get is a bootloop - even when rebuilding the stock boot image.
[Android Software Development] bovirus:
[MENTION=6762020]rejinarudo[/MENTION]

It's a complete non-sense QUOTE an enire post just to add onne line of your request.

Please edit your post and remove all text of QUOTE.
[Android Software Development] osm0sis:
So upload a log and the stock boot.img for me to look at? What platform are you using? Don't expect help while providing no useful information.

[MENTION=1162986]Captain_Throwback[/MENTION]'s latest TWRP build repacks identically with the --original switch: https://twrp.me/htc/htcdesire626s.html
[Android Software Development] rejinarudo:
It is a Qualcomm MSM8909 Snapdragon 210 chipset and there are no logs I am aware of.

I am using Windows 10 home x64.

I edited the default.prop to secure kernel 0 and debuggable 1 .

It repacks without any errors but when I flash it I get a bootloop.

I tried the --original switch and while it does boot it does not save the changes I made to default.prop

This is the stock boot image from the RUU. I am not allowed to post links so I put a space in between

https : // drive.google.com/open?id=1wiNgttztIV9eoAHdO56aRrCFI8N-PAwH

Also the closest thing I could find to a log a screenshot of the cmdline when I repack boot image.

https : // drive.google.com/open?id=1QLQlI_gPavsT0G0oRycgwOF7qoFWP_Il

Some more information

I have twrp 3.2.3-0.

I have S-Off and Super CID

The phone was originally a HTC Desire 625 from Cricket but I lost my backup and flashed it with a T-Mobile 626s RUU

since I read they were the same phone.

Also I do apologize for all the edits. It has been quite a long day.
[Android Software Development] osm0sis:
So by log I mean the output of AIK, and by platform I mean what system you're running AIK on. If it works with --original then at least we know it's not the extra chunk of data that's on the stock image. Must just be some issue with your system or editing the files. Try unpacking and repacking with no changes and see if it works.
[Android Software Development] rejinarudo:
I simply unpack stock boot image and repack boot image with no changes and flash it back and it causes a bootloop.

I am using the Windows version of AIK on Windows 10 home 64 bit.

This is the log when I unpack :

Supplied image: boot.img

Setting up work folders . . .

Image type: AOSP

Splitting image to "split_img/" . . .

BOARD_KERNEL_CMDLINE console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=400m androidboot.selinux=enforcing androidboot.hardware=htc_a32e androidusb.pid=0x0668

BOARD_KERNEL_BASE 80000000

BOARD_NAME boot:0

BOARD_PAGE_SIZE 2048

BOARD_HASH_TYPE sha1

BOARD_KERNEL_OFFSET 00008000

BOARD_RAMDISK_OFFSET 02000000

BOARD_SECOND_OFFSET 00f00000

BOARD_TAGS_OFFSET 01e00000

BOARD_DT_SIZE 731136

Unpacking ramdisk to "ramdisk/" . . .

Compression used: gzip

5659 blocks

Done!

Press any key to continue . . .

And here is the log when I repack:

Android Image Kitchen - RepackImg Script

by osm0sis @ xda-developers

Packing ramdisk . . .

Using compression: gzip

Getting build information . . .

kernel = boot.img-zImage

cmdline = console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=400m androidboot.selinux=enforcing androidboot.hardware=htc_a32e androidusb.pid=0x0668

board = boot:0

base = 80000000

pagesize = 2048

kernel_offset = 00008000

ramdisk_offset = 02000000

second_offset = 00f00000

tags_offset = 01e00000

hash = sha1

dtb = boot.img-dtb

Building image . . .

Using format: AOSP

Done!

Press any key to continue . . .