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!

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.

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

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!

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...)

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

nice

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 :-)

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.

Thank you very much for supporting our channel!

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

We are glad you like it. We didn't speak at Shmoocon so it must have been somebody else.

In such cases a target specific attack is required. It would need a separate research and maybe use different techniques like glitching.

You can use a signal analyser like the one we show in the video to try and understand what it is. With that number of pins and name, a quick (probably wrong) guess would be JTAG. However, we would be very surprised if JTAG is enabled on a laptop shipped to the public!

@@FlashbackTeam ok, but do you have any info about what could JDEBUG2 stands for? The only thing I can research on google is asus related posts and jdebug on the java JVM. I will try to crossmatch jtag and jdebug for a test on a new search quest :).

Hard to tell what sort of debug interface it could be. I think best is if you find a schematic for this laptop. There should be a diagram and description of the interface. Maybe try to ask on some laptop repair forums / YT channels?

@@DamjanDimitrioski JDEBUG2 is JTAG Debug (header number 2) :) It's a debugging interface for troubleshooting eventual motherboards issues.

@@ioanbustean7442 thanks, any specific specification url or more info about header number 2?