[Dailydave] The dream of the LISP machine is alive in the 90ies

[the grugq]

inline...

I like to think I'm as good an armchair philosopher as anyone else that
> watched that first season of True Detective.
>
> So let's talk about data as code or, more generally, input as
> influence.
>

Attacking information processing systems is what I’ve been researching for
the last few years. The only way to create propaganda or implement
deceptions is if you have a model of how the entity processes data. Once
you have that model you can craft information that will force the entity to
respond in the manner you chose. This is the theory anyway. There are a lot
of details about how to ensure that the target receives only spoofed
signals with your malicious data, and never receives real signals (probably
via a channel that you can’t spoof down, or that you didn’t know existed.)

The Russians call this reflexive control. The British called in deception
and psywar (even sikewar). The Americans called it “that stuff that those
cheating bastards do” (America has generally been terrible  at subtlety).


> Halvar has always been great at formalizing the intuitions of a
> certain generation of exploit developers.
>
> His ideas about programming the weird machine harken back to the
> operating paradigms of the LISP machines of lore, but in a way also
> formalize a class of thinking that is fundamental to not only exploit
> development, but input based influence on algorithmic processes in
> general. I would posit the concept extends far beyond the realm of
> computing. Team Russia is programming the weirdest machine ever right
> now and to astounding effect.  Treating an entire populace as a
> programmable entity through orchestrated manipulation of its
> information sources.
>
> Input as influence.


Your thinking is correct. I’d suggest reading The Decievers.

The whole topic is fascinating at fractal levels. Done properly deception
(or propaganda) is about the playing the player, not the game. The game is
just the implementation, but controlling how the other side thinks improves
your own position by controlling what strategy they implement.

Below here is some stuff about computers...


>
> I don't know if algorithmic process actually means what I think it
> does. I got the Knuth boxset, but mostly because Amazon had that
> pricing glitch on it way back when. In fact I got two. One for me, and
> one for a friend. He, in fact, did read all of it. We lost touch
> because he's insane, but I think he's out there in the world somewhere
> doing things more productive than porting PaX to MIPS these days, or


MIPS and the inability to set a NX bit fuck me off no end.


> at least I hope he is. I'd like to think I had some small part in
> that. Or at least that me and Jeff Bezos together, did.
>
> Tangent aside, having a novel thought on exploitation is hard. Heck,
> having a novel thought, period, is hard. Hive mind and all. Halvar
> would probably be the first to tell you that a lot of what he's saying
> is a mere representation of a certain zeitgeist.  Not in the least
> because he's German and Germans say things like "zeitgeist". That and
> "schitzel".
>
> But what you perceive as hard is relative. Generally a result of
> context, experience, repetition, intuition, aptitude, and whether or
> not someone actually told you something was hard to begin with.
>
> It's about having insights that simplify your understanding, and
> carrying those insights forward into ever more intricate layers of
> what it actually is you are doing. Abstraction as
> simplification. Collapsing large ideas down into building blocks. Most
> of those ideas probably aren't your own. But it's hard to be novel, or
> so I hear.
>
> Sometimes all it takes is a simple context switch.


A change in perspective is worth 80 IQ points.


