You explain the whole process of working with hardware in a very understandable way, its not too caught up in details. The way you walk people through it makes it so easy to understand the basics of working with hardware which for me atleast was the most intimidating part. Since watching the channel I've been able to do a chip off firmware extraction, get a uart shell with my flipperzero as a bridge and locate a vulnerability in a router. It might not sound like a lot if you're watching this guy's videos but this is from someone with zero hardware experience or formal education. Big ups to Matt for being an excellent teacher🙏
This whole series was a ton of information, skill and great advice. I would wonder if you can try to reverse-engineer those 2 binaries to, perhaps, find some holes that would enable local shell even without de-soldering the chip... But still extremely impressive! Thank you for sharing this.
I found your channel recently, and you have inspired me to start learning, and start building my own setup. I'm completely new, and excited to start my journey! So, thank you.
I love this channel! I've been into computers since DOS (that ages me), never attempted firmware mods like this but was heavily into decompiling and programming software as a hobby. I appreciate your simple explaining of not only procedures but why you are doing them. Keep it up and your channel will skyrocket!
Happy follower, and still very ADHD... cards linking to prior videos when you mention them (or a playlist or collection) would be lovely. Thank you for the work you do, and for explaining so well.
Very much agree with all other commenters on your format and detailed explanations! I would only encourage you to invest in slightly better cameras (resolution makes it blurry looking) and to beef up the lighting. It will make a huge difference to what the camera manages to capture.
This is a really awesome video, I would definitely love to see more of the process, like how you go about reversing the binaries you found or analyzing traffic as the device is being used
FYI: it looks like binwalk v3 has already been pushed to the arch repos, so unless you need your special fork you should be able to use the rust version with the main binary. It looks like you incidentally used v3 in the new binary without noticing when you ran the extract. Wonderful video as always.
Yep! I just have the old one installed also so I can compare findings. I already made one commit to the rust version and needed to see the delta with the old tool.
This was awesome. I love learning how to manipulate binary files. That's something I never got that deep into. Seeing these tools in action and having a reference to go back to is making me want to do more experimenting. Thank you!
Instead of pointing in /etc/inittab to /bin/sh I would consider pointing to a script placed on any RW partition (if available) then it would be easier to manipulate and test some behavior after reboot. Just a humble remark. And as always it was nice watching your findings.
@@mattbrwn Usually the flash will have a read/write area for configuration. Though if not, can usually find a way to alter the rootfs to run a script that is downloaded, or via NFS mount, or SD card. That way can play without having to rewrite the chip.
Technically < the space between the squashfs's shown in binwalk, like 4456448 - 1991168 = 2465280 although keeping it within the original squashfs header shown size is technically safest in case the gap has something else in it that binwalk doesn't know (usually not though).
That XGpro alternative is a god send, this will make extraction much faster and I don't have to use the sketchy windows program that they make you use!
really enjoyed the video, live that you explained every step of the way there great job! would love a vid where you explain a more general approach or one where you just explain where you find out what works and what wont work for certain chips or where you find you information
PCbite probes are new to me. Thanks for mentioning them. I previously tried a pogo pin array which I got to work but the pin spacing was never quite right.
Awesome video Matt! Much appreciated with your knowledge and skills. Questions, have you ever tried doing a chip off and firmware extraction from a Secure Enclave chip from an iOS device? Curious as its super robust (maybe encrypted at rest itself). Godspeed!
TY well done video! I'd be interested in seeing where those custom binaries call out /bin/cloud-iot etc... what , if any, data is shared out with the tplink servers .
Oh man, would love for you to work on some Tapo C120s for Thingino. I just want to be able to block their cloud and attach a USB-c OTG cable so I can use ethernet. Managed to just entirely replace the Ingenic T31x on some Wyze pan v3 crap, but secure boot is a real PITA.
It would be hard to overstate how impressive both your expertise and how your concise explanations are. You have inspired me to start playing around with hardware hacking. For your next video, can we take a look at some of those binaries and also maybe look for their cloud servers? Also, is it possible to enable ssh on that firmware to be able to connect without the uart?
Great work! Do you think it's possible to reprogram the chips without having to take them off the board? Is it just easier to get all the pins aligned and stuff if you have it on its own?
I prefer to try that first, "usually" it works fine, however sometimes injecting power to the flash chip pins will make the CPU or other chips "wake up" and then that can get in the way because then multiple things will be barking commands at the flash chip. Sometimes you can get the CPU to hang using tactics similar to the bootloader glitch like ground some of its address lines so it hangs trying to hit RAM or such (or some SoC chips have a reset pin which will hold the CPU in reset, which is better than glitching it), and then it will leave the flash DI/DO pins alone (floating) so the programmer (CH341 or similar) can use them without interference.
Nice video ! Quick question, in case you don't have a chip reader (or the ability to unsolder the memory chip), if you can anyway get a shell easily at boot, how would you extract files from that UART connection ? In this example /bin/cloud-iot. Thx
Ohh that's a good question! If there are any utilities that can transfer files (curl, netcat, etc) you can use them to exfil files off the running device. This is a good video idea
@@mattbrwn Yup, I suppose sometimes you even need to transfer such utilities from your host to the target device. AFAIC, file transfer over netcat is always syntactically painful
Can I ask what kind of wire you typically use for soldering on straight to a chip? I tried stranded 30g, and was having a terrible time. I am still a bit rusty on soldering though.
I saw telnet daemon listening on loopback interface (127.0.0.1), so you could also run it on all interfaces and access shell remotely instead of using UART. I wonder if there is any form of ssh server available there which could be used instead of telnet.
What would happen if the inserted squashfs is bigger/smaller than the original? I assume if smaller it'll be padding, but what about bigger file? Were the start offset of the next file within the firmware important?
Smaller is fine, bigger is a problem because there is another filesystem it would run into. however I don't think this other filesystem is used normally (it might be used for firmware updates)
It could be slightly larger since the actual space between the first squashfs offset and the second one is 2465280 bytes (=4456448 - 1991168). However occasionally a device might have some nonstandard/proprietary data in between like headers or nonvolatile settings or such, that binwalk may not decode. Checking with a hex editor for 00 or FF padding in the "unused" zone would help confirm it is not used. Usually devices avoid doing anything outside of the eraseblock size of the flash chip because it would have to erase and rewrite the last eraseblock of the squashfs with their custom data injected on the end to do that, which could lead to bricking or block wearout and is just bad practice.
Your new compressed squash fs binary was few hundred bytes smaller. When you write it to firmware - what happens? Does it mean there will be few hundred bytes of the original squash fs binary remaining in the firmware? Does it remain as a dead (non accessible data)? Also, what would happen if tje new squash fs binary is larger even if by few bytes?
P.S. Would be nice to see further videos on what you managed to reverse engineer, and how would you improvevthis device. P.P.S. I guess for making further changes you would need to do absolotelly the same procedure on modifying that read only fs. Because of that, would it not make sense to add some socket onto the camera board for easy removal/reinsertion of the chip (if they exist for this 8 pin package)?
Some devices don't have those, and showing how to do this regardless of specific device or board layout is more useful. Of course hunting around for test pads that end up at the SoC pins is always an "extra credit" option.
Excellent video, I love these hacks, I learn a lot from them. If I may give you one point of feedback: for me the flow of information is a little too slow in the videos. I find myself reaching for the playback speed setting and skipping bits. Not to say I want you to turn it into some kind of awful TikTok channel, it's just that the information density could be higher imo.
Cool video, like always :) But now, maybe something with disassembly firmware? Overall for me will be interesting to hack Tuya devices :P Because are cheap, but cloud-connected. Sometimes quality is ok, but i cannot buy it due to vendor lock.
Isn't that a 3V flash chip? Minipro claims it's using 5V. Usually not something that'll kill the chip right away though, and maybe just a beta version artefact. (I ran 3.3V myself to a 1.8V flash recently and it survived so ..)
1:32 "yOU Can see..." lol edit: while watching this, something came to mind. i want to explore this in a chroot now. what architecture is this cpu? can you maybe release the stock rootfs? would love to tinker around with it!
This is tricky but if you can put in a reader like the Xgecu and pick a chip profile with the same chip type it will probably give you a chip ID error like "expected chip ID 0x11223344 but received ID 0x55667788" Then you can try to search around for that chip ID.
If you can see the early bootup messages sometimes the kernel will spew the chip identification when MTD comes up. Most chips use a fairly standard pinout (for the package type, like SOIC8 vs SOIC16 etc) and the same commands for the identify phase so even selecting the wrong thing as Matt said and then getting the actual chip-id that way usually works fine (just don't try to read/write/erase with the wrong setting).
if you make random passwords then when they are developing the device it makes it harder for them to get it. Not a good excuse but most of the time its devs being lazy
Assembly line programs a million flash chips at once. Having custom chips per device is more of a hassle. Some devices if they have a RW partition like jffs2 overlay will generate a custom password based on the MAC address or SoC serial number or something unique, like the routers that have custom wireless passwords per device. If it's all readonly like this one with no overlay it basically has to be same hash for all (of the same FW revision anyway). Some might have a custom /bin/login that reads the hash from a configuration partition (not a filesystem, not /etc/passwd) and then it could be customized per device along with the MAC and such. Usually the wifi or ethernet chip will have its own MAC so the firmware doesn't have to set it.
Can you get shell and extraxct an d get root accses with the smartphone like : 1. xiaomi, it's eazy bcs the comunity root xiaomi, but the cahlenge, to get shell without unlock bootloader. 2. huawei (harmonyOs), becasue the phone is lock bootloader and can't open the bootloader. 3. Etc , like phone chinesse budget friendly. Btw , thabks for you, bcs your video , teach me for extract, repack the system file , and teach me how to , repack the system, without kernel panic. Thanks a lot.
I've done a lot of contacted IoT testing for some of the big companies. Given you had a root shell, no chip off writing of flash was needed. This device has pretty poor security: - no/poor secure boot implementation - poor uboot security - no verification of squashfs partition by previous stage - data on flash not encrypted via EFUSE keys Also fortunate not BGA chips. That said, not knocking the video - great tutorial on how to do chip off read/write.
If new squashroot is different size does newfw.bin not have either leftover data or truncated data? Would a more complete newfw.bin not require two calls to dd with new count for the 1st and offset for 2nd?
I really like the assume nothing, explain everything approach ... its beautiful
You explain the whole process of working with hardware in a very understandable way, its not too caught up in details. The way you walk people through it makes it so easy to understand the basics of working with hardware which for me atleast was the most intimidating part. Since watching the channel I've been able to do a chip off firmware extraction, get a uart shell with my flipperzero as a bridge and locate a vulnerability in a router. It might not sound like a lot if you're watching this guy's videos but this is from someone with zero hardware experience or formal education. Big ups to Matt for being an excellent teacher🙏
This is awesome to hear!! 🫶
I've learned more in this video than I'd like to admit. Great cadence, great content. Looking forward to more. Bravo!
This whole series was a ton of information, skill and great advice. I would wonder if you can try to reverse-engineer those 2 binaries to, perhaps, find some holes that would enable local shell even without de-soldering the chip... But still extremely impressive!
Thank you for sharing this.
This is the next step :D
9:58 - GOLD! Thank you for ALL the information and especially this about the orientation of the pins!!!
I found your channel recently, and you have inspired me to start learning, and start building my own setup. I'm completely new, and excited to start my journey! So, thank you.
I love this channel! I've been into computers since DOS (that ages me), never attempted firmware mods like this but was heavily into decompiling and programming software as a hobby. I appreciate your simple explaining of not only procedures but why you are doing them. Keep it up and your channel will skyrocket!
Happy follower, and still very ADHD... cards linking to prior videos when you mention them (or a playlist or collection) would be lovely. Thank you for the work you do, and for explaining so well.
I don't comment anymore yet
this video was great. I know nothing about IoT hacking at a hardware level yet, it was so easy to follow
Been watching your vids since you started and they've all been very informational but the quality and format have become excellent. Thank you !
I’m working through every single one of these videos cause they are so well done. Thank you for posting these!!
Cool beans!
Looks like this is the only way we can actually get cameras to use on foss security setups.
Very much agree with all other commenters on your format and detailed explanations! I would only encourage you to invest in slightly better cameras (resolution makes it blurry looking) and to beef up the lighting. It will make a huge difference to what the camera manages to capture.
which camera specifically is blurry? or all of them?
Basically all of them. Can't tell if it's the compression causing it or if the camera itself that is causing it.
My stream is clearer than 99.9% of people doing this type of video. Incredible quality. Thanks for all the work you out into this.
Great video as always Matt!
This is a really awesome video, I would definitely love to see more of the process, like how you go about reversing the binaries you found or analyzing traffic as the device is being used
FYI: it looks like binwalk v3 has already been pushed to the arch repos, so unless you need your special fork you should be able to use the rust version with the main binary. It looks like you incidentally used v3 in the new binary without noticing when you ran the extract. Wonderful video as always.
Yep! I just have the old one installed also so I can compare findings. I already made one commit to the rust version and needed to see the delta with the old tool.
This was awesome. I love learning how to manipulate binary files. That's something I never got that deep into. Seeing these tools in action and having a reference to go back to is making me want to do more experimenting. Thank you!
Instead of pointing in /etc/inittab to /bin/sh I would consider pointing to a script placed on any RW partition (if available) then it would be easier to manipulate and test some behavior after reboot. Just a humble remark. And as always it was nice watching your findings.
No RW partitions. Otherwise we could modded firmware from the temp shell we got from the bootloader (see prev. vid)
@@mattbrwn Usually the flash will have a read/write area for configuration.
Though if not, can usually find a way to alter the rootfs to run a script that is downloaded, or via NFS mount, or SD card. That way can play without having to rewrite the chip.
So good. Important point is if you repack the squashfs - make sure new image size is
Technically < the space between the squashfs's shown in binwalk, like 4456448 - 1991168 = 2465280 although keeping it within the original squashfs header shown size is technically safest in case the gap has something else in it that binwalk doesn't know (usually not though).
That XGpro alternative is a god send, this will make extraction much faster and I don't have to use the sketchy windows program that they make you use!
I love it Matt!!! Thank you for this kind if content!!!
really enjoyed the video, live that you explained every step of the way there great job! would love a vid where you explain a more general approach or one where you just explain where you find out what works and what wont work for certain chips or where you find you information
Very nice and well explained. I always enjoy your content.
Great knowledge! Brilliant explanation! Thank you Mat!!!!!!!!!!!!!!!!!!!!!
PCbite probes are new to me. Thanks for mentioning them. I previously tried a pogo pin array which I got to work but the pin spacing was never quite right.
Really interesting stuff, brilliantly presented. Thanks!
Good call on the bin compression
Très instructif, merci pour ce partage d'expérience.
Awesome job thanks for the tips shared in the video nice job
Could you make a video detailing your education and how you got to your skill level? Vids are great, keep it up!
you are covered. Love your videos.
Cool vid. Waiting on the episode of reverse Eng. Of these binaries
Awesome video Matt! Much appreciated with your knowledge and skills.
Questions, have you ever tried doing a chip off and firmware extraction from a Secure Enclave chip from an iOS device?
Curious as its super robust (maybe encrypted at rest itself).
Godspeed!
Great video, as always 👍
You could have used the break out Pads instead of the pins, not as fiddly😉
As always great video
yoooo droppin str8 heat!!
TY well done video! I'd be interested in seeing where those custom binaries call out /bin/cloud-iot etc... what , if any, data is shared out with the tplink servers .
Hi Matt, could you please add a link for the pogo pins? You mentioned that there was a link but I don't see it.
Thanks 🙂
Did you spot the users called "r0ot", "rood", and "rnot" in the shell? 32:48 UART issues?
yeah there is some weird stuff going on with the uart shell. other vid had similar issues
Oh man, would love for you to work on some Tapo C120s for Thingino. I just want to be able to block their cloud and attach a USB-c OTG cable so I can use ethernet. Managed to just entirely replace the Ingenic T31x on some Wyze pan v3 crap, but secure boot is a real PITA.
It would be hard to overstate how impressive both your expertise and how your concise explanations are. You have inspired me to start playing around with hardware hacking. For your next video, can we take a look at some of those binaries and also maybe look for their cloud servers? Also, is it possible to enable ssh on that firmware to be able to connect without the uart?
You can do it with dropbear and known password in /etc/shadow file and add dropbear on rc startup file
good informative content , thank you !
Great work! Do you think it's possible to reprogram the chips without having to take them off the board? Is it just easier to get all the pins aligned and stuff if you have it on its own?
Nice video,
Noob question, is it necessary to desolder the chip for reading / flashing? I've seen these clip-on soic cables.
I prefer to try that first, "usually" it works fine, however sometimes injecting power to the flash chip pins will make the CPU or other chips "wake up" and then that can get in the way because then multiple things will be barking commands at the flash chip. Sometimes you can get the CPU to hang using tactics similar to the bootloader glitch like ground some of its address lines so it hangs trying to hit RAM or such (or some SoC chips have a reset pin which will hold the CPU in reset, which is better than glitching it), and then it will leave the flash DI/DO pins alone (floating) so the programmer (CH341 or similar) can use them without interference.
What are the Magnetic goose neck probes you are using? would you recommend them?
There's a "PEM private key" file. Is it encrypted and does it correspond to any of those PEM Certificates?
Excellent video. Well done.
Nice video ! Quick question, in case you don't have a chip reader (or the ability to unsolder the memory chip), if you can anyway get a shell easily at boot, how would you extract files from that UART connection ? In this example /bin/cloud-iot. Thx
Ohh that's a good question! If there are any utilities that can transfer files (curl, netcat, etc) you can use them to exfil files off the running device. This is a good video idea
@@mattbrwn Yup, I suppose sometimes you even need to transfer such utilities from your host to the target device. AFAIC, file transfer over netcat is always syntactically painful
Very cool, thanks
yay for open source! good vid too ;-)
Golden content
Can I ask what kind of wire you typically use for soldering on straight to a chip?
I tried stranded 30g, and was having a terrible time. I am still a bit rusty on soldering though.
Very interesting thank you.
On your Linux unit, what distro are you running, that's got a cool look to it
Distro does not really matter, he uses DWM as far as I can tell and some kind of basic bash shell
He uses arch
arch + i3wm
I saw telnet daemon listening on loopback interface (127.0.0.1), so you could also run it on all interfaces and access shell remotely instead of using UART. I wonder if there is any form of ssh server available there which could be used instead of telnet.
Many times there is no space, even for something light like dropbear. Gotta have room for their custom bloatware cloud apps. :)
What would happen if the inserted squashfs is bigger/smaller than the original? I assume if smaller it'll be padding, but what about bigger file? Were the start offset of the next file within the firmware important?
Smaller is fine, bigger is a problem because there is another filesystem it would run into. however I don't think this other filesystem is used normally (it might be used for firmware updates)
It could be slightly larger since the actual space between the first squashfs offset and the second one is 2465280 bytes (=4456448 - 1991168). However occasionally a device might have some nonstandard/proprietary data in between like headers or nonvolatile settings or such, that binwalk may not decode. Checking with a hex editor for 00 or FF padding in the "unused" zone would help confirm it is not used. Usually devices avoid doing anything outside of the eraseblock size of the flash chip because it would have to erase and rewrite the last eraseblock of the squashfs with their custom data injected on the end to do that, which could lead to bricking or block wearout and is just bad practice.
can you do a firmware modification on a mikrotik device. they have a custom openwrt somehow look and work more stable
Are your start and stop bits for UART set correctly?
Your new compressed squash fs binary was few hundred bytes smaller. When you write it to firmware - what happens? Does it mean there will be few hundred bytes of the original squash fs binary remaining in the firmware? Does it remain as a dead (non accessible data)?
Also, what would happen if tje new squash fs binary is larger even if by few bytes?
P.S. Would be nice to see further videos on what you managed to reverse engineer, and how would you improvevthis device.
P.P.S. I guess for making further changes you would need to do absolotelly the same procedure on modifying that read only fs. Because of that, would it not make sense to add some socket onto the camera board for easy removal/reinsertion of the chip (if they exist for this 8 pin package)?
Why are you not connecting the tx and rx to the test points on the pcb that are nearby the chip (4 round ones) ??
Some devices don't have those, and showing how to do this regardless of specific device or board layout is more useful. Of course hunting around for test pads that end up at the SoC pins is always an "extra credit" option.
Excellent video, I love these hacks, I learn a lot from them. If I may give you one point of feedback: for me the flow of information is a little too slow in the videos. I find myself reaching for the playback speed setting and skipping bits. Not to say I want you to turn it into some kind of awful TikTok channel, it's just that the information density could be higher imo.
Cool video, like always :) But now, maybe something with disassembly firmware? Overall for me will be interesting to hack Tuya devices :P Because are cheap, but cloud-connected. Sometimes quality is ok, but i cannot buy it due to vendor lock.
I like using hot air to remove them but I tend to prefer hand soldering soic... Wson is a different story
can you try ubiquiti devices
Isn't that a 3V flash chip? Minipro claims it's using 5V. Usually not something that'll kill the chip right away though, and maybe just a beta version artefact.
(I ran 3.3V myself to a 1.8V flash recently and it survived so ..)
1:32 "yOU Can see..." lol
edit: while watching this, something came to mind. i want to explore this in a chroot now. what architecture is this cpu? can you maybe release the stock rootfs? would love to tinker around with it!
Hello Matt I have device with scraped chip on it how can determine what it is ?
This is tricky but if you can put in a reader like the Xgecu and pick a chip profile with the same chip type it will probably give you a chip ID error like "expected chip ID 0x11223344 but received ID 0x55667788"
Then you can try to search around for that chip ID.
If you can see the early bootup messages sometimes the kernel will spew the chip identification when MTD comes up. Most chips use a fairly standard pinout (for the package type, like SOIC8 vs SOIC16 etc) and the same commands for the identify phase so even selecting the wrong thing as Matt said and then getting the actual chip-id that way usually works fine (just don't try to read/write/erase with the wrong setting).
@Spudz76 i will try that. Its SOIC20 a bit odd.
The chip actually supports secure boot. Its such a shame that it wasn't implemented for this platform
Noob question: Why are passwords so often hardcoded?
if you make random passwords then when they are developing the device it makes it harder for them to get it. Not a good excuse but most of the time its devs being lazy
Assembly line programs a million flash chips at once. Having custom chips per device is more of a hassle. Some devices if they have a RW partition like jffs2 overlay will generate a custom password based on the MAC address or SoC serial number or something unique, like the routers that have custom wireless passwords per device. If it's all readonly like this one with no overlay it basically has to be same hash for all (of the same FW revision anyway). Some might have a custom /bin/login that reads the hash from a configuration partition (not a filesystem, not /etc/passwd) and then it could be customized per device along with the MAC and such. Usually the wifi or ethernet chip will have its own MAC so the firmware doesn't have to set it.
♥ HTP ♥
💖💖💖💖
❤
Can you try a9 mini camera all apps needed to access it is chinese based and needed to access wifi and storage which is sus
You could also just spin up an isolated Windows VM that has no network connection to run "sketchy Windows software".
It's a great way to test out sketchy software. But in the long run, using native OSS SW is best
Can you get shell and extraxct an d get root accses with the smartphone like :
1. xiaomi, it's eazy bcs the comunity root xiaomi, but the cahlenge, to get shell without unlock bootloader.
2. huawei (harmonyOs), becasue the phone is lock bootloader and can't open the bootloader.
3. Etc , like phone chinesse budget friendly.
Btw , thabks for you, bcs your video , teach me for extract, repack the system file , and teach me how to , repack the system, without kernel panic. Thanks a lot.
wau
Pins 22 and 23* not 23 and 24
I've done a lot of contacted IoT testing for some of the big companies.
Given you had a root shell, no chip off writing of flash was needed.
This device has pretty poor security:
- no/poor secure boot implementation
- poor uboot security
- no verification of squashfs partition by previous stage
- data on flash not encrypted via EFUSE keys
Also fortunate not BGA chips.
That said, not knocking the video - great tutorial on how to do chip off read/write.
1:30 fart
Third!
first!
4thhhhhh
37s 0 views bro fell off
If new squashroot is different size does newfw.bin not have either leftover data or truncated data? Would a more complete newfw.bin not require two calls to dd with new count for the 1st and offset for 2nd?