Yeah, it's because Bugcrowd doesn't know that I can hack hardware. I need to hit them up and be like, hey, by the way. Yeah, me submits one bug a year on Bugcrowd . And it's like, who is this guy? Hardware, god. I didn't know. Yo yo yo, we're rolling. Yo yo, how's it going? Pretty good, dude. This past couple of weeks has been kind of crazy, but we're getting ready to kick off a live hacking event again. So it's not going to slow down, I don't think. Oh, dude, nonstop.
It's like one thing to the next thing to the next thing. Yeah. Well, at least you got a week off last week from the pod. Yes, a little bit, barely. Yeah, you had crazy stuff going on though. So that's how it rolls. Yeah, yeah, yeah. All right. Yeah, let's check out the new stuff for the day. First, first up on the docket was Naham Khan, who are sponsoring this episode.
So thank you, Naham Khan. Just wanted to give them a shout out and say, I'm going to be speaking there on the Saturday slot at 1220. And I'm going to be giving a presentation on PCI DSS, which is essentially payment card stuff and how pretty much every single website that we've seen is vulnerable to some sort of trickery in this area due to the way that the DSS recommended structure is. So there's going to be some really, really awesome content in that that will drop.
So definitely don't miss that on Saturday at 12 PM PST. Yeah, dude, I'm really looking forward to that. I know that Naham always has amazing people on for his Khan and just for his show in general and all the content that he makes. But yeah, it's super awesome. I'm super stoked to see what you talk about there.
I think the Khan in particular, I think is one of the one of the best structured ones for Bug Bounty Hunters because Ben just has such a good network in the Bug Bounty Hunter field that he can put together a bunch of people that really know what they're talking about and have differing expertise to share.
I was looking at the lineup and there's a bunch of eclectic hacking styles and you've got people from influencers like Stulk all the way down to people like Douglas Day that just really get in the requests every single time. So it's really cool to see the whole gamut being run there. Yeah, it should be awesome. Yeah. Oh man. The next item on the news list makes me so sad, man.
On Twitter, you see Gareth Hayes talk about JavaScript stuff all the time and he's one of those people that you can just feel the passion when he talks about JavaScript. He just freaking loves JavaScript and he tweeted out earlier this week and I threw it on the list that his favorite XSS vector is going to stop working, I think, is it like November when they're going to depreciate it? Yeah, I didn't catch the exact date.
Yeah, Chrome 119 November 2023. They're going to depreciate data URLs inside of the use element in SVGs. Yeah. So for those who aren't aware, this is basically one of the really common ways that you would pop an XSS within an SVG, not just like SVG on error or on load or whatever, but within the SVG element itself, you can include stuff like, well, with this use element, you can use different things. I think it's meant to take a bunch of different data types.
Yeah, it uses a data URL here and uses that within the SVG itself, but it seems like they want to have that piece, that data element removed from the SVG use element and that would result in, I guess, potentially you could still load it externally, but then you've got CSP stuff that you're going to run into. So it's a double edged sword there.
Yeah, I know there are a couple other vectors and looking at the Web Security Academy on the Portswigger, there's these ones that use animate inside of SVG. Oh yeah, I've seen that. Some of them do use that use element, but not all of them do. So I'm wondering if that will still be a valid attack vector. Yeah, I mean, as long as it's not, because the use element is still staying, it's just that the data URL inside of the use element is kind of going away.
And I think I'm looking at the reason for removal and it looks like it's largely because of the sort of same origin issue that's going on there. So sad to see that go, but really cool vector. And I'd always love to see Gareth Hayes talking about XSS stuff. He's one of the people that I do have notifications turned on for, tweet notifications turned on for, because every single time it's super high quality research. And I really appreciate that. Yeah, yeah, yeah. His book is amazing too.
Yeah, I mean, he's just like, he's such a JavaScript fanatic, you know? It's like all he does, it's like his main focus. So he's one of those people that has so much insight about the nuance about what's going on. So anything that you can do to consume Gareth's knowledge is something I would recommend. And I love that little, I love that he wrote a little book too. I feel like that's something that people that specialize in the industry, it's really handy because the book is not long.
It's not very hard to consume, but it outlines all of this cool shit that he has in his brain that otherwise we wouldn't have access to. And so I definitely endorse that method, not only just for knowledge sharing reasons, but also just for, it's a great thing to do when you're a specialist. Take the, however long it takes, do a little brain dump on this topic that you're just a super expert at and put it out there.
And now you've got a product that you can, you're getting reoccurring income from, and you're also sharing that knowledge with a large community. Excuse me. So that's really, I really respect that. Yeah, for sure. And we've talked about this as well in the past. Any type of the, it doesn't have to be groundbreaking research, right?
But any of that knowledge sharing type content is really amazing for building out the community and just helping other hackers learn and get better and helping secure everything as a whole. Works. Sometimes it ends up being one of these things where eventually the browsers will come and they'll patch something that shouldn't behave that way or whatever. But like, okay, yeah, that sucks for us as hackers, but it's good for security as a whole. And I think that insight is valuable regardless.
Yeah, dude. It makes me think of that. Man, did we cover it on the pod or did it just make it into the news list? But it makes me remember this one at a live time at a live hacking event. There's this guy, BitKa that showed me this way that you can exfiltrate data via fetch. And what you do is you get it cached and then you say, hey, you force fetch to use cache.
And it was like, at the time it was just like, oh, this is totally amazing because you could get a cookie, you could get a cookie to get the data and then it would cache the response. And then you could send the fetch request without the cookie with caching, pull from the cache set to mandatory. And then it would pull the results back. And it was just like, man, this is such a genius method. And so- That's really smart. It's sad because those methods get deleted as soon as they become popular.
But if you're lucky enough to have met a great researcher at a live hacking event or at networking, sometimes you can pick up these little tidbits that will really help you pop some crazy bugs during engagements. Yeah, yeah, for sure. Did you hear about this move it, the move it vulnerability? Oh my gosh, yeah. It's hard to have not have heard of that, man. Twitter's kind of blowing up about it. Yeah, yeah. So I was reading about this and it's this file transfer app, right? Yeah, yeah.
Yeah, that was my understanding. I hadn't actually heard of this before, like move it until the vulnerability. They were saying it's all over the place, but I actually hadn't seen it very much. I wonder actually how much net presence it does have. Yeah, yeah, it was super interesting. So I wasn't sure. They said that Huntress, is that who owns it or is that the people who found- I think that's John Hammond did some work with them.
And I think he sort of did this whole, I guess sort of, I don't know if this is like an incident response. Yeah, they call it rapid response to this sort of vulnerability. And I thought this was really cool because, you know, even, and I also linked that and the click the Twitter link in the doc right below that Joel. Like I love to see this sort of thing. John is like out there at 4 a.m. tweeting like, oh man, I can't figure out like, oh, is this it?
I'm putting screenshots of code and I just, you know, I read through that whole thread and I was like, man, this is why, you know, he rocks.
This is why, you know, if you can come into this with this much passion where you're up at like 4 a.m. like, you know, really just trying to grind out this POC because what he was trying to do was reverse the POC, you know, reverse the flow from, I guess it looked like in the beginning all he had was a packet cap or like a like a log of the various endpoints that they hit.
So, you know, if you click that that image at the top of the tweet, it's like, you know, it hit move it is API dot DLL and then it hits a couple other things. And so he's trying to like follow that flow and figure out how they ended up popping this the shell. So yeah, it's it's amazing to see, you know, when people are that into it and that like enthralled and then they look up it's like 4 a.m. and you're like, ah, what the heck? Yeah. Yeah, no, that's awesome.
Yeah, it actually looks like he works. He's a researcher at Huntress. So yeah. Yeah. So super, super interesting. It sounds like they basically, yeah, like they got a packet capture or something like that. And so they started digging into it and trying to figure out like how it was working and the whole chain. And I don't want to like spoil all of this because I think it's worth reading.
Yeah, they don't drop the full exploit either, which is, you know, for me, a little bit disappointing, but also, you know, totally reasonable, I think. Surely it's already somebody's already figured it out. Yeah. Yeah. So it's a really awesome. I feel like this would have fit perfectly with our source code analysis episodes that we just did. But yeah, this is one of those cases where you just do the deep dive.
You keep digging, digging, going through rabbit holes, trying to figure out like, how does this code work? How does this code work? What is this code doing? And eventually you get to the root of it. And it's really awesome. It's a super interesting case study for sure in terms of like how something like this would work out in the wild.
And I think that there's definitely some like learnings that you could pull away from like an organizational standpoint or how could you secure your org to protect against this like in the future, like what kinds of rules and stuff would you want to keep an eye out for other certain traffic patterns that you should be like looking out for that might have popped up if you were exploited by this second and stuff?
Yeah, he adds like some Yara rules and like some indicators of compromise to the write up, which is great too. And yeah, just like you said, you know, about going down rabbit holes, if you go to John Hammond's Twitter right now and you know, on June 3rd, I saw it, that's the next day, you know, he's like, oh, we finally got it. And he's like, PS, it doesn't have anything to do with the crazy shit that I was viewing it for. So it's like, I just I feel that man.
And yeah, it's cool to see, you know, for those of you that are always thinking like, oh, man, I'm not sure. Am I going down the right path? You know, how do I how do I know? Look at John here, you know, one of the most skilled guys out there on the arena, you know, he does education in, you know, cybersecurity stuff all the time. Shout out to his YouTube channel. Excellent, amazing YouTube channel. And even he goes down these rabbit holes and ends up, you know, this is the wrong thing.
So it definitely happens. It's part of the process. And at the end of the day, if you keep on being persistent, just like John, you'll you'll end up popping the full bug for sure. Yeah, for sure. I think as well, it's really interesting. Like I feel like I've been in that scenario so many times where I've spent like eight hours or like more just like looking at one thing. And I'm so invested that I don't want to step out of it.
Yeah. So do you have any what do you do when you're in that scenario? It's funny you mentioned that because I'm going to actually just pull it up on my email right now. There's somebody messaged this week into info at critical thinking podcast.io. And he said this is the question he said when you were hunting and you're doing recon and getting a feel for the app, you have something interesting that you are poking at. How do you know you are on to something promising?
Do you have any tips for knowing when it is time to cut bait and move on? How to know when the potential for success is there or whether it's not worth the effort? And I was like, yeah, that's the rub, right? You know, to just bring it back to the Shakespearean eye. That's the rub. You know, whether it is nobler to continue to pursue down your rabbit hole or to, you know, I forget the rest of the quote, but it's Macbeth. So yeah, I was not. English was maybe my least favorite class.
They made us do like a presentation of that and I was the guy reading that, so I should remember it. But you know, whether it is nobler to continue to hack or whether it is nobler to not continue to hack is the question. And yeah, it's really hard to know, man. And I think at some point, you know, you kind of get to a point where you're like, all right, I've looped on my brain so many times. Like I keep on just coming to the same conclusion, same conclusion, same conclusion.
And for me, it's probably five or 10 cycles of that, you know, somewhere between five and 10 cycles of that before I'm like, man, I'm not really sure I'm going to find anything else at this at this specific code pathway. And that's when you start working back. And I will add, this is one of the things that I think was developed for me a lot by the OSCP because the OSCP has a has a time limit, right? You know, you've got 24 hours.
And if you spend too much time going down a rabbit hole that you can't, you know, that doesn't end up with anything, you've lost a bunch of time. So that is that is something that pretty much only comes with experience, I think, is knowing whether when to cut, you know, cut your losses and move on or whether there's something there. So I would say, you know, to the listeners that are wondering about this question, yeah, I'll just call them CG. Thanks for that. Thanks for the question, CG.
You know, experiment with it, right? So, you know, if you maybe you'll do one session where you're like, all right, anytime I run into a wall, I'm just going to move along. Right. And I know some people that do that, actually. And, you know, it works for them. And that's great. And I know some people that, you know, if they run into a wall 15 times at the same endpoint, they're still going to keep going at it.
So you've got to figure out what is right for you as a hacker and where that limit lies. And it can be something that's intuitive, or it can be something, you know, that's set and concrete saying, hey, I've thought, where am I going to go five times now? Time to move on. And then you're back, you know, and you move along. So what do you think about that, Joel? Yeah, I think I'm very similar where it's not like I'm not an instant kind of pass when it's pushing back a little bit.
I do like to push through it a little bit further just to see, like, am I missing something here? Is there something more to this? Am I just doing something like, you know, very minor here that is blocking me up here? Like sometimes I'll be like testing something for a while. And I've just made like a simple error in my request or something. It's like it's the worst, right? You spent like an hour. You're like, I guess this is like total.
And then you're like, oh, my God, I've been using the wrong the wrong request this whole time or something like that. Like, yeah, that's what that happens to me. Really help to write. Yeah, that extra set of eyes is so useful. Just having somebody who's like, hey, that's the that's the wrong request. Like just add the extra little second brain on your shoulder. Yeah, that's super helpful. But I think for me, it's something like it's very similar to like what you have.
It's like some it's I don't have a specific number, but it's a certain number of times where I run it and hit the brick wall. And I'm like, OK, I should probably move on. And some of it will also depend on whether or not I have other interesting things to be looking at.
I feel like that also affects my like how lenient I am to just move on and go to the next thing, because if something has been really like pulling at me like this is something interesting I need to look at, but I need to finish what I'm looking at right now. If I'm not getting anywhere with what I'm looking at right now, I'm more likely to go start looking at that new thing. No, that that totally makes sense. And I think I have that same mentality.
But for me, I think it feels a little bit more like a surrender when I move away from it. Like I think I do have a little bit more of that fighting spirit than is good for me sometimes. You know, and I've talked about this publicly on the pod before how I used to not really do that at all. And I would just move along.
And, you know, those were the days when I was finding a bunch of like, you know, I doors and access control stuff because I was getting a bunch of volume because I was moving along so quickly as soon as anything would would, you know, bump into my way. Right. And, you know, if it's a function of volume, you know, for those sort of bugs, because it works or it doesn't work, it's not there's no fiddling normally.
But when I started, you know, banging my head up against a wall, sometimes when I saw an attack vector, that's when I started finding these more serious volumes that are more deeply embedded in the apps and started walking away with some bigger bounties. And, you know, to be perfectly honest, looking at the statistics, my amount earned hasn't changed that much between those two strategies. I think it's a little bit higher where I'm at now.
But you know, my amount earned does not actually deviate that much because like we've said in before, those I doors and those access control issues can be extremely impactful. And if you can get a bunch of those, it really pays off big. So it's really up to the individual hacker. Yeah. So do you have a preference between the two in hindsight, having done both and seeing that there's not a huge impact on the on the earnings? Would you ever go back to the first one?
No, I mean, I think my preference is strongly where I'm at now because it's more interesting and it feels more risky. And sometimes it's a little bit less, you know, a little bit more stressful because you're like, well, if this doesn't pop, then I'm screwed, you know.
But, but, you know, I think as I've developed as a hacker in my stress management and my anxiety management as well, you know, over bug bounty and as I've become a little bit more financially stable as well and, and, you know, realizing, hey, it's not the end of the world. And I've also just become a little bit more confident in who I am as a hacker as well, you know, in my identity as a hacker. I, you know, definitely lean a little bit more towards the latter now.
It's like, oh, let me, let me spend a little extra time. Let me find some cool shit and spend a little bit less time grinding through the burp requests. But I definitely recommend that in the beginning for any beginner as well, because if you can hit a lot of volume, you'll see a lot of, you'll see a lot of HTTP requests. And like we talked about those reps lead you to be a better hacker. So there's, there's definitely, you know, you could go either way, depending on which way you want to grow.
Yeah. Yeah. And I think one of the other things I recommend is especially this, this happens early on a lot when you first start hacking, you're just going to be like looking at stuff and it's going to be hard to find your first bug. And moving on is really difficult because when you first start, you don't know when you should move on. And like you have like no context in terms of like, what, what does that feel like? Or like, where is the right place to draw the line?
And so I'd say like, if when you do decide like to move on, don't like, don't think about it too much. Like don't let it beat you up because you'll have to remember that like all the bug bounty is basically trying to beat the odds. You're trying to like find something that is bad, that shouldn't exist. And you're trying to like break the system that is designed to keep, you know, customer data safe or whatever it is. And so if you don't find anything, it doesn't mean that like you failed, right?
It just means like that app might be secure and that's good. And that's, that's okay. And you know, it's time to just move on to the next thing and find something that feels less secure so that you can find all the holes in it. Yeah. Yeah. And you know, we, we preach this on the pod all the time. You know, there's a whole team of people that are dedicated to you not being able to do your job when you're doing book bounty.
So it's a really, it's a really challenging thing, but we believe in you, you got it. So go get those bounties. And I will say, you know, for the more experienced hackers out there as well, don't get set in your ways. Don't, don't get so tied up in your approach that you never, that you never experiment because I know I grow a lot as a hacker as I started experimenting away into the more rabbit holdy sort of find the weird shit sort of things rather than the volume of requests.
So I think there's a lot of room for growth there as you experiment with the various techniques. Yeah. A hundred percent nice man. Well, we, that was, that was a nice little, little vibe. We deviated a little bit from the plan, but I'm, I'm glad we talked about that because that's, that's just really important things. Yeah, for sure. All right. So this is what I had on, on, on the plan for today, Joel.
We did, as we mentioned before, we've done a good bit of hardware hacking lately with the live hacking event that we last went to. So this is the episode where we talk a little bit more about that, where we give some details on some of the techniques that we used and kind of go into detail. So I mean, we could start with the hardware recon. Is that, does that work for you, Joel? Or you got anywhere else you want to start? Let's, let's, let's start from the top.
Yeah. So click, click that link that's about, that's in under the, the next bullet point there. Cause I wanted to ask you something specifically about this. So you know, if you scroll down and we'll link this link, this is, this is River loop securities hardware hacking right up. You know, you scroll down and eventually they're soldering onto test pins on the backside of an EMC chip, right? Yep. So for those of you that just, that just sounded like garbage EMMC is an embedded multimedia card.
Is that right? I think that's, yes. Yes. And that is sort of like the hard drive of these IOT applications where they're storing the file system. It's the non-violet volatile storage, right? And so one of the reasons we want to get at that is because it contains the source code and the actual file system for the IOT device. We can be really insightful to us as hackers.
So what I wanted to talk, I wanted to ask you, Joel, in this sort of hardware recon section is like, there are these test pins on the back of that and we can use those. If we can find these test pins that correlate to this EMMC protocol, I guess we can use those to read from the EMMC chip as well. And we don't even have to pull the chip right off the board. Is that right? Yes. So in some cases, yes. It's kind of two routes. Some cases, no. Yeah. They talk about it a little bit.
So typically if you want to read off of an EMMC chip while it's like in use, it's probably not a great idea for a couple of reasons. It would be basically like trying to read a hard drive while it's plugged in and being used. So there are other operations happening on the drive at the same time from a different like from the host OS that hasn't mounted. And so it might be reading and writing at the same time. It might be performing operations. It might have stuff locked like you never know.
And there might be like conflicting data with the controller within the EMMC that will cause it to like have problems. So sometimes that works. Sometimes it doesn't. But it's really good for at least at the minimum, like looking at like debug, like what's going on like, are these pins the right pins? Is this chip functional? Like, am I looking in the right area? All that kind of stuff.
Is it potentially possible to use those test points to interact with the chip if we can figure out a way to have the chip activated, you know, with power and not have the CPU, you know, hitting that same bus? Is that right? Right.
Yeah. So like to the best of my understanding, you could literally just pull up the spec for that chip, read through it, see what the voltage is supposed to be, see what the amperage is supposed to be, take out a DC power supply, set it to the right voltage and amperage, connect it to the VCC and ground and power it up. Power it up.
Yeah. Yeah. And then, okay, so that's cool because that actually gives us a second sort of route to get, or I guess maybe a third or fourth route, depending on how much stuff we get to cover today. But essentially for me, as a more of a beginner, I feel like I've kind of got a grip on some of the hardware hacking stuff now. But what my playbook kind of looked like was like, okay, is there a UART interface on this device?
So you search around, you look for the UART interface, and we'll talk about UART and JTAG on a different episode. That'll be a hardware hacking episode too. And then if you can't find those, then you just do a chip pull and throw it into a reader and then try to pull the operating system off that way. But there's actually another method that doesn't destroy your device because that's the problem with the chip off method is it destroys your device.
And if you can solder some pins onto these sort of test pins there, or solder some connectors onto those test pins and hook that up to some sort of device that can communicate over EMMC, and I think in this blog that we'll link in the description, they use a logic analyzer here to figure out which individual pin correlates to what part of the EMMC, right? Then you could potentially get a file system read through that, and it would still come across as like an SD card to your computer, right?
Yeah. So generally, I like this approach because it's very ground up. It doesn't require you to pull up the data sheet or anything like that. However, I would say in most cases, like 99% of cases, you can literally just take the chip number, Google it, pull up the data sheet, and you know exactly what the pinout is. Most of the time, you don't need to be figuring out which is the clock pin because they're not changing that stuff. That comes straight from the manufacturer of the chip.
There are cases that I've seen where either there will be like... So typically, there's a dot on top of a chip, and that dot is in one of the corners, and that references which one is pin one. And so sometimes, they'll put a dot somewhere else, or they'll put a dot on multiple corners so you don't know which pin is pin one, and so you have to figure it out yourself. That's savage, dude. That's so freaking savage.
Yeah. And I'm not sure whether or not that's purposeful or whether or not that's just... They make a chip that can be used in multiple configurations, so they put it in multiple... I don't know, but I have seen that. I've seen pictures of that on the wild, so that's just something to be aware of. But if you have a very straightforward chip, it is like a single dot on the top. You can also just... There are easy things you can verify.
So for example, every chip is going to have a voltage and a ground pin. So if you take your multimeter and you put it on continuity testing, which will basically tell whether or not the signal is going between one probe and the other probe, typically, there's a way to make it so it beeps, and then you tap the leads together and it goes beep, right? So that's continuity testing. You put one lead on the ground pin from your data sheet. You read the data sheet.
You go, okay, this should be the ground pin. And then you can go as far back as you want. You could go all the way to the power connector. And one of those pins should be power. One of them should be ground. And you can test and see, is there continuity between these pins? Yes or no. And you can do the same thing for VCC. And that's also how you can test the test pads and see, is this pad pointing to this pin or this pin on the chip?
And then that's a pretty easy way to determine whether or not it's using a standard pin out or not. Nice. So I mean, I guess we can do that to a certain degree with a multimeter, right? And with the continuity testing like you were talking about. But when it gets to something like, for example, in this article, it was talking about the various pieces of EMMC protocol, which I'll kind of touch on very lightly for the audience that haven't read the write-up yet.
But essentially, there's three main parts of the protocol that you need to identify. There's the clock, there's the CMD, which is the line that's used for sending commands, and then there's data zero. And that's the minimum requirements that you need to be able to communicate over EMMC with the actual chip. So we're getting much lower than we normally do here on the pod because we mostly talk about web and mobile stuff.
But this is actually talking about hardware level protocol stuff, which I think is really, really fun to dive into. But once we start trying to identify all those little pieces, that's where we really need a logic analyzer versus a multimeter because we have to be able to actually read the blips in power coming across those various lines. Is that right?
Yeah. Yeah. So basically, what the logic analyzer is going to be doing is it's going to be looking at shifts between high and low, where that's basically a high voltage or a low voltage, where it's either drawing, where it's pulling it down or it's pushing it up. And so, for example, the clock pin that they identify, super easy to identify that because it runs like a clock, right? It goes on, off, on, off, on, off, on, off on a very regular schedule.
And that's basically telling the chip how fast it should be operating. And then data is for data and CMD is for telling it what to do. And so, it's basically as straightforward as that. But logic analyzers will make that so much easier just because a lot of the stuff that's built into the software will do it automatically. So in the article, they use a sale. I use, it's called analog discovery two by Digilent. It's pretty good. It's cheaper than a sale.
But I think if I were to buy one again, I'd probably go with the sale just because it's a little bit higher specced. It's a little bit more expensive, but the software is really, really good. And it's generally considered one of the top of the line tools that are out there. Digilent actually did just like last week announce the analog discovery three, which is an improvement to what I have. It has, I think, faster polling rates, faster measurement rates. It uses USB-C instead of micro USB.
It's got a couple different things. But yeah, no, any sort of like logic analyzer is going to be a good investment if you're doing this type of hardware hacking just to identify like what's going on. Is this pin UART? Is this pin JTAG? Is this nothing? Like, what is it? Yeah. Yeah, that's a good point. I think I get a little excited about this stuff and I jump right in. Let me just say, this is relevant to you all as bug bounty hunters out there.
The majority of our audiences are active bug bounty hunters because this is a very, very untouched scope normally. Like if you can go ahead because one, because the tools are very expensive and you know what we talk about here on the pod, you invest the money, you get the tools, you buy the premium and it opens up a bunch of scope that pays for itself.
And a lot of these hardware hacking programs out there on Hacker One or Bug Crowd, you have to buy the piece of hardware yourself and then you're going to break it and it's going to be annoying. But if you go through that difficulty, if you pay the price, the bounties are much higher. So I'm hoping that we can inspire some of you to sort of pivot into the hardware hacking realm. It's really fascinating and there are a lot of really good write-ups out there actually on it.
And so, and it's not as hard as you would think to pivot into it. Yeah. So one of the things I would recommend, if you or somebody that you know has a background in electrical engineering, this is a great space to dig into because like a fundamental electrical engineering background is so helpful for just understanding some of the basic stuff. Like why are things behaving the way they are? How would I interface with this?
If I want to read data off of this pin, do I need to like have a pull down resistor? What is a pull down resistor? Right? So many fundamental electronic questions that would be so much easier to answer if you have any sort of electronics background. It doesn't even have to be like a full electrical engineering background.
If you've done basic electronics stuff for many years, which I know lots of people have, yeah, like robotics, any of that kind of stuff, working with electronics, you're familiar with like voltages, like how circuit boards are designed, created, built, all that kind of stuff. Like this is a great area. There's not a lot of people who know this kind of stuff. It's a very like sparse knowledge space within hacking. So good.
Yeah. Yeah. Like if you can pop one of these devices, it usually pays like a significant amount of money because most of these are owned by like large conglomerates. They have a lot of money on the line. They have a lot of people with this device in their hands. Yeah. And there's just a skillset mismatch too, right? There's not as many people that can do hardware hacking stuff as there are web because it requires tools. It requires background knowledge.
And so I think the competition is a little bit less and there's more of a demand, supply and demand just sort of dictates that the boundaries would be higher. Yeah. Yeah. Yeah, for sure. I also just wanted to mention two things on what you just said. One, this is a great reference to the conversation that Corbin and I had last week on the pod and we'll link that in the description. But we have a great conversation about what kind of degree is best for a hacker to get.
And this conversation we're having with Joel here is one of the main reasons why I suggest a computer engineering or maybe even electrical engineering degree for some hackers because you get a lot lower level understanding of things and it's so much easier to build on top when you have the bottom bricks, right? Think of it, think of it.
Sometimes if you're trying to get an understanding of things and you don't know what's happening underneath, you kind of got this very shaky understanding, you're very shaky base and then you're trying to build bricks on top of it. But if you have a solid base, then it becomes so much easier to just boom, build up the wall and you've got a great understanding. I don't know, man.
I have a little bit of a self-consciousness about my analogies because Mariah is like, Justin, that analogy doesn't make any sense. But hopefully that one came through to you guys. No, no, I 100% know what you mean. I get that same sense where, especially with hardware hacking, I'll be honest, hardware hacking is that for me as well because I'll be working on something and I'll be so confused as to why it's not working.
And a lot of the time it's just because I've made a simple mistake due to a lack of fundamental knowledge or understanding. And it's very hard to find those problems or answer those unknown questions without the knowledge, right? So I think this applies to beginner hackers as well. It's like, how do you know when to draw the line to stop hacking and move on? How do you know when you have no experience and no knowledge or context, when to draw that line? Do you just guess?
Is there any sort of concrete identifier? And that is very similar for hardware hacking where it's like, how do you know if this is just a fundamental thing that you need to go learn or if this is just a common problem that even the experts hit or what is going on here? Where do you draw the line? So I wouldn't beat yourself up too much over it. But if you have that solid fundamental knowledge, that solid foundation, it's going to make things so much easier.
Yeah. I think the procrastination education piece with hardware hacking is a little bit different too because sometimes you really do need to be like, ah, actually, I don't know about this very specific little thing. For example, Joel and I were working on a project where we needed to read from an RPMB sort of, it's not really a partition. Yeah, a protected memory block. A protected memory block on an EMC chip. And we had never even heard of that.
So we both had to go and read the white paper on that specific piece of technology and kind of understand what it does at a lower level to be able to come back and hack. So there's definitely some different tricks in the hardware hacking field to get caught up on. But if you can pull it off, one, I don't think I'll ever forget this moment in my entire life.
Joel, that first time we took the chip off of there and I put it into my computer and I just saw like 15 different partitions like new disk, new disk, new disk, new disk found. I was like, you've got to be kidding me. It's so satisfying. I cannot believe I just pulled. I took this to put device apart. I took the chip out of the device and I put it into a thing and my computer just read it like that's nuts.
So there's lots of really amazing feelings that kind of come along with diving into hardware hacking and finding your first little pathway to getting source code or a bug. Yeah. Dude, I'm not going to lie. Even after all that reading on RPMBs. Dude, no one, that's a stupid protocol, man. I don't even know. I don't know if I could describe what it is, how it works, how it's supposed to be, if we did anything right there.
Because when we eventually got on the device while it was running, we could access it, but after we had pulled the chip, we couldn't. So I don't know. It's still very confusing to me, but it's a super interesting topic area. Yeah. It's replay protected memory block. Replay. Oh, that's what it is. It's replay protected memory block. And so essentially the whole point of that is you shouldn't be able to write to that block without going through the authentication protocol.
But there's a bunch of things that say online, because the spec is a little fuzzy, about whether you can read from that without having the authentication key. And really, if you read the actual doc, the actual spec for the device, it shows that the encryption piece of RPMB is just an HMAC on the read side. So if you don't choose to validate that MAC, then you can read from it just fine. And it's mostly, I think, designed to protect against tampering at a hardware level.
So anyway, it's a cool thing. I do know a lot more about it now than I did before. So that's cool. But I don't know when that will ever come in handy again. Next time I'm doing some crazy... It's just one of those little brain space fillers. Exactly. Exactly. OK. So getting back, we look around on the board for test pins. Let's see if we can hook up to those test pins, see if we can figure out some way to power up the chip via VCC.
Or maybe, I think in the article, yeah, we'll definitely check out the article. Because there's still some stuff they mention here about glitching with the CPU to get it to not try to read over that disk. So maybe there's some cool stuff you can do there. Yeah, you could definitely do some power glitching and stuff to try and get the CPU in a weird state. I do generally like trying to power it with the onboard power stuff, if I can.
So for example, if I'm trying to use UART or something, I definitely want to have it do its normal. I basically want the device to think that everything is normal and that it's getting all the same power delivery and everything that it would while functioning normally instead of trying to rig that myself. I probably could, but I don't know if something's going to go wrong. I don't know if there's special power requirements that the chip is doing or that other things on the board might need.
And the last thing you want to do is fry something on the board accidentally. I'm scared of that. That's the biggest risk, in my opinion, is that you fry something in an expensive piece of hardware and then you have to buy another one or call it quits. Those are nice. And sometimes HackerOne, and I assume Bugcrowd does this too, but I haven't had that experience with Bugcrowd, so I don't know. They do. Okay. Yeah, it's because Bugcrowd doesn't know that I can hack hardware.
I need to hit them up and be like, hey, by the way. Me submits one bug a year on Bugcrowd. It's like, hardware, God. Yeah, but it's really nice when the HackerOne programs and the Bugcrowd programs actually send you the hardware to test on without you having to pay for it. Okay. So we talked about the logic analyzer. We talked about a little bit of recon.
So let's say, for example, we can't get the test pin to work, test pin method, with our sort of natural power and we can't get it to power up, you know, giving it power directly. So we got to go for a chip pull. And yeah. So there are some equipment that we need for this. And I kind of noted some of them down here. Joel, you can kind of take a quick look over that and make sure I wasn't missing anything.
But the essentials are a heat, a heat, sort of a heat gun or a heat hot air station, I think is what they're called. And that will allow you to just very send very focused hot air on the specific chip. So you know, you strip down the device, you find the EMMC chip, and you can find that by Googling, you know, what text is on it. And sometimes it's obvious from the way that it looks. But yeah, you know, you set that hot air station up, you shoot hot air on it. And then what happens?
Yeah. So basically, for like the mental image, for people who are just listening, a hot air station is if you've seen a heat gun, it's not like a blow dryer. It's like just the like, straight part of a blow of a blow dryer without the handle. And it basically is just an electric coil that blows hot air. And then it has these little funnels on the end, like you mentioned that, like narrow the hot air down to like a very. You can see it. You're pointing at it right behind you.
I'm sorry, for those on YouTube, you can actually see it on my desk behind me. But for those of you on audio, listen to Joel, sorry. Yeah. So there's like a little, you know, it's like a giant pen kind of thing. It's wired up to this power supply. And then on the power supply, you set what temperature you want it to run at. And then there's a little nozzle on the end that controls how large of an airflow that it's pushing hot air out.
And then just as a fan over a heating element, it just blows hot air. OK. So hot air can go very, very hot. Very, very, very hot. Easily burn yourself. Very, very, very, very hot. So this is not something to like just, you know, mess around with. Obviously, be careful as you're using these tools. You know, respect, respect what it can do. It is a heat gun. It creates heat. You can get burned. I have gotten burned. Yes. Yeah, me as well.
Yes. I had a hot plate that I was also doing some desoldering with it. I just like stuck my hand on it by accident. I forgot I was on. So that was fun. But yes, so a hot gun, a heat gun, a hot air reflow rework station. It's called a lot of different things. We'll link some stuff down in the description for those of you that kind of want a basic setup. Yeah. But what you need to, all you need to know is that basically chips, generally speaking, have two different forms.
They have pins that are like coming off the side of them that are then soldered down to the board. And then they have these things called a BGA, a ball grid array. And a BGA is essentially little tiny balls of solder that connect underneath. Like it literally, it's sandwiches on top. There's the chip, then there's balls of solder, and then there's the board right underneath it, and there's contacts on the board underneath it.
And it holds it, you know, once the solder is not melted, it holds it there essentially acting as the pins that connects it between the contacts on the bottom of the chip and the contacts on top of the board. And so when we use a hot air gun, we're essentially heating up those little balls of solder underneath such that they liquefy enough and then you pull the chip off. And that's it. That's basically all you're doing.
You're doing what you would do with a soldering iron, like the hot tip thing and you put it on whatever it smokes and chip. It's all that, but it's just like from a distance. So you're just doing it with hot air. Yeah. With hot air. So, you know, I guess more concretely, you know, you get the hot air station and you're kind of using that pen and you're going back and forth and back and forth. And I think the last time we did an assessment, Joel, we set it to about 400 degrees Celsius.
But I think the best way to do it to preserve the safety for the devices, excuse me, is to set it at like a lower level, maybe like 250 or so, and then sort of slowly work your way up. So, you know, you shoot it, you know, back and forth, back and forth for about a minute and a half, two minutes. And then, you know, you try to lift the chip and it's, you're not going to be forcing it. It's literally just going to be a lift. Like you're going to put the grab your tweezers.
That's another thing you need. You're going to grab your tweezers. You're going to grab the chip with tweezers and you're going to try to lift up. And if it doesn't come with you, don't force it. And then you sort of back off, let the chip cool down a little bit because you don't want to fry it. You can maybe wait two or three minutes and then, you know, bump up the heat to 275 or 300 or something like that. And then sort of work your way up.
I think the place we found it was around 400, 425 maybe is a good spot. And then eventually, you know, you do that for sometimes it's not even 30 seconds. Sometimes it's like, you know, a shorter amount of time and you'll be able to just lift the chip right off. And then you've done a successful pull, hopefully, if you didn't rip off any pads. Yeah. So I'm sure that there are some hardware people cringing as they listen to this being like 400 degrees, 425.
So the one thing I'll say is most of these hot air guns are made cheaply and they do not have the best quality control and they're not the most consistent things, especially across brands and across devices. So your mileage is going to vary probably greatly from someone else's and you will just need to do some testing on your own. Like Justin said, I would start at a low temp, like start at melting point of solder. So like probably around 200 C and just work your way up.
If you're, you know, you're constantly moving your air gun, you're heating the whole area. The thing that you mentioned this, but you didn't really explain it. You need to be constantly moving the air gun around the chip because you need all of the balls of solder underneath the chip to be melted at the same time. Yeah. Evenly. Right. And the other thing is flux. Oh my God. Flux is your best friend. Yeah. So yeah. So flux based flux, it basically, it helps solder flow.
This is not really optional. I, you know, this is very important. Yes. You need flux like big time. So flux helps solder flow. It helps prevent it from oxidizing. And so essentially what that's going to do, solder has surface tension, essentially. That's what holds it in place. When Justin said that the chip will be very easy to pull off, it's like a water bug on top of a surface of water. It's a really good analogy.
The chip is basically magneted in place because there are copper contacts underneath it and there are copper contacts on the top of the chip and the balls of solder that are between it are surface tension to those pieces of copper and it's holding, like if you were to bump the chip, it would snap back basically because the solder is holding it in place. If it's doing that, that means it's ready to lift.
So your goal is that you want all the solder to be liquid enough that you can basically bump the chip and see it wiggle and then just lift it. And it's very, I mean. There should be no force. You're not peeling. You're not, you're not sort of, you know, starting at one side and like sort of lifting it up a little bit. No, you're going to break the chip that way. Don't do that.
It's really, you know, very lightly and, you know, maybe not even with the pointed tip of your tweezers because you don't want to like scratch it or like, you know, cause any damage to the chip. You're just kind of gently pushing against it. And if you, like Jill said, if you don't see that sort of movement, then it's not ready to pull. So yeah, there's a lot of really good videos. Well, actually there's not. There's a couple of really good videos. Yeah, I was going to say, I don't think so.
Yeah, yeah. People find, I think a lot of these are more like for repair and they don't, they don't care so much about the integrity of the chip that they're pulling off. And that's fine. It's like a demonstration, but just keep that in mind with temperature, right?
Like generally speaking, if you were to read the spec sheet for these chips, these chips are not designed to be in environments that are above probably like a hundred degrees Fahrenheit or like, you know, 30 degrees Celsius or something. Meanwhile we're heating them up to like 200, 400 degrees Celsius. So you know, part of that is that that's a direct temperature coming out of the gun, but that's not the temperature that's hitting the chip.
And that's also why we want to move it around and we want to keep constant flow so that all that heat isn't targeted into one specific place. It's going to fry or melt stuff within the chip. So yeah, those tweezers, super useful. If you look at any videos online, you're going to see basically lots of flux, lots of moving the heat gun around. Eventually, you know, they'll tap it. They'll tap it with like some really fine point tweezers and they'll see that it moves.
And then they just grab the edges of it and just lift it up. You know, microscopes, some people really like to do it under microscopes. Some people like to do it under like a magnifying glass. Some people like to just do with their eyeballs, depending on the size of the chip. You may or may not need to do that. You know, it's really, it's really up to you and your eyesight, I guess. But I do it without a microscope.
The other thing is, for those of you watching on YouTube again, you can see over my shoulder this little device that Joel, you know, freaking influenced me into buying. It's called, what is it called? Is it called? Handy Hands. Handy Hands. That's it. Yeah. And it's got like these little sort of, for those of you listening, it's sort of like Doc Ock style, you know, flexible arms that kind of grip the actual board.
And then they have sort of a magnifying glass light and they've got like a little clamp there that you can use to hold the board. And it's just got some nice things that make the whole process go smoother. And so I would recommend those that made it a lot easier for me. I know when I did, cause I didn't have that when Joel and I were doing my first pull, I was actually trying to heat up the chip on top of a heat sink to keep it flat. And Joel was like, dude, what are you doing? No, stop.
And so, yeah, definitely, definitely a good recommend there. Yeah. And then any kind of Handy Hands is really good. Yeah. The really good product. I really like it. And then, so once you pull the chip off, you got to clean it and you got to clean it better than you think you got to clean it. Just coming from a beginner's perspective here, cause I was like, ah, you know, this is probably fine.
Nah, you really want to take the time with isopropyl alcohol and a Q-tip and, you know, gently with some tweezers and, you know, you want to put, I think you, Joel, even use like the tip of a soldering iron and sort of drag some flux or some solder around on it, right? Yeah, yeah. So it's called reflowing. And basically you take like, you know, a larger than normal blob of solder and you can just heat it up and get it.
So it's like stuck kind of, yeah, it's melted, but it's stuck to the end of your soldering iron tip. And then you just want to glide that ball of solder over the contacts, over the copper contacts on the bottom side of the chip after you removed it. And that's going to one, pick up any extra solder that is on those pins. And it's also going to put a thin layer of solder back on top of any ones that don't have solder on them. So it's going to basically like clean up.
It's going to uniformly, right, right, right. And then you just, you know, lift it off and you should have your big blob of solder still on your iron. And that's going to help prevent any contacts from getting bridged, any of that kind of stuff. The flux, yeah, isopropyl alcohol, the higher percentage, the better 99%. If you can get it, 91 is probably what you'll find at like a store or something. But yeah, just a Q-tip or a cotton swab or anything like that.
You know, just be aware that it can leave like little fibers behind. Yeah, I don't like that. Yeah. Yeah. And you know, some Q-tips are less fibrous than others, I guess, less hairy than others. So what I did when I was doing it was I actually pulled off a little bit of the hair, you know, and kind of made it a little bit less hairy, you know, when I first started using the Q-tip. And then, you know, that sort of got it to drop less fibers.
So, or maybe even you could like, you know, twist it in your hand and try to compact some of that down so that it doesn't leave as many fibers on there because that is a pain to get off afterwards. I think maybe I used a microfiber cloth or something like that at one point to try to get this off. Yeah. Yeah, something like that. So yeah, reflowing it and using isopropyl to clean any excess flux. Those are the two ways that I generally clean the bottom of a chip.
If you're having a read problem with a chip and it looks like visibly like there's no defects in the chip, there's no physical damage, all the contacts look like they're intact, it doesn't look like any of them have been ripped off or anything like that, clean it again. Just that's number one. I just say clean it again because we had that happen both on my side and Justin's side where a chip wasn't reading properly in the reader, took some more ISO, just cleaned it one more time.
There must have been like a thin layer of flux or something that was, you know, interrupting their... Yeah, I don't know. But yeah, that fixed it. And that last one, that last pull that you did on the last exercise or the last thing we were working on, like it was, I mean, he was holding it up to the, you know, to the webcam and it looked like it just came out of the factory, man. It was like clean as could be. So that's the goal. It was mint. So that was really cool.
And then one of the other things I just wanted to mention, we're going back, you know, so, well, actually we'll go back after. Let's go ahead and finish this up. So you clean it and then we're going to go ahead and put it in a EMMC chip reader. There are quite a few different devices out there. The only one I have experience using is not on my desk right now, but it's an all socket EMMC reader, very easy to use.
It has a bunch of nice little plastic fittings you can use for different sizes of EMMCs. It does not, we did run into an issue last time where it actually didn't have the right plastic size to get it to read, which was kind of a pain, but we found another way to do it. So that was good. But yeah, so that's one option. And then I know people also use something called a T56. Yeah. Let me pull it up, universal programmer. And I've had some success with that. So, yeah, so I have both of these.
The BGA, so the all socket BGA EMMC reader, super, super useful. Like you mentioned, it basically has different base plates that will hold it over the right pin, like the pin readers within the socket adapter. The thing to note about that is one, it's quite expensive for like, it's a very targeted tool. It's designed for, I think it's BGA 159 or something, 186 or, I mean, let me pull it up real quick.
Yeah. And when he says it's very expensive, I mean, it's in the hundreds range, not in the thousands range because I'll just throw it out there. It was $87, but it's just this adapter, right? $87 plus $8 of shipping. And it's designed for EMMC, FPGA 153 and 169. Okay. So specifically that's like, those are two different form factors of chip. It might refer to like the number of, no, it doesn't. It can't be the number of solder. It's a specific form factor of chip basically.
And you'll see like, if you're reading the data sheet, that there will be different form factors for different chips. A lot of them will fall into the same categories, but as just mentioned, for example, we pulled a BGA chip that was, I think it was a BGA 153, but it wasn't the right size dimensions. It didn't have the faceplate to hold it in the adapter. So we couldn't read it very easily. And I had even tried like 3D printing an adapter to fit it in there and it didn't really work that well.
Yeah. Yeah. That was a little bit of a bummer. But definitely, if you're going to buy specialized equipment for a specific thing, I think these all socket EMMC readers will cover the large majority of the ones, but you got to know you may run into a situation and you may want to measure the size of the chip beforehand in millimeters and make sure it supports that form factor. I do want to say, I said it just a second ago, but Joel said they're expensive.
There are some things on Amazon that are selling these things for like two and a half grand. That is not what we're asking you to buy. Do not buy that. They're cheaper options. I think it was like, yeah, $100 or $700. So we'll link some of those down in the description. You can find them on some of them, you can find on Amazon. Some of them you can find on some of the other websites. So definitely don't go and spend like two and a half grand for one of these things because it's ridiculous.
Yeah. Yeah. For the T56, that's really good for like... Yeah, tell me about that. Yeah. So that's good for like NAND flashes and stuff. It has different use cases. Generally when I use that... What is a NAND flash? Well, a NAND is just like a basic part of a chip. It's like an electronic structure, but a NAND flash, it's just a different type of flash. Okay, gotcha. As opposed to an EMMC or a NAND flash, they're different types of flashes, NOR flashes.
But you can buy these large sets of adapters. So I have a huge box that's full of just like every type of T-SOP, like T-SOP 48, T-SOP 56, like every single T-SOP or SOP adapter that you can think of. And then on the bottom, it has these little pins that they're just pin headers. And essentially you clamp it in this T56 and then you plug it into your computer and you can read it. And it's just, it's a different way of mounting it. Basically the all socket one I'm using for BGA stuff.
I suppose you probably could do BGA stuff this way with the T56. Yeah, it says, if you... Here, I'll send it to you right now on Discord. If you look at the third item down, it says supports BGA 45, 63, 64, 153, 162, 169, 221. So I think it definitely has a wide range of BGA that it's compatible with. Yeah. Yeah. So I think the main thing is you just have to get the right adapters for it. I'm honestly not sure how this thing works.
Every time I've ever used it, I just plug it in and it either has the chip in the software or it doesn't. And it just like, yeah, I don't know. It's kind of weird, but it's pretty useful. Yeah. So this could be a good one to check out and add to your arsenal as well. I think probably altogether, I spent maybe five or $600 on sort of like a beginner's setup for all of this stuff when I was first starting out.
So definitely it's not cheap to get into it, but also now I've got the tools that I'll use in the future as well. So that's pretty helpful. Yeah. Yeah. Hardware hacking is one of those things where you could easily spend a couple thousand dollars on tools and still not have the right thing that you need. So I would just say do a lot of research before you buy stuff, especially specifically for your use case. So like what specific chip do you want to use this tool for?
Is it going to work for that chip? And don't be surprised if it doesn't work for other chips. That's kind of just the way it is. If you can find some of those more generic tools, sometimes they're more expensive and they'll require some more like effort on your side in terms of like programming or like maybe you'll have to write something custom to interface with it, but those tools will let you interface with almost anything. Nice. Yeah, that's awesome.
I definitely value that flexibility a little bit because it's nothing worse than like you sit down on a weekend and you're ready to go and you're like, all right, I'm just going to hack this and you get like an hour in and you're like, I don't actually have the thing that I need. Yes. That's a pain. All right. So you cleaned it, you put it in your reader.
Like Joe mentioned in the beginning, there's a little dot at the corner of a lot of the EMMC chips that show you where the number one pin is and you'll want to align that with the arrow on your all socket EMMC reader if you're using that and sort of clamp it down, slide it right into a SD card slot either on your computer.
Ideally your computer has a EMMC reader built in at a sort of internal chip level rather than using like a USB thing, but the USB things will work as well unless you're trying to access some specific features that only a EMMC reader can access rather than an SD card reader because they are sort of cross compatible, but EMMC has some features that SD can't handle, I think. Right.
Yeah. So like the RPMB stuff that we talked about, like that is one of those specific things where you need an EMMC controller that is in like on your device in order to interface with something like that. They sell PCIe ones that are like proper EMMC controllers, but most of the time you're going to find it needs to be like an onboard full size SD reader on your computer on like a laptop or something. And even then a lot of the times it won't.
If you use like a USB reader, USB like SD readers, they are basically just storage interfaces for EMMC. So they have an EMMC controller on the, you know, in the USB adapter or whatever. But when you plug that in, all it's doing is exposing those storage interfaces. So it's going to be all the storage partitions, but you're not going to have access to the raw EMMC like RPMB and any of those other like special EMMC type things, unless you have an onboard EMMC controller.
So if all you need to do is read data partitions, totally fine. If you need to read RPMB. Which is what you need to do normally. Yes. Normally speaking, like 99% of cases you'll probably be fine. But if you want to try and get at RPMB or any of that kind of stuff, you're going to need an onboard EMMC controller. Yeah. Yeah. So now you've got it hooked up. You're seeing the partitions pop in.
What we did last time is we just used the DD command in Linux to just pull a raw, you know, device level image of that device into an image file. And then we ended up using, was it 7-zip? 7-zip. Yeah. 7-zip to go ahead and break that out into the individual partitions. And then, you know, you'll see various files created. And if you run file on them, you'll see like, you know, there's an ext4. Ext4, yeah. Or like a fat partition or whatever.
You know, there's going to be a bunch of different partitions because that's always what they have in a bunch of these IoT devices. But you know, identifying all of those various partitions is really fun. And this kind of pivots into the last section that I wanted to cover, which is like, Joel, what kind of like, preventions have you seen from this?
Because the only one that kind of comes to my head was like, man, we would have been in trouble if they stuck all of the source code or like the file system for that device inside of that lux encrypted partition that we saw for some of the more sensitive data. And then, you know, stored the key for that lux encrypted partition in a secure on give and at like a hardware level at the CPU or something like that. That would have been a royal pain in the butt to get access to.
So I mean, there's that option. I imagine that would sort of delay startup quite a bit because every time you wanted to use the device, you'd have to decrypt everything on the partition and then also copy that into an actual functioning partition. So that might affect the boot speed a little bit. But what other kind of hardware level preventions have you seen that might, you know, foil a hacker?
Yeah. I think I mentioned like that kind of stuff, that's going to be like 99% of the time is going to stop like a lot of what you're trying to do. You're going to have to find some other attacks near if you want like a shell or something like that to figure out like what it's doing, you're going to need to like glitch it or maybe you'll have to read the MMC while it's running or something like that. Right. Like this is one of those cases where that might actually be the right scenario.
But yeah, an encrypted partition would stop like pretty much all the stuff that we were doing there. Another thing that you see commonly, and this isn't for storage so much as it is for like debugging stuff, but there's typically, there'll be like a fuse either within a chip or on the board. And it's typically called like a JTAG fuse or a UART or a debug fuse or something. And they'll basically pop the fuse by like putting enough power to it and then it can never be reverted.
So it has a physical break in the communication between like your test pins and the JTAG interface on the chip. And you can't get around that unless you like, I don't know, do some like really crazy like pulling the chip apart. Like I don't know. You're going to have to like cut into the chip and like get access to it. Which I've seen by the way. That's crazy. Yeah. That's really gnarly.
That's interesting though that that's a counter measure that people might take, you know, just kind of putting a fuse in there and blowing it, you know, severs the connection for that sort of thing. That's a good idea. Yeah. I've seen, there's a couple of really interesting Twitter threads out there. I'm trying to remember who created them, but every once in a while you'll see like some crazy hardware hacker just like put a video of what they're working on, like on Twitter.
And this one time there was this guy, he was using a razor blade to scratch away the surface of a chip while it was on the board to expose the contacts underneath. And then he took like, you know, probably, I don't know, speaker, speaker wire. I don't even know. Like, you know, like maybe like a coil wire or something like really, really fine wire, like wire, wire gauge wire. And then like, I think he soldered it down so it wouldn't move.
And then he soldered the like tip of it to like the contact on the chip. Dude, it was so crazy. I got to, I'll find it. We'll put it in the show notes. Yeah, no, definitely find that. I want to see that. And I know I watched a talk at Defcon by Leonard, I think is the guy that did it. Hardware hacking guy, you know, just glitching. I think it was some SpaceX or stuff or some whatever their, their wifi thing is that's everywhere. Just absolutely amazing.
There's so much to learn about in this space, which really excites me as a, as a more veteran hacker in the, in the web and, and mobile space a little bit now. You know, having another realm to dive deep into is really, is really cool. So I'm excited to continue learning about that sort of thing and be able to do some, some glitching and, and some, some of the stuff that I haven't tackled next time around. Yeah, for sure.
I mean, there's this space is like, I feel like I've just barely scratched the surface in terms of knowledge and understanding and, and what's possible and all that kind of stuff. And I feel like I'm just, just like, I'm doing like, you know, a baby's first hardware hacking right now. So like there's so much, so much I, I don't know. And there's so much I haven't explored that that seems so cool.
Well, it's very different too, you know, and if you talk to some of these lower level guys, they, they don't have any, you know, experience doing web stuff. And so it's just different realms and different sections of places where people are focusing. And so it's cool to get some sort of cross experience. It makes you really feel like a more well-rounded or developed hacker, I think. I did want to add a disclosure at the end here. This does not constitute a vulnerability.
So being able to pull the operating system off of a chip, I personally don't believe constitutes a vulnerability. I've seen some hackers report that. I'm not sure whether they got paid or not. But you know, there's not a really great countermeasure to it. And, and so it's just kind of a part of hardware hacking and more like finding JavaScript files in, in, in web stuff or more like decompiling an APK and grabbing at the Java source code, you know, in mobile.
So definitely, definitely don't go and like, once you get your chip and you pull the data off of it, don't go report it like critical, you know, source code disclosure, because I believe most of the time that is something that is not going to get accepted by the program. So there's your disclaimer. Yes. Yeah, for sure. And I agree. I've actually, I've seen people report this exact thing as, as a bug.
And it's personally, it's not something that I would report either, but I do see that there is a security risk to it. I think I would probably just like, it's a really hard attack scenario to like justify is like, you know, to say like, oh, it's a higher crit or something. That's a really hard thing to justify, depending on what it is, depending on what it is.
There are certainly hardware devices, like cell phones that are in like so many people's hands and pockets that that might be a justifiable attack scenario. But I think just in and of itself, having a decrypted partition, maybe not enough. Yeah, totally agree. Yeah. All right, man. So that's all on the notes for this episode. You got anything else or are we going to wrap it up here? Nope. That's it. I did find those links. So we'll put them in the show notes. Be sure to check out those links.
One is from Gtorix and one is from Hacking Things, both on Twitter. I'm going to go, I'm going to go look those up right now. I will say as we're heading out, so many of you went over to the website after last episode, criticalthinkingpodcast.io and dropped your email in the newsletter. Super appreciate that. I would love if you continue to do that. And also, please remember, NahantCon, that ends, let me pull up the dates really quickly. I want to say it's June 15th to 17th.
Yeah, June 15th to 17th. The Saturday is when I'll be speaking at the 1220 slot. You won't want to miss out on that. Lots of great, talented Bug Bounty Hunters there. They're dropping some amazing presentations. So we'll see you there. Yes. So remember, it starts one week from the drop of this episode. So be sure to tune in if you want to hear a little bit more Justin. And some other awesome John Hammond's going to be there. So yeah, super, super awesome security conference. Go check it out.
For sure. All right. Catch you all next week. Peace. All right. No issues.