I need some help with a Hack that may be reasonable, or ill-fated.

First of all, here is what I want to do:
I am part of a team building a kernel for a target.
At the current maturity, each device does not show a unique serial number for its 'USB Gadget'. The serial number identifies the device to the host system and android adb. Since we are sharing a server for builds and debugging, it is a problem that all the target devices show the same serial number and are thus indistinguishable - there is no way for one person to avoid operating, or re-flashing the wrong device.

I also want to avoid rebuilding, since each engineer builds in his own sandbox, and that may introduce variables, and variable results.


THe Solution I came up with:
Unpack vmlinux from vmlinuz
Find and overwrite the SerialNumber string with a unique ID
Save the modified vmlinux
Recompress the modified vmlinux
Repackage it:
Rebuild vmlinuz with all bytes from its start to compressed vmlinux offset
Append recompressed <hacked> vmlinux
Append bytes from vmlinuz that followed the compressed vmlinux

Basically, I extract, uncompress, hack, and replace the compressed vmlinux image.

On recompression, the image may grow or shrink a few bytes....THIS IS KEY!!

Sadly, my solution has not led to a successful boot.

I have looked at the Makefile, and much online literature about building vmlinuz.....all about build/tools, mkpiggy, etc., but it is still somewhat greek to me.

I imagine I could employ a subset of the vmlinuz make process, employing a few steps with binaries such as build/tool and mkpiggy, bootsect, etc, but haven't been able to make it clear.

Is my present solution reasonable, correct, and correctible (if a bit adventurous), or is it wrong for some fundamental reason ?

Is there something reasonably simple I can do to adjust my hack ?

What is the sequence of actions I need to take to properly replace a hacked vmlinux image in such a way that the vmlinuz image will surely boot ?

Should I just give up and commit to a rebuild for each unique ID ?

Please answer whichever questions you feel moved address.

Thanks!!!

Is it accurate to say that you un-compress the binary, patch the binary, and then re-compress it?

If no, please explain in more detail.

If yes, do you re-install the boot mechanism after storing the new vmlinuz on the boot volume?

Yes to your first question.
as to 're-install' the boot mechanism, I am not sure what you mean.
What I do is:
0. for the sake of context: The vmlinuz file is composed of three contiguous sections:
a) all bytes from start of vmlinuz to the last byte before the compressed vmlinux image.
b) the compressed vmlinux image
c) all bytes from one after the last byte of the compressed vmlinux image, through to the last byte of the vmlinuz.

1. supposing sections a and c of vmlinuz were saved to likewise named files, and the hacked-recompressed b section is in a file b-prime:
I create a vmlinuz-prime by this command sequence:
cat a > vmlinuz-prime
cat b-prime >> vmlinuz-prime
cat c >> vmlinuz=prime

2. then I rename vmlinuz-prime to 'kernel' and rebuild the boot.tar.gz with contents (3 files): kernel, cmdline, ramdisk.img


3. my scripts to install the kernel on the target system require the boot.tar.gz with the aforementioned contents.

4. I flash these items to my phone and then pray.

On a disk based desk top machine, if I replace the kernel file, even if the newer kernel file has the same name and exactly the same size, it may occupy a different set of blocks on the disk. Space for the new instance of the file is allocated in a different place, the data is copied there, then the directory and related structures are adjusted to point to the new version of the file.

Some boot programs want to know what specific blocks to load from the disk, so that information needs to be supplied to the boot mechanism in some way.

I don't know if there is any similar thing that has to be done in the Android Linux environment, when the kernel image is replaced. If there is, that may be the
missing item.

Thanks kakaka.

Please bear in mind, I am not changing the the internal structure of the vmlinux image. I am overwriting an ASCIIZ string with a different string of exactly the same length.

I am not changing the image on the disk, I am changing the image prior to its being installed on the disk.

As to how many sectors it may take up, there is a chance that the compressed image might take up one more or less sector.

In the present case, the difference in size is 12 bytes. That leaves a low probability of changing the sector count. If a sector is 512 bytes, then that is a probability of 5% that that is why the install/load failed.

It also shows a 95% probability of there being a different explanation.

Does anybody have one ?

robertfkh.