yashsingh1/xdaforums huggingface dataset:
[HTC One SV] :
I'm confident it will work. In the README.md you see me unpack a stock recovery. That particular recovery had custom offsets so far off the charts that when I was assisting the guy in building TWRP for his device it would ALWAYS give failing results in the values. That is why I have spent the past three days or so non stop trying to crack the formula for these offsets. Even better, when you go to rebuild using the same script it will apply those offsets to insure the image is built properly. Has been confirmed even with that insane recovery I demonstrated with lol. The biggest issue I noticed with the closed source was that it did not notify the user of any non standard base addresses. So I made sure to include that info in the script since the base address is extremely important.
[HTC One SV] bigsupersquid:
boot.img is my thunderc boot.img, lzma compressed cpio I believe.

streakboot.img is the nasty.

I have tried several times now but get this:
[HTC One SV] :
Send me the image. Looks like the script didn't play nice on your phone.

Edit: Also, make sure you place the bash binary to /system/xbin so the script will work. Binaries are compiled for ARM devices so you are aware. After looking at what you posted, it is definitely clear that the script didn't work on your device. Those errors aren't due to the image but the language being applied and how it was being applied on your device.
[HTC One SV] :
Send me a download link and I will run a test on my end and report back.
[HTC One SV] bigsupersquid:
I did put bash in /system/xbin, chmod 755.

and also ran the script with 'bash mkboot' as well as './mkboot' with the same results.

my boot.img:

commandline

mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10

base 0x12200000

I can dig up other parameters for mine if you need them.

the streakboot.img, I can get commandline and base from source (it's in config)

but nothing more. abootimg, like I said, cleanly splits the kernel and ramdisk as far as I can tell, the rd is readable. but the re-assembled img, unbootable.

info on the streak:

http://xdaforums.com/showthread.php?t=768721
[HTC One SV] bigsupersquid:
works fine on my evo.

throws a minor hissy run without su but everything is still in the output directory.

Now to see if the recombined img will boot on that silly streak.

Not sure why it works on Evo not Optimus V but probably something with the armv6-tweaked source code. Both running 4.4.4
[HTC One SV] :
Ah, ARMv6... Yea, could definitely see that being the case lol. Make sure you run the script after you run su in the terminal to prevent any complaints. This way you can insure the script runs like it should and doesn't provide any false feedback.

With that said, when you go to repack your boot.img it will compress the ramdisk as gzip but as you already know it was originally lzma. If your kernel supports gzip compression (which it should since it is standard) then it won't be an issue. When I get off of work I will add to the script to make it compress the ramdisk to the same compression it initially was.
[HTC One SV] bigsupersquid:
.gz not compressed enough to fit lil bitty boot partition thus lzma.

That isn't currently an issue, have full control of thunderc from source.

Is the streak that has been giving me flak.

thanks for the assistance.
[HTC One SV] :
https://github.com/ModdingMyMind/mkbootimg_tools/commit/dafc83f0afdc308b09662cd608ceae5e9be07870

It will now compress the ramdisk based on the original compression of the original ramdisk. If gzip then it will compress the new as gzip and so forth.
[HTC One SV] :
https://github.com/ModdingMyMind/mkbootimg_tools/commit/35ccef5bc8c581fa8db3b4c64e1e1ba36019c4e5
[HTC One SV] :
OP has been updated to reflect a new mkbootimg toolset. See post #2 for more information and a link to it's source.
[HTC One SV] fivefour:
Thanks for putting this together.

One note about compiling bm with c4droid, for some reason the c static library is missing from the latest c4droid installation. You must manually place the necessary libc.a in ”/data/data/com.n0n3m4.droidc/files/gcc/lib/gcc/arm-linux-androideabi/4.9.1/libc.a" for linking to occur.

I noticed you also use c4droid is why I mention it.
[HTC One SV] :
Yup, I use it lol. I was aware about libc.a. There has been many changes to c4droid I have recently made in order for it to compile properly like it would if using a computer. Other than those manual changes, the app works really well and I am very impressed with the dev who has put it together. I especially appreciate how the app uses a terminal which is my preferred method. As of recent I have leaned more on using my computer lately. By the way, I have to take a look at bm with regards to dtb. It was recently brought to my attention that the dtb binary is found corrupted when extracted from the image. The header for a dtb is "QCDT" and should be found at 0x0 but this hasn't been the case. However, if you check post two you will find that I have forked a project from xiaolu and heavily modified it. That project will get the job done properly and effectively. The project most certainly supercedes bm by far. It even supports Mediatek SoC images as well.

Thanks for your input :)
[HTC One SV] TheNathranielB:
Thanks a Million