>
> I remember when I first started looking at heap corruption as a kid
> and, growing up in a small Dutch village in the 90ies, my access to
> formal computer science resources was pretty limited. I had an old
> beat up copy of K&R and I knew some assholes on IRC. That's about it.
>
> Over and over I'd juggle logical vs physical representations of memory
> layouts in my head. I remember looking at something as simple as an
> unlink operation, and all the pointer dereferences would just not
> stick without me having to look them up constantly.
>
> For a while I just committed entire chunks of the allocator algorithms
> to rote memory. Writing down the parts that were relevant to the
> primitives I cared about over and over. That worked fine. I was never
> a Dvorak or a Scrippie, but I was stubborn, angry, and obsessed with
> problem solving. Enough to get the job done.
>
> Unlike the Germans, the Dutch don't say things like "zeitgeist", but
> we do say things like "schnitzel".
>
> Anyways, one day instead of trying to treat my brain as a glorified C
> compiler, I just started visualizing the ideas behind what it was I
> wanted to do.  Imagining a chunks as just buckets of data that I
> either fully or partially filled with liquid I controlled, coloring
> the logical and contiguous memory layouts in my head accordingly.
>
> Then it became easy. I mean you still had the implementation details
> of whichever allocator you're dealing with obviously. Sizes here,
> pointers there, bitmasks up and down. But that's just typing on the
> keyboard. That's stuff you SHOULD look up by reference. Concepts and
> big picture understanding are things you should be able to juggle in
> your head.
>
> And at the risk of fetishizing Halvar quotes to Dave Aitel levels, I
> remember his original quests to visualize all the things because
> "humans are designed to recognize the shape of the animals they hunt,
> and turn them into schnitzel, not stare at numbers". I paraphrase.
>
> Our generation of hunters just happens to track game around
> allocators, kernel surfaces, and logic flows.
>
> Of course they teach you that stuff in week 1 of most programming
> classes. Linked lists operations that is, not German hacker
> philosophy.
>
> But I'm in my teens in a country side village in the east of
> Holland. The closest thing I have to a computer science curriculum
> revolves around people messaging me on IRC about how I should really
> start grepping for syslog(3) calls that don't have quotes in them. The
> closest thing I have to philosophy classes are Scandinavians preaching
> about the gospels of non-disclosure. A potent recipe to build weird
> minds, really.
>
> Halvar things aside, I think that is the difference between someone
> that looks at e.g. the V8 codebase and is like "oh Christ that is
> entirely too much C++" and someone that, in a fairly pragmatic
> fashion, just identifies where data is input, how that data is acted
> upon, and how the algorithms acting upon that data are influenced by
> said data.  The ability to visualize, collapse, and abstract whatever
> does not matter to the problem you are trying to solve, away.
>
> Unless you're a fuzzer of course, in which case I harbor some weird
> late-90ies resentment towards you that is based on nothing but
> spending too much time with a generation of hackers that read "fight
> club" like it was the only thing available after eating some bad
> chicken.
>
> Hard is relative. We dance the same dance over and over again in a
> hall full of ghosts of exploits past. I am Jack's haunted ball room
> picture.
>
> One of my old friends who is probably one of the best exploit
> developers I've worked with, never went after "hard" bugs. He just
> found what he referred to as "simple bugs in hard to reach places".
>
> That is a powerful concept.  If you're willing to dig deep enough,
> shovel enough reverse engineering work, go deeper into the coal mines
> than anyone else before you, chances are you will win. I mean you
> might have black lung by the time you do, but still.
>
> Of course one of my other friends is the exact opposite and he insists
> on finding ridiculously complicated bugs in simple places.  I think it
> kind of depends on what you're after. These days with the Google borg
> spinning up trillions of cores and Google bucks to fuzz input into
> whichever surface they can get their grubby little hands on, I'd tend
> towards simple bugs in hard to reach places.
>

Culture beats strategy.


> Having said that, beyond code isolation, rapid advances in branch
> coverage by modern fuzzing approaches kind of moot both. But, it
> appears that anno 2019, someone can still comfortably sit on a pile of
> 0day in the same code bases that everyone else is fuzzing CVE's out
> of.  What is today's CVE if not yesterday's 0day?
>
> It's probably some intricate dance between code flux, bug density,
> surface exposure, and whether or not there's a strategy behind the
> effort beyond "this is what Tavis felt like auditing this weekend".
>
> Most of computer science is this weird struggle to emulate our own
> biological processes either consciously or subconsciously.  It makes
> sense because it's the only way we know how to solve problems,
> perceived or otherwise.
>
> Our problem solving paradigms are based on our biology. Collectively
> pushing towards an understanding of the world through the filter of
> being a part of it. It's hard to stay objective, if objective even
> exists.  Consensus based reality is probably the best you can hope
> for.
>
> But with the right inputs, it would appear you can influence almost
> anything to the point of control. Programs, people, society ... and,
> perhaps, maybe even reality itself.
>
> It's 7am. Time for work.


It’s 7am, time for sleep.

Cheers,

—gq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20190216/c3674768/attachment.html>