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.
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.
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
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.
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.
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.
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.
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.
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!
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
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...)
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.
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.
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
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 :-)
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...
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.
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 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.
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?
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.
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
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.
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.
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. :)
Everything is explained clearly without wasting time or over-explaining. Well done.
That's exactly what I was going to say!
Please never delete this video, it's very helpful.
Download it qnd save it
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.
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
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.
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.
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.
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.
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!!!
wow.... this is one of the most fascinating videos I've ever seen on YT....
You should consider offering a recorded ‘on demand’ version of the course. I would buy it!
Your videos are the best! Please don't stop making the tutorials! Thank you.
Perfect! Not to simple, not to complicated, with practical information.. Thank You
More information than from my technical degree in a few minutes
What a beautiful work!. Thank you for sharing your time and effort.
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.
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!
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!
I'll be promoting you guys in all the forums I'm in ... STARTING with this video!!
WOW mind blow stunmbled on this channel and glued to the screen...
Please regularly upload such a knowledgeable videos. After long time I am watching your videos. Love from India 🙏
Thanks for this content, it is really well explained.
Wow, it was cool to see how embedded devices get hacked as for man who is interested in embedded and IoT. Thanks for video
Damn this channel is a hidden gem
Yesss! I love to see you back!
Pleasee consider to upload more often
This channel is a treasure..
I just discovered your team, thank you so much for this interesting content!
Very good hacking ! Nice job guys. I hope one day I can do your training session
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
Thanks for this content we can see al the time you have spend to make this incredible video !
I understand the general idea but executing it is a different story. I'm no hacker but this is very informative in itself. 👍
He's so good at what he does.
You are a proper educator. Insta-subbed.
Simple, efficient, educative !
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...)
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.
Love these videos flashback team!
Very interesting, and looking forward to more content!
That's nice. Great video brother!
I particularly like the sound quality during the NOR description!
Thank you! We are slowly improving our recording hardware and editing techniques :-)
one of the essential videos on youtube )
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
Ima download it thanks for sharing!!
thank you so much, Ive learnt alot from you in this video.
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
Lmao! Alright you got me with the Saleae joke.
this is some good quality stuff (even if i dont understand half of it lol)
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
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 :-)
Pls more videos ! Thats awesome
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 RUclips algorithm finally decided to give our channel a chance!
Good job Pedro from the flash back team
hanks lot Sir.. You helping us..
Amazing vid ... found a new rabbit hole .... yeeee haw
Truly impressive!
I was waiting so bad for a new video! Great
you can use a pico as the logic analyzer and as a hydro thing
Muito bom !!
Obrigado.
Tudo de bom para ti Pedro e também para o Radek.
Thank you, it works perfect!
Very nice simple and clean
Interesting. Look forward to more content.
very informative video !
Nice video. Sad it used such a proprietary board, but thankful that board is open source.
I DEFINUTELY subscribed to this channel! F'ing quality bro!
Iv just found this channel though a other channel and brother learning curve on both wow thinking 🤔 ik what I want to do
that's really good!
Excellent! used for hikvision
great video !
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.
Great work!
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 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.
Nice info, thanks :)
well Done! Very helpful, like from Pakistan
Interesting. Thanks!
Very Nice!
Cool! I'd like to see more of the data extracted and what you can do with it. Translate to English so to speak.
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!
great video!
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?
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.
Amazing Video, Any time coming to India for training?!
i wish there were more master / slave relationships in electronics. would be so much more fun to learn.
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
Excelent video.
wow...nice!
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.
Amazing ....
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 ;)
Finally found something useful information 🤠
pięknie, mega wideo ;)
thx dude
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
Great resource
Great one
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
You guys should work on a firmware update to allow the installation of a thirdparty Nas system.
Guauuuu !!!!. Very interesting !!🤪😜
can hydrabus use to communicate with JTAG?
It can, with openocd. It also supports JTAG pin discovery.