Thanks man for this tutorial. After running through some problems,I finally did it. You helped me doing some boot.img stuffs. In return you shall deserve a thanks button. :good::good:
[HTC One SV] pcprice76:
hi, i'm at

root@android:/data/local/tmp/ramdisk # gunzip -c ../ramdisk.cpio.gz | cpio -i

and i get "invalid magic"

I'm in /data/local/tmp/ramdisk folder :(
[HTC One SV] AlphaSoft:
getting the same error::

Gunzip: Invalid magic
[HTC One SV] bigsupersquid:
Might be lzma instead of cpio zipped.
[HTC One SV] :
https://github.com/ModdingMyMind/mkbootimg_tools

Refer to this repo on my github. Unpacking and repacking is done so through a shell script and calling on needed binaries when required. Original work is from xialou but I made it compatible for ARM devices as well. Even further, I did a massive makeover to the script. It will unpack the kernel (dtb is supported), and the ramdisk. Then it will determine the compression type of that ramdisk and decompress it appropriately. Should it's compression type not be supported then the script will let you know what type of compression file it is and that it currently is not supported. This project will also let you know if your boot.img or recovery.img uses unusual offsets then the original vanilla mkbootimg binary seen in the Google source. Try it out. It's rather useful and versatile.

---------- Post added at 05:26 AM ---------- Previous post was at 05:13 AM ----------

See post #2 for more detailed information :)
[HTC One SV] PiggyFlooper:
[MENTION=6367467]Modding.MyMind[/MENTION] I thought you were missing in action

Should bash be symlinked to sh?
[HTC One SV] :
Up to you. However, I would just place the binary in /system/xbin so the mkboot script can take it from there.
[HTC One SV] AlphaSoft:
Tried it already but it shows unknown extension something like that....
[HTC One SV] bigsupersquid:
http://xdaforums.com/showthread.php?t=2670512 ?
[HTC One SV] :
Send me your boot.img/recovery.img. Let me look at it and verify. Post a download link for me. Thanks.

Also, check post #2 of this thread. The first post points directly to dealing with ramdisk compressed by gzip. Post two is a completely different toolset that goes above and beyond most mkboot tools found on xda. For starters, most mkboot tools will only work on images where the ANDROID header is at the start of the image. The tool set in post #2 is designed otherwise and it doesnt use unpackbootimg or unmkbootimg. It handles itself with the mkboot shell script.

---------- Post added at 01:53 PM ---------- Previous post was at 01:31 PM ----------

The toolset found in post #2 currently supports gzip, lzma, lz4, and xz off the top of my head. It will also let you know the true offsets so if you choose to do so you may modify the standard mkbootimg.c file with those true offsets and build it giving you a mkbootimg binary that is specific to your device. Of course, this is assuming the image uses any non standard offsets.
[HTC One SV] AlphaSoft:
Here is the link to my TWRP image http://www.mediafire.com/download/zt2a3392a9e420p/recovery_TWRP_MMX_A177.img
[HTC One SV] :
The ramdisk is gzip compressed. See picture in the attachment. You are doing some wrong on your end. Your current issue is simply user error. Make sure you follow and understand the instructions. Also, this image is based on MediaTek. Which is built differently than most images. You will need to refer to post #2 if you wish to properly unpack and repack this image due to it's uniqueness.
[HTC One SV] AlphaSoft:
I successfully unpacked the image but I can't unpack ramdisk.cpio.gz...

