yashsingh1/xdaforums huggingface dataset:
[Android Software Development] Magendanz:
Thanks, [MENTION=4544860]osm0sis[/MENTION]!

In their quest to get Widevine L1 certification, they've done something clever to prevent me from replacing the stock OEM recovery with TWRP. These devices can be flashed over USB OTG using the WorldCup device driver, and so it's relatively easy to push new firmware with a custom recovery. However, it seems the old TWRP that worked fine on that hardware until now is incompatible with the new DTB and the new kernel is incompatible with the old DTB. If I rebuild TWRP with their new kernel, that also hangs on the logo screen running with the new DTB and bootloader. My guess is that the new kernel is doing some proprietary integrity check, but I'll take a closer look at those binaries in the /sbin directory.
[Android Software Development] tdct12:
Anyone know where the fstab. marlin/sailfish file is hiding on the pixel? I can't flippin find it I just want to disable dm-verity without rooting.
[Android Software Development] ashyx:
It's not in the Ramdisk?

Might be worth checking out CF's post regarding dm-verity on the Pixels.

https://plus.google.com/+Chainfire/posts/fvEPo42GKXS
[Android Software Development] osm0sis:
If I recall correctly, there's another post where Chainfire talks about how the fstab is now in the dtb on these newer devices starting with Oreo. Basically, the fstab for vendor is in the dtb and the fstab for everything else is in vendor.

[MENTION=631273]Chainfire[/MENTION] and [MENTION=4470081]topjohnwu[/MENTION] have dtb fstab patching to disable dm-verity built into their root methods now, but it's pretty complicated and involves splitting the dtb into parts, and patching each and then recombining. :eek:
[Android Software Development] ashyx:
Is the dtb still in the boot.img?

If so maybe possible to use supersu to patch the dtb, pull the boot.img using a fastbooted twrp then repack the patched dtb with the stock kernel and reflash back?
[Android Software Development] osm0sis:
Yup, though there might be some other changes required in the ramdisk that wouldn't be possible without a root package's custom init binary and possibly kernel hex patch to fake the / on the Pixels.

One could also use sukernel and the commands from SuperSU's installer zip to do it, or for open-source, magiskboot and its commands would do the same and possibly also be able to be compiled for host if someone wanted to mess around on their desktop.
[Android Software Development] faizii.official:
Download official firmwhere for your device and change the extention from .xx to. Rar and extract the files.. Then search for file you want
[Android Software Development] osm0sis:
That's not how fstabs work at all, especially not in marlin/sailfish (Pixel). Welcome to xda but please don't drag out a thread with posts if you don't know, especially where we've already provided the correct answers.
[Android Software Development] tdct12:
I just modified the updater script not to run magisk99.sh and not install magisk or the magisk binary. At first I tried to only use topjohnwu's dm-verity disabler from the boot_patch.sh and the included hex edits but I couldn't get it to boot. So I just modified the updater-script and I achieved my goal. Thanks for your advice :highfive:
[Android Software Development] famewolf:
AIK confirmed to work on a T-mobile LG V10 (H901).
[Android Software Development] osm0sis:
Development update

It's come to my attention that mkbootfs is starting to cause more problems than it fixes.. this is due to fragmentation. I've kept up with Google's master branch, but of course a lot of these devices are on older trees.

Some are up to date and accept Google's newer changes to the default permissions/ownership in the ramdisk like .rc's being root:shell, etc. and others seem to break with that, and before my fixes we had the opposite, where some devices would break when mkbootfs would blanket repack everything as root:root.

So basically these changes increasingly aren't backwards compatible and it's making it harder and harder to upkeep a mkbootfs that works for all devices. :(

The good news is, knowing what I know now I've come up with a new solution that allows cpio to unpack and repack a working ramdisk like it does in recovery, totally removing the need for mkbootfs.

For those interested in the technical details, it does this using an empty make_ext4fs .img file, loopback mounted into the filesystem, much like how magisk.img and su.img are, except AIK-mobile will just do this as needed. :cowboy:

It's a brand new and interesting idea, and definitely something that will make AIK v3.0 worthy of the major version bump, since it will be even more universal with all default ramdisk attributes now remaining intact through a repack. :cool:

RIP mkbootfs, and good riddance. ;)
[Android Software Development] erad1:
[MENTION=4544860]osm0sis[/MENTION] So I've unpacked a Bacon kernel and added Spectrum support (an .rc and an .sh file) and edited the device file to import these but it seems not to repack the added files into the new ramdisk. After repacking I have immediately unpacked the boot.img and it has't changed from the original though it (Android.Image.Kitchen.v2.9-Win32.zip} runs through it's command lines with no issue. Any ideas?
[Android Software Development] osm0sis:
The repacked image is called image-new.img, sounds like you're just unpacking the original boot.img over and over?
[Android Software Development] erad1:
Thanks for the reply but actually not. After I finish adding the scripts then click repack exe and I see the new.img Then I click the clean-up exe. The folder resets and I'm left with boot.IMG. Does that sound right?

