No joke: I think a friendly way to learn how to think like a hacker is to play Untitled Goose Game. The goose takes otherwise innocuous everyday objects from its environment and chains them together for exploits to achieve its own ends
You should! It is the video game embodiment of hacking!
All of the rules are clearly laid out but it's up to you to find loopholes and modify the rules to reach the goal (or sometimes, bringing the goal to you).
I think an integral part of being a builder is being a breaker. How do you expect what you build is ready for the hordes if you don't think about unexpected ways to break it?
I'll confess where I get lost is the details of where I could break things outside of code, especially networking things
this came to me from watching a Moxie Marlinspike talk way back in college. i'm not good at articulating it.
vertically, computers, and systems in general, are built on layers upon layers of abstraction. as a developer, you only really need to understand the layer you're working with
but as a hacker, you want to understand the layer below that so you can find where assumptions and generalizations are made. this is where errors are also made, where you may very well have the opportunity to influence a small part of a system that dominoes into a greater effect
horizontally, with most things, there are standards governing how they should look or behave for interoperability's sake. the easy analog with human systems are written policies. these standards are often written by people who are not beholden to the realities of trying to implement such a system
so one potential place for error or opportunity is the difference between the standard and what the developer believes the standard to be. the next place is the difference between what the developer believes they are implementing and what they actually are implementing.
the map is not the territory
don't think about hacking as breaking things. a better analogy would be thinking about it as taking a puzzle, decinding what the desired effect should be, how it should look when finished, then solving it.
Unsolicited Response: I learned by being a systems integrator. I integrated systems. Now my key skill is being a systems disintegrator and exploiting flaws between subsystem components.
Take what you know and pull it apart and consider the weaknesses. Break it where you can. VMs, clouds, docker
Comments
As a user, I want to use this feature in a way that wasn’t intended, so I can….
In this story, what might that user want? How might they go about achieving that goal?
Theres also the classic Hacknet game for something a little more directly computer hacking beginner tutorial, but as a game
All of the rules are clearly laid out but it's up to you to find loopholes and modify the rules to reach the goal (or sometimes, bringing the goal to you).
peace was never an option
I'll confess where I get lost is the details of where I could break things outside of code, especially networking things
Channel your inner Dee Dee.
the way i think of it is there are a number of places within any given system that give rise to opportunity
vertically, computers, and systems in general, are built on layers upon layers of abstraction. as a developer, you only really need to understand the layer you're working with
the map is not the territory
Take what you know and pull it apart and consider the weaknesses. Break it where you can. VMs, clouds, docker