What I talk about when I talk about Consulting

Note: this post has very little to do with Atredis as company. The only relevance being a part of a consultancy has on this tirade is that its existence has positioned me to be invited back to BlueHat for a second year in a row to talk about whatever seems interesting to me at the time. 

This post is a textual version of my talk at Microsoft HQ and honestly more of a manifesto. It intends to define another way to explore your company, another way to look at technological expertise and another path to approach security as a fluid entity, or at the very least, track down Godot.

So, years ago I used to work at the Mitre Corporation. For the uninitiated to the realm, Mitre is a Federally-funded Research and Development Center and can be thought of as a pseudo-government think tank for pseudo-applied research constrained to non-profit status. I entered that organization with a solid career background as a developer specializing in crypto implementations, artificial intelligence and applied game theory. I was quickly tasked, at least in the Mitre sense of the word, with "do something cool and expand yourself". In a decidedly rash "because why the hell not" moment, I picked mobile security and human interactions as my paths of exploration. While I'm sure we will meander into security before the end of this diatribe, I'd oddly enough like to start with problems from the other space.

Specifically at Mitre, I looked at how to foster cross-domain innovation. I basically spent a couple years looking at how new ideas blossom when domain experts from disparate verticals interact and share conceptual structures. I spent weeks modeling building layouts and walking paths trying to ascertain how knowledge spread across the campus. I mapped social networks and interaction structures, I explored forced office mate collaborations and I basically geeked hard on graph theory. I wanted to know how small situational changes could force "Dr. Satellite WaveForm Guru" to stop and share a cup of coffee with "Intern Physicist" and for some reason I always expected robots to fall out of the conversation. Awesome laser wielding autonomous robots that would simply self design more robots and blow things up with lasers while rad 80’s metal blared in the background. I guess I had a thing for robots.

I also wanted data, mounds and mounds of data, to fit into beautiful Gephi graphs that could be analyzed and improved upon. I wanted innovation efficiency. Maybe I thought that the end game was me sitting back in some darkened hivemind control room, watching structured magic happen in realtime, I really don't recall. 

I thought that if we could simply control the environment with enough scientific accuracy, we could control that initial "spark" that so many startup books lauded as the beginning of massive scientific breakthroughs. Stated simply, I wanted to play God to a campus of Mensa-level experts. What a surprise it didn't work right? Solving the social graph is a slightly harder problem than raw data collection, who knew?  

I did walk away with some insight, that while obvious to most people, had eluded me in the depths of my contrivances. A happenstance chat between two people is almost never really an accident, and it takes a catalyst stronger than a once in an occasional espresso to bond two elements from opposing sides of the periodic table. 

In my case, the best catalyst was a bonding agent delivered in the form of an inquisitive procrastinator. An outgoing person who would shirk their own responsibilities and deadlines to randomly walk around and ask people "what are you working on". None of the managers could facilitate these meaningful interactions because they had little insight into what other teams were doing outside of their own silos, and were too damn busy “Getting Things Done”. 

A lowly slacker barely hanging onto gainful employment, though, could cross-pollinate like mad. Randomly walking around the building and asking people "whats up, what are you working on?” and then accidentally sharing others problems during small talk. Someone doing that was pure innovation gold. That person was also a huge burden to the immediate bottom line of the company and easily dismissed as a dead end to a small organization. An unrecognized hero that all too often is left with a pink slip and some much needed "forced vacation". [Shawn says: see also Maclolm Gladwell's "The Tipping Point", on influencers and hubs.]

Let's pause that line of thought for a second and chat about why I sometimes look at Katie Moussouris as the Paul Erdös of Microsoft. If you don't catch it, we will un-pause this conversation when I start talking about degenerates with spray paint.

Mathematician Paul Erdös. Knuth is his homeboy.

Paul Erdös was a brilliant mathematician who solved no small amount of insanely difficult problems, but that's not what he is really known for. He crossed into the general public consciousness for his prolific collaboration across fields, he is more than 15-minute Andy Warhol Famous for the Erdös Number. The Kevin Bacon of Academia in a sense. 

There are books and websites on this construct, so I'll let the one person reading this unfamiliar with the topic explore at their own pace because I don't care about the number either. I want to point out something less evident. 