Edit: so yeah your post made me realize it was a mistake on my part to not pull the new IMG from the folder before hitting clean-up. Thanks, all good now. :good:
[Android Software Development] osm0sis:
So by cleaning up you're removing image-new.img. Rename it first. Reset means reset. ;)
[Android Software Development] Simonex16:
So,it's like an emergency for me.I have lg g3 fulmocs 7.6 and i had to remove RCTD.The app "RCTD lg remover" or something installed me via twrp aik.Now,i can't use wifi and if i deactivate mobile data i can t reactivate them until i reboot the device.How can i unistall/unflash aik?
[Android Software Development] osm0sis:
Sounds like something you should ask in the RCTD thread.
[Android Software Development] Simonex16:
thanks, i asked anywhere,but i think i need to go back to stockù...:good:
[Android Software Development] rcmpayne:
I just pulled a boot.img from a 8.0 Pixel webiste, extracted it and tried to add some extra log tags but after repacking and loading on the device the new prop commands are not listed. This works with Nexus 5x and 6. One thing i see differently in pixel boot.img is default.prop with a simlink to prop.default. Has anyone tried this yet?
[Android Software Development] mingkee:
I used it to unpack Sony G3313 kernel (.sin), edited defalut.prop only and repack, but I found out the repacked image cannot read SIM caused no reception.

Am I missing something?
[Android Software Development] osm0sis:
Use AIK-Linux with ./unpackimg.sh --sudo

Read the development update a page back.
[Android Software Development] mingkee:
I still need Linux PC.

I have to install Ubuntu on old laptop
[Android Software Development] Zackptg5:
[MENTION=4544860]osm0sis[/MENTION]

Edit: just realized I put this in the wrong thread, should have been in AK2, sorry!

I've been working on making an init.d patcher that would be universal for all devices (or as many as AK2 supports). However, what I'm not sure about is device identification since a lot of devices have weird boot img stuff that requires some of the special binaries. Here's where I'm currently trying to figure it out: https://github.com/Zackptg5/Init.d-Patcher/tree/test

So far, I think I have pixels, nexus, samsung pxa variants, and rockchip figured out:

# Custom grep_prop function
grep_prop() { grep "^$1" "/system/build.prop" | cut -d= -f2; }

# Pixel support
if device_check "bullhead" || device_check "angler"; then
mv -f $bin/other-tools/avb $bin/other-tools/BootSignature_Android.jar $bin/other-tools/mkbootfs $bin
elif device_check "sailfish" || device_check "marlin"; then
mv -f $bin/other-tools/avb $bin/other-tools/BootSignature_Android.jar $bin/other-tools/mkbootfs $bin
slot_detection
if [ -d $ramdisk/boot/dev -o -d $ramdisk/overlay ]; then
patch_cmdline "skip_override" "skip_override"
else
patch_cmdline "skip_override" ""
fi
fi
# Samsung/marvell support
if [ "$(grep_prop ro.product.board)" == "PXA1088" ] || [ "$(grep_prop ro.product.board)" == "PXA1908" ]; then
mv -f $bin/other-tools/$API/pxa-mkbootimg $bin/other-tools/$API/pxa-unpackbootimg $bin
# Rockchip support
elif [[ "$(grep_prop ro.product.board)" == rk* ]]; then
mv -f $bin/other-tools/$API/rkcrc $bin
fi

The big question is what kind of identifiers can I use for the other tools? I'm not sure exactly what devices each binary is for. For example, is the ELF stuff for all sony devices? Is dhtbsign for all samsungs or only galaxy tab A 7?

Also, the loki patcher you have isn't that relevant anymore for lg devices since that exploit was patched by lg a while ago. We use bump now:

