uBoot for ES-series?

[xorloser]

I plan to write up some posts on the process once I get some more spare time, but in the interim here is the code from the start() function of the bootloader. This uses some crypto hw regs (I assume in the cpu) to verify the cmac over the bootloader is correct before it will execute Main().

Code: Select all

void start()
{
  unsigned int *ptr;
  int is_end_of_bss;
  
  sr_val = __get_CPSR() & 0xFFFFFFE0 | 0xD3;
  __asm { MSR     CPSR_cf, R0 }
  init_all();
  ptr = (unsigned int *)&timestamp;             // this is a pointer to start of bss area
  do
  {
    *ptr = 0;                                   // zero bss area
    is_end_of_bss_ZF = (char *)ptr == &bss_end;
    ++ptr;
  }
  while ( !is_end_of_bss );
  
  _sdp_mmc();                                   // loads 0x20000 bytes of bootloader to 0x47000000
  if ( !(crypto_hwreg_disabled & 1) )
  {
    crypto_hwreg_cmac_addr = 0x47000000;        // address of start of bootloader in ram
    crypto_hwreg_cmac_size1 = 0x1FFF0;          // size of bootloader to calc hash over
    crypto_hwreg_cmac_size2 = 0x1FFF0;          // size of bootloader to calc hash over
    crypto_hwreg_cmac_cmd1 = 0xC3;              // hash command?
    crypto_hwreg_cmac_hash[0] = 0x210BADD;      // hash at the end of bootloader
    crypto_hwreg_cmac_hash[1] = 0x6C767816;
    crypto_hwreg_cmac_hash[2] = 0x45EE2C72;
    crypto_hwreg_cmac_hash[3] = 0x47EDCF85;
    crypto_hwreg_cmac_cmd2 = 0x23;              // hash command?
    while ( crypto_hwreg_status )               // wait till hash calc is done?
      ;
    while ( crypto_hwreg_result != 1 )          // if hash doesnt match?, enter infinite loop
      ;
  }
  Main();                                       // start main bootloader function
}

[E3V3A]

My guess is that "crypto_hwreg_disabled" is actually the address to one of the BOOT_CONFIG_x pins. These are usually hardwired GPIO pins directly connected to CPU. And in many chips you have SECURE_BOOT mode that tell the processor to check keys and signatures etc...

We have an ongoing discussion about this (based on the service manual) for the BD player HERE.

[sbav1]

My guess is that "crypto_hwreg_disabled" is actually the address to one of the BOOT_CONFIG_x pins. These are usually hardwired GPIO pins directly connected to CPU. And in many chips you have SECURE_BOOT mode that tell the processor to check keys and signatures etc..

Yeah, or it might be some kind of one-time-program/non-volatile setting stored in main SoC. We know there are 2 pre-programmed kinds of CMAC keys supported by Samsung security engine (ROM key and fuse-bit key - not counting arbitrary/user key option), I wonder which one they actually use in onboot hash check - ROM or FUSE key?

In my HT-D7100 (Firenze 2011 BDP) secure boot is actually disabled (0x303f0038 register == 0x1). That seems to be somehow uncommon, there is only one result in google while searching for "Secure boot disabled. skip authentification stage" (i.e, bootlog posted by Samsung developer, having problem with kernel on "TP1001 Evaluation board" - whatever it is).

I suspect this particular Samsung-made "secure boot" is the one directly mandated by CI+ robustness rules, so it's presumably not strictly required to be enabled in BD-player models with no tuner/CI+ slot (?).

[E3V3A]

Currently there is no support in Samsung DTV & BDP kernels for eMMC boot partitions dumping, only for flashing. ...While patching kernel MMC driver sources to allow boot partitions dumping is quite easy (just adding another ioctl call with partition switch command should be sufficient), it's pretty hard to do equivalent thing safely on live/running kernel. So, for bootloader dumping, you'll need to flash custom-build kernel first in your device, OR hope someone will eventually figure out how to dump eMMC boot partition[s] "the hard way", without recompiling the kernel.

What does that mean? Why can't you just use "viewmem" or "dd" to dump? (I.e. In which way are they blocked?)

Too bad we don't have any HW info on these processors! Just incredible...
Someone must have leaked something somewhere. We'd need a pinout diagram or a BOOT-CONFIG description or a detailed schematic.

@nobody: Also, if bootloader is present in "/dev/mmcblk0p0", one reason you don't "see" it as a normal device is that it can be mapped to IROM. That is, it's an internal bootloader, just like the Primary Boot Loader in many Samsung Android phones! Another possibility is that it can be a hidden partition on the eMMC. This way of hiding is in the kernel driver module AFAIR...

[xorloser]

I started to write a reply and then it got so long I decided it was time to do the write up I keep meaning to get around to doing. So check here for info on the whys and hows along with sourcecode to help you do so.

viewtopic.php?f=50&t=5449