xeniter

  • Posts

    28
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xeniter's Achievements

  1. security is a fight which most likely always lost, depending on your enemy you can only increase the effort so its not worth for the opponent to reverse or break into your data. And the effort you put into that depends how much money/effort you will loose if your opponent made it. So depending on that you have to decide how secure you would like to make your system. One Example is hash u-boot and verify its hash. This could be sha1 for example if you trust it now (afak first collision atacks were already made) and long enough in the future to get not cracked soon. (Depending you assume its not already cracked or can be easily calculated with a new quantum computer... as i said always lost... depends only who is your opponent and how much effort/money they are willing to spend on it) if you don't trust a hash enough i have at least no other idea for now how to protect or verify u-boot from spl In that case its better to switch the processor where you get more insights or documentation and a better chain of trust support.
  2. Nice, did you managed it on h3 or h5? Unfortunate (or as far i know) u-boot doesn't have support for it. You must verify it on your own. For example hash with sha1 it you trust it enough (SPL is very limited here from size)
  3. On the allwinner you have still a backdoor over fel mode, you can enter in it secure mode from it. So depends how secure you would like it to have, you can not route this usb if you create your own pcb (still someone could solder it out) or you could burn the fel usb in production like i heard some other do here ( i am still amused by this insane method) Except from the fel backdoor you can burn some keys in the fuses and provide it via u-boot to the kernel (will require own kernel modul for that) and don't forget to decrypt your u-boot environment and disable u-boot console otherwise its still easy to get into it or boot something else
  4. hi, have an issue with booting from toc that sound does not work anymore, have anyone same issue? only when booting with u-boot with sec mode (setenv bootm_boot_mode sec;) its working again, however in that case the linux system has only one cpu core available. edit: sound did not work cause dma did not work, per default dma are disabled, you can enable it via the DMA Security Register. yours, xeniter
  5. how did you you written the key? could you post fel code? assume the felscript to burn fuses will not work for H6 cause the sid register are now on 0x03006000 instead at 0x01C14000 (see https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf) So you need adjust at least the sid part of the script, also there some new efuses for changing boot order. would double check if its not necessary to set them. yours, xeniter
  6. if you have USB/FEL Access you can use code snippets from https://pastebin.com/Aw5q6bdU be aware! you have to adjust the code! this version will burn fuse bits and lock your board, so you have to change it to program only the NV2 zone. what h3 soc do you have? are you sure its not locked? does it boot from a spl or toc header?
  7. thanks for the nice summary, epic fel mode solution( made my day ) why i didn't think about it, hope you verify in your EOL tests that fel mode is really not working anymore
  8. 1) According to Sunxi toc wiki -> You may need to change the entry point address from 0x0 to 0x10000 if you want to run it on A64/H64/H5 (the default 0x0 value is used for H3) have never tested secure toc boot on other hardware than H3, assume it will also work on H5 2) Yes, it is possible to read it via fel mode, since till now as far I know nobody found out how to disable it, the better question is -> is it really possible to disable it... 3) stop dreaming and buy a arm core with documentation or at least from a manufacturer where you can get it, otherwise you are on your own you could try ask allwinner, here some possible answers you may get: there is no documentation about this... what is toc0? <- made my day^^ possible solution: Easiest way is maybe to burn the key in the AES fuses, read it from ram via u-boot and pass it as crypt variable to the kernel parameter (https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration) maybe someone who will use this setup could post the steps, anyhow i wouldn't trust such a step per step without fully understanding each step and its likely you have to adjust anyhow something.
  9. now its only for verification of the spl bootloader, maybe you could write some aes keys in the fuses and use it later for decryption. the h3 has also a crypto engine didn't look into deeper it yet, maybe someone has some experience with it already
  10. @spitfirenice to hear that it finally worked strange that the original tocgen does not work, was lucky that i test the ruby script before. good point with fel mode, would be very interesting if its possible somehow to disable it
  11. looks like your rotpk key is okay verified with: https://pastebin.com/ShSQFe95 rotpk 00000000 1a 18 e6 e9 8f 9a b1 5f 62 6e 1d f9 d8 9f 2b 65 |......._bn....+e| 00000010 9e e8 73 35 21 3d 9c 6f 47 29 f9 a8 c5 6a 32 f5 |..s5!=.oG)...j2.| only used tocgen from lichee when fuses where all zero, did you try it also with jemk egon2toc.rb? here is my bare metal example of writing the key, use it at own risk! and double check you replaced your rotpk (1a=f6.... 94=f5) correctly: https://pastebin.com/Aw5q6bdU to read keys create new main and call print_stuff and add a smc instruction before it to be able to print your burned roptk key via fel mode to run it via fel from sdram: arm-none-eabi-objcopy -O binary main.elf main.bin ./sunxi-fel version ./sunxi-fel -p write 0x2000 main.bin ./sunxi-fel exe 0x2000
  12. hi can you post or pm me the private key? assume hash is wrong, simple sha256 hash of pem file is not correct.. you can use tocgen to generate it for you, or generate it yourself liked described in the sunxi wiki ROTPK_HASH = SHA256([Byte 0-255] = RSA modulus || [Byte 256-x] = RSA public exponent || [Byte x-511] filled with 0x91) means SHA256 from [256 bytes modules + 3 bytes public key exponent ( normally 65537 means 0x010001) + 253*0x91 fill bytes] if you used exactly this key, please try to read the hash back and post me the result + source of reading the rotpk fuse out
  13. yes finally it worked (with jemp script, maybe with tocgen also not tested yet...) you have to write the keys only little endian instead big endian
  14. No results yet... Found maybe the original tool to create toc0, always looked over it. https://github.com/friendlyarm/h3_lichee/tree/75b584e2502450b1e8d2f98ac16fb2410cf8c30a/tools/pack/pctools/linux/openssl looks like with it it could be possible to create a valid toc0 which boots with key (assume jemk scripts are based on it) question is now how to use it, haven't tried it yet edit: generating keys: /h3_lichee/tools/pack/pctools/linux/openssl/dragonsecboot -toc0 dragon_toc.cfg ../../../common/keys/ generate toc0: . /create_toc0 dragon_toc.cfg /h3_lichee/tools/pack/common/keys dd if=./toc0.fex of=/dev/sd? bs=1024 seek=8 > did only boot on my board with rotpk fuses burned with all zeros ): maybe you have more luck (cause maybe i burned fuses in wrong order... or something else...) used this to generate Trustkey.bin to be able to use my old generated key: openssl rsa -in rotprivk_rsa.pem -text > /robart/mdipolt/2del/SECBOOT/h3_lichee/tools/pack/common/keys/Trustkey.bin sboot.bin must be raw bin file (no spl and no elf file!) you can verify your sboot.bin with executing it via fel mode: ./sunxi-fel version ./sunxi-fel -p write 0x2000 sboot.bin ./sunxi-fel exe 0x2000 create_toc0 created the ".\\x509_rotpk.bin" which had the same rotpk checksum as jemk script, so i assume its correct. question is how had it to be written into the fuses xxd -i .\\x509_rotpk.bin unsigned char __x509_rotpk_bin[] = { 0xf6, 0xab, 0x5e, 0x33, 0x80, 0xd9, 0xdd, 0xa8, 0x82, 0x86, 0x85, 0x5f, 0x22, 0xdc, 0x9d, 0xc0, 0xf9, 0xa4, 0x2c, 0xbf, 0xec, 0x05, 0xd0, 0xcd, 0xcd, 0xa4, 0x9b, 0xf4, 0xb4, 0xba, 0xf8, 0x94 }; unsigned int __x509_rotpk_bin_len = 32; i burned it like that: // allwinner H3 == sun8iw7p1 #define SID_PRKEY_NEU (SUNXI_SID_BASE_NEU + 0x50) #define EFUSE_ROTPK (0x64) static void sid_program_key(unsigned int key_index, unsigned int key_value) { unsigned int reg_val; writel(key_value, SID_PRKEY_NEU); reg_val = readl(SID_PRCTL_NEU); reg_val &= ~((0x1ff<<16)|0x3); reg_val |= key_index<<16; writel(reg_val, SID_PRCTL_NEU); reg_val &= ~((0xff<<8)|0x3); reg_val |= (SID_OP_LOCK<<8) | 0x1; writel(reg_val, SID_PRCTL_NEU); while(readl(SID_PRCTL_NEU)&0x1){}; reg_val &= ~((0x1ff<<16)|(0xff<<8)|0x3); writel(reg_val, SID_PRCTL_NEU); return; } for(int i = 0; i < 8; i++) { printf("%08x:", rotpk[i]); sid_program_key(EFUSE_ROTPK+4*i, rotpk[i]); }
  15. hi, did only copy paste the printf somewhere so no warranties. copied the makefile also somewhere together to compile bare metal, also without warranties https://pastebin.com/x9RftzVm is the makefile (make main.elf) original is from https://github.com/linux-sunxi/sunxi-tools/blob/master/uart0-helloworld-sdboot.c had often issues that programmed died, didn't find out why yet so don't trust it the sram is very limited because of the FEL mode see http://linux-sunxi.org/FEL/USBBoot what helped is to load the uboot spl to init ram, after that i copied my program to the ddr ram. ./sunxi-fel spl ./sunxi-spl.bin ./sunxi-fel write 0x40000000 ./main.elf ./sunxi-fel exe 0x40000000 make sure you adjust linker script with correct adress -> main.lds . = 0x40000000; => set program to start of ddr ram found out, or it looks like the ruby tocgen is missing the #define ITEM_NAME_SBROMSW_KEY 0x010303 pack_tools/toc_tools/key_ladder/create_key_ladder.c: key_item_bin.KEY0_PK_e_len = (key0_e_len+1)>>1; typedef struct SBROM_TOC0_KEY_ITEM_info { unsigned int vendor_id; unsigned int KEY0_PK_mod_len; unsigned int KEY0_PK_e_len; unsigned int KEY1_PK_mod_len; unsigned int KEY1_PK_e_len; unsigned int sign_len; unsigned char KEY0_PK[PK_MAX_LEN_BYTE]; unsigned char KEY1_PK[PK_MAX_LEN_BYTE]; unsigned char reserve[32]; unsigned char sign[256]; } SBROM_TOC0_KEY_ITEM_info_t; assume h3 boot code reads length from it, that could be a possible reason why its not booting the toc. haven't tried to add it yet will continue to test it when i have time for it left again...