# Custom grep_prop function
grep_prop() { grep "^$1" "/system/build.prop" | cut -d= -f2; }

# Detect if LG bump devicecheck (credits to topjohnwu and Drgravy @xda-developers)
LGE_G=false
RBRAND=$(grep_prop ro.product.brand)
RMODEL=$(grep_prop ro.product.device)
if [ "$RBRAND" = "lge" ] || [ "$RBRAND" = "LGE" ]; then
if [ "$RMODEL" = "d800" ] ||
[ "$RMODEL" = "d801" ] ||
[ "$RMODEL" = "d802" ] ||
[ "$RMODEL" = "d803" ] ||
[ "$RMODEL" = "ls980" ] ||
[ "$RMODEL" = "vs980" ] ||
[ "$RMODEL" = "l01f" ] ||
[ "$RMODEL" = "d850" ] ||
[ "$RMODEL" = "d852" ] ||
[ "$RMODEL" = "d855" ] ||
[ "$RMODEL" = "ls990" ] ||
[ "$RMODEL" = "vs985" ] ||
[ "$RMODEL" = "f400" ]; then
LGE_G=true
ui_print "! Bump device detected !"
ui_print " "
fi
fi

# Goes under write_boot function
if ($LGE_G); then
# Prevent secure boot error on LG G2/G3.
# Just for know, It's a pattern which bootloader verifies at boot. Thanks to LG hackers.
echo -n -e "\x41\xa9\xe4\x67\x74\x4d\x1d\x1b\xa4\x29\xf2\xec\xea\x65\x52\x79" >> boot-new.img;
fi;

Thanks!
[Android Software Development] osm0sis:
AIK also supports Bump. AK2 leaves it up to the user to have the Bump script as a /data/custom_boot_image_patch.sh since that's what SuperSU does/expects.

ELF is Sony's format, but unlocked newer Sony devices also accept the standard, so could be either there. DHTB is only Samsung/Spreadtrum - pretty much only the Tab A 7 so far.

As for trying to support every image in one flashable zip, that's crazy. Look at AIK. Crazy. Especially trying to do it all as opt-in per device name/board. You might be better off hacking AIK-mobile and AK2 together for the better detection, but I've specifically avoided that because with all the added binaries the zip would be huge.

In AK2 I handled some simple magic parsing for ELF dtb repackaging based on whether they were QCDTs or not, you could possibly tackle things that way as well but you're getting pretty far off of AK2 at that point. You could much more easily have a zip for standard images (arm binaries would cover the majority of devices), then you could swap in unpackelf or whatever for unpackbootimg as variant zips for any other devices.
[Android Software Development] mingkee:
Eventually I have Ubuntu setup on my old laptop, but I have to do some work.

default.prop needs to change user (it was root) and I have to use chown to switch to my group and switch back to root after that.

Now the patched .img file works OK
[Android Software Development] Zackptg5:
Oh geez, I didn't realize how large that zip would get. Yeah, I was thinking as a plan B users could just tack on "ELF" or something like that on the end of the zipname and installer would act accordingly but 70mb for just patching init.d is excessive. I'll just keep it as is and let users add the needed tools. Thanks!
[Android Software Development] ScottIsMyName:
Sorry for the noob question. I have unpacked/repacked a boot.img from the Pixel 2 XL and flashed it fine (no modifications).

If I want to add files, where do I add them exactly? When I replaced the init binary in the ramdisk folder, if I try to repack the image it comes out much smaller than expected. Am I supposed to add those files inside the split_img/boot.img-ramdisk.cpio.gz file? If so, what's the best method to decompress/recompress this file?
[Android Software Development] osm0sis:
The ramdisk folder is that file decompressed. Don't worry about the size as long as it works. If it doesn't and you think it has something to do with the compression level you can use the ./repackimg.sh --level # argument to mess with it.
[Android Software Development] ScottIsMyName:
I figured out it was a permissions problem. I needed to run the repack bat script as administrator (on windows 10) and then it built the image just fine. Thanks! Turns out the repack script was spitting out an error message I didn't even notice before.
[Android Software Development] osm0sis:
Can you post the image you were having trouble with?

Interesting idea.. I wonder if that could help cpio work better. :)
[Android Software Development] ScottIsMyName:
Here is the stock image I was working with

https://drive.google.com/file/d/0B9qRrGF_Lbu9eUdGSEJzUm05WDQ/view?usp=sharing

