The Cave

SSTIC 2025 Demos

2025-06-17T00:00:00+02:00

This is just small post to share the videos of my SSTIC talk.

Stm32wb55 FUS 2.0

2025-06-07T00:00:00+02:00

A few days before my SSTIC presentation Récupération de la clé des firmwares radio du stm32wb55 (in french), while doing my slides, I was made aware of a new release of the FUS for the stm32wb55. And of course, the attack I was going to present 5 days later was no longer working...

No release for 4 years, and a month before my talk, a new release with fixes ?

So I was good for a speedrun analysis of FUS 2.0.

What was fixed

Race condition in flash_erase_page

The code that was handling flash page erasure was changed from something like

void flash_erase_page(int page) {
   uint32_t cr;
   cr = Flash.C2CR;
   Flash.C2CR = page << 3 | cr & 0xfffff807 | 0x2;
   Flash.C2CR |= cr 0x10000;
}

to something like that:

void flash_erase_page(int page) {
  uint32_t cr;
  cr = Flash.C2CR;
  Flash.C2CR = page << 3 | cr & 0xfffff807 | 0x10002;
}

Preventing indeed a race condition that was allowing us to change the page FUS was wanting to erase.

Ensuring OBL_LAUNCH

In FUS 1.2.0, the code to launch an OBL_LAUNCH was like this:

void launch_obl(void)

{
  dword dVar1;
  int iVar2;

  iVar2 = wait_flash_done(0xf00000);
  if (iVar2 == 0) {
    dVar1 = read_volatile_4(Flash.CR);
    /* Trigger OBL_LAUNCH */
    write_volatile_4(Flash.CR,dVar1 | 0x8000000);
  }
  return;
}

So, if OBL_LAUNCH was forbidden by OPTLOCK, the reset would not occure and the FUS state machine was running the next step.

In FUS 2.0 the code is more like this:

void launch_obl(void)

{
  dword dVar1;
  int iVar2;

  iVar2 = wait_flash_done(0xf00000);
  if (iVar2 == 0) {
    dVar1 = read_volatile_4(Flash.CR);
    /* Trigger OBL_LAUNCH */
    write_volatile_4(Flash.CR,dVar1 | 0x8000000);
    /* Trigger ARM reset */
    SCB.AIRCR = 0x05fa0004;
    while(1);
  }
  return;
}

Thus, enforcing a reset, and so preventing the state machine to run the next step unprotected (more details on attack in the original blog post)

Changing the FUS state machine

The FUS 1.2.0 state machine for firmware installation was this one:

My original attack was at step 3, preventing the flash protection to be effective and then messing with the flash during step 4 to gain code executin on CPU2.

But there was another attack that could maybe have been done. During step 2, the CPU2 was calculating the hash of the ecnrypted firmware to feed it to the PKA. This hash is slow to compute (especially if you slowdown CPU2). So it would have been possible to change the encrypted binary (tricky, changing the start is easy but since the last page of the firmware has a hash of the unencrypted firmware, you must manage to at least write the last page of the firmware).

ST probably spotted this potential issue and then choose to change the FUS 2.0 state machine to:

Closing the window...

So, with this new state machine, The first step is to protect the flash by changing SFSA and performing an OBL_LAUCNH (with the protections mentionned above).

So, as the flash was protected from CPU1 during both validation ans decryption of the image, we were no longer capable of altering the flash.

I was starting to think that my talk was going to end by "But this no longer works".

Wait

...and opening the door

When FUS 2.0 has to protect the flash, it must know what size to protect right ? Ha yes, the header in the wireless image has a Flash (nb of 4K sectors) byte. And this header is validated by the firmware signature.

The code handling this is somehow like this:

void protect_flash(struct header *header) {
   int start_page;
   start_page = 0xf4 - header->pages;
   /* write SFSA */
   FLASH.SFR = FLASH.SFR & 0xffffff00 | (start_page & 0xff);
   obl_laucnh();
}

Appreciate the & 0xff... so by feeding 0xf5 in the header, the CPU2 would only protect the upper page of the flash...

Yes, but the header is validated by the signature.

...

Omg, the signature is only checked after the flash is protected !!!

...

 ____                          _   _
|  _ \__      ___ __   ___  __| | | |
| |_) \ \ /\ / / '_ \ / _ \/ _` | | |
|  __/ \ V  V /| | | |  __/ (_| | |_|
|_|     \_/\_/ |_| |_|\___|\__,_| (_)

TLDR

Write 0xf5 in the wireless image page info
Start the installation (FUS perform a reboot)
Notice that SFSA is at 0xff
Patch FUS to no longer check signature
Enjoy

Conclusion

This is how, with a 3 night work, instead of finishing my talk with shame, I got applaused ;)

ECC collision HOWTO

2024-10-29T00:00:00+01:00

This is a small blog post I would have been happy to read while searching how to find ecc collision when dealing with how to exploit a limited write to flash.

No rocket science, just a little write-up.

Short Context

