Month: June 2021

“Superstition is the tribute paid by ignorance to knowledge of which it recognises the value but does not understand the significance.”

Dion Fortune, Sane Occultism

If you have read my previous post on magic as hacking, you may find yourself persuaded by the similarities between the two activities, but asking yourself where exactly that leaves you as far as putting the information into action.  A set of techniques or processes gets us only so far as the use cases they were developed for:  continuing to slavishly rely on them in circumstances they were not intended to address seems superstitious at best (using Dion Fortune’s definition above), and potentially ineffectual or counterproductive at worst.  Nor does it help to understand what the tactics are unless you can also have some insight into where (and why) these can and should be applied.  With that in mind, I’ve been spending my time lately considering what a methodology would look like if we are to approach magic together in this way.

Why methodology?  Because without it, you’re sunk.  As a fledgling hacker, you don’t have the real-world experience to know what the paths of least resistance are likely to be, to know what techniques are likely to work, or what threads are worth pulling on and which are more trouble than they’re worth and likely to bear little in the way of fruit.  That wisdom is gained only with time and experience, and no matter how experienced one becomes there’s always more to learn.  There’s also more to forget, which is why methodologies help experienced professionals just as much as they do inexperienced novices.  It isn’t sufficient to bang blindly on the door when the person behind the door is expecting a password and a secret handshake.  You need a method, or what you’re left with is just madness.  Techniques and procedures give you tools to open the door, but in order to know how to open that door effectively you need a way of determining which tool to use in a given situation.  You need a methodology.

In order to apply that methodology, however, it all begins with intent.  This is step zero.  In the real world, criminal hackers don’t just break into systems for the thrill of it:  they have motivations and operational goals.  And while a computer’s attack surface may be finite, when you’re talking about an infinite playing field the arena is equally unbounded.  Like a threat actor, you need to be clear about what your goals are when it comes to doing a particular magical working.  While the playing field may be infinite, our human time and energy and attention is not; so this clarity of intention is necessary to provide the focus you need to start scoping out the problem you’re attempting to solve–even if that problem is messing around with some variable (e.g. astrological timing) simply for the sake of determining what you can get away with.

After you’re clear on your goals and intentions, the first phase of the work is recon.  In order to leverage a particular attack path, hackers will generally look at what tools or techniques are out there in order to achieve the goals they have in mind.  The first part of this process is surveying the field to find preexisting tools and to better understand the problem at hand.  Research may or may not be your favorite thing, but proper research can greatly enhance your understanding and thereby the efficacy of your practice.  With this in mind, research your topic.  How have others historically approached this or similar problems?  Gather together your sources of data and compare them.  What commonalities stand out?  If different people across different periods of time, and especially across diverse cultures, have used similar methods this can generally be used as a heuristic to infer that the methods have proven effective.  That said, today’s world is very different from that in previous centuries, and we cannot take this assumption for granted.

The second phase of the methodology is reverse engineering.  Assuming you have found relevant tools and techniques in your research, dive into them to better understand what makes them work.  Examine the methods and approaches, looking less at the particular forms (which are like the raw source code of a program) and instead paying attention to how they are intended to function in order to achieve the desired results.  This part of the process is what transforms the raw data of history into information, and finally into insight.  But don’t mistake this insight for understanding:  insight can be had in the realm of theory, but understanding can only come from experience.

The third phase is execution.  Now that you possess some insight into the subject matter, and have a menu of techniques to choose from, take one of those procedures and try it.  Alternatively, adapt pieces of different procedures to assemble a set of functional “code blocks” which work together in a cohesive manner to serve the intention you have in mind.

Fourth comes debrief.  Observe the results of your working.  Did you get results?  Did you find anything about the outcome surprising?  By examining your outcomes, especially with respect to anything unexpected that comes up, you can begin to identify assumptions that may be worth testing and identify threads to pull on in the future.

Finally, experiment.  Adjust your methods and/or your hypotheses, and try again.  There’s no substitute for experience, and practice makes perfect.  Consider your failures as valuable as your successes, because they provide you with opportunities for learning and growth.  Challenge your assumptions.  If your workings get results, see how far you can bend the procedures and methods without breaking the efficacy of the working itself.  Be persistent and keep trying, until you can determine with some degree of confidence that you’ve found something which works for you, or until you’ve determined that the approach you’re trying is simply not viable enough to bear further experiment.

Just like an exploit program, you can’t necessarily guarantee that everything will run smoothly the first time, even if you do everything right.  You may be looking for results, but you’re also looking for data.  And should all else fail, you still have a data point.  Again, be persistent in trying to obtain results.

