Really informative video, thank you! Sadly I see there will be fewer and fewer devices "hackable" in the near future as more and more manufacturers (especially of routers / e.g. DOCSIS 3.1) start using hardware based encryption technology for their ROM. With little to no possibility to ever read extracted data. What do you think about this?
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 ?
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.
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.
Very helpful for someone like myself just beginning to understand this stuff. Explaining the function and description of terminology is something i would normally have to do significant research for.
So dope that you guys put this out for free. If it was near me I would totally attend your in-person training. A paid virtual event would also be awesome.
FYI: most routers are linux-based (e.g. Huawei created their own distro called "Dopra"), which means if you lucky then the flash isn't encrypted and you can mount EXT filesystem from it
impressive stuff guys. I'm just getting started with electrical engineering. I've been seeing that a lot of intelligence agencies like to play games with each other at this level. It's all really fascinating.
What an entertaining channel! I've been watching some pluralsight and udemy courses recently, and I wish the presenters of those courses had the same style and pace as you guys. You are always interesting. Well done!
I'd propose that while getting firmware images from a manufacturer's website is the easiest path, it still leaves the question of whether the firmware on the device is the same that is currently flashed to the device. While higher risk, and effort, pulling the firmware from the device is the most deterministic way to get the current firmware.
Nice! Used a similar process a few years back for some NAND flash. Didn't know about the hydrabus back then though. Instead I wrote a plugin using the older version of Saleae's SDK to dump the data of read commands to a binary file. Then had to do a little post-processing to get rid of the error correction codes that NAND has to transmit. Glad to see content showing an approach to the process!
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!
This is really interesting, thank you for this content. Have you ever thought about analysing the SONOS smart speakers? I know that there is a lot of people interested in understanding these in order to be able to analyse the protocols used so that they can add their own DIY builds like with a raspberry pi to the network
I applaud your patience. My method of IoT “hacking” involves only two steps. Search, then destroy. I may start posting my handywork on another platform.
This is really cool! I wanna dump the firmware of my e-scooter to hack it a bit, I didn't realize it could be that trivial :-) hopefully I get lucky and I can read/write firmware that easily!
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...)
I remember encountering myself with a "Flashrom repository" or something like that. It had tons and tons of Flash Chips to look at, so much that I got overwhelmed with the information. It is great that nowadays reverse engineering is becoming something more common. Greetings from Paraguay.
You guys with the accents are smart, sometimes its too much work to understand. You speak clearly, everything about the presentation is perfect. You make it easy to understand things I should already know. Thanks
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 :-)
Reassembling the memory from just sniffed traffic is feasible... But you only get the parts that are actually read. Might have to exercise the device a little so you get better coverage. Boot sequence might be enough to get a foot in.
A new subscriber here, but is unfair when channels like this are Not popping up more often on the recommendations when the algorithm know I'm tech nerdy...
Yeah, the normal clips are garbage. I'll check the Ponoma clip then! You're the first one I've done across that mentioned the name of the better clip so now I'll be able to actually buy one xP
Yes. You can also write using SPI. And yes, you can fix bricked motherboards this way. In fact, we did it in the past. After bios update of one of our laptops, it got bricked and we overwrote bios flash using SPI to restore it.
You are right. In most of the cases, microcontrollers with internal flash are shipped with read protection. In those cases different techniques are needed. Unfortunately they are not-standardized and attack path would need to be unique per MCU family. One of the approaches here could be using fault injection to attack bootloader / early routines that checks a fuse state.
I found in my Rog Strix laptop some interface called JDEBUG2, which has 15 pins. Not really an embedded device, but I wanted to know more details on this interface and whether I can have some commands to show me laptop's diagnostics :).
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?
I don't understand how you read the SPI flash in circuit on the target board. Doesn't applying power to the SPI flash chip power up the target board processor and thus both are trying to read (push pull) on the same data lines? Can't this blow out the drivers in the target board processor?
Yes, applying power to chip in many cases will boot up entire board. As you mentioned, this can result in both us and a target to compete and race for the resources. However, from our experience, in those situation we usually wait a bit and after the target has done reading from flash we can start flash dumping.
@@FlashbackTeam Even when the CPU is not actively talking to the flash the lines are still in push-pull not high impedance so how can you talk to the chip without blowing up the line drivers in the cpu?
@@wowcolorsbecause the current to power up that chip is very low, and almost no current flowing through the data lines. It’s hard to burn something without enough current.
Did you recently speak at Shmoocon about this, but on a higher/conceptual level? Someone with a similar accent did. Regardless, this video is what I was hoping for!
About UFS, there are also UFS memory cards that look like MicroSD cards at first glance. They are said to be a lot faster than MicroSD. The only problem is that not a lot of devices use them. The funny thing is and I may be mistaken on it too BTW is that they re royalty free. If that is true I don't see any reason other than having to redesign things as the reason for no one switching over to it. Maybe they have a serious flaw and that is the reason why you don't see a lot of devices aside from a couple Samsung phones and laptops. Samsung may have something to do with the format but I do not believe that they were the only ones who created it. I don't believe that it is proprietary to Samsung at all but instead no one wanted to use it for some reason.
Hi flashback team. I want to understand and do things like what u doing but I don't know where to start learning. I know C programming (intermediate), I know data structures and algorithms, currently learning digital electronics, operating system and computer networks but I don't know where to proceed further actually doing these things. Any advice is highly appreciated.
Quite interesting video!. Im thinking to apply this tecnique to a grandstream fxs voip adapter: i have two, one working properly another bricked (extract ok -> write bricked). It seems a corrupted flash , so it worth the effort
Really great video.. I've never done this, but have most of the tools and have been thinking of trying it just for fun.. I'm curious though - When you are powering that EEPROM from the clip, I'd be worried that I'd also be backfeeding power to the rest of the circuit, and potentially causing it to boot up, which might cause the MCU to start taking over the SPI bus.. Is there some way to guarantee you're only powering the memory that I'm missing, or is this really not as big of a problem as I am envisioning? Could techniques like finding the reset pin on the MCU and holding it low to prevent booting perhaps be a good workaround? Any other hints? How much experience is needed before I shouldn't expect to be completely lost in one of your in person training classes!?
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.
How do you prevent the master MCU from talking to the flash at the same time? Most of the time when you provide power to the flash the MCU will powered as well, because they'll use the same power rail.
From our experience, in most of the cases that is not a problem if a device also powers up. However, on some occasions we give it more time for the device to finish booting process. Once a firmware is loaded to a memory there should be less operations directly on a flash. If dumping in-circuit is impossible we can always desolder the flash chip.
Hello, Flashback. I have a question. 16:59 and 17:42 The datasheet told us to use the Rising Clock. but why? Saleae told us the data use Falling Clock.
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.
I see lots of SOIC-8 flash chips like at 9:56 with a second set of pads at 90 degrees to the SOIC-8. I'd love to know what's going on here because it seems to common. I assume it's for some kind of SOIC-16 flash chip instead of the '8 but I've never heard anyone talk about it.
I just want to point out that "package" has absolutely nothing to do with how many legs an IC has. In this case, the package for the SPI flash, is an SOIC, often times, manufacturers will add a quantifier to the package name to denote the leg count to differentiate the device from others of the same type and class, in this case, for the SPI flash, the quantifier is 8, due to there being 8 legs. However, this doesn't alter the fact that the package is still an SOIC. An example of the differences in packages can easily be shown when looking at the differences between SOT-523, SOT-323, and SOT-23. In the case of transistors with these packages, they can all be the same exact transistor, with 3 legs, but the packages are different. With Sot-523 being roughly 1.6mm x 1.6mm, Sot-323 being roughly 2mm x 2.1mm, and Sot-23 being roughly 2.9mm x 2.4mm. Of coarse, there are many other types of packages, but this just illustrates the difference between package, and leg count, or package quantifiers.
Yes, you are right. We know there are a lot of different packages available. However, from our experience, some are more common then the others. In most of the cases, on the targets that we have worked on, they are as in the video. After first guess looking at the IC, we would always cross-check with the datasheet.
amazing. 17:40 was cool to see the actual wire signal. It surprised me that the hardware responds without missing any clock cycles, I guess working in web development I forget that computers are actually fast
Really informative video, thank you! Sadly I see there will be fewer and fewer devices "hackable" in the near future as more and more manufacturers (especially of routers / e.g. DOCSIS 3.1) start using hardware based encryption technology for their ROM. With little to no possibility to ever read extracted data. What do you think about this?
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. :)
Please never delete this video, it's very helpful.
Download it qnd save it
Everything is explained clearly without wasting time or over-explaining. Well done.
That's exactly what I was going to say!
Damn this channel is so underrated.. just stumbled upon this while scrolling but definitely gonna stay for more .. Thanks for explaining this so well!
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.
Very helpful for someone like myself just beginning to understand this stuff. Explaining the function and description of terminology is something i would normally have to do significant research for.
So dope that you guys put this out for free. If it was near me I would totally attend your in-person training. A paid virtual event would also be awesome.
We will be having both onsite and online trainings this year.
Your videos are the best! Please don't stop making the tutorials! Thank you.
FYI: most routers are linux-based (e.g. Huawei created their own distro called "Dopra"), which means if you lucky then the flash isn't encrypted and you can mount EXT filesystem from it
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 for explaining this for those who are trying to get into this line of work but find it difficult to do so. Keep up the great work!!!
impressive stuff guys. I'm just getting started with electrical engineering. I've been seeing that a lot of intelligence agencies like to play games with each other at this level. It's all really fascinating.
wow.... this is one of the most fascinating videos I've ever seen on YT....
What an entertaining channel! I've been watching some pluralsight and udemy courses recently, and I wish the presenters of those courses had the same style and pace as you guys. You are always interesting. Well done!
I'd propose that while getting firmware images from a manufacturer's website is the easiest path, it still leaves the question of whether the firmware on the device is the same that is currently flashed to the device. While higher risk, and effort, pulling the firmware from the device is the most deterministic way to get the current firmware.
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.
I'll be promoting you guys in all the forums I'm in ... STARTING with this video!!
Perfect! Not to simple, not to complicated, with practical information.. Thank You
WOW mind blow stunmbled on this channel and glued to the screen...
You should consider offering a recorded ‘on demand’ version of the course. I would buy it!
What a beautiful work!. Thank you for sharing your time and effort.
Nice! Used a similar process a few years back for some NAND flash. Didn't know about the hydrabus back then though. Instead I wrote a plugin using the older version of Saleae's SDK to dump the data of read commands to a binary file. Then had to do a little post-processing to get rid of the error correction codes that NAND has to transmit. Glad to see content showing an approach to the process!
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!
Damn this channel is a hidden gem
lol 😆🤣 9:55 oh Jesus got me cracking but all jokes aside this is one of the best well explained video on firmware extraction thanks
Please regularly upload such a knowledgeable videos. After long time I am watching your videos. Love from India 🙏
Yesss! I love to see you back!
Pleasee consider to upload more often
This channel is a treasure..
¡Gracias!
Thank you very much for supporting our channel!
This is really interesting, thank you for this content. Have you ever thought about analysing the SONOS smart speakers? I know that there is a lot of people interested in understanding these in order to be able to analyse the protocols used so that they can add their own DIY builds like with a raspberry pi to the network
I applaud your patience. My method of IoT “hacking” involves only two steps. Search, then destroy. I may start posting my handywork on another platform.
Nothing better than the legitimate duo
I just discovered your team, thank you so much for this interesting content!
More information than from my technical degree in a few minutes
Very interesting, and looking forward to more content!
Very good hacking ! Nice job guys. I hope one day I can do your training session
Thanks for this content we can see al the time you have spend to make this incredible video !
You are a proper educator. Insta-subbed.
Love these videos flashback team!
Thanks for this content, it is really well explained.
This is really cool! I wanna dump the firmware of my e-scooter to hack it a bit, I didn't realize it could be that trivial :-) hopefully I get lucky and I can read/write firmware that easily!
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...)
That's nice. Great video brother!
Simple, efficient, educative !
I remember encountering myself with a "Flashrom repository" or something like that. It had tons and tons of Flash Chips to look at, so much that I got overwhelmed with the information.
It is great that nowadays reverse engineering is becoming something more common.
Greetings from Paraguay.
nice
Thanks for sharing all your knowledge and experience.. 🙌
You guys with the accents are smart, sometimes its too much work to understand. You speak clearly, everything about the presentation is perfect. You make it easy to understand things I should already know. Thanks
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 :-)
one of the essential videos on youtube )
He's so good at what he does.
I DEFINUTELY subscribed to this channel! F'ing quality bro!
I particularly like the sound quality during the NOR description!
Thank you! We are slowly improving our recording hardware and editing techniques :-)
Reassembling the memory from just sniffed traffic is feasible... But you only get the parts that are actually read. Might have to exercise the device a little so you get better coverage. Boot sequence might be enough to get a foot in.
Lmao! Alright you got me with the Saleae joke.
thank you so much, Ive learnt alot from you in this video.
Interesting. Look forward to more content.
A new subscriber here, but is unfair when channels like this are Not popping up more often on the recommendations when the algorithm know I'm tech nerdy...
Happy you like it! It looks like UA-cam algorithm finally decided to give our channel a chance!
What is the name of the blue clip you're using to connect to the legs of the chip?
They are called Ponoma clips, and they're much more expensive than "normal" clips, but well worth the extra money.
Yeah, the normal clips are garbage. I'll check the Ponoma clip then!
You're the first one I've done across that mentioned the name of the better clip so now I'll be able to actually buy one xP
Wow, it was cool to see how embedded devices get hacked as for man who is interested in embedded and IoT. Thanks for video
I was waiting so bad for a new video! Great
Amazing vid ... found a new rabbit hole .... yeeee haw
Concise and compherensive 👌👌
Good job Pedro from the flash back team
Ima download it thanks for sharing!!
Valeu!
Thank you for supporting our channel!
Pls more videos ! Thats awesome
could you use spi to upload flash files? would this be a way to fix "bricked" motherboards?
Yes. You can also write using SPI. And yes, you can fix bricked motherboards this way. In fact, we did it in the past. After bios update of one of our laptops, it got bricked and we overwrote bios flash using SPI to restore it.
this is some good quality stuff (even if i dont understand half of it lol)
I understand the general idea but executing it is a different story. I'm no hacker but this is very informative in itself. 👍
What about reading firmware out of chips with included flash like STM32F4? They are often read-out protected against firmware extraction.
You are right. In most of the cases, microcontrollers with internal flash are shipped with read protection. In those cases different techniques are needed. Unfortunately they are not-standardized and attack path would need to be unique per MCU family. One of the approaches here could be using fault injection to attack bootloader / early routines that checks a fuse state.
Possibilities to going further into this for us? I need extract a firmware from uController too...
I found in my Rog Strix laptop some interface called JDEBUG2, which has 15 pins. Not really an embedded device, but I wanted to know more details on this interface and whether I can have some commands to show me laptop's diagnostics :).
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?
I don't understand how you read the SPI flash in circuit on the target board. Doesn't applying power to the SPI flash chip power up the target board processor and thus both are trying to read (push pull) on the same data lines? Can't this blow out the drivers in the target board processor?
Yes, applying power to chip in many cases will boot up entire board. As you mentioned, this can result in both us and a target to compete and race for the resources. However, from our experience, in those situation we usually wait a bit and after the target has done reading from flash we can start flash dumping.
@@FlashbackTeam Even when the CPU is not actively talking to the flash the lines are still in push-pull not high impedance so how can you talk to the chip without blowing up the line drivers in the cpu?
@@wowcolorsbecause the current to power up that chip is very low, and almost no current flowing through the data lines. It’s hard to burn something without enough current.
Truly impressive!
Did you recently speak at Shmoocon about this, but on a higher/conceptual level? Someone with a similar accent did. Regardless, this video is what I was hoping for!
We are glad you like it. We didn't speak at Shmoocon so it must have been somebody else.
About UFS, there are also UFS memory cards that look like MicroSD cards at first glance. They are said to be a lot faster than MicroSD. The only problem is that not a lot of devices use them. The funny thing is and I may be mistaken on it too BTW is that they re royalty free. If that is true I don't see any reason other than having to redesign things as the reason for no one switching over to it. Maybe they have a serious flaw and that is the reason why you don't see a lot of devices aside from a couple Samsung phones and laptops. Samsung may have something to do with the format but I do not believe that they were the only ones who created it. I don't believe that it is proprietary to Samsung at all but instead no one wanted to use it for some reason.
Holy crap, that hydra bus is a lot more expensive than I thought it was gonna be
Muito bom !!
Obrigado.
Tudo de bom para ti Pedro e também para o Radek.
Thank you, it works perfect!
Amazing Video, Any time coming to India for training?!
you can use a pico as the logic analyzer and as a hydro thing
Hi flashback team. I want to understand and do things like what u doing but I don't know where to start learning.
I know C programming (intermediate), I know data structures and algorithms, currently learning digital electronics, operating system and computer networks but I don't know where to proceed further actually doing these things.
Any advice is highly appreciated.
that's really good!
Amazing! Is there any plans to come to Brazil? Obrigado!
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 ;)
Quite interesting video!. Im thinking to apply this tecnique to a grandstream fxs voip adapter: i have two, one working properly another bricked (extract ok -> write bricked). It seems a corrupted flash , so it worth the effort
well Done! Very helpful, like from Pakistan
Really great video.. I've never done this, but have most of the tools and have been thinking of trying it just for fun.. I'm curious though - When you are powering that EEPROM from the clip, I'd be worried that I'd also be backfeeding power to the rest of the circuit, and potentially causing it to boot up, which might cause the MCU to start taking over the SPI bus.. Is there some way to guarantee you're only powering the memory that I'm missing, or is this really not as big of a problem as I am envisioning? Could techniques like finding the reset pin on the MCU and holding it low to prevent booting perhaps be a good workaround? Any other hints? How much experience is needed before I shouldn't expect to be completely lost in one of your in person training classes!?
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
Very nice simple and clean
Great work!
How do you prevent the master MCU from talking to the flash at the same time? Most of the time when you provide power to the flash the MCU will powered as well, because they'll use the same power rail.
From our experience, in most of the cases that is not a problem if a device also powers up. However, on some occasions we give it more time for the device to finish booting process. Once a firmware is loaded to a memory there should be less operations directly on a flash.
If dumping in-circuit is impossible we can always desolder the flash chip.
Nice info, thanks :)
hanks lot Sir.. You helping us..
very informative video !
great video !
You guys should work on a firmware update to allow the installation of a thirdparty Nas system.
Dear Santa.. I know what I want for Christmas. :D
Hello, Flashback.
I have a question. 16:59 and 17:42
The datasheet told us to use the Rising Clock. but why? Saleae told us the data use Falling Clock.
Great video! Hey, is there a less expensive alternative to the Saleae Logic Analyzer that will achieve similar results?
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.
Cool! I'd like to see more of the data extracted and what you can do with it. Translate to English so to speak.
I see lots of SOIC-8 flash chips like at 9:56 with a second set of pads at 90 degrees to the SOIC-8. I'd love to know what's going on here because it seems to common. I assume it's for some kind of SOIC-16 flash chip instead of the '8 but I've never heard anyone talk about it.
send pic
@@phr3ui559 06:27 09:56
great video!
Iv just found this channel though a other channel and brother learning curve on both wow thinking 🤔 ik what I want to do
thanks for the video. I ve got one question. What is flash is internal to the MCU, so how would it be possible to extract the firmware ? Thank you.
In such cases a target specific attack is required. It would need a separate research and maybe use different techniques like glitching.
Why are you not at BlackHat?! This was excellent video!
I just want to point out that "package" has absolutely nothing to do with how many legs an IC has. In this case, the package for the SPI flash, is an SOIC, often times, manufacturers will add a quantifier to the package name to denote the leg count to differentiate the device from others of the same type and class, in this case, for the SPI flash, the quantifier is 8, due to there being 8 legs. However, this doesn't alter the fact that the package is still an SOIC.
An example of the differences in packages can easily be shown when looking at the differences between SOT-523, SOT-323, and SOT-23. In the case of transistors with these packages, they can all be the same exact transistor, with 3 legs, but the packages are different. With Sot-523 being roughly 1.6mm x 1.6mm, Sot-323 being roughly 2mm x 2.1mm, and Sot-23 being roughly 2.9mm x 2.4mm.
Of coarse, there are many other types of packages, but this just illustrates the difference between package, and leg count, or package quantifiers.
Yes, you are right. We know there are a lot of different packages available. However, from our experience, some are more common then the others. In most of the cases, on the targets that we have worked on, they are as in the video. After first guess looking at the IC, we would always cross-check with the datasheet.
MISO line - "data should be shitted out" 😂
I get it now, why its called firmware 'dumping'...
Very informative video, thank you!
It's shifted, not shi**ed! :D
@@FlashbackTeam Haha. Maybe it’s the accent. It really sounds like it at 13:16 😂
Thanks again for the very informative video!
amazing. 17:40 was cool to see the actual wire signal. It surprised me that the hardware responds without missing any clock cycles, I guess working in web development I forget that computers are actually fast