Replicant

I played around a bit, but I can't help here; sorry.

I was able to extract a .gz by using this bash code:
# for OFFSET in `od -A d -tx1 boot.img | grep '1f 8b 08' | awk '{print $1}'`; do dd if=boot.img bs=1 skip=$OFFSET of=initramfs-$OFFSET.gz; done
Source: http://forum.cyanogenmod.org/topic/30996-how-to-extract-bootimg/
but:

• this just worked out of the box on my self compiled boot.img, and not on the latest official release (Replicant 4.2 0004) version, and
• the extracted .gz seems not to be in the right format, so I can't extract it with the usual extraction methods:
  • gzip -dc {name}.gz | cpio -i
  • lzma -dc {name}.gz | cpio -i

and so the .gz ist possibly simply useless.

I can't extract the .gz from the Replicant 4.2 0004 boot.img, because there are two results for
# hexdump -C boot.img | grep '1f 0b 08'
Source: http://forum.xda-developers.com/showpost.php?p=53082699&postcount=4
Some more details could be extracted from here: https://webcache.googleusercontent.com/search?q=cache:0iaqKKG6ToQJ:code.metager.de/source/xref/CyanogenMod/android/bootable/recovery/applypatch/imgdiff.c+&cd=10&hl=en&ct=clnk&gl=us
(You could extract both of them manually by the way described in the link above, but I got the same useless .gz format here in my test).

To cut a long story short. It seems I can't extract the ramdisk part out of the boot.img, too. I also have tried several 'unpack_ramdisk' bash scripts, or 'split_bootimg' perl scripts without success. All I can say, AFAIK the boot.img should have (more or less) the same structure, as the one used in CyanogenMod 10.1.3:
https://github.com/CyanogenMod/android_system_core/blob/cm-10.1/mkbootimg/bootimg.h
Source: http://wiki.cyanogenmod.org/w/Kernels

So I hope somebody else could help you or other people with the same question here.

As I wrote I was able to extract the initramfs cpio archive (with some help from "binwalk"), skipping the lzma decompressor in the beginning and lzcat-ing the rest, which contains among others the cpio data.

The question was whether there is a formal definition/description of the boot image contents, sufficient for unpacking and repacking, other than the packing implementation aka build scripts and unpacking implementation available as source or documentation of the bootloader and of the kernel.

This is a typical case where "open source" is not sufficient by itself. One has to examine and understand a very large amount of various data (The Source, from different involved projects), alternatively run a lot of various tools without knowledge/control over what they do (full build), to be able to make and test a very small and straightforward change. The cost becomes prohibitively high.

A specification of the replicant boot format being in use would make initrd tweaks easy and straightforward (note, a specification, not "a tweak tool" implementation, which can not be reliable without a specification).

As I wrote I was able to extract the initramfs cpio archive (with some help from "binwalk"), skipping the lzma decompressor in the beginning and lzcat-ing the rest, which contains among others the cpio data.

Really? While I can't read that part in your fist post, it's possible my english is just too bad...

The question was whether there is a formal definition/description of the boot image contents, sufficient for unpacking and repacking, other than the packing implementation aka build scripts and unpacking implementation available as source or documentation of the bootloader and of the kernel.

IMHO, the Replicant mailing list (https://lists.osuosl.org/mailman/listinfo/replicant) could trigger more people...
But you also could try it on the CyanogenMod (and/or XDA-Developers) Forum with the explicit hint, that you mean the doc for the legacy CM 10.1.3 version; probably there exist something like this, which you (and me) just can't find ad hoc.

I'm out, because I sadly can't help here, yet.

I was probably not sufficiently clear:

"While I was able to make some sense of it by manual splitting,..."

meant that I got the initrams data but was unhappy about the reliability of its extraction and especially of the repacking of a modified one.

There are no replies on the mailing list yet (I posted there before asking the question here), so thank you for being the only one who reacted :)