Take a ROM apart. Put it back together.

Every path, with what will be written

Select a file and the inspector shows both sides of it: where it sits in the project, and the line that will end up in the image. Device path, mode, owner, capabilities, SELinux label. Symlinks are shown with their target and with whether that target actually resolves inside the tree.

• A file you add is labelled for you: crb resolves the SELinux context of every new path from the ROM's own rules, and where those do not reach, from the nearest labelled parent, which is exactly what restorecon would give it. Owner and mode follow the same convention Android builds with: root and 0644, the shell group and 0755 under a bin directory.
• Metadata coverage checks the whole partition for paths with no ownership line or no SELinux rule. If one would still go in unlabelled, the build does not start: it stops and names the path, because an unlabelled file reaches the phone as a denial rather than as an error.
• The rules are files, not a black box: the ownership and context tables live in the project as plain text you can read and edit, and the compiled file_contexts.bin that ships in the firmware is decompiled back into its rules on extraction. What the build is going to apply is legible before it applies it.
• Browse inside an image without unpacking it: open super.img or any filesystem image read only, and extract just the files you want.
• Open a package and walk a firmware archive level by level: a zip holding an Odin tar holding a compressed image. Nothing is written until you ask for it.
• Search across the tree, filter a folder, rename, reveal, delete, or import a loose image into the project.

The mount table has to agree

Switch /system from ext4 to EROFS and the panel immediately says what is wrong: the table in the ramdisk offers ext4 and the build is set to write EROFS, so first stage mount would fail. One button adds the missing row, puts it on the correct side of read only, writes it into the mount table inside vendor_boot.img, and reminds you that the boot image itself now has to be rebuilt for the change to reach the device.

• What the kernel can mount is read from the kernel configuration inside the boot image. If this device has no EROFS support, or cannot decompress the algorithm you picked, you are told before the build, not after the bootloop.
• Algorithms and levels per filesystem: EROFS with lz4hc, lz4, lzma, deflate or zstd and a level from 1 to 12; f2fs with LZ4 or LZO, and compression that can be turned off entirely.
• Auto Size runs a measuring pass first, so the image is fitted to the exact space its contents need, accounting for read only mode and compression.
• Read only, sparse output and partition size are preselected from the original image, and every override is marked, with one button to put the partition back the way it was extracted.

super is assembled with the budget in view

Dynamic partitions are laid back into a single super.img using the layout the firmware itself declares. The group total, what your images use and what is left are shown before you start, so an overflow is something you see rather than something the builder discovers at the end.

• Raw or Android sparse output, preselected from what the original image was.
• Partitions you did not rebuild are taken from Source automatically, and the panel says so per row.
• Read only and read write attributes are reconciled against the declared layout, and any correction is written into the log.

The dry run is not a preview, it is the point

Every one of these tools will tell you what it would do and then stop. The report names each file it examined and the decision it reached for it, and the run ends on the line that matters: (dry-run: no files were modified). Nothing about the project has changed, and you know whether the operation is worth starting.

The apply keeps a copy of everything it replaces, and then checks its own work: dex checksums, signatures, and the methods it touched. Backups are listed in the same panel and restore from there, so undoing is one click and not a re-extraction.

Every image mapped to a destination

Each file in the list is matched to a partition on the device and given a status. An image that is larger than the partition it targets says so. An image that lives inside super on this phone says there is no partition of that name to write it to. A raw image going to a target that expects sparse says it will be converted first.

• Modes: Android over ADB, bootloader and fastbootd, recovery sideload, and Samsung download mode with the Odin protocol. crb can reboot the phone into the mode an operation needs and wait until it is really there.
• Information first: partition table with sizes, slots and which one is running, super geometry, bootloader variables in full, and whether numbers were measured or assumed.
• Refusals with reasons: a locked bootloader, a snapshot merge in flight, a device that is not the one the project came from, two files aimed at the same partition, or super ticked together with partitions it already contains.
• Two lists it will not treat as ordinary: what holds the device's identity, the calibration and the keys written once on a factory line, is refused outright on every transport, because nothing could put it back. What holds the bootloader is refused with no override over Odin, and over fastboot it takes a confirmation that names the partition out loud.