That's the problem I'm facing.....
[HTC One SV] :
The reason why is because MediaTek images use a special header in the compressed ramdisk. They are either gzip or lz4. But a header which is not android standard whatsoever is placed ahead of the ramdisk itself. So, unless that header is removed then the compression file cannot be read properly. Both the boot and recovery use the same header on their images for mediatek devices. The difference is the string found in their headers. The recovery ramdisk will show the string "recovery" and the boot ramdisk will show the string "boot". Each comes with a bunch of added bytes if you view the ramdisk with a hex editor. My project in the second post supports these images. Some mediatek images also come with an embedded logo image as well which the logo currently is not supported at the moment. But if you have no intentions on messing with the logo image then that won't be a concern for you. My script will remove those bytes in the ramdisk and then unpack the ramdisk properly. When the script rebuilds the ramdisk it will compress it appropriately and then re-add those bytes.
[HTC One SV] AlphaSoft:
OK what command shall be used by me to repack the recovery image ....

./mkboot? ?

If yes , then can I flash it after repacking??

---------- Post added at 07:20 PM ---------- Previous post was at 07:17 PM ----------

Forgot to mention it worked for me... Now repacking........
[HTC One SV] :
Sounds like you got it figured out. But for others to know, you call the script "mkboot" followed by the name of the boot/recovery image followed by the name of the folder which can be anything you want it to be since that folder will be created and used as the project folder. This is to unpack the image.

Example would be:

./mkboot customrecovery.img recovery_folder

To repack the image you use the last two args backwards.

Example:

./mkboot recovery_folder mod_customrecovery.img

As you see, I pointed the script to the folder where the contents can be found. It then rebuilds the image and names it "mod_customrecovery.img".

With that said, I do plan to add support for handling those logo images but I just have not gotten around to it. Mediatek uses some really funky methods for building their images lol.
[HTC One SV] AlphaSoft:
Thank bro....

I did it then by reading post#2 ...

One more n perhaps the last thing...

When I change the images in the recovery & try to repack it , it shows *****;hazard****hazard****

Ramdisk is data format.....

I think if the size changes somehow example by replacing the png's it fails to repack it as it reads the size from recovery_info.....

Now if I am right, then is there any way to get out of it I mean if I calculate the new size and write it in recovery_info, will it work then ??

And thanx for your support :thumbup: :) .
[HTC One SV] :
Never had this problem. Let me make a change in your twrp recovery and see if I get the same results. But this is the first I have heard of this issue.
[HTC One SV] :
[MENTION=6301064]AlphaSoft[/MENTION], you must have done something wrong (user error). When you modify the ramdisk and rebuild the image the script will tell you the ramdisks new size. See picture in the attachment. I basically deleted the entire image folder and then rebuild your twrp recovery without any issues.
[HTC One SV] PiggyFlooper:
You've done very good here sir, organized and soooo simple, MMM can you present this as flashable?

Copying grep over temporarily broke root as it was linked to toolbox.

mkboot recovery ThisIsSoDamnEasy.img

Great job!
[HTC One SV] :
Shouldn't need to copy grep over lol. Only binary that should be moved from the mkbootimg_tools folder is bash which would be placed at /system/xbin. The rest should remain where they are. I would make a flashable zip but I do not have access to this thread anymore. Four months ago, roughly, I stepped away from XDA. I had request for my previous account to be deleted. I'm sure a Mod could give me back this thread but I won't pester them to do that and I am sure it wouldn't be so simple to do so either. Could always open another thread but I am not a fan of duplicates. I could make a flashable zip and push it to my repo however. Don't really see the need to though since really the only binary being moved is bash. The rest of the folder could simply be placed in /data/local/tmp (or anywhere that would allow the project folder to properly read and write) without complications like you would see if attempting to use this on your sdcard. I am open to ideas.
[HTC One SV] :
Pushed some changes to my repo for the mkbootimg_tools. One added feature is to check the sizes of the original image and newly built image. Should the new image be larger in bytes than the original you will see a caution pop up on the terminal informing you of the difference in bytes size. It will inform you to insure that the new size is not larger than the partition (which you plan to flash the image too later on). A friendly courtesy.
[HTC One SV] AlphaSoft:
Yes yes i did it .....