I added a modified init binary and a new directory and for some reason there was permissions problems unless I ran as administrator.
[Android Software Development] Bernie_W:
recovery.img with signed header

Hi osm0sis,

thanks for that great tool.

I have a question. I got a new mobile and wanted to port TWRP to it like with my previous mobile. But I recognized that the original firmware's recovery.img contains a signature header and thus flashing the TWRP isn't working, since the repack of the recovery does not have this header anymore.

Actually all images and bins of the original firmware have this signing, so flashing anything without signed header is aborted in SPF.

Have you come across this before? I guess there is no chance to rebuild this header as I do not have the key pair. Or do you know a way? Chipset is based on MT6580, so no spreadtrum as far as I know.

Thanks
[Android Software Development] osm0sis:
Upload an image and I'll take a look.

You could try just prepending the original header to the new file, depends how advanced the bootloader check is.
[Android Software Development] Bernie_W:
Thanks for your reply. Actually I tried to prepend it, but it wasn't working. Would love if you can have a look, but where would you prefer I upload the recovery image?
[Android Software Development] osm0sis:
Here is fine. Zip it and attach it. More info would be nice too. Device name, model number, etc.
[Android Software Development] Bernie_W:
Awesome, thank you so much.

The device is called BV4000 from Chinese company called Blackview. It runs on a MT6580 chipset and was just recently launched. Android version is 7.0 and kernel based on 3.18.35 using user-keys. Cortex A7 at 1,3 GHz and Mali-400 MP. A very basic ruggedized mobile for 3G only.

Thanks in advance
[Android Software Development] osm0sis:
Ah yes, I've seen that before. BFBF magic was also present on the Aquaris M8, which was also an MTK device so I'm guessing this is their current proprietary signing. Interestingly, though your device is an MTK board it doesn't have the MTK zImage and ramdisk headers (where the Aquaris still does). Maybe MTK is finally moving away from that nonsense now that they have new signing?

My best suggestion is you should check to see if anybody made any headway on the Aquaris M8. Huawai's signing on the Mate 8 and Mate 9 (probably others) is also extremely similar in appearance, though lacking the BFBF header and much less padding. You could also check them out (9 has an enforcing bootloader).
[Android Software Development] Bernie_W:
Thanks a lot osm0sis.

I feared already that it isn't that easy. I do not 100% understand the thing about the headers concerning zImage and ramdisk, but nevertheless I will watch for the Aquaris M8, but a first search didn't reveal anything.

What I could try is to sign the recovery myself and see if it allows a flash then, but my hope is low. I saw in the Play app that it is a certified device, so quite certain they use some proprietary/new signing. If it is based on Brillo's Android Verified Boot, I really can't tell. Without root I am lost :) I also didn't find much concerning this BFBF header as such, but I'll try again.

Truly thanks for your effort
[Android Software Development] martyfender:
I have been using Windows for many years and I have found that for many problems, such as yours, that running as administrator can solve a problem. (right click, choosing: run as administrator.)

This may be an over simplification, but I believe it is similar to using the sudo command in Linux.

However, I am new to Linux, I have been using Linux Mint Mate since June and am loving it. I rarely ever boot to Window 7 anymore.
[Android Software Development] rcmpayne:
Issue with P9 lite 2017. I can unpack and repack without any changes and the device fails to boot. loading the boot image without using image kitchen on it loads the device fine.

OS: windows 10

Repack extra switches: None

Image: https://drive.google.com/open?id=0B7olfkMi8BeQTlpQQTBsemtVMms
[Android Software Development] bovirus:
[MENTION=6017044]rcmpayne[/MENTION] (and everyone)

Please when you get problem please provide a link where anyone can download the file that are you trying to unpack/repack
[Android Software Development] rcmpayne:
i did!?
[Android Software Development] osm0sis:
Use AIK-Linux with ./unpackimg.sh --sudo and see if that works. You're likely another victim of fragmentation; read my development update a couple pages back.
[Android Software Development] martyfender:
Personally, I don't have a problem with the current version of AIK with my current device's boot.img, in Linux Mint Mate, but for clarification, and learning linux better, could you explain that command? I have been using Linux now for only a couple of months. Most of the time I have used sudo before a command, without the two --. And I will search for a good command reference guide, or maybe you can recommend one.

Or will man command name give me this information.?

Thanks [MENTION=1143630]osmosis[/MENTION]