Finally, this should go without saying–but once you do find something that works, let it work.  That doesn’t mean you stop experimenting, but turn your focus to a different problem.  Relegate the solved problems to the realm of play, where you can continue to make discoveries but are spending the majority of your attention on the areas that are going to gain you the most beneficial experience.

Reality Hacking Methodology

    0.  Clarify Goals & Intentions
    1.  Reconnaisance
    2.  Reverse Engineering
    3.  Execution
    4.  Debrief
    5.  Experimentation

We look hard
We look through
We look hard to see for real

Sisters of Mercy, “Lucretia My Reflection”

Inspired by my recent conversation with the delightful Erik Arneson, I decided to take some time and write up a more cohesive set of my thoughts on the interrelationship of magic and computer hacking.

Prefatory note:  “Hacking” is a very broad term, which covers not only intrusion into computer systems, but also their defense, engineering, and an entirely vast array of non-computer-related tinkering, making, and puzzling.  Here, however, I’m talking specifically about the offensive side of hacking:  the approach to breaking into computers and networks.

In my day job, I’m a professional computer hacker.  I work on an internal red team, which means that I’m paid by my employer to break into our own systems before criminal threat actors can do so, and serve as a sparring partner for our network defenders.  In recent years I’ve seen a great many parallels between hacking and magic, and ways in which the former can inform the latter.  In doing so, I’ve also found myself viewing magic through the lens of a hacker more and more frequently.

By and large, my experience is that most people who become magicians are drawn to it by a common set of motivations.  We are people who are drawn to understand why and how reality works, and who have glimpsed beyond the common assumptions to know that there are secrets waiting to be discovered.  Those secrets captivate us, and we want to uncover them.  We see a closed door, and we want to know what’s behind it.  When the door is closed to us, we can choose to walk away–or we can start learning how the lock works and figure out how to pick it or otherwise bypass it so we can see what’s on the other side of that door ourselves.

Hacking is no different from magic in this regard.  In both cases, we want to dig beneath the assumptions to see how things actually work, regardless of how we think they’re supposed to work.  We find threads to pull on, we explore, we investigate, we play with the puzzles.  And with a certain amount of skill and luck, we can leverage our findings to give us the ability to do things we would ordinarily be unable to do otherwise.

Hacking and magic are, at their core, both systems of control.  They are both pursuits which involve approaching a system that appears to have a consistent set of rules and behaviors, and then trying to break those rules (or otherwise circumvent them) in ways that serve to our advantage.  And in both cases, the systems that we are exploring have seemingly denied us access.  When hacking computers, these can be access controls (like not having a valid password, or not having the right permissions to get at the data we want); or they can be technical limitations, such as having to figure out how an unknown program communicates over the network so we can learn how to speak with it.  In the case of magic, we are trying to achieve goals and accomplish effects that appear to be otherwise impossible given what we understand of the world around us and how it works.  Through magic, we attempt to exert some agency and gain leverage in order to achieve our desired effects.  Similarly, hacking is also fundamentally about control.  In both cases, the universe appears to tell us “no”, and we aren’t prepared to accept that answer.  So instead we go digging, we research, we experiment, and–like the velociraptors in Jurassic Park–we test those controls which appear to lock us in place.

The key in both cases is experimentation.  You can research and study works of magic all you like, but that isn’t the same as actually doing magic.  You can read as much as you want about the offensive uses of PowerShell or Python, or how to exploit a vulnerability in a piece of software, but doing so doesn’t make you a hacker.  For both the magician and the hacker, it’s putting that knowledge into action that defines the pursuit.

I recently had the pleasure of being interviewed by Erik Arneson, host of the outstanding Arnemancy podcast.  We had a delightful conversation on the relationship of magic and computer hacking, the esoteric uses of cryptography, and a great deal about the philosophical underpinnings of magic–including some of the big questions that arise when you begin to explore the nature of magic itself.

Mercifully, we did not talk about the Kybalion.

Big thanks to Erik for having me on the podcast!

Listen now:  Anything but the Kybalion

 My friend Taylor Bell recently interviewed me for the Green Lion Podcast, in a two-part episode.  I always have great conversations with Taylor, and it was a lot of fun to record this one together.  We dig into the weeds of magic, Forteana, and all things weird and wonderful.

Interview Part One

Interview Part Two

Recently I had my first podcast interview, on Projeto Mayhem.  Watch as I get tag-teamed by Marcelo del Debbio and Andre Descrovi about the Kybalion, one of the most controversial texts in modern western occultism.  Thanks to both of them for having me on the show and for the thought-provoking questions!