It worked awesome but unfortunately I have lost my IMEI now and i had no.backup .... And also the TWRP backup didnt do anything..... :( ...... Thanks for ur help .......
[HTC One SV] :
That's a bummer. Sorry to hear that. Hope you get it fixed soon.
[HTC One SV] PiggyFlooper:
I'm glad you've returned, was wondering where ya went and asked somebody about you over on Android Forums a couple months ago.

The reason I mentioned about grep is because when copying to /bin it broke root. grep was already linked to toolbox and when checking on it afterwards, everything symlinked to toolbox was the size of grep.

I'll host a file from my dropbox, hopefully you could help me with this if anything is wrong- In updater script toolbox is backed up, possible linked 'applets' are deleted, binaries are placed, toolbox reinserted, symlinks made, and permissions set.

https://db.tt/rS3Bz4Am

Thanks again
[HTC One SV] :
Interesting. Though, there is a flaw in your updater-script. You are deleting the grep, cpio, etc, etc, binaries (they are already symlinked) and then resymlink them again via toolbox. Afterwards you overwrite them with the binaries from my project.

Instead, you could consider removing the symlinks to toolbox and attempt to use toolbox with no symlinks and then install the binaries from my project to the bin directory. May or may not work.

You could also, instead, install the project to the /cache directory or any other common location other than /bin as to prevent any breakage with toolbox, etc.

Going off the top of my head on this.
[HTC One SV] PiggyFlooper:
I gave the example that worked for me, the binaries aren't re-symlinked. Just deleted the ones that might be symlinked already, backed up toolbox, installed binarys, restored toolbox, and symlinked again, but not to cpio, grep, or gzip.

I didn't mess with install location because not sure where call from each other at.

This is your baby. I was hoping for a flashable solution. If you wanna fix it, you can use my dropbox. I'm sure you can come up with something way better than myself
[HTC One SV] :
I have a solution that will work but I am heading in to work right now so it will have to wait until I get off. Will make my changes and send you the flashable zip to take a look at it.
[HTC One SV] :
[MENTION=5483848]PiggyFlooper[/MENTION], here you go.

I renamed pretty much all of the files except for the actual script, "mkboot", by adding "_mmm" to them. I also removed everything which was related to toolbox inside the updater-script. It isn't needed with my method. Went ahead and used busybox to mount and unmount the system partition while flashing the zip to eliminate the need for having to specify the actual path. Also removed some symlinks as they are not needed as well. You will find the solution to be relatively simple yet convenient. See attachment for the download link to the flashable zip.

I haven't pushed these changes to my github. Will most likely keep my repo the way it is and just allow other users such as yourself to do with them as you please lol.
[HTC One SV] :
Would like to add that the mkbootimg and mkbootfs binaries may not work for those on Android 5.0. Both binaries were compiled to be static but they still depend on libc.so and libdl.so. The compiler decided not to link against libc.a and libdl.a - easy fix. Starting as of Android 5.0 Lollipop all binaries are expected to be either compiled as true static or PIE. I will be recompiling them two as true static down the road. All other binaries are fine though and will work on Android 5.0 Lollipop.
[HTC One SV] :
MKBOOTIMG_TOOLS is updated and should now work on Lollipop devices.

https://github.com/ModdingMyMind/mkbootimg_tools/commit/9273ea45bffe88765455b4639e05cf2a65e25cf9

All binaries are now statically compiled.
[HTC One SV] :
Important fix to mkbootimg_tools. If using this project then I highly recommend grabbing this update and throwing away the other obe you have. A bug for calculating the non standard offsets had been going unnoticed but it's now fix and the actual non standard offsets or true offsets are properly determined.

https://github.com/ModdingMyMind/mkbootimg_tools/commit/6c44267b4a8a43504c870678c68df6a31b8e2f18

This bug was discovered earlier today when a good friend sent me his boot.img for assistance. If not for that then no telling how much longer it would have gone unnoticed.

Cheers.
[HTC One SV] :
A screenshot showing mkbootimg_tools in action. It's also been confirmed to work on Lollipop. Also, some busybox binaries may be incompatible with this project due to some lacking in arguments. I have tested it with Busybox 1.23.1-Stericson and currently is recommended should anyone use this.
[HTC One SV] :
Long time now. Do you have libc.a available? In need of it if you could please share it. Working on compiling Graphics Magick again but with some modifications to the source and am also gonna tackle trying to compile it as true static with hopes of being successful lol.

Edit: Nevermind, using the one from tcc. Sucks I can't use libdl.a :(. Gives too many errors lol.
[HTC One SV] PiggyFlooper:
Hi, I'm wanting to offer this flashable zip. I mentioned it to MMM. Who I think is now [MENTION=6367467]SHM[/MENTION] ? This is what I came up with, because a couple of the binaries were linked to toolbox and messed stuff up. The solution for me was to flash this- https://db.tt/iLEhR3lh

And then do my ramdisk thing, then afterwards, delete the binaries, and then dirty flash my Rom.

Did you include the updated binaries, because mine are different, and the github link is broke.
[HTC One SV] :
Yea sorry, github account is gone. Will upload attachment which also includes all static binaries. Give me a second. You will need to make it into a flashable zip though. Just mimick the flashable zip found in post 153 but swap out all binaries and files once I upload the attachment in my next post.
[HTC One SV] :
Here you go. This isn't a flashable zip. Just unzip and everything will be there. Do not symlink to toolbox.
[HTC One SV] PiggyFlooper:
Okay [MENTION=6367467]SHM[/MENTION], I just downloaded and only different file is mkboot, which I believe is one of three files ( also mkbootfs and mkbootimg ) you updated when you found error back in Feb. when working with your friend's boot.img.

I can tell your English isn't very good. I didn't say I linked those to toolbox, I said they were already linked to toolbox and copying or flashing over them messes up other symlinks to toolbox, so first they are removed so everything will be good to go.

I'll update the zip with the newer mkboot.

You're a talented person, thank you for this my friend.

I've included a busybox that is compatible.

This is same as link above but with updated mkboot- https://db.tt/iLEhR3lh

Same process, flash this, unpack, edit the ramdisk, repack, then delete the binaries, and dirty flash your Rom.

Sent from above using Xparent Tapatalk
[HTC One SV] :
I would recommend to grab all the binaries. The flashable zip I sent you previously in the past were using dynamically linked binaries and therefore wouldn't work on lollipop. The attachment I just sent you today includes all binaries as statically compiled and will work even on Lollipop. So, make sure ;). Meanwhile, you are welcome my friend.
[HTC One SV] Antonio Almeida Filho:
Congratulations! very important tutorial! ??
[HTC One SV] pauljblo:
Boot.img for you as asked
[HTC One SV] :
Yup, definitely need to make some changes and push to my repo to support this image properly.
[HTC One SV] pauljblo:
Thank you would be great.

Let me know if you get it working
[HTC One SV] :
Getting it to work won't be an issue. My plan is to target the header signature and extract from there. May do this with all supported compression types and eliminate the file binary and magic file as the most recent version is giving me troubles to cross compile for ARM.
[HTC One SV] :
[MENTION=1949427]pauljblo[/MENTION], https://github.com/ModdingMyMind/mkbootimg_tools/commit/efca29a8cad7424bece454c0eba244fcd360b2d0

LZOP compression support is added.
[HTC One SV] :
Ok peeps,

https://github.com/ModdingMyMind/mkbootimg_tools/tree/master/ARM

The above repo (project) will work on ARM but is also tested and confirmed to work on Ubuntu 15.04 Linux. Should work on other linux distros as well.

I renamed the real mkboot script as wrapper and created another script that manipulates the shebang which is now named, mkboot.

It's usage is still the same.

Unpacking image:

./mkboot recovery.img recoveryfolder

Packing image:

./mkboot recoveryfolder recovery.img

Bash is no longer needed to be placed at /system/xbin but may remain in the project directory.

The wrapper script, aka mkboot, makes it possible to use this project on both an ARM and Linux environment by executing the real mkboot script, aka wrapper, using the bash binary from within the actual project directory without having to make any unnecessary modifications between both environments.

This is important since /system/xbin does not exist on a linux distro by default.

All binaries are compiled statically using both the arm-linux-androideabi and arm-linux-gnueabi toolchains which made it possible to run these binaries on ARM devices and Linux.

This project has just become relatively creative and smart ;)

With that said, it supports lzop, lzma, xz, gzip, and lz4 compressions. If there is any other types of compressions being used for ramdisks and this project doesn't currently support it then let me know and please send me this boot.img/recovery.img so I can see about adding it for support.
[HTC One SV] pauljblo:
Thanks for adding lzop support