[Replicant] Help with understanding a makefile

Thu Feb 25 11:51:14 UTC 2021

On Wed, 13 Jan 2021 19:13:47 +0000
Jack Knightly <j__a__k at hotmail.com> wrote:

> Hello everyone,
Hi, 

Sorry for the delay, I've a huge mail backlog.

> Anyway, my downstream kernel builds ok, and my boot.img has the same
> important parameters unpackbootimg displays as the most recent custom
> rom zip, but it won't boot the kernel, just goes back to fastboot.  I
> think it is something to do with the fact that both TWRP and Evervolv
> (the custom rom) have a boot exploit coded into their device repos.
Then you probably need that. I don't know that device (the Kindle Fire
HD 3rd generation (2013)) but given all the information you gave here
it seems that the some software (the bootloader?) checks the signatures
of some partitions (boot.img, system.img, recovery.img) or
that the bootrom checks u-boot.bin signatures.

I've copied the Makefile you mentioned below:
> LOCAL_PATH := $(call my-dir)
> 
> SOHO_HEADER_DATA := '\x50\x03\x00\x00\x00\x25\xe4\x00'
> SOHO_HEADER_SIZE := 848
> SOHO_HEADER_OFFSET := 52
> SOHO_SMASH_ADDRESS := '\x00\x50\x7c\x80'
Here it looks that it exploit some buffer overflow or similar out of
bounds checking. What typically happens is some code (like the stock
bootloader or the bootrom) has to parse certificates and so on to do
signature checking, and sometimes there are security issues in that
code.

There is probably some information on security flaws of that
device's (bootloader? bootrom?) somewhere.

> INSTALLED_UBOOT_TARGET ?= $(PRODUCT_OUT)/u-boot.bin
> 
> INSTALLED_EXPLOIT_TARGET     := $(PRODUCT_OUT)/exploit
> INSTALLED_EXPLOIT_TARGET_ZIP := $(PRODUCT_OUT)/exploit.zip
> 
> SOHO_RECOVERY_UBOOT_OFFSET := 8117072
> SOHO_EXPLOIT_UBOOT_OFFSET  := 1598288
I'm not familiar with that device. You probably need to find more
information on the boot process on that device to be able to understand
something. More precisely:
- What is signed during the boot (is the bootloader signed, what about
  the boot.img, recovery.img, system images, etc)
- What is vulnerable, and what people are typically exploiting and for
  what purpose.

> SOHO_EXPLOIT_SMASH_OFFSET_BOOT     := 8389312
> SOHO_EXPLOIT_SMASH_OFFSET_RECOVERY := 704
> SOHO_EXPLOIT_SMASH_OFFSET_SYSTEM   := 6519488

> define exploit-boot-image
> 	@dd if=/dev/zero of=$2 bs=$(SOHO_HEADER_SIZE) count=1
> 	@echo -ne $(SOHO_HEADER_DATA) | dd of=$2 bs=$(SOHO_HEADER_OFFSET) seek=1 conv=notrunc
> 	@cat $1 >> $2
> endef
It's a function that takes 2 argument: a source image ($1) and a
target image ($2). It creates a target image from the source image and
adds an exploit to it.

