A tip for soldering the wires on is to get a roll of 48SWG enamelled copper wire with solderable insulation, which will tin when you apply a soldering iron tip to it. Allows you to solder to fine pins, and even to non filled vias with no problems, and gives a good connection. If the wire is to be there more or less permanent you can then tack it down with some UV cure glue, or even regular gel superglue if the bloom it will have is not going to worry you. Used it to repair damaged solder pads as well, soldering the IC pin to the wire, and then the wire to the track, and a drop of superglue to hold the lot down, followed the next day with a light scrub in IPA ( I was using TCE though, before it was banned from the military as well) to get the bloom off, leaving a good clean firm connection. Lasts decades with no issues, though not going to handle more than 50mA reliably, but getting you a wire out to a place where you can have a small strip of Veroboard 3 holes long, and however many point you want wide, stuck down to some point inside was a good way to have reliable monitoring.
Back in the day, glitching was used to hack the smartcards in satellite receivers to enable all the channels on Dish and DirectTV receivers. The smartcards had a simple CPU and once successfully glitched, the door was wide open to clone the cards, modify subscription info, etc. Good times!
Even easier than soldering: short the clock pin to the data of the flash with a pair of tweezers, a screwdriver, a bit of wire, etc. You'll mess up the read just the same, thereby dropping into u-boot, with less chance of overheated traces, lifted traces, solder bridges...
take a raspberry pi pico, as your UART interface, write a small program that detects the glitch timing and trigger the glitch on the GPIO - auto glich jail breaker.
i really like your content, it’s above my knowledge base but I’m learning more and more through your content. I like how you strike a balance between explaining things again / assuming your audience has seen your previous videos/know what you’re talking about. great stuff
Nice video as always, Matt. A suggestion for your soldering - always tin your wire ends before soldering them on anything. It is much easier to solder a freshly tinned wire to your target.
ho ho ho, i didn't know your youtube channel Matt, so amazing demonstration of glitching a device. Just received my bus pirate 6 a couple of days ago. I was working on a little fiber converter where uart was of corse disabled at the boot. I dumped the firmware, but now i have a new exercise with this video, let's glitch it ! Thank you for sharing your knowledge, giving it to the community is what makes you a real hacker !!!!
I'm in the middle of a cybersecurity degree and I LOVE your videos ! I just saw two for now : one where glitching the flash chip to ground doesn't give you a shell, and this one. It's always incredibly instructive and I really like how you explain stuff ! Watching these two vids made me feel like watching the same explanations twice, especially when you explained the role of UART and stuff, but it's ok for me ! I really look forward to watching more videos on hacking physical IoT devices ! I wish you the best for the future
I love that you show everything, very educational and cool for a programmer with interest for electronics and hacking. Also nice you leave in authentic parts like when it's a struggle to solder :D
These videos provide an interesting way learn about Linux/embedded systems in general, without having to go through droning lectures about kernel/bootloader/rootfs interactions. Thank you
If youre struggling with soldering, dont worry, its most likely not your fault! Those jumper cables you used to solder to the chip are notorious for not soldering good. Also having the correct flux and solder combo will be your best friend! I used to use a bunch of tip tinner for my soldering iron until I found a good flux like 'MG Chemicals' or 'Chipquick'. Both say no clean but I still clean anyway. Also, use 60 / 40 solder instead of the typical 63 / 37 solder, it might not seem like a big difference on paper, but its a whole different animal! I usually keep my soldering iron around 650F - 750F depending on what Im doing while keeping solder on the tip when I let the iron rest so its easier to clean for the next time I pick it up. Hope that helps and thank you for the informative video!
Great video. You could sneak in an esp8266 that would connect to the tx/Rx, float the DO pin on the flash until it sees the second auto negotiate and then ground the DO. After that it could do the modifications to the bootcmd, run the normal init and then just provide telnet pass thru access to the root shell that it has.
To solder to small pins in circuit, it's easier to use plastic insulated wire-wrap wire. Multiple colors. Single strand thin pure-copper wire with plastic insulation (not enameled speaker coil wire). Strip just enough of the insulation for the length of the pin you are attaching to, tin the end, hold the wire nearly perpendicular to the PCB (slight angle) so the wire is soldered parallel along the pin from the bend at the chip to the bend at the PCB. Best when you want to wire up more than two pins right next to each other to avoid solder bridges. A vertical microscope might not be the best option since one of your hands will be nearly directly over the pin being soldered. Not great capturing video. The best view to look at this is 30-60 degrees off vertical. I don't use a microscope. I use either a magnified adjustable desk light, or a Jewlers eye-loupe, or for really fine pins a set of dentist's magnified glasses. This kind of wire can also be used to solder to tiny discrete components that are right next to other tiny components where larger stranded wire is just too big.
Yes #30 wire-wrap is great. Use Teflon coated wire, it has a higher melting point. You will want to tape it down, solid wire breaks pretty easily when bent a few times.
I also noticed he's soldering to the base of the pins, aiming outwards at 90 degrees... Sometimes it works better when you come over the top, and solder parallel to the pin, down its side. Bend the wire to shape first, and hold it down with your finger on top of the chip. Obviously this doesn't work if you need to use loads of pins on both sides, but it's a trick to keep in mind.
I was into this sort of thing years ago. Work took over and time got shorter. This and your other videos has rekindled my interest. Simple process on this one but superb video never the less. 👍👍👍
Finally found a new interesting channel so subscribe to. Weird that you were never recommended to me before. Well, the algorithm works in mysterious ways I guess. 😃
My soldering was the same, watched a ton of videos, most important was to have nicely tinned solder tip and the temp is correct. Ans with a ton of practice its near perfect. ❤
@@mattbrwn I think lots of things are done better when not trying to record yourself doing it. Just having to work around the camera makes it harder before you even start on the psychology of it.
@@UnCoolDad For the most part its alright if the tip is oxidized like that, I can get back to normal with Tip Tinner and some good flux after that. Ive only ever replaced one tip at work and thats because of someone elses mistake.
I do some fairly high level soldering, installing csp’s bga’s QFN’s you name it, fly wires from the solder balls etc. currently going through a metallurgy class about SMT from a metallurgy nerd. I know so much more than I care to know about solder lol.
IMO this would be good opportunity to followup (as you were saying) with a firmware dump, modify, re-program, etc. This would be beneficial in that it would provide ideas for those who run into situations where it would be required to do so. Viz inits resetting all tty connections, etc. Just my $.02. Great Videos!
Great video! During a software downgrade I bricked my C200, looking around online I found a post on Reddit that someone was able to interact with it via an ethernet port on the board and push the firmware via TFTP, unbricking the camera. Won't post the link as I'm sure anyone can find the post with some google-fu. Unfortunately I have zero skill with electronics and ended up ripping the pads from the board, but this takes it to the next level!
you need to post that link you haven't been doing this long but what you jut did is the most infuriating thing to possibly put into a forum for this kind of hobby.
I like how you break it down. You should have covered how to differentiate the different UARTs; how to read the datasheet a little. Still, I'll recommend this to some of my students. Also DuPont wires don't really have a color code.
Matt, suggested future similar projects… focus on cheap hardware from Meraki that traditionally only could be used with a license but that which likely can use OpenWRT once ported. Especially the WiFi 6 and newer gear, eg MR28, MR36, MR36H, MR44, MR46, MR46E, MR56, MR76, MR78, MR86. Pioneer some work by getting a new model supported in OpenWRT like these models already are: (Google for OpenWRT and you’ll see a page full of already working models. Note that some like the MR33 have countermeasures in the 2017 firmware that will brick your hardware if going into uboot. Would like to see you fix that!) Then explain to the audience and demo how cheap “locked” Meraki gear can be reflashed with OpenWRT for inexpensive and powerful access points and switches. It’s enough if you can show and document just how to get into the newer access points; someone else will do the OpenWRT port. Getting in is apparently hard on some of these. Thanks for your channel.
Hi, Matt. Thank you so much for sharing such fantastic videos on UA-cam. I have a router device that doesn’t have an exposed UART interface, but I found in the MCU’s datasheet that certain pins are designated for UART functionality. Would it be possible to scrape off the solder mask on the corresponding pin traces and try to connect that way? Have you ever had a similar experience? This MCU uses a QFN128 package, with some pins located within the pad, so I can’t connect directly to its pins and can only try connecting through the exposed traces. My English isn’t very good, so I hope you can understand.
you going to have to either find a place those UART pins are exposed on the board OR remove the chip, solder magnet wire to the traces, then return the BGA chip back to the board... which is easier said than done
The solder wants to wick to the hottest part and away from the coolest. The leads will probably stay colder than the wire you are using to probe. Try a solid core wire, also that tip is probably oversized and slightly oxidized
I'm watching a ton of random videos and came across one that said you were thinking about starting a discord server. Did you ever create one? You've inspired me to buy some cheap TP link routers and start messing around haha..
I do not understand why you cannot override password hashes? At 24:44 in the video, you can see that overlayfs with writable sublayer (/overlay) is mounted as a root. So, it /should/ be possible to override any file, unless there is some other issue (like what is "pmpfs" filesystem).
Update: it worked! But the bootargs is missing on this one, it seems they built the kernel with it's command line baked in to stop this kinda thing (it's a build option, setenv bootargs does nada for me). Glitch immediately after the 2nd 'click' from the IR shutter. Glitching earlier will revert to a u-boot mask ROM i think but it's impoverished with only an 'httpd' command for firmware updates.
@@foobarf8766Yep sometimes they bake the boot args into the kernel binary or the bootloader so you cant change them unless you try to glitch the flash or flash a custom firmware on it. I also had a device that did not allow me to change the bootargs or any kernel parameters
Great video! It would be neat to install in the device a pi pico or similar micro to watch the uart output and perform the glitch automatically on every boot like a game console modchip. Not sure how useful it would be for this case but nice proof of concept.
I have a Netgear AC1200 R6120 i tried doing this with by monitoring the UART serial console and the R6120 wouldnt boot with it set up, i had to manually short spi pin 2 to pin 4. I tried with a push-button and it wouldnt boot either lol
No idea why this came up on my YT feed, but .. well, it was pretty cool. I have no idea why I'd want to hack my Tapo cameras. Didn't even know it could be done. But now I know...
Probably could also `setenv bootdelay=3` to enable break to bootloader prompt without future glitching (since UBoot input was not compiled completely out, and `stdin=serial`). This is similar to grub with a timeout of 0 vs non-zero.
Any resources which tells why those glitches works? Is it a bug with the uboot/security measures or intended behavior? If I'm interpreting correctly you basically shorted the flash chip to make them temporarily unavailable to the uboot, then rather than gracefully handle the exception, uboot just give preboot access?
Uboot wasn't able to read flash chip ID so couldn't autoboot and dropped into hush shell. More locked down IoT won't give you a shell, won't let you change bootargs etc.
Thanks for the video. Would still like to see a video flashing Freshtomato to a router to see if it has better security. More videos about taking control of an IOT and making my own, so it will not report home to some place in china or where ever. The devise will be 100% under user control.
There appear to be 4 small round pads near the corner of your CPU very near to the primary UART pins that you are probing. Have you checked to see if they might connect to the pins that you want? I have a similar camera (with a different motherboard) that had such pads. They are big enough on my device that I was able to tack solder my UART wires to it.
I think that's known as a pogo pin, and they appear to be on a wire armature for hands free placement. The pins have a tiny spring inside that helps apply pressure and keep contact.
Hey what do you mean by a wire armature? I'd like to have a similar setup and did a fair bit of googling after watching a previous vid but I must've not had the right terms to search for
I ran into some weird text glitches with a UART port on another device. Eventually I switched to a different adapter and they went away. Might be as simple as a poor connection so the voltage rise/fall of the signal is delayed or doesn’t peak high enough for the adapter to it as a 1 or 0
Security cameras are one of the things that absolutely must have observable, user serviceable firmware in many applications; but is somehow one of the few things that has no practical mass market option offering these properties.
Those serial issues are very weird, I never saw anything like that. I'd try to drop the baudrate a bit, just in case the serial controller inside the SoC is shit.
Well done! The ease of this has my head spinning with ideas. *Edit: I got a question, actually... * how do you deal with unknown/random CRC's when modifying bin files for write back to EEPROM/FLASH? I have a small I2C EEPROM (only like 256 bytes) .... it has a few addresses that shuffle in a way that looks suspiciously like a CRC... but I cannot figure out the polynomial or algo for how it's calculated. This EEPROM is, in essence, the vector into this device, so I have to be able to modify the data here to move further. I can't do that unless I pass the CRC validation.
Are there tools for glitching data transfers that are a bit more subtle? Like watching for a pattern coming across from an eeprom to a micro and just substituting a few bits as it goes across?
Hey Matt, the livestream you recently did with the spi glitch is what got me into my Netgear AC1200 R6120 but I'm having issues modifying the squashfs on a downloaded firmware update. I'm trying to modify setup.cgi to drop a reverse shell but the location of /etc is "/etc/null" I've tried "mkdir /etc" but it auto deletes after unmounting squashfs.img. The kernel panic doesn't allow UART input. Any suggestions? eg: research material, personal advice etc
so if Uboot does not recognize the flash type, it falls back onto a default type that consequently will load the kernel image at the wrong offset, throwing an exception that eventually leads into the uboot prompt?
If I recall, uboot will try a list of boot options in an order defined at compile time (much like BIOS on a PC trying the floppy drive then the CD drive, then the hard drive). If this all fails, it drops to the prompt. Most manufacturers don't bother changing any of these defaults... Partly because it isn't necessary for the product to work reliably (if the flash fails, the device is dead anyway), and partly because they set it up for development purposes to boot off multiple things, and simply never bother changing it.
Here's a random suggestion. Yealink makes some office phones that are branded verizon that even when you flash standard yealink firmware to them, the first thing it does is connect to a server and download the Verizon stuff. And then no web gui. You can get around this by interrupting the connection to that server at just the right time and then change the address of the server in the web gui to garbage but it's a giant pain to do. Would there be a way to do this solely by messing with the hardware? I know this is random but I had some of these phones and they were a giant PITA to deal with
It looks like you just want to kill access to the server dishing up the Verizon firmware. You should be able to do this with a firewall rule on your router - if destination is nasty IP, drop connection - or sinkhole the domain name in DNS using say a Pi-hole. Use Wireshark to check if the server IP is found via DNS or if it is hard coded to know which is best way to proceed.
@@dingokidneys Or put the phones on a VLAN that doesn't have DNS specified in the DHCP. Or use a custom DHCP response for those devices that gives no DNS servers.
No. The AVB (Android Verified Boot) spec states that when the bootloader can't verify the boot/recovery partition (where the kernel image is), and the bootloader is "locked", the device should enter the RED verified boot state (the boot fails entirely). Also, the bootloader cannot under any condition allow for the loading and execution of unsigned (non-original) code. In practice, this means that if you somehow manage to alter the boot image that's being loaded, the bootloader will refuse to boot and enter some kind of emergency download mode (in the case of Samsung, it's called "ODIN") to let you restore the device. This mode however, will only let you flash firmware that's signed by the manufacturer's key.
Getting asked about the probes used in this video. They are PCBite probes.
Link: amzn.to/4eotvVh
A tip for soldering the wires on is to get a roll of 48SWG enamelled copper wire with solderable insulation, which will tin when you apply a soldering iron tip to it. Allows you to solder to fine pins, and even to non filled vias with no problems, and gives a good connection. If the wire is to be there more or less permanent you can then tack it down with some UV cure glue, or even regular gel superglue if the bloom it will have is not going to worry you. Used it to repair damaged solder pads as well, soldering the IC pin to the wire, and then the wire to the track, and a drop of superglue to hold the lot down, followed the next day with a light scrub in IPA ( I was using TCE though, before it was banned from the military as well) to get the bloom off, leaving a good clean firm connection. Lasts decades with no issues, though not going to handle more than 50mA reliably, but getting you a wire out to a place where you can have a small strip of Veroboard 3 holes long, and however many point you want wide, stuck down to some point inside was a good way to have reliable monitoring.
I was about to ask. Thanks!
Me as well 😀
Also lowering the temperature can help, otherwise it takes to much time to solidify, and it's not easy to stay still for so long
You should make a colab with Laurie Wired!
Back in the day, glitching was used to hack the smartcards in satellite receivers to enable all the channels on Dish and DirectTV receivers. The smartcards had a simple CPU and once successfully glitched, the door was wide open to clone the cards, modify subscription info, etc. Good times!
Matt the type of guy to just have a random password hash chilling in his browsers search bar 😂
Right?! I remember that bit of lore…
You guys don't?
Even easier than soldering: short the clock pin to the data of the flash with a pair of tweezers, a screwdriver, a bit of wire, etc. You'll mess up the read just the same, thereby dropping into u-boot, with less chance of overheated traces, lifted traces, solder bridges...
That’s kind a stuff I knew it is possible, but never made it. Thankfully Matt made it like it’s easy peasy and explained it perfectly.
That's a great tip about uboot, just what I needed for a sigmastar camera module I have laying around for months.
New video, cup of tea, sit and relax!! Amazing job! Thanks Matt
take a raspberry pi pico, as your UART interface, write a small program that detects the glitch timing and trigger the glitch on the GPIO - auto glich jail breaker.
Had the same thought but using a simpler Arduino loop timed to sense a power rail waking up and a variable to set the timing,
i really like your content, it’s above my knowledge base but I’m learning more and more through your content. I like how you strike a balance between explaining things again / assuming your audience has seen your previous videos/know what you’re talking about. great stuff
Nice video as always, Matt. A suggestion for your soldering - always tin your wire ends before soldering them on anything. It is much easier to solder a freshly tinned wire to your target.
Brilliant video ! It reminded me of how I once had to glitch a Thinkpad bios chip to get into the password protected bios 🙂
ho ho ho, i didn't know your youtube channel Matt, so amazing demonstration of glitching a device. Just received my bus pirate 6 a couple of days ago. I was working on a little fiber converter where uart was of corse disabled at the boot. I dumped the firmware, but now i have a new exercise with this video, let's glitch it !
Thank you for sharing your knowledge, giving it to the community is what makes you a real hacker !!!!
I'm in the middle of a cybersecurity degree and I LOVE your videos ! I just saw two for now : one where glitching the flash chip to ground doesn't give you a shell, and this one. It's always incredibly instructive and I really like how you explain stuff ! Watching these two vids made me feel like watching the same explanations twice, especially when you explained the role of UART and stuff, but it's ok for me ! I really look forward to watching more videos on hacking physical IoT devices ! I wish you the best for the future
awesome work... p/s we all have those bad solder days. looking forward to seeing your next one.
I love that you show everything, very educational and cool for a programmer with interest for electronics and hacking. Also nice you leave in authentic parts like when it's a struggle to solder :D
Nice, I have two of these at home and was wondering about messing with them 🤘
These videos provide an interesting way learn about Linux/embedded systems in general, without having to go through droning lectures about kernel/bootloader/rootfs interactions. Thank you
If youre struggling with soldering, dont worry, its most likely not your fault! Those jumper cables you used to solder to the chip are notorious for not soldering good. Also having the correct flux and solder combo will be your best friend! I used to use a bunch of tip tinner for my soldering iron until I found a good flux like 'MG Chemicals' or 'Chipquick'. Both say no clean but I still clean anyway. Also, use 60 / 40 solder instead of the typical 63 / 37 solder, it might not seem like a big difference on paper, but its a whole different animal! I usually keep my soldering iron around 650F - 750F depending on what Im doing while keeping solder on the tip when I let the iron rest so its easier to clean for the next time I pick it up. Hope that helps and thank you for the informative video!
Great video. You could sneak in an esp8266 that would connect to the tx/Rx, float the DO pin on the flash until it sees the second auto negotiate and then ground the DO. After that it could do the modifications to the bootcmd, run the normal init and then just provide telnet pass thru access to the root shell that it has.
To solder to small pins in circuit, it's easier to use plastic insulated wire-wrap wire. Multiple colors. Single strand thin pure-copper wire with plastic insulation (not enameled speaker coil wire). Strip just enough of the insulation for the length of the pin you are attaching to, tin the end, hold the wire nearly perpendicular to the PCB (slight angle) so the wire is soldered parallel along the pin from the bend at the chip to the bend at the PCB. Best when you want to wire up more than two pins right next to each other to avoid solder bridges.
A vertical microscope might not be the best option since one of your hands will be nearly directly over the pin being soldered. Not great capturing video. The best view to look at this is 30-60 degrees off vertical. I don't use a microscope. I use either a magnified adjustable desk light, or a Jewlers eye-loupe, or for really fine pins a set of dentist's magnified glasses.
This kind of wire can also be used to solder to tiny discrete components that are right next to other tiny components where larger stranded wire is just too big.
Yes #30 wire-wrap is great. Use Teflon coated wire, it has a higher melting point. You will want to tape it down, solid wire breaks pretty easily when bent a few times.
I also noticed he's soldering to the base of the pins, aiming outwards at 90 degrees... Sometimes it works better when you come over the top, and solder parallel to the pin, down its side. Bend the wire to shape first, and hold it down with your finger on top of the chip. Obviously this doesn't work if you need to use loads of pins on both sides, but it's a trick to keep in mind.
I was into this sort of thing years ago. Work took over and time got shorter. This and your other videos has rekindled my interest. Simple process on this one but superb video never the less. 👍👍👍
Finally found a new interesting channel so subscribe to. Weird that you were never recommended to me before. Well, the algorithm works in mysterious ways I guess. 😃
My soldering was the same, watched a ton of videos, most important was to have nicely tinned solder tip and the temp is correct. Ans with a ton of practice its near perfect. ❤
I swear I usually solder better when I'm not recording myself doing it...
That's def the way it goes lol
@@mattbrwnyour tip looks oxidised - get a new one.
@@mattbrwn
I think lots of things are done better when not trying to record yourself doing it. Just having to work around the camera makes it harder before you even start on the psychology of it.
@@UnCoolDad For the most part its alright if the tip is oxidized like that, I can get back to normal with Tip Tinner and some good flux after that. Ive only ever replaced one tip at work and thats because of someone elses mistake.
Great viewing as always! Thanks Matt! Can you show how to modify firmware, and maybe add RTSP to a camera?
Another great video Matt! Any interesting network traffic on this tplink camera? Calling home for anything good?
I do some fairly high level soldering, installing csp’s bga’s QFN’s you name it, fly wires from the solder balls etc. currently going through a metallurgy class about SMT from a metallurgy nerd. I know so much more than I care to know about solder lol.
IMO this would be good opportunity to followup (as you were saying) with a firmware dump, modify, re-program, etc. This would be beneficial in that it would provide ideas for those who run into situations where it would be required to do so. Viz inits resetting all tty connections, etc. Just my $.02. Great Videos!
That was incredible.
You are genius.
Amazing video, thanks for sharing with us.
Great video! During a software downgrade I bricked my C200, looking around online I found a post on Reddit that someone was able to interact with it via an ethernet port on the board and push the firmware via TFTP, unbricking the camera. Won't post the link as I'm sure anyone can find the post with some google-fu.
Unfortunately I have zero skill with electronics and ended up ripping the pads from the board, but this takes it to the next level!
you need to post that link
you haven't been doing this long but what you jut did is the most infuriating thing to possibly put into a forum for this kind of hobby.
@@somacruz8272 youtube has been deleting links in comments for years at this point.
Funny seeing you struggle with soldering. Brings back memories from uni.
I like how you break it down. You should have covered how to differentiate the different UARTs; how to read the datasheet a little. Still, I'll recommend this to some of my students. Also DuPont wires don't really have a color code.
Awesome!
I think you just gave me a very good reason to clean up the mess in my mancave and start poking in some devices I have laying around 😂
Matt, suggested future similar projects… focus on cheap hardware from Meraki that traditionally only could be used with a license but that which likely can use OpenWRT once ported.
Especially the WiFi 6 and newer gear, eg MR28, MR36, MR36H, MR44, MR46, MR46E, MR56, MR76, MR78, MR86.
Pioneer some work by getting a new model supported in OpenWRT like these models already are:
(Google for OpenWRT and you’ll see a page full of already working models. Note that some like the MR33 have countermeasures in the 2017 firmware that will brick your hardware if going into uboot. Would like to see you fix that!)
Then explain to the audience and demo how cheap “locked” Meraki gear can be reflashed with OpenWRT for inexpensive and powerful access points and switches.
It’s enough if you can show and document just how to get into the newer access points; someone else will do the OpenWRT port. Getting in is apparently hard on some of these.
Thanks for your channel.
Hi, Matt. Thank you so much for sharing such fantastic videos on UA-cam. I have a router device that doesn’t have an exposed UART interface, but I found in the MCU’s datasheet that certain pins are designated for UART functionality. Would it be possible to scrape off the solder mask on the corresponding pin traces and try to connect that way? Have you ever had a similar experience? This MCU uses a QFN128 package, with some pins located within the pad, so I can’t connect directly to its pins and can only try connecting through the exposed traces. My English isn’t very good, so I hope you can understand.
you going to have to either find a place those UART pins are exposed on the board OR remove the chip, solder magnet wire to the traces, then return the BGA chip back to the board... which is easier said than done
The solder wants to wick to the hottest part and away from the coolest. The leads will probably stay colder than the wire you are using to probe. Try a solid core wire, also that tip is probably oversized and slightly oxidized
But honestly if works it’s not broke.
I use high quality wire wrap wire. It is thin and single core, so no fraying. Quality wire wrap is silver plated, so easy to solder.
23:08 there's serial bitflips or something that turned the x in 0x3FE0000 into 0p3FE0000 i just noticed
I'm watching a ton of random videos and came across one that said you were thinking about starting a discord server. Did you ever create one? You've inspired me to buy some cheap TP link routers and start messing around haha..
I do not understand why you cannot override password hashes? At 24:44 in the video, you can see that overlayfs with writable sublayer (/overlay) is mounted as a root. So, it /should/ be possible to override any file, unless there is some other issue (like what is "pmpfs" filesystem).
Great tutorial thanks! I'm going to try this! The flash on mine is an eon qh64a-104hip, luckily it has UART test pads too.
Update: it worked! But the bootargs is missing on this one, it seems they built the kernel with it's command line baked in to stop this kinda thing (it's a build option, setenv bootargs does nada for me). Glitch immediately after the 2nd 'click' from the IR shutter. Glitching earlier will revert to a u-boot mask ROM i think but it's impoverished with only an 'httpd' command for firmware updates.
@@foobarf8766Yep sometimes they bake the boot args into the kernel binary or the bootloader so you cant change them unless you try to glitch the flash or flash a custom firmware on it. I also had a device that did not allow me to change the bootargs or any kernel parameters
@@309electronics5 thanks dude, good to know its not just me! the vendor has a github repo so I can build it maybe but where to find the .config?
Great video! Another tool in the toolbox! Thanks!
Great video! It would be neat to install in the device a pi pico or similar micro to watch the uart output and perform the glitch automatically on every boot like a game console modchip. Not sure how useful it would be for this case but nice proof of concept.
This would be a good exercise regardless of how practical it is... good idea!
@@mattbrwn ...just some more brainstorming, maybe an ESP32 with a web interface that would let you could change the boot args for the next boot
I have a Netgear AC1200 R6120 i tried doing this with by monitoring the UART serial console and the R6120 wouldnt boot with it set up, i had to manually short spi pin 2 to pin 4.
I tried with a push-button and it wouldnt boot either lol
No idea why this came up on my YT feed, but .. well, it was pretty cool.
I have no idea why I'd want to hack my Tapo cameras. Didn't even know it could be done. But now I know...
You can get SOIC8 clips that would make accessing those flash signals a little less invasive.
Ohh man do I have a video for you
This is really cool! I would love to be able to buy these proprietary-style hw on the cheap and then use them for libre software systems. thanks
I used a piezo speaker as it has high impedance. That allows to hear the TX during boot.
Probably could also `setenv bootdelay=3` to enable break to bootloader prompt without future glitching (since UBoot input was not compiled completely out, and `stdin=serial`). This is similar to grub with a timeout of 0 vs non-zero.
What DMM and software are you using for the overlay in the video? I want it! :)
Awesome video, thanks!
Any resources which tells why those glitches works? Is it a bug with the uboot/security measures or intended behavior? If I'm interpreting correctly you basically shorted the flash chip to make them temporarily unavailable to the uboot, then rather than gracefully handle the exception, uboot just give preboot access?
Uboot wasn't able to read flash chip ID so couldn't autoboot and dropped into hush shell. More locked down IoT won't give you a shell, won't let you change bootargs etc.
Thanks for the video.
Would still like to see a video flashing Freshtomato to a router to see if it has better security.
More videos about taking control of an IOT and making my own, so it will not report home to some place in china or where ever. The devise will be 100% under user control.
I'd like to see more glitch stuff. Can you do an automated one that needs more of a precise injection?
Think you might have been able to do it with just connecting one wire to the pin and touching it to a ground point (the big mounting holes)
There appear to be 4 small round pads near the corner of your CPU very near to the primary UART pins that you are probing. Have you checked to see if they might connect to the pins that you want? I have a similar camera (with a different motherboard) that had such pads. They are big enough on my device that I was able to tack solder my UART wires to it.
10:33 what is this kind of probes called that he is using? They seem so seemless to use like a plugging mechanism.
PCBite probes :)
I think that's known as a pogo pin, and they appear to be on a wire armature for hands free placement. The pins have a tiny spring inside that helps apply pressure and keep contact.
Hey what do you mean by a wire armature? I'd like to have a similar setup and did a fair bit of googling after watching a previous vid but I must've not had the right terms to search for
@@theodorekorehonen A more common term is probably bendable third hand.
I ran into some weird text glitches with a UART port on another device. Eventually I switched to a different adapter and they went away. Might be as simple as a poor connection so the voltage rise/fall of the signal is delayed or doesn’t peak high enough for the adapter to it as a 1 or 0
What a wonderful video.
Matt , if you are on N.America . Where and when ?coolest guy I can speak of . You may may be the one .
Great stuff keep it up
Maybe get SSHd running by reading some extra files off the network after boot? Might be easier than glitching it to get in each time.
Estou lutando a muito tempo para mudar a logomarca de um DVR, mas não consigo chegar nesse ponto que você está. Parabéns pelo vídeo.
Security cameras are one of the things that absolutely must have observable, user serviceable firmware in many applications; but is somehow one of the few things that has no practical mass market option offering these properties.
Do you recommend that products disable UART for production ? But how would we debug issues then ?
Those serial issues are very weird, I never saw anything like that. I'd try to drop the baudrate a bit, just in case the serial controller inside the SoC is shit.
Well done! The ease of this has my head spinning with ideas. *Edit: I got a question, actually... *
how do you deal with unknown/random CRC's when modifying bin files for write back to EEPROM/FLASH? I have a small I2C EEPROM (only like 256 bytes) .... it has a few addresses that shuffle in a way that looks suspiciously like a CRC... but I cannot figure out the polynomial or algo for how it's calculated. This EEPROM is, in essence, the vector into this device, so I have to be able to modify the data here to move further. I can't do that unless I pass the CRC validation.
With such a small memory they may have used an 8 bit CRC. You could brute force this by changing the variable data from 00 to FF and re-testing.
Please tell me that flash chip was reinstalled? There’s no way it came that messy
Are there tools for glitching data transfers that are a bit more subtle? Like watching for a pattern coming across from an eeprom to a micro and just substituting a few bits as it goes across?
Hello Matt, can you please make a Video, that explains how I can get adb on an Echo Show 5 2 gen.
Great video as always. Can you tell us what the exact model is?
That soldering job was brutal!
excellent vid
Hey Matt, the livestream you recently did with the spi glitch is what got me into my Netgear AC1200 R6120 but I'm having issues modifying the squashfs on a downloaded firmware update.
I'm trying to modify setup.cgi to drop a reverse shell but the location of /etc is "/etc/null" I've tried "mkdir /etc" but it auto deletes after unmounting squashfs.img. The kernel panic doesn't allow UART input.
Any suggestions? eg: research material, personal advice etc
interesting 👀 i will definitely test it out on some devices
What did you study matt, comp science or electronics engineering
so if Uboot does not recognize the flash type, it falls back onto a default type that consequently will load the kernel image at the wrong offset, throwing an exception that eventually leads into the uboot prompt?
If I recall, uboot will try a list of boot options in an order defined at compile time (much like BIOS on a PC trying the floppy drive then the CD drive, then the hard drive).
If this all fails, it drops to the prompt.
Most manufacturers don't bother changing any of these defaults... Partly because it isn't necessary for the product to work reliably (if the flash fails, the device is dead anyway), and partly because they set it up for development purposes to boot off multiple things, and simply never bother changing it.
Possible to do the same thing on a blink mini camera? I hate the Amazon bs you have to deal with.
Maybe
GG matt !
Why aren't you using IC chip clips?
The reason why I guess it didnt paste it correctly is because of the hardware flow control
Could you add the link for the probe tool you're using to connect to the MCU UART pins?
just added in the pinned comment since more than 1 person asked!
Here's a random suggestion. Yealink makes some office phones that are branded verizon that even when you flash standard yealink firmware to them, the first thing it does is connect to a server and download the Verizon stuff. And then no web gui. You can get around this by interrupting the connection to that server at just the right time and then change the address of the server in the web gui to garbage but it's a giant pain to do. Would there be a way to do this solely by messing with the hardware?
I know this is random but I had some of these phones and they were a giant PITA to deal with
Get the server address they use and then use a proxy to connect to the server you want instead.
It looks like you just want to kill access to the server dishing up the Verizon firmware. You should be able to do this with a firewall rule on your router - if destination is nasty IP, drop connection - or sinkhole the domain name in DNS using say a Pi-hole. Use Wireshark to check if the server IP is found via DNS or if it is hard coded to know which is best way to proceed.
@@dingokidneys
Or put the phones on a VLAN that doesn't have DNS specified in the DHCP.
Or use a custom DHCP response for those devices that gives no DNS servers.
"Qstar"? that dont look like any 'Q' im used to.
SigmaStar?
An interesting video idea would be to defeat a secure boot and be able to load your own firmware
I have one on my desk, it's a rainy day, let's break it, mess up and throw it away ;)
cant you cross compile another kernel?
So can this be used to gain root access in phones with locked bootloaders? Looking at you, Smasnug
No. The AVB (Android Verified Boot) spec states that when the bootloader can't verify the boot/recovery partition (where the kernel image is), and the bootloader is "locked", the device should enter the RED verified boot state (the boot fails entirely). Also, the bootloader cannot under any condition allow for the loading and execution of unsigned (non-original) code.
In practice, this means that if you somehow manage to alter the boot image that's being loaded, the bootloader will refuse to boot and enter some kind of emergency download mode (in the case of Samsung, it's called "ODIN") to let you restore the device. This mode however, will only let you flash firmware that's signed by the manufacturer's key.
The hell I need this berries thanks
On 23:01 it seems the uboot got your setenv command wrong, is it because of bad echoing system or something else?
If you watched the video u know why..
Probably didn't need to do all of this. Those chips have an in circuit programming mode in the uart pins.
do you have reference link to read more on this for sigmastar?
bro could you share your linux config?
thanks
Nice hack 🎉
the echo back is always wierd at 115200 baud rate
is that Linux for MIPS ?
Let's go 🤩
You should do the w/ the Spotify Car Thing it will be bricked my Spotify soon.
There are a bunch of videos getting to U-Boot
No men we need this more than ever her in latam those cams tons
Marvelous
Do the same for Playstation 5
protip, tin your wires before trying to connect them.