To some extent, Erdös created a bug bounty in academia. The impetus was vastly different, obviously. I can't speak for Katie or MS, but I don't think either of them wanted to offload problems that would be open and unsolved post personal demise for the simplistic sake of leaving nothing unknown and unexplained. I've never found a definitive source for his original construct, and have always assumed it was an amphetamine-fueled decision process wherein he thought "If I could only be more people, I could solve more problems". A "Fear and Loathing in Las Academia" path to cloning I guess. 

Erdös attacked the problem by offering small rewards to those that solved open problems he didn't have time or the mental faculty to tackle himself. He simply outsourced problem solving before there was a term for it. If inquiring minds want to know more, read "Erdös on Graphs" or anything about Fermat's last theorem both will expound upon the program. The problems were (and the open ones still are) immensely hard.

Take a look at the Collatz Conjecture, for example:

Take any natural number n. If n is even, divide it by 2 to get n/2, if n is odd multiply it by 3 and add 1 to obtain 3n+1. Repeat the process indefinitely. The conjecture is that no matter what number you start with, you will always eventually reach 1.

Paul Erdős said about the Collatz conjecture: "Mathematics is not yet ready for such problems." He offered $500 USD for its solution. 

Simple, huh? As someone who has wasted a considerable amount of time contemplating this one, I welcome you to join the dark side. It is hard and you have loved ones and friends that need you more, but the outcome would be so fascinating, I really don’t mind you not having nights or weekends 

An Erdös check isn't even the type of check you cash, actually. You frame that check and hang it on your office wall when Harvard offers you tenure for being an epic badass. Your prize is writing a page in the book of human knowledge. I might have a slight hero complex here.

Taking a step back though, all Erdös did was to entice random people from random spaces to attack a generic problem. This construct enabled unique points of view to descend upon the same problem space and interact. He seeded the coffee shop with talking points and smart people. He asked a couple of questions and in a sense played God with the outcome. 

History and time actually solve the problems, building upon breakthrough after breakthrough. Fermat's Last Theorem itself was solved with a mix of pure innovation and branches of mathematics that are now foundational but were revolutionary or simply non-existent when Fermat trolled the world and much later when Erdos offered up a reward for the joke.

Pierre de Fermat, Legendary Troll

Treating exploration as foundational knowledge can be seen in most everywhere if you look, but nothing springs to my mind as a better exemplar than graffiti and street art. It is a scene, a lifestyle, legally dubious and in our conversation, a collection of raw transitory data cataloging human interaction. It all starts with an empty wall and one after another people come along and tag it, expand upon it, connect the disparate parts and create a living entity of artistic expression. I guess it would be akin to free form jazz collaboration, but in this instance a city worker washes it away on a scheduled basis and the entire process cycles anew.

London Graffiti

Eyesore or museum quality, in this context we don't care about the transitory expression itself. We care about the process and the components that play the game. Every actor has a part in the whole and each person comes into the collaboration with a specific intent and a specific skill set. Every interaction becomes essential to the overall evolution of the art that exists and each artists specialty is a core component of the overall construct.

Let me say the same sentence again with slightly different actors: 

Every interaction becomes essential to the overall evolution of the product that ships and each team specialty is a core feature of the overall ecosystem.

If you just woke up from a nice nap with a nightmare about team meetings, I’m sorry and I’ll pause the metaphor break for a bit longer. Consider it a snooze button on the alarm clock of Windows Phone Bluetooth explorations because I want to talk about expertise first.

If I say Kasparov, you probably think about knights and blue mainframes, but let’s drop the mind games and focus on chess for a second. True and utter mastery from our perspective. Not infallible, but an expert by every definition I am aware of. It would be ludicrous to expect anyone in this room to beat a grand master at his or her own game (it could happen, but your ego aside please let me have this statement as fact). Best of 3, 7, 101. As long as we are in the game of chess Kasparov wins. But what if we switch to checkers? Theoretically your odds are better I guess given it is a divergent game, but the outcome is predictable. 

What if we extrapolate this out to “all games” though? I’m going to go out on a limb and bet that at least one person reading this could beat Kasparov at Quidditch and probably half of us would win at Texas Hold ‘Em.

Gary Kasparov, sub-par Quidditch and Poker player

Expertise mixed with human nature tends to silo itself, specific and targeted perfection normally does not mix with well rounded knowledge. It’s the reason people group themselves by similar interest and it is the reason why my two scientists never made laser wielding robots at Starbucks. 

