any plans for extraction / decryption functionality?

[hexdump0815]

hello repk,

are there any plans to add the reverse functionality to gxlimg, i.e. to be able to decompose an existing boot image into its pieces? this would be very good to extract the bl2 and bl30 parts of existing devices (for which the public available versions do not work) from an existing firmware/emmc to use them for rebuilding a working and up to date mainline u-boot for them. for instance i tried to boot some s905w based tv boxes with a self built mainline u-boot based on the public available bl2 and bl30 images and it often failed in either bl2 (wrong chip message) or bl30 (dvfs does not work well and sending for instance too high clock speeds) - so looks like to make this work, one would have to reuse the bl2 and bl30 of the boxes themself to get a working version and for that one would need to be able to extract them.

in the code i saw functions like gi_bl2_extract with a note that they are not implemented yet, so this brings up some hope that they will be there soon. i looked at the code, but i think for me this would be a bit too complex to get this implemented.

a lot of thanks in advance and best wishes - hexdump

[repk]

Hi hexdump0815,

Sure will do, I'm a bit busy lately, but you can expect it to land in this week.

Best wishes

-- Remi

[repk]

This should be fine with 90640e1f1464f44d8dd203e02177e0c2160dc51d. What you can do from a boot image (first remove first sector by hand if that boot image is a sd card dump): $ mkdir images $ ./gxlimg -e gxl-boot.bin ./images With that you will get all encrypted bl* in ./images directory that would be enough to take bl2.sign bl30.enc and bl31.enc from here to create a new boot image with a different u-boot.

But if you want to go further and decode everything you can do:

$ ./gxlimg -t bl3x -d ./images/bl33.enc ./images/bl33.bin $ ./gxlimg -t bl3x -d ./images/bl31.enc ./images/bl31.bin $ ./gxlimg -t bl3x -d ./images/bl30.enc ./images/bl30.bin $ ./gxlimg -t bl2 -u /tmp/res/bl2.sign /tmp/res/bl2.bin

Thus you'ld get the actual bl machine code.

Please tell me if it is not working fine in your case.

[hexdump0815]

hi repk,

i'm impressed - i did not expect it to be ready that quick :) - thanks a lot, will test it during the next days, latest next weekend

best wishes - hexdump

[hexdump0815]

hi repk,

i gave your new functionality a try today: i dumped the boot area off the nand from a box which failed before with "Wrong chip" in bl30. i was able to extract all the elements as you described (there is btw. a typo in your example above around the /tmp/res/ dir) - only bl33.bin gave some strage error on decryption (error: amlcblk.c(592): Cannot read fd 3: Success), but i guess this is as i did not dump enough from nand to have the full u-boot in it.

as the next step i tried to combine those bl* with my self-built u-boot (there is another typo in the gxlimg README i think: you first mention u-boot-dtb.bin and later use u-boot.bin in the gxlimg cmdline example) - this somehow seemed to fail reading the bl2 properly: "GXL:BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:3;RCY:2;SD:800;EMMC:800;NAND:0;READ:0;0.0;CHK:0;"

to doublecheck i built the bl2 according to your README from the libretech-cc fip tar and combined it with the other extacted bl3 and that worked and properly booted my self-built u-boot, which did not ever work before. also the loaded bl3 used are the extracted ones according to the date stamps in the boot output :)

so my question would be, how would the bl2 part of the cmdlines look exactly to build it from the extracted bl2? it might also be that my nand dump is not ok, but the extracted bl2.bin looks very similar to other bl2.bins in hexdump -C ... or that this bl2.bin from that box is targeted to nand only. it would be useless for me anyway, as it seems to load the bl3* hardcoded from nand which is not what i want.

ah and btw. i force the box to boot from sd-card via hdmi dongle (https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle).

once more a lot of thanks for your effort, i would say at least to 99% it works perfectly fine ... maybe even at 100% and its just my fault

best wishes - hexdump

p.s.: just in case someone else reads this and wants to dump the boot area from nand (i.e. not emmc) - these were the commands i used:

amlnf rom_read 0x4000000 0x0 0x800000 mmc write 0x4000000 0x1 0x400

afterwards from the sd card i dumped it to: dd if=/dev/sdb of=nand-boot-dump.dd bs=512 skip=1 count=1024

it took me quite a while to figure this out :)

[repk]

Hi hexdump0815,

This is almost good news :). So yes if I remember from IRC the problem you had was with dvfs right ? If so that explain why changing bl30 fixes it (bl30 is the SCP firmware, a cortex-M3 processor that handles power and frequency scaling among other things).

So far I have no idea why the extracted bl2 does not work. Did you remember to sign it with "gxlimg -t bl2 -s bl2_new.bin bl2.bin.enc" before doing the fip ?

Would it be possible to see what the bl2.sign looks like (I mean the one you got with "gxlimg -t bl2 -u bl2.sign bl2.bin" ? I hope s905w does not use signv2 boot image format.

Thanks for the typos and the weird error code will take a look at that.

-- Remi

[hexdump0815]

hi remi,

this is not a S905W, but a S905L (seems to be close to S905X) which did fail as the public available bl30.bin do not seem to support it ("Wrong chip" error) but i'm sure this procedure will work well with the S905W too - will test it soon too.

the command i used to build the failing boot image was: gxlimg -t fip --bl2 ./bl2.sign --bl30 ./bl30.enc --bl31 ./bl31.enc --bl33 ./u-boot-dtb.bin.enc ./gxl-boot.bin

best wishes - hexdump

p.s.: please check your email :)

[repk]

Hm your bl2.sign looks definitely fine can I please see the gxl-boot.bin ?

Thanks

[repk]

I just tried to recreate an image with: $ ./gxlimg -e x96mini-nand.dd ./images $ ./gxlimg -t fip --bl2 images/bl2.sign --bl30 images/bl30.enc --bl31 images/bl31.enc --bl33 u-boot.bin.enc ./gxl-boot.bin

And the resulting gxl-boot.bin's bl2 looks completely identical, so you should at least see some BL2 logs.

[hexdump0815]

i overwrote the first gxl-boot.bin when i did my second try with the bl2 from libretech cc fip ... anyway i'll try it again on S905W soon and will let you know if it works there - maybe i just made some mistake of this box is strange ...

[hexdump0815]

hi remi,

good news: i just tested it with a S905W box and it worked flawlessly. this one is with emmc, so dumping the original boot was way easier. extraction with gxlimg worked perfectly fine and without any error for all parts. rebuilding a new gxl-boot.bin based on the extracted bl* and my self-built u-boot-dtb.bin worked flawlessly too and boots perfectly fine. and everything is running well with proper S905W cpu speeds etc. - this is really cool, as this opens up running amlogic tv-boxes with mainline u-boot on emmc - i did not try this yet, but i do not see any reason why it should not work.

thanks a lot once more and best wishes - hexdump

[repk]

Hi hexdump,

That is great news, congrats. So I think I can close this issue.

Thanks a lot.

-- Remi