Forgive me, I am searching still, but as of yet, have not found info for what special characters do, such as ./ and --
[Android Software Development] osm0sis:
./ means the current directory, so that's how you execute AIK's scripts. Not all commands in the scripts require sudo, so I added --sudo as an optional argument to trigger the use of sudo on the appropriate commands.
[Android Software Development] martyfender:
Thanks for being patient with a newb.

I have found many command reference guides, info about bash and special characters, etc, but not what the -- does, yet. I do know I used it when I was setting up jdk, with a command I copied and pasted to determine my version number.

Again, thanks
[Android Software Development] osm0sis:
- is used for short-form arguments, and -- is used for long. So for example, a couple Android command equivalents; `su -mm` and `su --mount-master` do the same thing. Some arguments don't have short equivalents, or vice versa. All of AIK's are long only, so -- prefixed.
[Android Software Development] rcmpayne:
That worked. I can repack and it loads fine.
[Android Software Development] Bernie_W:
Just a short update, I self-signed with SSL and copied the BFBF header via HEX-Editor to the newly signed recovery.img and tried to flash, but to no avail. I guess without the right private key and possibly an additional checksum in the header, it is nearly impossible to flash anything custom.

If this becomes the new standard, then root or custom roms will not work anymore (unless one of the experts find a way).
[Android Software Development] osm0sis:
I think the BFBF header is only on newer MTK devices that enforce signing, so not too widespread. Hopefully someone can reverse engineer it at some point.
[Android Software Development] Bernie_W:
Yes, you are right, newer devices seem to get this AVBv2, but I do not think it is only affecting MTK devices.

I read a bit about avbtool and during encryption they use an own partition (vbmeta?) but also change the partition size of boot/recovery. I guess that's where the padding comes from. In addition the header seems to contain hashes, but it is not indicated from what they calculate them.

So that is something for the pros, i.e. definitely not me.

No root for me this time :crying:

Thanks osm0sis
[Android Software Development] osm0sis:
At this time I do not believe BFBF is AVBv2.

Like I said, these 2 newer MTK devices are literally the only 2 I've ever seen it on.
[Android Software Development] Bernie_W:
So MTK proprietary? Absolutely possible. Guess I am lost here. For me it's the first one I saw.

Thanks for sharing your view!
[Android Software Development] yan_saputra:
Hi dev [MENTION=4544860]osm0sis[/MENTION] and all friends... Can you teach me how to unpack & repack twrp.img to change the background wallpaper look without using pc-cmd line, with fx app and script command what should i do? ?

Before I use aik.apk & unpack / repack.apk by following tutorial instruction on youtube did not work too ... I followed the tutorial from screenshot of P. George no change when changing the display theme & splashscreen using twrp v3.1.1-0 mat recovery v3 latest update ... And I've done flash aik installer v2.9.zip also no change ... just change to default initial recovery mat (Back to color mat default again). ☹️

Device : Asus zenfone 2, ze551ml, z00a, x86, 4 gigs ram, root su v2.82, custom rom rr v5.8.5 - nougat v7.1.2 nightly with xposed.apk v3.1.2 + xposed installer v88.1 latest update, and busybox 1.27.2 - / su / xbin (Default), unless manual install / system / bin reads busybox root access, but when restarted will return to default again - / su / xbin (Default). ?

Before i have no experience for unpack / repack twrp ... ?

I just get used to decompile recompile system apk application only ... Please help & solution ... ?

---------- Post added at 11:14 AM ---------- Previous post was at 10:44 AM ----------

Before I use twrp v3.1.1-0 official and get it from official twrp app.apk and I copy & paste it to twrp.img - / system / data / local / aik mobile / ... And execute and run the result empty ... What command what should I type and do? I'm very new once ... Please guidance ... ?

The following screenshots below ... ?

https://drive.google.com/file/d/0BwqlfKDeEnZadDhpZm8zZC1wSDQ/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaQUFJWml6OGd5U0E/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaV1VwQWs1VGNnQlU/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZackNQalo4OGZtNGc/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaR0o1aExWWWVUUmM/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZadTlsNWNUTlFwcVE/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaY2VKM05tT0VyLW8/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaZ1NXUUVfWHNKaEk/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaMTZiSkxmM2ltYk0/view?usp=drivesdk

https://drive.google.com/file/d/0BwqlfKDeEnZaNXdlZ2RaM2VmLXM/view?usp=drivesdk