But what if we replace Kasparov with von Neumann, a generally accepted “smart guy” and game theorist at heart. His perfection was not a single game, but the entire construct of a game. Dr. John would not have the skill depth to win against a master, but would understand the implications and theoretical correctness of every move, in every game. Except maybe Quidditch, but probably even that scenario he would see things subtly missed by the lay player. Master in none but “expert” in all? Not really, probably more appropriate to say master in none but meta-understanding in all. He couldn’t beat Kasparov, but he could enumerate where he and Kasparov made mistakes. In a way, he would be qualified to help train and guide a master.

John von Neumann, would build Quidditch state machine

This was a very long winded way of getting to my point. I want this for you. You are the Kasparov and the Scientist. You have teams that are immensely smart in specific domains and sub-domains and sub-sub-domains, you probably even have a couple slackers helping ideas spread (please don’t fire them, they are your revenue stream in 10 years). What I’m arguing for is a game theory bonding agent, one that can look across silo interactions internal to your products and across all of your competitors.

I want this for you because the real secret is. They are not your competitors. You don’t compete, you innovate and build technology. Other companies do that as well and you share market space with them. Sure, quarterly profit margins make it feel like a race but the longer term reality is that you are responsible for making things better. That is your real place in the game, you construct the future. If you were simply competing, all your advertisements would look like political ads and read “We don’t suck as much as $Product_X”.

From a security perspective, internal teams can tell you exactly what is exposed within the confines of their expertise. If those teams are looking at public security theater they can ensure you are not exposing anything documented with a CVE or any vulnerabilities frozen in YouTube presentations. This should be your base minimal expectation.

One last divergence before my parting thoughts:

Please, please, please don’t ever expect your people to “think outside of the box”.  You want experts and that saying is simply “marketechture” and “thinkfluence" bullshit. No one thinks well “outside of the box” because no one is an expert at something they are not an expert at. 

All you get with that request is someone fumbling around and maybe getting lucky. Instead, bring an outsider into the process and expect to get another set of eyes on your problem from someone with a completely different view of the world. Someone with a (potentially lesser) expertise in a (potentially) much larger problem space. An outsider brings new context to the thinking process, “thinking outside of the box” kills morale and wastes smart people on silly things.

Final tirade aside, if you want to know how your different silos interact within a product, you need someone who understands how that technology works. Generally, you want someone who understands all the technology at a less expert / more meta-theory level. Let that person force both expert teams into understanding consequences outside of their vertical.

