We see more vendors using all kinds of firmware protection in their devices but still quite a lot of this can be bypassed. We actually cover this topic and how to bypass firmware encryption in our training. Few examples that we have used or seen on real life devices: * Firmware upgrade is encrypted but there is decryption binary on the device. All you have to do is reverse or emulate the binary to decrypt outside of the device. * Firmware upgrade is encrypted but the actual firmware on the flash is not. * Firmware is encrypted but you can get access to a running system. * Firmware stored on flash is encrypted but encryption keys are not stored properly or are cached. * Firmware is protected by read-only fuse but it would be possible to bypass that check and extract firmware. * Side channel attacks allow to reveal encryption keys But if vendor did a really good job and encryption material is stored in hardware and it can't be retrieved easily or firmware can't be decrypted, you have to level up - find a zero day vulnerability using black box techniques, which we also did on few occasions. It's always a matter of how much time and energy you can invest on a target.

@@FlashbackTeam what about qualcom chipsets ? can we hack it , because they lock the cpu and gpu clock. trustzone and other hardware controles the clock frequencies now , any way to hack it ?

smells like scriptkiddy in here

Such encryption is inherently flawed because the mechanism to decrypt must reside within the device itself; so there's always - at least in theory - going to be a way to extract the decryption key from the device. I'm pretty sure the more common this becomes, the more people will find ways to do exactly that.

@mr wpg Spoken like a true engineer. :)

That's exactly what I was going to say!

Download it qnd save it

Thank you for your kind words. We are working on a new video that we will release in the coming weeks. We are very excited about it and it's going to be just awesome! This time more into vulnerability research and exploit development.

We will be having both onsite and online trainings this year.

How did it go?

Burned down their home... 😢

Hope they didn't sue you

I am an Idiot. I failed to get a ROM dump I could read. Might be encrypted. Anyone wanna look at it?

Why is your smart stove even able to have a checksum error? Why did get a smart stove? 😂

In the past we were using Teensy with custom code to dump NAND Flash. Worth giving it a try too! But of course the most efficient is to simply use a programmer, but less fun.

@@FlashbackTeam Lots of lessons learned! I don't think I knew what a programmer was at the time. We relied on the SoC's bootloader to copy the file system from flash and we just copied the bus. Asking the flash to kindly show us its memory would have definitely been more elegant 😂. Luckily the flash data at rest wasn't encrypted!

They usually add a header to the firmware that you need to strip out.

@@superslammer you're right! I did figured out weeks ago on my old huawei router

@@KangJangkrik linux to the rescue :D

Thank you! We are slowly improving our recording hardware and editing techniques :-)

Yes, that's a very good point. Plus you can find extra info, i. e. Device's config that is not part of the firmware downloaded from vendor.

We're happy you got inspired. Keep in mind that it all depends on where a firmware is stored. If it's external flash it is relatively easy. If firmware is stored within SoC/MCU then it won't be that easy as most likely there will be read protection that would need to be bypassed first.

@@FlashbackTeam That's exactly what I was thinking - I use MCUs for work stuff, and it's not necessarily that easy to dump their firmware given their flash is on-chip! I'm just hoping I might get lucky with the e-scooters one way or another ; if not dumping existing firmware to reverse it and tweak it, then perhaps finding an open source reimplementation that I could flash onto the chip, or making a new board myself if I have to (the main control board in that scooter isn't the one doing power distribution to drive the motors, so it's not unrealistic to just make my own, just will take more time...)

Thank you very much for supporting our channel!

There are some Chinese clones of Saleae, such as this one: www.sigrok.org/wiki/MCU123_Saleae_Logic_clone Unfortunately Saleae doesn't sell the small 4 channel cheaper version that we show in the video any more. But keep in mind this version can't sniff high speed protocols like USB, while the other Saleae big boys can. If you're doing it as a hobby, I guess the Chinese clones work well enough. But if you are going to take this seriously, we highly recommend buying a proper Saleae.

We are not native English speakers, but we always provide proper English subtitles (edited by us, not auto translated) in case you can't understand us / hate our voices :-)

nice

Hi. Thanks for your feedback. Very interesting questions. 1) From our experience, some boards would indeed be powered-up when we connect to the chip. Keep in mind, that we are supplying 3.3V so I assume it really depends on the board design. However, we didn't find it a big of an issue for us. When this happens, we usually wait a bit to increase the chance that the SPI bus is free. On many targets, after the boot process is finished and firmware placed in memory, there is much less data being fetched by a CPU compared to a booting stage. We just start our dump at that moment. Also, SPI protocol has that CS line which selects a chip. So all in all, it's not big of an issue for us. But keep in mind we are not electronics engineers, we are just hacking those devices using whatever works for us. 2) The reset pin technique is a very good idea. In fact we used it in the past on one of the target but for a different purpose. 3) If you can interrupt boot sequence, for example by entering bootloader menu, there should be very little interaction with the chip. 4) So far in most of the cases we didn't have to desolder SPI chip to read content from it. Usually in-circuit and it just works. It is on a contrary to NAND TSOP-48. Those almost never work in-circuit and we need to desolder it. 5) As for the training, it's an intermediate level course. The hardware part is on first day and we always use hw hacking only for the purpose of getting the firmware or enabling debugging. Sort of a first step in the chain. Then on the remaining days we move on to vulnerability finding and exploitation. For that reason, a student needs to have a good linux command line knowledge and some basics of reverse engineering and C knowledge. But we never leave anybody behind.

which MCU

Happy you like it! It looks like KZfaq algorithm finally decided to give our channel a chance!

Hi Fabiano, if the right opportunity pops up, for sure. We both would love to go there, we haven't been yet!

@@FlashbackTeam Thanks

@@fusca14tube de nada meu irmão ;)