Am Samstag, 22. Oktober 2022, 12:19:31 CEST schrieb Thomas Schmitt: Hi Thomas,
thanks for the very large and very usefull information. However, it looks not easy and requires lots of effort. I thoughtm I could boot a livefile, then update it, then repack it as a new iso. When thinking it over, I believe, this will not be possible, as a booted live system is putting a lot into memory by default, and so it would not work. I also thought of usinng some virtual system, like virtualbox, quemu or virtual-manager. This would work, but virtualbox for example, can only export to an OVA-file, not to an ISO. I know, one can convert OVA to ISO, but this might be create new issues. Lastly I would stay with live-build, this is lasting a long time, but it works. Additionally I will contact the kali-people, because there is some issue with their repo, I believe. As I do not want to download every(!) package from the repo again and again, I am using apt-cacher-ng. But since several months thisis not working any more. At not explainable reasons sometimes I get errors by downloading the packages saying, there is a ggp-key nismatch of the package. Deleting the whole cached packages on my system and download them freshly shows no error. Still could not discover, why this happens. It looks like the package-ggp-keys are not updated. Something with the repo, that I could not fix. This above was the reason, that I looked for another way, not to download everything again and again, and so I came to the idea with the iso. I could file a bugreport, but the kali-people are very busy and I believe, I am the only one, who is creating his own kali-live (and mine is not the standdard one, mine has a lot of packages added, it is in German and there are third party packages added). And so, and this is very understandable, they do not much care of the special problem of one single user. So, thank you very much for your help, I will read this carefully to understand everything. Best regards and happy hacking! Hans > Hi, > > Hans wrote: > > I had the idea, to boot the ISO in a chroot environment, then > > upgrade the booted ISO via apt, and at last save the updated livesystem as > > an ISO-file again. > > This might give you the desired data content or not. I could imagine > stumblestones but have no experience with such an operation. > The booted system might be a wild mix of files from the ISO, from the > initrd, temporarily generated files, and pseudo files like in /proc. > > Further you might have to authorize your newly installed packages by > checksums or signatures. For that you will have to ask Kali people. > > In any case you will have to pack up your manipulated file tree to the > ISO so that it is bootable. Probably i can help with that aspect. For > Debian ISOs i wrote > https://wiki.debian.org/RepackBootableISO > > > Let's have a look at the current boot equipment of Kali amd64 ISOs: > > wget https://cdimage.kali.org/kali-2022.3/kali-linux-2022.3-live-amd64.iso > > xorriso -indev kali-linux-2022.3-live-amd64.iso \ > -report_el_torito plain -report_system_area plain > > yields > > Volume id : 'Kali Live' > El Torito catalog : 2080 1 > El Torito cat path : /isolinux/boot.cat > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA > El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2529 > El Torito boot img : 2 UEFI y none 0x0000 0x00 1792 2081 > El Torito img path : 1 /isolinux/isolinux.bin > El Torito img opts : 1 boot-info-table isohybrid-suitable > El Torito img path : 2 /boot/grub/efi.img > System area options: 0x00000102 > System area summary: MBR isohybrid cyl-align-on > ISO image size/512 : 7458904 > Partition offset : 16 > MBR heads per cyl : 228 > MBR secs per head : 32 > MBR partition table: N Status Type Start Blocks > MBR partition : 1 0x80 0x17 64 7456448 > MBR partition : 2 0x00 0x01 7456512 1792 > > So it boots from DVD on Legacy BIOS and UEFI. For booting from USB stick > i see only the official opportunity to boot via Legacy BIOS and EFI in > legacy CSM mode. > But, as Pete Batard of Rufus relentlessly points out, all known EFI > implementations would boot not only from an MBR partition of type 0xEF > but also from any other MBR partition type which contains a FAT filesystem > with a file \EFI\BOOT\BOOT*.EFI which matches EFI's idea of the present > processor type. > Peeking ahead, it turns out that partition 2 contains BOOTIA32.EFI for > 32-bit x86 and BOOTX64.EFI for 64-bit x86. > > Kali is so nice to include like Debian a file with the program name and > arguments which were used to pack up the ISO: > > sudo mount kali-linux-2022.3-live-amd64.iso /mnt/iso > cat /mnt/iso/.disk/mkisofs > > yields (in one single line): > > xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3 > -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 > -A "Kali Linux" > -p "live-build 20220505kali1; > https://salsa.debian.org/live-team/live-build"; -publisher "Kali" -V "Kali > Live" --modification-date=2022080415360800 -b isolinux/isolinux.bin -c > isolinux/boot.cat -no-emul-boot > -boot-load-size 4 -boot-info-table -eltorito-alt-boot > --efi-boot boot/grub/efi.img > -append_partition 2 0x01 binary/boot/grub/efi.img > -o live-image-amd64.hybrid.iso binary > > "binary" was the directory name where the tree of files was prepared. > As stated above, i am unsure which path you should give when packing up > the manipulated Kali system. > > /usr/lib/ISOLINUX/isohdpfx.bin is installed by Debian package "isolinux". > But you may also extract the first 432 bytes of the original ISO: > > dd if=kali-linux-2022.3-live-amd64.iso bs=1 count=432 of=kali_mbr.img > > and then use it by > > -isohybrid-mbr kali_mbr.img > > > We learn that partition 2 holds a copy of the same image efi.img which > is also offered by the El Torito boot catalog. > The latter is a file in the ISO: > > sudo mount /mnt/iso/boot/grub/efi.img /mnt/fat > find /mnt/fat > > shows > ... > /mnt/fat/EFI/boot/bootia32.efi > /mnt/fat/EFI/boot/bootx64.efi > ... > /mnt/fat/boot/grub/grub.cfg > > So it is very likely that the EFI ifirmware of an amd64 machine will > detect partition 2 as bootable, although it does not have the officially > specified partition type 0xEF. > > ------------------------------------------------------------------------- > > If you would only want to add some files to the ISO's tree, then it > would be possible to do this by a single xorriso run: > > xorriso -indev kali-linux-2022.3-live-amd64.iso \ > -outdev changed-kali-linux-2022.3-live-amd64.iso \ > ... xorriso image manipulation commands like -map, -rm, -mv ... \ > -boot_image any replay > > I tested that xorriso-1.5.0 of Debian 10 and xorriso-1.5.2 of Debian 11 > both detect the need of the same xorriso commands for the final replay of > the boot equipment, as the current release xorriso-1.5.4 does. > xorriso-1.4.6 of Debian 9 is too old. > > If you can't get xorriso >= 1.5.0 you may download and build > > https://www.gnu.org/software/xorriso/xorriso-1.5.4.pl02.tar.gz > > according to "Compilation, First Glimpse, Installation" in > > https://www.gnu.org/software/xorriso/README_xorriso > > Installation is not needed, if you can live with using a long program path > like "$HOME"/experiments/xorriso-1.5.4/xorriso/xorriso . > > > Have a nice day :) > > Thomas