If you want to know how your technology implementation compares to other companies selling products, look for someone who has an interest in the overall technology space and don’t try to force them into expertise. In AI I used to search for sub-optimal paths: problems with multiple answers wherein the selected solution was the closest to optimization within the computing constraints. Look for sub-optimal expertise, sometimes you don’t need a PhD for progress. You just need a really excited intern. (Unless it's one of those times you need a PhD).

Do you honestly want to know how your product is going to fare in the post ship-date real world? You need to understand every problem in your technology space, all of the problems in your vendors technology spaces and all of the potential problems from technology that might have conceptually portable attack scenarios. 

Trying to secure Bluetooth? I’m sure you have hardened the driver against your hardware, but have you looked at porting all known RFID attacks to your implementation? Do you know what services other vendors expose at the unpaired level of discovery? Have you explored how IoT or RTOS based kernel attacks could be conceptually leveraged against your driver code? If you ever bring in consultants or employees to answer these overall questions and have the realistic intent to use them for anything more than staff augmentation, you should ensure they will do this. You should ensure it excites them and that they want to do it.

Ok, so you really want to know how to leverage the process used by a good consultant?

Stop trying to make everyone an expert at a thing and start trying to make technology better. Period.

We don’t look at other companies as your competitors, we look at the meta case of “how do we make technology more secure by having fun and breaking things we admire”. You can do the same thing, or you can outsource that to the sub-optimal-experts 

We tend to continually learn a technology by looking at all implementations of it. We tend to start with cross domain similarities and extrapolate from there. We look for the general delta between our knowledge base and your product, and we try to minimize that delta.

Thanks,

m0nk

(and I promised I would mention Godot in this diatribe, so… Godot)

Making a 1st Impression with Hardware

Fluffy Introduction Text

I get the “What exactly do you do for a living?” question fairly often, and tend to generically toss out a canned response of “hacker” or “information security professional” or “computers” depending on the person asking and whether or not I’m being questioned by a customs official with a gun and a surly look. I thought it might be fun to blog up a example or two of what we actually do for a paycheck, as it might help explain our niche inside a niche industry and maybe illuminate where our customer’s money goes and what value we provide.

For this exploration, let us focus on 2 random devices sitting on my desk this weekend: The Samsung Galaxy Note 3 (specifically the SM-9005 variant) and the often misunderstood and slightly obscure Samsung Anyway S102.

For the Note 3, I’ll detail what a teardown looks like to me and why it matters to the customer. The device is fairly well documented on the internet, so a full and complete hardware reverse engineering analysis probably isn't worth the time. As such, I’ll just focus on the high level overview. Consider this my first couple of hours on a project, simply what I look for and what my plan of attack would be. This teardown will disregard software and the USB stack entirely, and just be a glance at the hardware.

After the SM-9005, I’ll walk through a deeper analysis of the S102. I expect this to be quite interesting and fun, though it will be a separate post that will go up within the next couple of weeks.

So, without further ado….

The Samsung Galaxy Note 3 (SM-9005) Teardown

With any common mobile platform that crosses my desk for analysis, I start with a quick perusal of iFixIt for a teardown. For the Note III, we find this: <iFixIt Link>

The device is fairly straight forward to crack open, but the public teardown doesn’t tell us much about the internals. We can fix this with a bit more time on google and quickly run into the beloved chipworks.com tear down (we will come back to this later): <ChipWorks Link>

While the overall information is nice, what we really care about here is:

• What components are being used (ChipWorks gave us a listing already)
• How was the device built
• Did the designers leave any debugging mechanisms exposed or active during production
• Are there any weak or squishy portions of the design that look easily exploitable

So with the background we have at hand, it’s time to take a screwdriver to the phone and see what’s inside for ourselves.

A GENERIC TEARDOWN PHOTO

Taking a closer look at the main PCB, we see all the same components and latch plugs that the other tear-downs exposed. We also get a first pass understanding of the device complexity and it’s general craftsmanship, and in this case the Samsung engineers design stays true to form with a clean and well structured PCB. All the components are well placed and the overall view is aesthetically uncluttered. We can quickly see the camera in the center, as well as the SIM card slot and the battery connector. The large chip below and to the right of the camera is the main slab of NAND Flash on the device. The other components we will revisit after we finish our “lay of the land” exploration.

TOP OF THE PCB

Further analysis of the phone shows the case connections are just as cleanly laid out. Typically there is little of interest on the case and screen sides of a phone, but on the Note 3 we can see a handful of interaction points that drive the screen and touch sensors underneath the PCB. The small silicon on the right (below the headphone jack) is the Synaptics S5050A touch screen controller. If the interest of this project was to manipulate user interaction points, this would be our starting place. Aside from the controller and the pads on the left, there is little on the screen side but dense connection cables, and these tend to be easier to explore on the main PCB.

SCREEN SIDE OF THE CASE, UNDER PCB

Our last view of the entire PCB will be from the bottom. This is where our main SoC (system on a chip) is hiding, along with a collection of other interesting components.

Starting with the top left corner, we can see where the PCB contacts the pressure connection pads on the case that I mentioned before. I this were a real project I would eventually explore them with a multimeter to be sure, but my initial assumption is that these simply share power and ground with the screen.

Moving to the top, we can see the 4 pins that connect to the battery when the phone is assembled, and to the right of that is our main slab of RAM followed by 2 sets of RF Shielded components.

BOTTOM OF THE MAIN PCB

If you didn’t notice, I did a bit of “it’s magic” handwaving when locating the SoC (it’s hiding underneath the slab of RAM). We know this because we googled the device and ChipWorks already discovered this for us and they tell us it is the new Snapdragon 800 (MSM8974). Had this not ben the case, I would have to start desoldering components looking for Qualcomm silicon. While cleaning a PCB of all components gives me great joy, this phone was a present and I’d like to at least boot it once before we kill it, so we will take the ChipWorks finding as gospel for the time being.

So far, our analysis is far from special or unique. iFixIt delves to this level trying to help people fix or replace broken components on a phone and ChipWorks delves a bit deeper looking for new hardware and trends in the engineering space. At this level, we also diverge, but our path is to catalogue hardware interaction points and to explore the PCB for potential debug interfaces.

Jumping down the stack a bit

Now, before we delve much deeper, it’s probably a good idea to spin up a quick vernacular, especially if you are not experienced in hardware. First, modern PCBs are typically dense and multi-layered. As such, a simple visual inspection is not always going to grant you 100% understanding as we can’t see internal sandwiched layers from the top or bottom. Phones and high end consumer electronics are especially dense, while more esoteric hardware still tends to be dual layer (top and bottom only).

When wanting to connect a trace between layers, a via is used. These are simply the “dots” you see from visual inspection and they generally mean that a trace has jumped to another layer (though they can be use for other things as well, like pulling a reference voltage or ground signal from a different layer).

Lastly, when PCBs are being mass produced they need to be tested prior to deployment. While a multitude of options are available, the majority of devices we look at in the real world still support the concept of a “bed of nails”. <insert google image search results here>. This concept basically means that interesting or problematic areas of the board have testing points exposed on the outer layers of the PCB so that an external testing machine can quickly validate them on the production line. Furthermore, my favorite hardware designers tend to expose debug functionality with these interaction points to allow for firmware and OS flashing post production.

Now that we are loaded with a simplified lexicon, we can delve a bit deeper into some closeup photos of the SM-9005 board.

The first thing I notice upon glancing at the PCB is the bed of nails pads lying about the board (these are the copper / gold circles in the below picture). If this wasn’t a Samsung device and I had not spent countless days tracing prior hardware revisions of these pads, I would be really excited. I’d immediately start tracing the pads with a multimeter and tapping them with a logic analyzer to explore what they are exposing. Given the target though, we will wait on that task until the S102A analysis (where I expect much more interesting results).

BED OF NAILS PADS AND CABLE SEAT

The other thing to take note of in this picture is the wonderfully large spacing of leads off the ribbon cable seat. These pinouts, while still fairly tight and small, are spaced far enough apart that latching with a logic analyzer to watch all the data pass over the cable is an approachable task and much easier than tapping the cables directly. If we cared about PCB to Screen interactions, this would be our starting point.

While we will disregard the bed of nails pads because I’ve explored Samsung phones in the past and know better, I do see something on the board that makes me second guess that  decision. Below, you will see a collection of unpopulated pads that are designed to seat standard capacitors and resistors. Seeing these gets me quite excited, especially because some of the traces end in nail pads as well.

You will rarely see PCB layouts with truly unused components, everything about physical hardware is about tradeoffs between space, cost, usability and mass production. Engineers don't simply design and produce extra unused pads as a rule, so if they are on production equipment they probably have a function.

UNPOPULATED PADS

In reality, these are probably laid out to support the different hardware variants that Samsung utilizes around the world. In this manner, the designers can lay out a single PCB and mass produce it instead of full redesigns for each variant of the hardware that is to ship. The factory would then populate the board with different component sets depending on whether or not the phone was to be an AT&T LTE device or something else.

Aside from the logical, these pads could expose something immensely more interesting: hardware debugging and firmware manipulation. At some point in production, the device must be loaded with software and most common SoC vendors protect that functionality with a series of hardware flags controlled by resident voltages. In this case, I would start tracing the pads with a multimeter to see where the missing discrete components would effect, and what circuit they could complete if bridged.

We have seen hardware of a lower mass production scale where through hole resistors were utilized to open the SoC for firmware debugging and then simply clipped by hand before the final device closure and shipment to customers. If my target was to acquire Qualcomm firmware or debug the resident NAND, these pads would be my starting point. Further enticing me along this path is the mysterious pads exposed directly next to the SoC / RAM stack (as seen below).

PADS ALONG THE MAIN SOC / RAM

Final Thoughts

While we’ve meandered around a bit without real focus, I do hope I’ve explained a bit about what I look for in a teardown and what excites me to see. If this were a real engagement to find security related issues on the Note 3, I would be tracing all the pins and attempting to recreate the full PCB schematic. I would then acquire spec sheets for every piece of silicon I could and start looking for debug or flashing capabilities. The main focus of this part of a hardware analysis is to plan an attack to grab the resident firmware and the Note 3 exposes a couple of paths that while probably dead ends are none the less worth running down.

We would also explore the USB side of this hardware and obviously look at the driver/os/kernel as well, but I think I’ll save those walkthroughs for an easier device and another time / blog post.

Thanks for reading,

m0nk

if you have any questions, please email us or find us on twitter @m0nk_dot / @Atredis

What I talk about when I talk about Hacking

Most of the security industry (which I find myself an ever-increasing part of these days) seems focused on the end goal of "popping a shell".

I've honestly never cared about this end goal, it is but a single step in the process for me, a sign of being one step closer to the finish line. In and of themselves, shells and exploitation are simply tools for playing a much more interesting game. I want to understand, I want to play, and I want to break things because I think that facilitates learning.

I abuse the Linux kernel because I think it's a fascinating bit of machinery. I want to take it apart and rebuild it just as a student mechanic would a car engine. I want to find logic flaws in things like NAND flash, not to make fun of the engineers, but to understand why it works the way it does, and map all of its limitations.

I would urge others to do the same, to stop sprinting to the supposed finish line and start really learning the platforms you are exploring. We, as a general rule, spend our days pointing out small (but important) problems in highly intricate and beautiful machines. People on the other side of the fence have spent months or years building and designing these platforms only to see us tear down the house of cards with little regard. We tend to be the proverbial bull in the china shop sometimes. 

Once you start exploring the logical and theoretical constructs that all of our machines are based upon, from laptops and smartphones to embedded and SCADA devices, you can move from the world of single-point exploitation to a mindset of questioning real limitations. This will not only grow your intellect, it will inject a deeper context into what we all do and how we do it.  It can move your toils from a quick and dirty PoC into a truly marvelous exploit, one that is both much harder to patch, and much more helpful to those that truly want to make their products more secure.

Personally, I have found that business and manufacturing-based design decisions can lead to some of the most interesting logical conundrums we face as consumers and users of these devices. Scaling issues in particular are an interesting subset often at the root of our problem space. I hope you wouldn't berate or belittle an architect for designing a house whose structural base could not support 100 stories when the initial request was simply to build a single-family home. That requirement wasn't the original goal, it wasn't designed with those stipulations in mind, and thus the foundation simply wasn't engineered to support that scale. 

In software development and engineering, innovation at the edge can quickly burst past the constraints of the original design (this is a huge problem, of a different nature) and things that once worked perfectly become rife with new and unexpected problems. These problems tend to be exploitable with a quick and dirty PoC, sure, but they also tend to be based on a slow and logical progression of some proud engineer's beautiful baby getting bigger and bigger. 

If we can understand a target platform as well as the builder, we can follow that mindset and find the underlying thread that opened the surface for attack. Unlike our quick and dirty PoC, a better exploit coming from a deeper understanding tends to be highly reusable across targets, as it is really an exploit against how developers were trained to think about problems in the first place. It all circles back to unforeseen consequences of very logical decisions. The machine does not change, but the context has shifted immensely when products go to market and attempt scale.

It is also, in my opinion, a worthwhile endeavor to understand the business mindset that drives our targets. Comprehending the driving factors that pushed a platform into your willing hands also lays a blueprint for your path to controlling it. Some companies put more effort into protecting their intellectual property than they do in protecting their users' data, while others do the opposite. Understanding this, as well as other corporate design cultures, will help you craft your plan of attack, be that plan to help the company be more secure or not (depending on what colour of "hat" you "wear" -- yet another rambling topic covered ad nauseam elsewhere). 

I am in no way saying exploitation itself is easy or boring.  It is a highly complex and truly fascinating subset of the process. Anyone who has explored ROP payloads (and stopped long enough to look) knows they are a truly remarkable and beautiful construct mixed with an old school Punk Rock mentality of Xacto knives and duct tape (cut, splice, reuse your environment and build something new and epic). I do enjoy exploitation and find my personal skills adequate to the task. I am simply stating that it is one part, and not the whole, of the activity. Not a goal but simply a stage.  My goals have always been to learn and improve, not to simply script and pop, but I guess that is clear by now.

In closing, please don't always just rush to a shell.  

Slow down, learn and actually enjoy where the path takes you. Getting to a shell is simply getting back to a place of comfort and understanding. It can be a great tool, but it can also be a crutch of stagnation. Instead, take some time and learn the system.

So let's take one more second and define “hacking” in this construct.

Hacking (n): (in our context) "The exploration of the delta between the artificial design boundaries and the hard physical boundaries of a machine, with the intent of harnessing that information for extracurricular computation"

Hacking(n): (in the human context) "The moral obligation to question and test authority and constraints as they relate to complex systems"

Thanks for the read,

m0nk

Thanks to Enrique A. Sanchez Montellano, Valerie Leige, Sergey Bratus and everyone else who helped me craft this diatribe. Next time I blog, I promise it will be about actual intricate machines and not navel gazing the community.