While working on a target, I found a primitive that allowed me to overwrite a flash page. By overwriting I mean, writing again. If you are not familiar with how some flash works, they must first be erased (aka, every bit is set to 1 (or 0) level, and the written (a bit can be flipped to the other state). Overwriting is doing the same flip again, but you can only flip on bit in the erased state to the written state.

ERASE
flash state:
0xffffffff

WRITE 0xffffff01

flash state:
0xffffff01

WRITE 0xffffff00

flash state:
0xffffff00

WRITE 0xffffff01

flash state:
0xffffff00

See ? On the last write, the last bit was not set back to 1, but kept to 0.

So, this set up with a limit on what we can overwrite to the flash page (eg, if this is the first page to be executed, a jump to another place), but this is something that can dealt with easily.

Let's imagine that we have the jmp 0x00abcd encoded as 0x8000abcd and that 0x00000000 is a nop

Inital flash state:
0x8000abcd 0xffffffff 0xffffffff ... 0xffffffff
[jmp 0xabcd]

WRITE 0x00000000 0x80e00000 0xffffffff

flash state:
0x00000000 0x80e00000 0xffffffff ... 0xffffffff
[nop, jmp 0xe00000]

and now we can jump to our (controlled) code

Here enter ECC

Unfortunatelly, the flash I was dealing with had a protection mechanism to deal with errors. Internally, every 256 bit pages of data was stored on 256+22 bits, and those 22 bits kept an ecc code to detect (and correct) errors.

(ECC stands for Error Code Correction)

A quick overview of what the problem is, with samller bits numbers:

Wen doing a normal write of data

ERASE
flash state:
DATA: 0xffffffff ECC: 0xff

WRITE 0xFFFFFF01 (calculated ecc=0x20)

flash state:
DATA: 0xffffff01 ECC: 0x20

An ecc code is calulated and written

For another data, the ecc is different:

ERASE
DATA: 0xffffffff ECC: 0xff

WRITE 0xffffff00 (calculated ecc=0x30)

flash state:
DATA: 0xffffff00 ECC: 0x30

This mess with with our overwriting scheme (since ecc bits are stored in the flash, they also cannot be switched back to erase state)

eg:

ERASE
flash state:
DATA: 0xffffffff ECC: 0xff

WRITE 0xFFFFFF01 (calculated ecc=0x20)

flash state:
DATA: 0xffffff01 ECC: 0x20

WRITE 0xFFFFFF00 (calculated ecc=0x30)

flash state:
DATA: 0xffffff00 ECC: 0x20 = (0x30 & 0x20)

And here, the flash controller will detect that 0xffffff00 and 0x20 don't match.

The necessary maths (or not)

Disclaimer, I am not (I mean, no longer) a math guy, so I'll just put here the basics things needed to understand.

The Ecc code generated is an hamming code. It has surely a lot of property, but what will interest us in the cas of ecc colisions, is that:

Is is generated by a simple multiplication by a generation matrice
at the bit level, the sum is a xor

(for more maths, go to wikipedia)

so:

Ecc(DATAS_BITS) = DATA_BITS x GEN_MATRICE

and:

Ecc(DATA1 ^ DATA2) = Ecc(DATA1) ^ Ecc(DATA2)

Calculating ECC

Back to our problem. We have:

Inital flash state:
0x8000abcd 0xffffffff 0xffffffff ... 0xffffffff ECC(inital_data)
[jmp 0xabcd]

We want:

flash state:
0x00000000 0x80e00000 0xffffffff ... 0xffffffff ECC(new_data)

With

ECC(new_data) & ECC(initial_data) == ECC(new_data)

(ie, no bit writtent to zero in initial_ecc must be switched back to 1 in new_ecc)

But we may also be happy with

flash state:
0x00000000 0x80e00000 0xefffffff ... 0xffffffff ECC(new_data_2)

With the same constraint:

ECC(new_data_2) & ECC(initial_data) == ECC(new_data_2).

The first 64 bits of our payload need to be fixed, but we don't care of the state of the (256 - 64) bits remaining. So we have some latitude to forge a payload that will satisfy the constraint.

Remember that Ecc are additive ?

Let's call bit_array_n the 256 bits set to 0 except for bit n set to 1.

So here, as we have

new_data_2 = new_data ^ bit_array_65

we have

ECC(new_data_2) == ECC(new_data) ^ ECC(bit_array_65)

Let's call ECC_n = ECC(bit_array_n ( the ECC value of 256 bits set to 0 and bit n set to 1). (We can use an unprotected dev board of the same chip to extract thoses).

And for any interesting test_data, we have N bits (i1, i2, ..., iN) such as

test_data = new_data ^ (bit_array_i1 ^ ... ^ bit_array_iN)

and

ECC(test_data) = ECC(new_data) ^ ECC_i1 ^ ... ^ ECC_iN

Finding the collision

Now we can easily compute the ECC of any payload we will try to overwrite. But we still needs to find a collision, ie, we need to find the set of bits from 65 to 256 to set to zero in order for the resulting ECC to be initial_ecc.

So we must find (i1, i2, ..., iN) within {65..256} such that

ECC_i1 ^ ... ^ ECC_iN = ECC(new_data) ^ ECC(initial_data)

In order to do so, we first build for each couple and triplet of bits:

ECC(i,j)   = ECC(i) ^ ECC(j)
ECC(i,j,k) = ECC(i) ^ ECC(j) ^ ECC(k)

And sort them by the number of bits set, and keep the ones with only 3,4 bits set.

We have something like:

ECC(069,146)      002100a0 (04 bits changed)
ECC(065,066)      00012880 (04 bits changed)
ECC(130,134)      00012804 (04 bits changed)
ECC(236,132)      00004281 (04 bits changed)
ECC(227,108)      00004805 (04 bits changed)
...
ECC(128,145,153)  00000284 (03 bits changed)
ECC(231,124,144)  00000282 (03 bits changed)
ECC(224,078,155)  00000281 (03 bits changed)
...

At that point, I stopped doing automated thing and started to search by hand which bit set would produce the desired ECC(new_data) ^ ECC(initial_data), noticing that some combo leads to a one bit setter (eg ECC(224,078,155) ^ ECC(236,132) = 0x4000)

I was lucky in that ECC(new_data) ^ ECC(initial_data) had only a few bit set. But hasn'it be the case, I would first search the ECC_i space that would have minised the number of bits set.

I also didn't handle the case where a bit is part of two set you want to use.

For the record, here is the sequence I identified:

target ecc 22e773
set_1:
00220202 ->  e571
set 2
00000502 ->  e073
set 3
00009011 ->  7062
set 4
00007000 ->    62
set 5 & 6
00020240
00020220 ->     2
set 7 & 8
00340002
00340000 ->     0

And voilà !

I can now overwrite the flash page with a controlled jump without the flash complaining about Ecc errors.

Conclusion

I tried to make this as much simple as I could, but reading it back, not sure I managed to do so.

Also note that, in my case, the ECC was also calculated on the address of the flash page, but in the end, it does not change the approach used.

Feel free to share if you found this interesting.

Bypassing a noexec by elf roping

2023-11-27T00:00:00+01:00

In this post, I will show you how I bypassed a noexec permission in a limited chrooted env.

Short Context

Ok, so you have found this vuln in this software. You're happy. You can upload file, and you have the opportunity to execve a provided string. All seems done and you can enjoy a well deserved beer.

But no.

The service you hacked is well limited in facts. The upload directory is a tmpfs with noexec mount option. And the service runs in a chrooted env with no shell (sorry, no /bin/sh -c /tmp/upload/myscript.sh)

Disclaimer

I don't pretend this a new approach or something never seen before. Just something I wasn't aware of ;)

Initial attempts

Luckily for us, even if the chroot is hardened, the provided application are dynamic executables, so we have access to ld.so and libc.so. In facts, in this system, it is the same musl binary.

My first attempt was to upload an elf in the tmpfs, and try an /lib/ld.so /tmp/uploaded.bin in order to bypass the missing -x permission on the file.

While I later learnt it used to be a classical noexec bypass, kernels nowdays refuse to mmap part of a file on a nonexec fs with the PROT_EXEC flag set, so no luck here.

First Victory

While playing with ld.so, I noticed something that proved very interesting, memory locations of ld.so and the uploaded.bin elf file, while randomized due to ASLR, were fixed relative to each other. This is not the case when executing an elf the normal way.

Another thing to notice, is even if my elf binary is non-executable (and hence non executed), it still can be loaded. You just have to have no PROT_EXEC segment in it and ld.so and the kernel will happily map it.

Once loaded, the last thing ld.so will normally do, is to branch to your entry point. Obviously, since we have changed the segments to be non executable, it will fail miserabily.

When exploiting, and you encounter a non-executable writeable address space is to go roping.

Remember that our loaded elf and libc.so are at a static offset ? So with a little math, we can tell ld.so that our entry point is far away from our loaded segments, but rather in the libc.so .text section ;)

And it works !

We just need now to carefully choose where we are going to jump.

But if we are going to rop, we need to be able to build a full ropchain on our stack, and unfortunately, the stack when entering the entry point is not really adapted... We just have a pointer to the argv and env strings in the stack.

Our best chance would be to be able with one gadget to swap the stack to a memory controlled region. But this turns out to be difficult (at least with the libc.so I was targeting) without a little more help.

A very well suitable function to switch stack is the longjmp which restore an executable context.

There are already calls in the ld.so that makes use of it.

FUN_00148920("Error recording dependencies for %s", lVar9);
if (DAT_001919e8 != 0) {
        /* WARNING: Subroutine does not return */
          longjmp(DAT_001919e0,1);
}

What is interesting is that the pointer to the structure used for the longjmp call is a writeable global.

Abusing Relocation

(hum, I may have spoiled a little here ... )

What's fun with elf loading is relocations. It basicly tells the loader, "Hey, I will need to use this function, please write me its position here, so that I can use it". (There are Far better tutorials on relocation on the internet...).

In fact you can even add an addendum to the position of the symbol you want the loader to inform you about.

Remember how we tell the loader to set our entry point to where we want inside the libc.so ? Well, we can use the same trick to let the loader know that we want address of symbol_a + addendum written inside the libc.so writeable .data section. For exemple at the position of the pointer used during the longjmp call.

fffffffffe7fd9e0  001800000101 R_AARCH64_ABS64   000000000000000 puts

And what's even more beautiful, is that we can use the loader to have the relocation point to our own object:

struct init_stack rop_exec_stack = {
  .sp = &rop_stack.rop_chain,
  .x30 = GADGET(START_STACK_GADGET),
};

void *address_of_rtld_fail = (void*)&rop_exec_stack;

After patching the elf:

fffffffffe7fd9e0  001800000101 R_AARCH64_ABS64  0000000000186140 \
                                                rop_exec_stack + 0

Now, we juste have to point entry to the call to longjmp, and our first and only gadget will have everything done for us... We have set the stack pointer to our rop-chain that we can carefully write now...

Wrapping it all together

I must admit this was not the funniest part, finding suitables gadgets is very time consuming (especially on AARCH64 I found).

