A little while ago, I put on about 20 lbs. of weight during a particularly busy work season, while studying for an intense certification (OSEE), and while carrying out an experiment of living in Manhattan. It was a stressful time, but thankfully I moved out before COVID really picked up, and now I live in beautiful Michigan. I had to "dig myself out of the hole" in terms of eating right and exercising, which are some primal activities that I greatly enjoy.

For the sake of this post, the inverse of “digging myself out of the hole” is "climbing down the mountain" as it applies to technology.

I'd like to talk about the perhaps not-so-novel idea of "The Tech Mountain". This is something that highly technical folks, who work across multiple abstraction layers, contend with on a regular basis. As a person who dabbles with information security, it's a concept that strongly resonates with me, so I thought I'd share it. Essentially, I am constantly trying to figure out where the boundary of one technology ends, where the next one begins, and exactly how they interface with one another so I can potentially exploit (or discover) a vulnerability. In other cases, I need to understand this interface at a deep level so I can implement some novel, one-off functionality to aid my cause.

As our technology "improves" and becomes more complicated, there is a greater burden on future generations of engineers to figure out how this technology works. Often times, people are focused on one layer of the technology stack, and they have no clue how things work below (or sometimes above) their own abstraction layer.

Generally, this is a feature. People can focus on their own layer and ease the burden of keeping all the other abstraction layers in mind.

But in order to truly understand how technology works, I believe it is important to climb down this "tech mountain." This is important as a hacker, because you are often working through multiple abstraction layers in order to ultimately exploit a piece of technology. As another example, a software architect must have intimate knowledge of how each layer of the technology stack will work with one another in order to ultimately create a solid system.

So how does this "tech mountain" work?

Let us take a look at this rough diagram I put together.

The above, simplified diagram should help clarify the idea. On top, we have high-abstraction. At the bottom, we have lower abstraction. People spawn at the top of the mountain when they are born, and throughout their technical careers, they traverse this mountain down. Folks that use computers as productivity tools often never descend below the first two layers, because they don't need to. Sometimes they learn some fundamental concepts in school, like "V=IR", but they have no idea how this actually applies to the machine they are using to type up their homework. While I think our education system including college needs revamping in general, the middle part of the above diagram is actually massive and takes many years, if at all possible, to descend through; there is an increasingly tremendous amount of abstraction layers.

This brings us to the main points of this post.

• You get the most value out of your time growing as a hacker by traversing the tech mountain down.


• You get much less value out of your time growing as a hacker by traversing the tech mountain left or right.

In other words, if your goal is to become a more formidable hacker, learn deeply, ensuring that you are traversing abstraction layer boundaries.

Here are some examples:

• How does your browser talk to websites? Understanding this helps you manipulate HTTP requests. This then helps you understand other application-layer requests.


• How does a program get loaded into memory by the operating system? Understanding this helps perform things like process hollowing.


• How does a process virtual memory space work? How does it translate to real physical memory? Understanding this helps to craft memory corruption exploits, or to bypass exploit mitigations such as SMEP.


• How does a processor perform branch prediction to improve performance? Understanding this helps you understand processor-level bugs like Spectre and Meltdown.

Sometimes, there are no tools readily available to "peek into" a lower part of the mountain, but there is great long-term value in creating these tools to peel away layers of abstraction and move down the mountain. When I first learned about debuggers for example, they seemed magical, because they gave me full visibility into a process's virtual memory space.

The nice thing about reaching a lower part of the mountain is that you can now easily understand technologies / concepts to the left or right of where you currently are. Here are some examples:

• Do you know how to use an iPhone? You could probably switch to Android.


• Do you know how to use Word? Excel will be a breeze.


• Do you know how HTTP works? FTP won't be hard to hack.


• Have you used MSSQL before? You can probably learn MySQL easily.


• Do you know Java? C++ will be fun, and the memory management will be a trapdoor to a lower part of the mountain.


• Do you know how to craft a full internet packet? You can start messing with TCP / UDP sequences manually.


• Do you know some Windows Internals? You can probably re-spec to programming for Linux without much difficulty.


• Do you understand x86 assembly? ARM is probably not going to be too hard to pick up.

Obviously, there are trade-specific situations where learning the breadth of the subject is a requirement. For example, as a database administrator, you probably need to really know the ins and outs of a particular set of technologies like MSSQL's quirks and SQL itself.

That's it for now! Thanks for your time. Consider signing up for the newsletter to stay updated with future blog posts.

-Faisal