Hello everyone. Mirrai here. If you've followed my content so far you'll know I usually write technical stuff. Registers, offsets, shellcode, that kind of thing; but today I'm in a more reflective mood. If you've been in cybersec or any technical skill really, you must have heard about the growth mindset. The idea that we should keep learning and growing in skill, knowledge and ability. Hackers have this mindset by default, I'd say. It's the renowned "Hacker" mindset. What exactly even is this you may ask? Well it's basically the growth mindset applied to external curiosity. Let me explain.
It starts with "what happens if"
Most people interact with software the way you'd interact with a vending machine or a remote control. You press the button, the thing you expect happens, and you don't think about the machine again until it doesn't work. That's a fair way to navigate the world. You shouldn't need to understand a whole machine just to use it. In fact, most software is made this way. Buttons are labeled and you are guided by instructions or intuition on how you should use it.
The hacker mindset is the opposite of that. Instead of "what happens when I do what I'm supposed to do", it's "what happens when I do random crap."
Imagine you got a machine you've never seen before. It's relatively new, barely documented and it's expensive. You have no manual either but you want to learn how it works. What do you do? You could either wait until you got a manual or for someone to operate it and teach it to you. Or you could say "YOLO" and go ahead and learn it by testing what each button does and hope you don't break it. The end result is either a broken machine (and your regrets) or mastery over that machine to the point that you may understand it more than the creators themselves.
I got a very early, very unglamorous lesson in this as a kid. I used to root my phone a lot back then. I rooted it, flashed TWRP recovery, and even flashed a custom ROM. I soft-bricked it into a bootloop at one point but managed to fix it. Eventually though, I flashed a driver I shouldn't have and hard-bricked the phone. RIP, wherever you are.
Did that stop me from rooting? Lmao, no. The next phone I had, I did it again almost immediately, even though I knew that if I messed that one up, I wouldn't have a phone for a very long time. It's about treating curiosity above playing it safe. The knowledge of past failures (like my hard bricked phone) makes you better at doing it and understanding things. That's where the growth mindset part comes from.
The instinct to poke at things doesn't mean much on its own if you stop the moment someone hands you an explanation but rather it's the need to keep digging that gives you something novel.
To break the rules, you must understand them
To be clear, this isn't permission to ignore what's already known or skip learning the basics. There's a difference between exploring the unknown and redoing something that's already solved. To do the former well, you often need to understand and practice on the latter. The example I gave with the unknown machine earlier is a situation where you have no choice at all. There's no manual, no tutorial, nothing to reference. You don't need to explore blind when a resource already exists to teach you the fundamentals first. While rooting that first phone, I used tutorials, which gave me the general knowledge of how rooting works. On the next phone, I took that general knowledge and deviated from it to find something that worked for that specific device. Basically, to break the rules you must understand the rules. Not understanding the rules gives you no frame of reference to start with. Imagine learning a programming language by typing random syntax with no prior knowledge. Yikes.
Also, if you can test things in safer, more controlled environments, you definitely should. You don't have to be risky about it because I was as a kid lol.
Comfort with the unknown (and pure persistence)
This might be the least talked-about part of the mindset. Most technical writing, mine included, presents a clean line from problem to solution. What it doesn't show is the several hours in between where you have no idea what's going on and every experiment you run makes it more confusing instead of less.
I think this is the actual difference between someone who pokes at a system once and gives up, and someone who ends up finding something real. Not raw technical skill, at least not at first but the tolerance for the boring, confusing middle part. It's the tenacity to look at a hexdump and be like "Pfft it crashed a 100 times? But something changed from last time. I'm so close, I can feel it"
It's a lens, not a toolkit
None of this is really about exploits specifically. It's a way of looking at any system, software or otherwise, and asking what it actually does versus what it's supposed to do, and where the gap between those two things might be hiding. Sometimes that gap is a security bug. Sometimes it's just an interesting quirk you write a blog post about and never fully resolve. Either way the instinct is the same. Don't let "that's just how it works" be the end of the conversation until you've actually checked.
I'll get back to other projects eventually. Or I'll find something else to poke at first and write about that instead. Either way, feel free to drop your own "what happens if" moments in the comments, I'd like to hear them. Bye for now.
Top comments (0)