> $(INSTALLED_BOOTIMAGE_TARGET): $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_FILES)
> 	$(hide) $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@.std
> 	$(hide) $(call exploit-boot-image,$@.std,$@)
> 	$(hide) $(call assert-max-image-size,$@,$(BOARD_BOOTIMAGE_PARTITION_SIZE),raw)
> 	@echo -e ${CL_CYN}"Made boot image: $@"${CL_RST}
> $(INSTALLED_RECOVERYIMAGE_TARGET): $(MKBOOTIMG) \
> 		$(recovery_ramdisk) \
> 		$(recovery_kernel) \
> 		$(INSTALLED_UBOOT_TARGET)
> 	$(hide) $(MKBOOTIMG) $(INTERNAL_RECOVERYIMAGE_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@.std
> 	$(hide) $(call exploit-boot-image,$@.std,$@)
> 	$(hide) $(call assert-max-image-size,$@,$(SOHO_UBOOT_OFFSET),raw)
> 	$(hide) dd if=$(INSTALLED_UBOOT_TARGET) of=$@ bs=$(SOHO_RECOVERY_UBOOT_OFFSET) seek=1
> 	$(hide) $(call assert-max-image-size,$@,$(BOARD_RECOVERYIMAGE_PARTITION_SIZE),raw)
> 	@echo -e ${CL_CYN}"Made recovery image: $@"${CL_RST}
> 
> $(INSTALLED_EXPLOIT_TARGET)/boot.img:
> 	$(hide) $(call exploit-boot-image,/dev/null,$@)
Here it creates an empty boot.img with only the exploit.

This is similar to "exploit-boot-image(/dev/null, $(PRODUCT_OUT)/exploit/boot.img);" 
in a C-like language.

> $(INSTALLED_EXPLOIT_TARGET)/recovery.img: $(INSTALLED_RECOVERYIMAGE_TARGET)
> 	$(hide) cp $< $@

Here it does something like that:
> cp $(INSTALLED_RECOVERYIMAGE_TARGET) $(INSTALLED_EXPLOIT_TARGET)/recovery.img

> $(INSTALLED_EXPLOIT_TARGET)/exploit.img: $(INSTALLED_UBOOT_TARGET)
> 	$(hide) for i in $$(seq 1024); do echo -ne $(SOHO_SMASH_ADDRESS); done | dd of=$@ bs=$(SOHO_EXPLOIT_SMASH_OFFSET_BOOT) seek=1
> 	$(hide) for i in $$(seq 1024); do echo -ne $(SOHO_SMASH_ADDRESS); done | dd of=$@ bs=$(SOHO_EXPLOIT_SMASH_OFFSET_RECOVERY) seek=1 conv=notrunc
> 	$(hide) dd if=$< of=$@ bs=$(SOHO_EXPLOIT_UBOOT_OFFSET) seek=1 conv=notrunc
Here it generates a file ($(PRODUCT_OUT)/exploit/exploit.img) from
$(PRODUCT_OUT)/u-boot.bin but I don't really understand what it 
does here. Maybe it's trying to make u-boot.bin jump to a specific 
address somehow? I'd probably need more context to understand that code.

> $(INSTALLED_EXPLOIT_TARGET)/system.img:
> 	$(hide) for i in $$(seq 1024); do echo -ne $(SOHO_SMASH_ADDRESS); done | dd of=$@ bs=$(SOHO_EXPLOIT_SMASH_OFFSET_SYSTEM) seek=1
It does the same thing so system.img.

> .PHONY: exploit
> exploit: $(INSTALLED_EXPLOIT_TARGET_ZIP)
> 
> INTERNAL_EXPLOIT_FILES := $(INSTALLED_EXPLOIT_TARGET)/boot.img \
> 	$(INSTALLED_EXPLOIT_TARGET)/recovery.img \
> 	$(INSTALLED_EXPLOIT_TARGET)/exploit.img \
> 	$(INSTALLED_EXPLOIT_TARGET)/system.img
> 
> $(INSTALLED_EXPLOIT_TARGET_ZIP): $(INTERNAL_EXPLOIT_FILES)
> 	$(hide) python $(LOCAL_PATH)/reproducible_zip.py $@ $^
> 	$(hide) unzip -l $@
> 
> ALL_DEFAULT_INSTALLED_MODULES += $(INSTALLED_EXPLOIT_TARGET_ZIP)
> 
> $(INTERNAL_EXPLOIT_FILES): | $(INSTALLED_EXPLOIT_TARGET)
> 
> $(INSTALLED_EXPLOIT_TARGET):
> 	$(hide) mkdir -p $@

If there was a flaw inside the bootrom, it would probably need to only
patch u-boot.bin. However here it seems to modify system.img as well
for instance.

So maybe the u-boot.img is used as a second bootloader? Or maybe
system.img and so on are needed for booting and then the u-boot.img is
installed once the system is booted? 

It's not clear to me.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20210225/75317c56/attachment.asc>