We can still use the loader to have it calculate values and offsets for us

But after some amount of time, I was able to write a rop chain that malloc a huge buffer, mprotect it to have it executable, memcpy a payload (embedded in the uploade.bin file) and then jump in it.

And it is easy (as in, easy once done) to embedded a static elf in our payload and have it executed.

Now, you can work on escaping the chroot, but that is another story...

Final thoughts

This was fun (and hard) to work on this. I wrote this one shot, after final succes, so typos / error may be present (don't hesitate to contact me !)

Feel free to share this blog post (and others ;) ) if you found it interesting.

Extracting stm32wb55 CPU2 firmware key

2022-07-21T00:00:00+02:00

The stm32wb55 mcu is a dual core (cortex-m4/cortex-m0) mcu with integrated wireless capabilities (ble/thread/zigbee).

The first core (the m4, later referred as CPU1) is for the customer. The second core (m0 known as CPU2 is dedicated to the low level wireless handling. The customer does not have access to this second core, neither to the firmwares running on it. Plus there is a bunch of security features embedded in the mcu to prevent access.

Why does this suck ?

I could understand the company did not want to provide the customers direct access to the wireless core (I assume that the low level stacks are valuable assets).

But

If you choose to go this way, at least don't mess up with the customer code.

It appears that various operation involving the CPU2 (the wireless dedicated core) are not tolerant to interruption (power outage, cpu1 reset, more...) and, as stated in some documentation of the mcu, may lead to a bricked device, or to the need of a manual factory reset (which means a full erase of the cpu1 customer code, which is equivalent to a bricked device)

This clearly sucks and I don't like it, so I decided to give it a look, to see what I could find.

A short presentation

The mcu comes with an embedded sram and flash. Both are shared between CPU1 and CPU2, but parts of the sram and the flash are dedicated to CPU2. There is an integrated features that prevent all access to customizable regions of the flash/sram except for CPU2. Neither CPU1, dma or anything else can access it.

We will focus on the flash, which is splitted by pages of 4k.

The region dedicated to the cpu2 is selected by setting the first page to be locked. All other upper pages are locked.

Setting this first locked page is done by writting in the so-called option-bytes registers (SFSA for the secure flash start address) which is a small dedicated flash. Of course, write access to this part of the options bytes is allowed only to CPU2.

Another CPU2 related option bytes is the boot address of the cpu (SBRV). Once again, write access is restricted.

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
          |             |
          +-------------+ <- SFSA
          |             |
          |             |
          | CPU2-only   | <- SBRV
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

             Overview

And obviously, dbg access to the CPU2 can also be forbidden.

Introducing FUS

FUS stands for Firmware Update Services. Basically, it allows to switch between different wireless stacks, handling all of the secure processing.

The mcu is sold to the customer with FUS already installed at the end of the flash.

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
          |             |
          |             |
page 0xf4 +-------------+ <- SFSA / SBRV
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

             FUS only

The last pages of the flash are marked as secure, and the boot vector of the CPU2 is set to the start of FUS.

With a shared mem and an hardware inter-processor communication mechanism (out of scope), the customer application code can order FUS to perform some tasks.

For example, it can request to install a wireless firmware. To do so, the ST-provided image must be written in the internal flash, and an FUS_FW_UPGRADE command must be sent to FUS.

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+
          |             |
          |  encrypted  |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+ <- SFSA / SBRV
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           Before install

As stated in the documentation (AN5185 on ST site), there will be some expected reboots during the install procedure. This is due to the fact that option bytes modifications are only applied after a reset. In fact there is even a special bit (OBL_LAUNCH) in a register in the flash controller that performs this reset.

Let's monitor SFSA/SBRV during this install process.

After first reset

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+ <- SFSA
          |             |
          |  encrypted  |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+ <- SBRV
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           First reset

The firmware and FUS pages are secure, but the CPU2 still boots on FUS.

Then there is another reboot and we have:

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+ <- SFSA / SBRV
          |             |
          |             |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           After install

At this point the wireless firwmare is runing. We can still however ask it to switch back to FUS. We then have again

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+ <- SFSA
          |             |
          |  encrypted  |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+ <- SBRV
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           FUS activated

We can ask to delete the current wireless firmware with FUS_FW_DELETE, and after another reset:

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+
          |             |
          |    Empty    |
          |    Pages    |
          |             |
          |             |
page 0xf4 +-------------+ <- SBRV / SFSA
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           FUS running

(of course, the unciphered wireless image is erased...)

A similar procedure can be used to upgrade FUS itself, involving more reset (probably due to a phase of relocation of the new FUS on top of the old FUS).

Firmware image ...

Let's look at the provided wireless firmware / FUS upgrade images provided by ST. They are (sort of) documented in the ST application note. Obviously, they are signed by ST, and encrypted, so not much to do as of now. Still, dig inside the github repository.

... hidden in plain sight

More precisely, look at the history of the firmware binaries. We can see updates andnew wireless protocols released. But there is more... during release v1.5.0, a file with a different pattern name appears: stm32wb5x_FUS_fw_1_0_2.bin...

And yes...

above all odds,

it's the unciphered binary !!!

Well, at least, we have something to work on. Even if it is not the latest FUS version, we may learn some valuable info.

Wireless install steps

After a bit of reversing of the FUS image, the wireless image install process can be more detailled.

Step 1 Image authentication

When ordering to procede to a wireless image install, FUS first search for 2 footers. The one with the ST signature, and the one with the image info.

A sha256 of the image is then calculated and an edcsa verification is performed, using an embedded (but hidden) public key. This ecdsa verification uses the PKA (public key accelerator) hardware block.

int verify_signature(void *start,int len,
                     void *pub_key, void *signature)
{
  int iVar1;
  int ret;
  char hash [32];

  ret = 1;
  zero_mem(hash,0x20);
  iVar1 = init_pka();
  if (iVar1 != 1) {
    ret = sha256(start, len, hash);
    if (ret == 0) {
        iVar1 = pka_ecdsa_verif(hash, pub_key, signature);
        if (iVar1 != 1) {

         ret = 1;
        }
    }
    stop_pka();
  }
  return ret;
}

If the image is authenticated, FUS saves it state in a dedicated page at the end of the secured part of the flash, set the SFSA register to the beginning of the image and trigger an OBL reset.

Step 2 Deciphering the image

FUS restart and knows it must now decipher the image. This is done in place by using AES in CTR mode with a nonce provided in the image footer, a start number of 2 (because why not) and a key stored in the end of the secured part of the flash. Each page is deciphered in a temporary memory buffer, erased, and the rewritten with the cleartext.

Once done, the next step is to save the state in the internal flash, set SBRV to the entry point of the wireless image and trigger an OBL reset.

The PKA

This hardware block accelerate calculation for various public key algorithms. It has a dedicated ram used to store various parameters (with hardcoded offset for each mode of calculation). Once setup and started, the block is busy during a while until the result beeing available (again, at an hardcoded offset of the PKA ram).

So, why don't we try to monitor the PKA registers during step 1 of the install process ?

So, I wrote a small loop on my demoboard that would monitor PKA status register, and indeed, I saw the FUS using the block.

Next steps is to see if we can override the PKA result, and thus bypass signature verification.

First, slightly modify the image so that the signature does not match, but still the image is valid, by modifying the build version in the image footer. Indeed, an attempt to install this binary fails with an FUS_STATE_IMG_NOT_AUTHENTIC error.

Then retry the install whilemonitoring the PKA End of Operation flag, and then quickly write 0 at the right place in the PKA ram.

And install continues !

Good, we can bypass signature verification.

I was about to focus on how to exploit this signature bypass, but unfortunately, later on, while poking with the demoboard, I accidentally bricked it (don't remember exactly how).

So I try to reproduce the signature bypass with a custom board, but it constantly failed...

Hardened FUS - 1

In facts, the demoboard was programmed with the v1.1.1 of FUS, but the purchased stm32wb55 were programmed with v1.2.0. There must have been some changes in this area.

I retry my monitoring of the PKA status register and found that it seems not to be used. Reading the reference manual, I spotted a feature I was not aware of. Access to the PKA block can dynamically be restricted to CPU2 by writting in the SYSCFG_SIPCR. And indeed, FUS v1.2.0 seems to use this feature. So goodbye signature bypass on this version...

You shall not erase !

At that point, it was logic to try to recover the cleartext of this new version of FUS.

I liked the approach of monitoring FUS activity by watching the various block status/control registers, so I wrote a small monitor of the flash activity of FUS during the deletion of firmware. And we can clearly see FUS erasing pages one at a time before switching back SFSA.

But look at the (old) code:

void flash_erase_page(int page)

{
  dword cr;

  cr = read_volatile_4(Flash.C2CR);
  /* write page to erase */
  write_volatile_4(Flash.C2CR,page << 3 | cr & 0xfffff805 | 2);
  /* re read */
  cr = read_volatile_4(Flash.C2CR);
  /* start erase */
  write_volatile_4(Flash.C2CR,cr | 0x10000);
  return;
}

See how the register is re-read ?

So, I wrote a little code that monitor Flash.C2CR, wait for the desired page to be scheduled for an erase and overwrite the value with a different page. And it worked ! Not a 100% success, but still enough to grab each erased page one by one.

Applied this technic during a FUS self-update from v1.2.0 to v1.2.0 and I managed to get the code for this latest version of FUS.

Hardened FUS - 2

First, I wanted to go back to the PKA call just to confirm what I suspected.

int verify_signature(void *start, int len,
                     void *pub_key, void *signature)
{
  int iVar1;
  int iVar2;
  int ret;
  char hash [32];
  undefined4 local_18;

  ret = 0x37921932;
  memset(hash,0,0x20);
  iVar2 = init_pka();
  if (iVar2 != 1) {
    /* lock pka access */
    iVar1 = read_volatile_4(SYSCFG.SIPCR);
    write_volatile_4(SYSCFG.SIPCR,iVar1 | 4);

    ret = probably_hash(start, len, hash);
    if (ret == 0) {
        ret = pka_ecdsa_verif(hash,pub_key, signature);
    }
    deinit_pka();

    /* unlock pka access */
    iVar1 = read_volatile_4(SYSCFG.SIPCR);
    write_volatile_4(SYSCFG.SIPCR,iVar1 & 0xfffffffb);
 }
 return ret;
 }

Yes, it is now locking PKA access from CPU1 during signature check. Also, quite funny:

i = verify_signature(next_sfsa, len + 0x20, &st_pub_key, &signature);
if (i == 0x29912337) {
   /* signature ok */
   write_flash_sfsa((int) next_sfsa);
}

verify_signature is now returning a weird 0x29912337.... Looks like someone attended an "How to protect your code from fault attacks" course...

Burn after reading

Remember that any changes to sfsa requires a reset, triggered by a write to the OBL_LAUNCH bit of the FLASH_CR register of the flash controller ?

3.10.5 - Flash memory control register (FLASH_CR)

...

Bit 27 OBL_LAUNCH: Forces the option byte loading

When set to 1, this bit forces the option byte reloading.
This bit is cleared only when the option byte loading is complete.
It cannot be written if OPTLOCK is set.

0: Option byte loading complete
1: Option byte loading requested

Yes, there is a mechanism to prevent unwanted write to the flash controller by first entering a sequence 2-words key sequence before beeing abale to perform some write and erase. And another sequence for option bytes.

Turns out that you can also relock access by writing a 1 to the LOCK bit of the controller.

With that in mind, I came with a strategy:

let the PKA verify signature
monitor the SYSCFG.SIPCR to know when it is has done so
wait for the state and SFSA to be writtent in flash/option bytes by monitoring flash activity
lock OPTLOCK to prevent OBL reset
rewrite the signed firmware with my modified one
unlock OPTLOCK to reset and make FUS continue

As I did not want to brick my board on the first try, I just made a first test without the flash rewriting step.

Here I must first admit I had made a mistake when thinking at my strategy. Instead of the real code:

void launch_obl(void)

{
  dword dVar1;
  int iVar2;

  iVar2 = wait_flash_done(0xf00000);
  if (iVar2 == 0) {
    dVar1 = read_volatile_4(Flash.CR);
    write_volatile_4(Flash.CR,dVar1 | 0x8000000);
  }
  return;
}

I had this version in mind:

void launch_obl(void)

{
  dword dVar1;
  int iVar2;

  iVar2 = wait_flash_done(0xf00000);
  while(1) {
    dVar1 = read_volatile_4(Flash.CR);
    write_volatile_4(Flash.CR,dVar1 | 0x8000000);
  }
  return;
}

I was thinking that, locking the OPTLOCK would let the CPU2 in an endless loop, and after unlocking OPTLOCK the board would reset and continue the install process. So, I was expecting a reset and this situation:

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+ <- SFSA
          |             |
          |  encrypted  |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+ <- SBRV
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           FUS activated

CPU2 code execution

I did have a reset, but after it, I was in this sitation:

page 0x00 +-------------+ <- 0x0800000 start of flash
          | customer    |
          |   code      |
          |             |
          ~ ~ ~ ~ ~ ~ ~ ~

          ~ ~ ~ ~ ~ ~ ~ ~
          |             |
page 0xdc +-------------+ <- SFSA / SBRV
          |             |
          |             |
          |   wireless  |
          |   firmware  |
          |             |
page 0xf4 +-------------+
          |             |
          |     FUS     |
          |             |
page 0xff +-------------+ <- 0x080fffff end of flash

           After install

With a running wireless firmware.

Indeed, this is coherent: the FUS had stored its state in flash, but was expecting a reset in order for SFSA to be updated. Instead, it just returned from the launch_obl() function and continue the next step in his state machine, until the next OBL reset (the one needed to change th SBRV)

But what is the next step after image signature verification ? Yes... unciphering.

So instead of waiting for the reset after unlocking back the OPTLOCK, I monitored the flash pages where the image was written, and bingo, I clearly saw pages beeing erased and rewrittent. I had access to the unciphered image...

Good, but I had already access to the code...

...

Wait...

I have read access to the unciphered image but I can also modify it !

The path now was straightforward: change the first page with a reset vector pointing to an unsecure flash page while FUS was unciphering the other pages and wait for the OBL reset.

Of course, after the reset the CPU2 was stuck, but after writing at the controlled page a jump back to the expected reset vector, the CPU2 was back online and functionnal.

Key extraction

Then, instead of jumping back to the firmware, I wrote a small dumper code that will exfilter the upper pages of the secure zone of the flash to a CPU1 readable area.

Within thoses pages, lies the AES key used by FUS to uncipher the firmware images.

 ____                          _   _
|  _ \__      ___ __   ___  __| | | |
| |_) \ \ /\ / / '_ \ / _ \/ _` | | |
|  __/ \ V  V /| | | |  __/ (_| | |_|
|_|     \_/\_/ |_| |_|\___|\__,_| (_)

Conclusion

Security through obscurity is not security.
FUS also has a service to store customer AES keys inside the secure flash. My advice is not to use this to store valuable encryption keys, since they can now been extracted also.

If you enjoyed this read, feel free to tweet about it, or to contact me

Firmware key extraction by gaining EL3

2022-06-07T00:00:00+02:00

A bit of history

A few months back, I turned my attention on my fiber gateway. So I ordered the same model on ebay, unsoldered and dump the nand, and after a lot of work, managed to have a clear view of the system, from bootloader to userland.

Basically, the bootloader check the signature of the kernel image, uncrypt the kernel image with a bootloader stored key, which in turn, uncrypt the rootfs image and voila.

[YYYY] / # ls
README       dev          lib          opt          sbin         usr
bin          etc          media        proc         sys          var
config       exports      mnt          root         tftpboot
ctmp         home         nonexisting  run          tm
[YYYY] / # cat README
If you can read this, congratulations !

Feel free to drop me an email, xxxx@yyyy.zz

I managed to flash a custom rootfs (since only the kernel was signature checked)

So I contacted the vendor, and explained what I did.

They fixed the issue by adding a signature check on the rootfs, and told me that, even if "impressed", as this was an old model with no secure boot nor secure storage, it was easy (as in "yes we know we can not secure this").

And they were right, nothing would have prevented me from flashing my own bootloader with my own public key or signature bypass.

Still, I was happy.

Then, a challenge came to my mind: "what if I could break into their latest model?"

So back to ebay.

First glimpses

I tried to apply the same methodology with more or less success

But still, with more ebay purchases, I managed to get a dump.

Which was obviously encrypted. Even the bootloader... so, secure boot, as expected.

Serial Output

Probing unpopulated connector footprints on the pcb during boot did not lead to anything. But I finally managed to find the serial signal on one resistor.

Following the tracks, it leads to the usb-c power connector, through some small IC. Adding a pull-up to the SBU pin of the usb-c connector and we have the bootlogs directly on the usb-c connector:

----
BTRM
V1.2
L1CD
MMUI
MMUA
DATA
ZBBS
MAIN
OTP?
REF?
REFP
RTF?
RTFP
OTPP
FSBT
EMMC
IMG?
IMGL
UHD?
UHDP
RLO?
RLOP
AHD?
ROT?
ROTA
MID?
MIDP
AHDP
SBI?
SBIA
PASS
HELO
5.0206-1.0.38-42.42
CPU0
L1CD
MMUI
MMUB
ZBBS
MAIN


xxx8a cfe decompressor (ROM).
DDR test done successfully
  - Decompressing ...
  - Decompression OK Load 1fc00000, Entry Point 1fc00000.

Base: 5.02_06
CFE version 1.0.38-163.180 for BCM963158 (64bit,SP,LE)
Build Date: Fri Dec  6 19:01:14 CET 2019 (xxxx@yyyy)
Copyright (C) 2000-2015 Broadcom Corporation.
XXX Version: 1.0


.text:   000000001fc00000-000000001fc2ea00
.rodata: 000000001fc2f000-000000001fd253f8
.data:   000000001fd26000-000000001fd26fc0
.bss:    000000001fd26fc0-000000001fd2c3f8
.stack:  000000001fd2e000-000000001fd6e000
.heap:   000000001fd6e000-000000001ff8e000

CPU Started with slow freq strap.
POR CPU frequency: 400 Mhz
CPU frequency set to 1675MHz
Boot Strap Register: 0x3fffff77
Chip ID: BCM63153_B1, Broadcom B53 Quad Core: 1675MHz
Total Memory: 536870912 bytes (512MB)
Enabling CCI500 coherency ... Done.
pmc_init:PMC using DQM mode
MMC: bus setup with width 8, sdr
SDHCI MMC init done.
i2c-gpio: using gpio24 (sda) gpio25 (scl).
i2c-gpio: using gpio15 (sda) gpio16 (scl).
fb0: SSD1320 frame buffer device (160x80 screen)

Serial: xxxx-xx-x-(xx)xx-xx-xxxxx / 0
Mac:    xx:xx:xx:xx:xx:xx
Bundle: xxxxxxxxxxxxxxxx

## Booting in standard mode.
 - Trying to load new bank0: no bank0 to flash, read fail
Loading firmware from 'emmc0:bank1': 31432192 bytes in 0.707 seconds.
ATF partition at offset 0000000011801000, size 11956
 - Validation stage 1.
 - Validation stage 2.
 - Kernel signature OK!
 - Decrypting kernel.
OP-TEE partition at offset 0000000011804000, size 129524
 - Validation stage 1.
 - Validation stage 2.
 - Kernel signature OK!
 - Decrypting kernel.
kernel partition at offset 0000000011824000, size 4574388
 - Validation stage 1.
 - Validation stage 2.
 - Kernel signature OK!
 - Decrypting kernel.
dtb partition at offset 0000000011c81000, size 21940
 - Validation stage 1.
 - Validation stage 2.
 - Kernel signature OK!
 - Decrypting kernel.
NOTICE:  BL31: v1.4(release):42d1e692
NOTICE:  BL31: Built : 18:19:32, Oct  2 2019
I/TC:
I/TC: OP-TEE version: 3.7.0-110-g6ba85038 (gcc version 8.3.0 )
                       #1 Tue Jan 28 13:57:39 UTC 2020 aarch64
I/TC: rng200_rng_init ...
I/TC: RNG200 init done.
I/TC: Initialized
ATF returned in EL2.
E/LD:  init_elf:259 sys_open_ta_bin(7011a688-ddde-4053-a5a9-
7b3c4ddf13b8)
E/TC:? 0 init_with_ldelf:229 ldelf failed with res: 0xffff000e
E/TC:? 0 tee_ta_open_session:727 Failed. Return error 0xffff000e

Arm Trusted Firmware, Op-tee, all signed and encrypted...

Test mode

During my work on the previous model, I found that by shorting two pins of one connector on the pcb, the board booted in a so-called test-mode. This mode, after a custom network authentication, allow to boot on a network loaded firmware image without signature check.

So I needed to do two things:

Trigger the test mode on the new model
Do the network authentication

To ease the process, first, let's get root on the device (sorry, won't cover that part, I know it's an achievement in its own, but I am focused on breaking secure boot, and yes, it would be sufficient to display the Pwned message on the screen of the device...but we are not here just for the lulz).

We can find some interesting things in /sys/class

[YYYY] / # ls /sys/class/xxxgpio/boot-eth
data_in    data_out   device     direction  pin_num    subsystem  uevent

boot-eth ? Sounds good !

[YYYY] / # while true; do
> cat /sys/class/xxxgpio/boot-eth/data_in
> sleep 0.1
> done
0
0
0

And then start poking arround all test points until we can see a 1 showing up.

I am focusing around the usb-c connector (just a feeling) and all the glue.

And it's a match.

Well, sort of. It seems that when injecting 3.3v on one test point, the gpio value alterns between 0 and 1. But injecting the 3.3v at the right time on boot get us a straight 1.

I got the feeling that "boot-eth" can be triggered by an appropriate usb-pd command/response, the test point coming from a gpio output of the usb-pd chip

I decided to cope with that, and not searching more. Since I can easily trigger test mode with this cursed method.

Test mode authentication

Here again, I got helped by my work on the previous model. Basically, in test mode, the board send an udp packet with a once, that has to be hashed with a per device specific key and sent back. This way, the board ensure it is on a vendor's developper owned network.

The key is derivated from a primary key. To sum up, each device owns a primary key, and can derivate key0, key1 roughly by calculating

rc4(md5(key_index + primary_key))

Each key index serves a specific purpose, and for test mode we need key1

On the previous model, primary_key was stored in the nand (aside with the mac address and other per-device stuff). But on this device, we do not have unciphered access to it.

But as we are root, and the device needs to be able to get a key index for it's own purpose, unless all encryption is done in the secure world.

But we are lucky:

[YYYY] /root # xxxkeys
usage: xxxkeys [OPTS] <key_idx> <key_len>
Where OPTS is one of:
   -b      base64 output
   -h      hexadecimal ouput (default)
   -n      fail when lock
[YYYY] /root # xxxkeys 1 16
ab553c48d5ade7426929c4c5b7f03aa

With that key, we are able to authenticate our network for the device to boot in test mode.

A note on firmware images

The firmware image format is roughtly the same as the previous model, so I reused the scripts I wrote:

xilokar@xilokar:~$ Tools/parse_tag.py -i image-xxxxx8r_bank1_4.2.9
crc:     ce46779a
magic:   3658382b
version: 00000002
len:     01e28000
tag version <xxxxx8r_bank1_4.2.9>
Build the 2021-02-08 18:38:30 by yyy@zzzzzzz
5 partitions present

partition 0
     crc:    0cf4403a
     offset: 00001000
     size:   00002eb4 (end=00003eb4)
     type:   00000002
     flags:  00000005
             skrypted
             xz
     name:   <part_00>
Computed crc: 0cf4403a

partition 1
     crc:    349f1619
     offset: 00004000
     size:   0001f9f4 (end=000239f4)
     type:   00000004
     flags:  00000005
             skrypted
             xz
     name:   <part_01>
Computed crc: 349f1619

partition 2
     crc:    64bde3c9
     offset: 00024000
     size:   0045cf94 (end=00480f94)
     type:   00000000
     flags:  00000005
             skrypted
             xz
     name:   <bcm63xx-kernel>
Computed crc: 64bde3c9

partition 3
     crc:    3bea7801
     offset: 00481000
     size:   000055b4 (end=004865b4)
     type:   00000003
     flags:  00000001
             skrypted
     name:   <bcm63xx-dtb>
Computed crc: 3bea7801

partition 4
     crc:    d7c8c9d2
     offset: 00487000
     size:   019a1000 (end=01e28000)
     type:   00000001
     flags:  00000001
             loaded in ram
     name:   <rootfs>
Computed crc: d7c8c9d2
Tag md5: cc6b4289d689c0b713e8afe7825022b8

It consist of a bunch of binary encapsulated, each with a type and flags.

xz means the partition is compressed
skrypted means the partition is encrypted and signed

Bootloader dump

Actually, I did that before venturing into test mode, but it does not matter.

Reuse the same approach as for my attack on the brcm61650 with a kernel module dumping the right memory space ( we have .text, .rodata addresses in the bootlog)

With the dump in hand, let's look at how the firmware is loaded.

ulonglong probably_load_partition
     (partition_info *param_1,char *name,char load_mode,
      void *suggested_load_addr, int param_5)

{
ulonglong uVar1;
ulonglong uVar2;
memmap_entry *pmVar3;
uchar *local_18;
ulonglong local_10;
undefined8 local_8;

print("s_%s_partition_at_offset_, _size_%" ,name,
      param_1->addr,param_1->len);
if (load_mode == '\0') {
    if ((*(uint *)&param_1->flags & 1) == 0) goto LAB_1fc06ec4;
}
else {
    if ((*(uint *)&param_1->flags & 1) == 0) {
       print("%s_partition_must_be_skrypted",name);
       maybe_update_load_status(0xf4);
       return 0xffffffff;
    }
}
...

And with

uVar3 = probably_load_partition(&atf_part,"ATF",1,&LAB_10000000,0);
iVar1 = (int)uVar3;
if (iVar1 == 0) {
  ATF_pointer = atf_part.addr;
 uVar3 = probably_load_partition(&optee_part,"OP-TEE",
                                 1,(void *)0x10800000,0);
iVar1 = (int)uVar3;
if (iVar1 == 0) {
  uVar3 = probably_load_partition, (&kernel_part,
                                  "kernel",mode != 2,
                                   (void *)0x80000,1);
  iVar1 = (int)uVar3;
  if (iVar1 == 0) {
    uVar3 = probably_load_partition,(&dtb_part,"dtb",
                                     mode != 2,
                                     (void *)0x1fb70000,1);
    iVar1 = (int)uVar3;

We see that even though, in test mode, kernel (and dtb) do not need to be skrypted, ATF and OP-TEE must be.

Let's look at how an image is "unskrypted"

ulonglong unskrypt_image(void *in,ulonglong in_len,void *out,
                         ulonglong *out_len,int type)

{
  int iVar1;
  uint cipher_index;
  ulonglong uVar2;
  ulonglong uVar3;
  undefined *key;
  int local_24bc;
  char hash_sha256 [32];
  undefined session_key [32];
  rsa_key public_key;
  undefined auStack9264 [272];
  skrypt_header local_2320;
  uint cbc_ctx [2162];

  memcpy(&ltm_desc,&PTR_s_LibTomMath_1fd1f800,0x198);
  crypt_register_cipher(&PTR_s_aes_1fd1f558);
  crypt_register_hash(&PTR_s_sha256_1fd1f658);
  memcpy(&local_2320,in,0x154);
  iVar1 = again_swap_bytes((ulonglong)local_2320.magic);
  if (iVar1 != 0x534b5259) {
    print("bad_magic");
    return 0xffffffff;
  }
  iVar1 = again_swap_bytes((ulonglong)local_2320.version);
  if (iVar1 != 3) {
    print("bad_version.");
    return 0xffffffff;
  }
  if (3 < local_2320.key_index) {
  print("%i:_key_number_too_big",(ulonglong)local_2320.key_index);
  return 0xffffffff;
  /* ...*/

  iVar1 = get_public_key(local_2320.key_index,&public_key,type);
  if (iVar1 < 0) {
  print("unable_to_get_public_key_!");
    return 0xffffffff;
  }
  if (support_decrypt_kernel == '\0') {
   print("-_Validation_stage_1?";
  }
  else {
  if (type == 0) {
    key = (&PTR_aes_key_0_0_1fd27028)[local_2320.key_index];
  }
  else {
    key = (&PTR_aes_key_1_0_1fd27048)[local_2320.key_index];
  }

Sooo, we might have a pointer to the aes key !

Unfortunatley, there is this funtion:

void * probably_clear_sensitive_data(void)

{
  longlong lVar1;
  void *pvVar2;
  undefined **ppuVar3;
  undefined **ppuVar4;
  int iVar5;

  if (support_decrypt_kernel != '\0') {
   iVar5 = 4;
   ppuVar3 = &PTR_aes_key_1_0_1fd27048;
   ppuVar4 = &PTR_aes_key_0_0_1fd27028;
   do {
     zeromem(*ppuVar4,0x20);
     maybe_dma_sync(*ppuVar4,0x20,0);
     zeromem(*ppuVar3,0x20);
     maybe_dma_sync(*ppuVar3,0x20,0);
     iVar5 = iVar5 + -1;
     ppuVar3 = ppuVar3 + 1;
     ppuVar4 = ppuVar4 + 1;
   } while (iVar5 != 0);
  }
  lVar1 = probably_get_board_serial_info();
  zeromem(lVar1 + 0x26,0x20);
  pvVar2 = (void *)maybe_dma_sync(lVar1 + 0x26,0x20,0);
  return pvVar2;
}

that is called just before passing the hand to ATF:

pvVar4 = probably_clear_sensitive_data();
probably_run_atf(pvVar4,(ulonglong)info);
uVar3 = cRead_8(currentel);
print("ATF_returned_in_EL%d",uVar3 >> 2 & 3);
uVar3 = cRead_8(currentel);
if (((uint)(uVar3 >> 2) & 3) == 3) {
  panic("Secure_OS_left_at_EL3!");
}

So, no chance to grab the aes key used to decrypt the firmware from the post-boot memory dump.

By looking further (too much code to dump here, so no screenshot) we can see that the firmware aes key are loaded from an encrypted partition. The partition is encrypted with a per-device key, accessible only when in EL3.

Good luck...

Back to test mode

Let's look at what we can do in test mode.

ATF and OP-TEE must be skrypted.

So focus on kernel (or dtb).

The xz flags is quite interesting. If not set, the partition is copied to the default location. but the xz flags loads an header with a target load destination.

With that in mind, maybe we could try to over-load the ATF (which is run at EL3) with our own code?

Nice try, but each loaded partition fills an memory_map entry, and no overwrite is allowed. (kudo to the developpers)

[00010000-0001ffff pmc.boot]
[00080000-00d0a807 kernel]
[10000000-10007027 ATF]
[10800000-108543af OP-TEE]
[11800000-11db4fff imagetag]
[1fb80000-1fbfffff cfe.mmu]
[1fc00000-1fffffff cfe]

I found a glitch in the loading code that would have allow to overwrite some code by wrapping the address, but found it unexploitable (data abort)

Exception Class: Data Abort From Current EL
Fault address: <ffffffffffffffff>
Fault status: Translation fault, level 0

At that point, I was about to give up.

But...

Remember, the ATF partition muste be skrypted. So it's signature is checked, and then it is decrypted.

Let's look a bit further. Here is the format of the skrypted partition:

struct {
   unsigned int magic; // "SKRY"
   unsigned int version;
   unsigned int data_offset;
   unsigned int data_len;
   unsigned int key_index;
   unsigned char signature[256];
   unsigned char iv[32];
   unsigned char session_key_crypted[32];
};

And at the code that handle deciphering:

print("Kernel_signature_OK");
if (support_decrypt_kernel == 0) {
  iVar1 = xmemcmp((char *)skr_header.iv,&zero__1fd27068,0x20);
  if ((iVar1 != 0) ||
     (iVar1 = xmemcmp((char *)skr_header.session_key_crypted
                      ,&zero__1fd27068,0x20),
      iVar1 != 0)) {
     print("kernel seems encrypted, which is unsupported");
     return 0xffffffff;
  }
} else {
  iVar1 = xmemcmp((char *)skr_header.iv,&zero__1fd27068,0x20);
  if ((iVar1 != 0) ||
      (iVar1 = xmemcmp((char *)skr_header.session_key_crypted,
                       &zero__1fd27068,0x20),
       iVar1 != 0)) {
       print(" - Decrypting_kernel");
       cipher_index = crypt_find_cipher(s_aes_1fc2f862);
       cbc_start(cipher_index,skr_header.iv,
                 session_key,0x20,0,cbc_ctx);
       if (cipher_index != 0) {
         print("unable_to_setup_aes_cbc");
         return 0xffffffff;
       }
       iVar1 = decrypt_aes_cbc(in,out,uVar3,cbc_ctx);
       if (iVar1 != 0) {
         print("unable_to_decipher_kernel");
         return 0xffffffff;
       }
  }
}
memcpy(out,in,cipher_index);
*out_len = uVar3;
return uVar2 & 0xffffffff;

See ? To decide if it will decrypt the partition with the session_key, the unskrypt function check if the iv and the encrypted_session_key are not full of zero.

So, instead of the unskrypted ATF binary, we can inject the ciphered ATF binary. Of course, we can not modify this image. But fuck hell, maybe with luck, the ciphered binary are valid aarch64 instruction that could help us ?

So let's grab all the signed ATF partition we can find and objdump the ciphered payload.

...

and

...

yes !

$ ./Tools/parse_skrypt.py ---dump atf.bin
magic:   534b5259
version: 00000003
offset:  00000154
len:     00002d60
key_id:  00000000
iv:  b'20c4f...a83c56c9492063d761bf17108d'
encrypted_session_key:  b'd1be...3aa0a87f1a1f'
Dumping to <atf.bin.ciphered>

$ objdump -D -b binary -m aarch64 atf.bin.ciphered
atf.bin.ciphered:     file format binary

Disassembly of section .data:

0000000000000000 <.data>:
0:       301752cf        adr     x15, 0x2ea59
4:       d07e50fe        adrp    x30, 0xfca1e000
8:       b530904a        cbnz    x10, 0x61210

One of the ciphered ATF partition decodes as three valid instructions, with the third one being a jump to an non-reserved memory_maped region (as the atf is loaded at 0x10000000 and the jump is relative, it gives us 0x10061210, between ATF and OP-TEE) ! (Luckily, x10 is not zero at that point of the code).

And if we omit the xz flag, the ciphered data will be copied as-is to the default ATF memmap.

So now, let's roll.

build a "kernel" image that we xz at the jump location, pack it with a skrypted ATF image, with iv and key set to 000...00, and boom, we have code execution at EL3.

We then just need to rejump to the code that handle partition decryption, and we can dump the shared firmware aes key...

void (*bl_printf)(char *str, ...) = (void *)0x1fc2d7f4;
void hexdump(char *prefix, void *p, int len) {
     unsigned char *c = p;
     int i,j;
     for(i=0; i< len; i+=16) {
             bl_printf("DUMP_%s_: %16x: ", prefix, c + i);
             for(j=0; j<16 && j+i<len; j++) {
                     bl_printf("%02x ", c[i+j]);
             }
             bl_printf("\n");

     }
}

void (*load_bootinfo)(void) = (void*)0x1fc0e768;
void dump_keys(void) {
     load_bootinfo();
     hexdump("AES_0", (void*)0x1fd2be70, 32);
     hexdump("AES_1", (void*)0x1fd2bdf0, 32);
};

ENTRY(_Reset)
SECTIONS
{
     . = 0x10061210;
     .startup . : { startup64.o(.text) }
     .text : { *(.text) }
     .data : { *(.data) }
     .bss : { *(.bss COMMON) }
     . = ALIGN(8);
     . = . + 0x10000;
     stack_top = .;
}

DUMP_AES_0: 000000001fd2be70: a1 ... 33
DUMP_AES_1: 000000001fd2bdf0: d8 ... c4

(obviously, I won't disclose)

Bypassing rootfs signature

Just a quick note on that.

To bypass the rootfs signature included in the new kernel released, just load a previous (signed) kernel (that do not check rootfs signature, just decrypt it) and then load a specially crafted module that mimic kexec on the new (modified) kernel on the crafted rootfs.

Conclusion

Custom firmware on a "secure boot" device.

The bootloader in itself is also signed/ciphered with an OTP key that is set unreadable before the ROM execute the bootloader. An hardware fault injection attack would probably be necessary to bypass that, but that's beyond my capabilities (atm).

The vendor has been contacted and fixed the bootloader.

Pwning the bcm61650

2022-04-04T00:00:00+02:00

The percello prc6000, also known as bcm61650 after Broadcom bought the company, is a chip used in 3g femtocells (Home-nodeB).

Here is a summary writeup of how I achieved to bypass its secure ROM to run arbitrary firmwares.

Intro

The bcm61650 is present in a femtocell of a large french operator. It allows you to have a small 3g tower in your house over your dsl/fiber line. It's an optional box you plug in your dsl box, with what looks like a pcie connector.

From PCIe in box to standalone Ethernet

When pluged in, the board present itself as a pci ethernet chip, that performs a bootp and load its firmware over tftp and then connects to an hardcoded IP to establish an ipsec tunnel to the core network (I won't cover this part). In order to fully use the femtocell for playing with osmocom, I decided to try get rid of the hardcoded parts.

To ease debugging, I decided to try to tweak it into a standalone, ethernet based, board, in order to be able to start, stop or reboot the board without having to mess with pci scanning and hotplug.

Desoldering the link between the pci ethernet chip and the bcm61650

And with a few probes, managing to get the board powered and booting.

With uart output.

Node-H FM-loader v1.2
booting in ******* mode
changing CPU frequency... done
image verification success
copying initrd at 0X8F6C8000...
copying kernel...
bytes: 3338752
booting kernel...

Hum... image verification

First glimpses

The firmware loaded over tftp is 11Mb.

binwalk output:

DECIMAL       HEXADECIMAL     DESCRIPTION
---------------------------------------------------------------------
123953        0x1E431         Copyright string: "Copyright (c) MIPS
                              Technologies, Inc. All rights reserved.
125092        0x1E8A4         CRC32 polynomial table, little endian
126181        0x1ECE5         Copyright string: "Copyright (c) MIPS
                              Technologies, Inc. All rights reserved.
128416        0x1F5A0         SHA256 hash constants, little endian
131224        0x20098         uImage header, header size: 64 bytes,
                              header CRC: 0x8ACC835E, image name:
                              "Linux-2.6.31.12-Percello-1.12-9"
131288        0x200D8         gzip compressed data, has original file
                              name: "vmlinux.bin"
1740800       0x1A9000        Squashfs filesystem

So, a bunch of unkown stuff at the start, then kernel and root filesystem.

Trying a simple change in the kernel/rootfs:

Node-H FM-loader v1.2
booting in ******* mode
changing CPU frequency... done
image verification failed
failed to boot: halt

Yeah, obviously

Some string a the start of the binary blob:

Percello bootloader version 0.6 (from
Silicon type:
, silicon ver:
, feature ver:
, ROM ver:
Boot block
not found
FM signature has invalid length

Did not see the Percello bootloader version 0.6 during boot. And the FM signature suggests we surely have a chain of bootloaders until linux (which is expected).

Trying to change a string in the bootloader completly blocks the boot, so bootloaders are either checksumed or a signature is checked.

Where to go from now ?

Got root ?

Extract initrd with binwalk, check /etc/password

Long story short: empty root password.

side-note: from now on, I will always check for empty password before trying to build an hashcat rule

Got Dump ?

dd if=/dev/mem  bs=4k | nc

With luck, the memory used during boot time will not (yet) be overwritten by linux.

Using the strings in the firmware and in the location of the matchings strings in the memory dump, we can find the location in ram of the bootloader, and thus adjust the load offset of the binary in our favorite RE tool.

After a few hours of digging things out:

The percello bootloader is loaded at 0x83fe0000 It then loads the FM loader
The FM loader is loaded at 0x83f80000 he is responsible for loading kernel and initrd

Both use code from ROM (0x9fc00xxx), for signature verification.

Time to go further down in our analysis.

Got Rom ?

The dd approach to dump rom does not seems to work:

# dd if=/dev/mem bs=1 skip=$((0x9fc00000)) count=10
dd: /dev/mem: Bad address
#

Not a surprise, the rom is surely not mapped in linux. But hey, we are root, and we can load modules!

So grab a linux-2.6.31.12 archive, try to build a close enough kernel (did I mentionned it was mips based ?) play with symbol versioning and voila

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

void dump_mem(unsigned char *start, unsigned char *end) {
   unsigned char *p = start;
   int i,v;
   printk("Dumping: %08x\n", (unsigned int)start);
   v = p[i];
   for(i=0; i< (int)(end - start);i++) {
     printk("DUMP:%08x: %02x\n",
             i + (unsigned int)start, p[i]);
   }
}


static int __init dump_init(void)
{
   printk("Dump init\n");
   // dump rom ?
   dump_mem((unsigned char*)0x9fc00000,
            (unsigned char*)0x9fd00000);
   return 0;
}

static void __exit dump_exit(void)
{
   printk("Dump exit\n");
}

module_init(dump_init);
module_exit(dump_exit);

MODULE_AUTHOR("Xilokar");
MODULE_DESCRIPTION("Dump driver");
MODULE_LICENSE("GPL");

(do not pay attention to code)

grab kernel messages from console, grep, sed, xxd and we have our ROM dump.

more time digging things out

Hello RSA my old friend

Remember the functions from ROM used in both percello bootloader and FM-loader ? Without surprise, they are also used in the ROM code, to check the percello bootloader signature.

log("s_Secured_device_-_OTP2:_verificat_9fc0dda8");

iVar1 = FUN_9fc0d15c(DAT_bf400888,DAT_bf400880,
                     &DAT_bf400ae8,&DAT_bf40088c);
if (iVar1 != 0) {
   log("s_FAILED_9fc0e364");
   return;
}

void FUN_9fc0d15c(undefined4 param_1,undefined4 param_2,
                  undefined4 param_3,undefined4 param_4)
{
   undefined auStack152 [20];
   undefined auStack132 [108];

   FUN_9fc0c380(auStack132);
   FUN_9fc0c96c(auStack132,param_1,param_2);
   FUN_9fc0d020(auStack132,auStack152);
   FUN_9fc0ccc0(auStack152,param_3,param_4);
   return;
}

Probably, FUN_9fc0c380 is hash init, FUN_9fc0c96c hash process and FUN_9fc0d020 hash finalize. The hash size is 160,

void FUN_9fc0c380(undefined4 *param_1)

{
   *param_1 = 0x67452301;
   param_1[1] = 0xefcdab89;
   param_1[2] = 0x98badcfe;
   param_1[3] = 0x10325476;
   param_1[4] = 0xc3d2e1f0;
   param_1[0x19] = 0;
   param_1[5] = 0;
   param_1[6] = 0;
   param_1[0x17] = 0;
   param_1[0x18] = 0;
   return;
}

And we have good old Sha constants, so hash is surely sha1

The last function (FUN_9fc0ccc0) builds a 0x80 long structure

00000000  00 01 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
*
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff 00 30 21 30
00000060  09 06 05 2b 0e 03 02 1a  05 00 04 14 00 00 00 00
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

and copy the sha1 at offset 0x6c. (yes PKCS1 scheme).

It then rsa-decode the passed 0x80 long signature with an hardcoded public key and memcompare the result to the built structure. No asn1 parsing of the provided signature, so no chance to find a pkcs bleichenbacher like attack...

Back to basis

At this point, It was like a deja vu:

(sha1 this time, but hey, even if sha1 collision are real, not preimage attacks)

But after more digging:

void probably_load_header(void)

{
  bootloader_header local_60;

  DAT_bf400888 = 0xa0500000;
  memcpy(&local_60,0xa0500000,0x4c);
  memcpy(&DAT_bf40088c,local_60.percello_sig + 0xa0500000,
         local_60.percello_sg_len);
  memcpy(&DAT_bf40090c,local_60.fm_sig + 0xa0500000,
         local_60.fm_sig_len);
  DAT_bf400880 = local_60.percello_sig;
  DAT_bf400884 = local_60.fm_sig;
  return;
}

0xa0500000 is probably the location of the tftp-loaded image. So this function maps the file header and...

Wait ! memcpy a user provided buffer (fm_sig at a known location (0xbf40090c), with a user provided length (fm_sig_len)?

And below the stack (0xbf403ff0) ?

# init stack pointer
lui        t0,0xbf40
ori        t0,t0,0x3ff0
addiu      sp,t0,0x0

Time for a good old stack smashing (for fun and profit)!

After a few time, found the right len to smash ra in the memcpy call on the stack, and jump just after the signature verification. Also needed to keep some values in ram, so my buffer overflow was not only full of 0xff and I was able to successfully jump to the percello bootloader, without signature verification.

Node-H FM-loader v1.2
booting in ******* mode
changing CPU frequency... done
image verification bypass!
copying initrd at 0X8F6C8000...

Then all was left was patching percello bootloader to skip FM-loader verification:

Node-H FM-loader v1.2
booting in Xilokar mode
changing CPU frequency... done
image verification success
copying initrd at 0X8F6C8000...
copying kernel...
bytes: 3338752

And then patching FM-loader to allow for arbitrary kernels and initrd:

Node-H FM-loader v1.2
booting in Xilokar mode
changing CPU frequency... done
image verification bypass!
copying initrd at 0X8F6C8000...
copying kernel...
bytes: 3338752
booting kernel...
[    0.000000] Linux version 2.6.31.12-Percello-1.12-9
...
[    1.633762] Freeing unused kernel memory: 152k freed

==================================================================
Welcome to Percello Root File System Version R2.4  (not so) Secure
Pwned by Xilokar
==================================================================
---- Mounting proc file system
Sat Aug  1 00:00:00 UTC 2015
---- Mounting ramdisk with size 32M
---- Remounting /dev/root
---- Starting syslogd
---- Mounting sysfs
---- Mounting devpts
---- Creating loopback device
---- Activating Ethernet device

(I realize I did not talk about understanding firmware image structure)

Conclusion

Unpatchable (ROM) secure boot bypass on bcm61650.

Time to reverse - Part 1/x

2018-03-06T00:00:00+01:00

After some time spent, I've finally managed to identify the jtag pins on my MC9620 "phone".

It looks obvious once found...

Unfortunately, I think I have fried the device while doing so.

Nevertheless, I've successfully dump the firmware of the phone, so now, it is time to fire up radare2 and try to extract some usefull information from the dump. But it will surely be a very hard and slow journey.

And I have to find another device, if I want to be able to speed up the process.

It Didn't Work

2018-01-11T00:00:00+01:00

A picture is worth a thousand words...

Video Distorsion

2017-04-10T00:00:00+02:00

Found this old piece of code, written in 2013. Only needed to change hardcoded resolution of the webcam to get it working again.

Hello World

2015-04-17T00:00:00+02:00

#include <stdio.h>

int main(int argc, char** argv) {
    printf("Hello World\n");
    return 0;
}