Zines/phrack/69/2.txt

                              ==Phrack Inc.==

                Volume 0x0f, Issue 0x45, Phile #0x02 of 0x10

|=-----------------------------------------------------------------------=|
|=------------------------=[ PHRACK PROPHILE ON ]=-----------------------=|
|=-----------------------------------------------------------------------=|
|=------------------------=[   Solar Designer   ]=-----------------------=|
|=-----------------------------------------------------------------------=|

|=---=[ Specifications

          Handle: Solar Designer
             AKA: solardiz.  Also, I used to hide under my real name.
   Handle origin: A turn-based game played over FidoNet (which IIRC I
                  played just once, but it took a while), and demoscene.
                  In 1994, I needed a handle to register on "private"
                  BBSes where real names were discouraged.  I chose this
                  one without giving it much thought, and it has stuck.
Age of your body: Older than Pushkin
 Height & weight: Quite some & not much
     Produced in: USSR
            Urlz: http://www.openwall.com/phrack
                  I imagine it will be gone when a historian reads this
                  many centuries later.
       Computers: B3-21, MK-52, (no longer have my EC-1841), 386DX40+387,
                  2x MicroVAX 3100-80, 2x Sun Ultra 5/10, Alpha 164SX (and
                  I had a 21066-based Multia for a year before), HP 712/80,
                  development boards (ZedBoard + Epiphany FMC, many ZTEX
                  FPGA boards waiting for their use), routers, etc. (the
                  EdgeRouter Lite is MIPS64, runs FreeBSD, and is used for
                  general development, so surely qualifies as a computer?)
                  HP200LX, Nokia Communicator series (9110, 9300, N900).
                  Lots of semi-ancient x86 (e.g., dual Pentium 3, RIMMs)
                  and many x86-64 (some laptops, etc.), some of which are
                  frankly what I actually use these days.  Some GPUs and
                  Xeon Phi in boxes we've setup for the larger community.
      Creator of: I'm the original author of most of the individual pieces
                  of software released under Openwall, including John the
                  Ripper password cracker and Linux 2.0.x to 2.4.x -ow
                  security hardening patches (now historical).  Openwall
                  GNU/*/Linux distro, with a team.  More recently yescrypt,
                  with 1.0 release planned in 2016.  Assorted programs for
                  DOS in a previous life, including (but not limited to)
                  "software protection" and cracks.
       Member of: Back in 1990s: BPC, uCF; I also participated in w00w00.
        Admin of: Openwall.  We host some moderated mailing lists, etc. -
                  including e.g. oss-security and kernel-hardening, and
                  also including the private distros list (which sort of
                  replaced vendor-sec and those predating it, and which I
                  always have mixed feelings about).  That's already-public
                  info, and it has to be such, so no OPSEC fail here.
        Projects: Most of those currently active at Openwall.
           Codez: You mean stuff that is of more hack and historical value
                  than of direct use?  I am often reminded of those first
                  ret2libc exploits I sent to Bugtraq in 1997.  I'll
                  mention a few more further in this prophile.
    Active since: 1994?  I was not into "the scene" before.
  Inactive since: 1997?  I no longer release under a group since then, so
                  maybe not on the scene either?  Besides, we got a
                  CFAA-alike in Russia since 1997, limiting the playground.
                  That said, I was doing computer stuff before 1994, and I
                  still am now.

|=---=[ Favorites

   Actors: Not really.  I think screenplay matters more.  I recognize some
           screenwriters and directors like Gilliam and Zemeckis.  Oh,
           actually, let me agree with PaX Team's answer here - Chaplin -
           as this is consistent with what I just said.
    Films: I can't pick just a few favorites, but I was relieved to find
           out that The Shawshank Redemption ranks so high on IMDB.  Maybe
           the humanity has hope (or at least IMDB reviewers do).
  Authors: I really would rather not name just a few, or I'd later regret.
           (I already almost regret mentioning just some directors above.)
 Meetings: What's meant to go into this field?  Where to meet?
           Restaurants, cafes, bars without loud music (unless
           intentionally attending a live performance).  I'd also consider
           meeting at a hackerspace.  I rarely meet people in person,
           though.  To compensate for that, I really like it how there are
           now two practical ("non-paper") computer security cons in Moscow
           per year - PHDays in May and ZeroNights in November - with
           mostly the local crowd, but always also some foreign speakers
           and attendees.
      Sex: What's the right answer?  Something like y?(+++++++)?
    Books: I'd say encyclopedia.  Now that would be Wikipedia.
    Novel: Sadly, I am not reading much.  If I were, I would probably not
           be able to single out just a few titles.  As a kid, I read War
           and Peace, and I liked it.  (I hear it was also taught in Soviet
           schools, but luckily I skipped that and read it on my own will.)
           More relevant to Phrack readers, I also recall I liked reading
           (in 1990s) Stephen King's The Dead Zone and John Varley's Press
           Enter (OK, that one is too short for a novel, and I had to look
           up who wrote it to refer to it now, but I did in fact like it).
  Meeting: HAL2001 stands out because it was a first for me, and I liked
           its atmosphere and extent.
    Music: There are few genres that I don't recall ever enjoying listening
           to, but I tend to especially like rock, jazz, bossa nova.
  Alcohol: Dark beer
     Cars: No favorite, and not my thing, but some do look stylish to me or
           have a history or fiction attached to them (such as the
           DeLorean, which apparently wasn't that good a car otherwise).
           I also value the designers' achievements.  At a local retro
           sports car exhibition last year, it was interesting for me to
           see how greatly the horsepower per cc and torque per cc improved
           over the years, and how a few custom engines stood out.  It's an
           optimization problem not entirely unlike what we have in
           computing and communications, where some designs were also
           "ahead of their time".
    Girls: Not between Cars and Food
     Food: Italian is usually a safe bet
   I like: All sorts of freedom (as long as it doesn't infringe on someone
           else's), free time, good people, nature, (im)perfection
I dislike: Simply inverting the "I like" above would be bad enough as it is
           (except that (im)perfection is its own inverse).
           I'd rather not provide even worse (or better, from adversary's
           POV) hints than that.  Oh, I'll add just one: filling out guinea
           pig forms like this... but who am I to break the tradition?

|=---=[ Life in 3 sentences

Way too little achieved in this much time.  I could do a lot more, but if I
act unnaturally would that still be me?  (Rhetorical.)

|=---=[ Passions, what makes you tick

Curiosity and self-defined challenges (especially if unannounced so they
don't become a drag) combined with whatever else I like.

|=---=[ Memorable experiences

You suggest some questions along the lines of "how did you start?" to be
answered for your readers further in my prophile, so I'll turn this section
into a background story for answering those.  It got rather long (and
off-topic?), so your readers should feel free to skip to the next section
and maybe revisit this one later.  Here we go, with some recalled or maybe
just made up computer and electronics related experiences from 1980s and
1990s roughly in chronological order:

Nearly winning a Darwin award as a kid.  Before I got access to computers,
I was having fun with electrical circuits, and some of those experiments
were not well-suited for a kid nor always conducted with appropriate
precautions.  Luckily, this only made me stranger.  When I was 8, I learned
the hard way that you don't test a hypothesis by assuming it's true and
just letting things go wrong if you're wrong, if "wrong" can mean it'd be
the last thing you'd realize.  If you feel you need to test, you recognize
there's a chance you are (or something is) wrong.  It's just like how you
shouldn't test whether your restarted sshd still works by first logging out
and then trying to log back in - something I still see adults do,
presumably because they were not that close to be Darwin winners as kids.

Playing with Soviet cable radio during a few of the "technical breaks"
(when normal broadcast stopped).  Listening to foreign shortwave stations
(DXing?), including through the jamming (was more tolerable out of town).

Finding near the garbage cans a cabinet drawer with tools (including a
soldering iron), electronic parts, and all 12 of the Soviet "Radio"
magazine issues from 1966.  I guess someone had passed away, someone who
ended up having some influence on me.  (Later I actually built and briefly
tested an 80 meter band transmitter described in one of those issues, based
on two vacuum tubes, but I never got into ham radio.)

Fast arbitrary precision division (typically 5 digits per iteration),
writing down some 100+ digit periodic sequences, which felt like magic
(will this thing repeat after N-1 digits again? oh yes it does), on a
non-programmable 8-digit calculator.  I came up with the algorithm on my
own.  I didn't know the word "algorithm" back then, nor programming.

Exploring and eventually programming my father's B3-21, with great fun.

Getting some written-off Soviet mainframe boards with K155 series TTL chips
on them (equivalent to 74 series), mostly K155LA3 (7400).  Luckily, a book
on those just happened to arrive to a nearby bookstore, so I started
building my own logic circuits.  I recall craving for more K155TM2's (7474,
dual D flip-flops), which were lacking.  I ended up desoldering a K155TM2
from an expensive toy, which I was done playing with, to build my own toys
with the flip-flops.  In general, almost all of the electronic parts I was
building circuits from had been previously used.  You couldn't just go to a
store and buy parts that you needed when you needed them.  For example, I
didn't have enough LEDs, so I used transistors and bulbs to indicate logic
levels like if it were 1960s or 70s.

Since 1989 or so, having sporadic time-limited access to BK-0010 and a
variety of x86 ranging from different PC/XT clones (with green phosphor
CGA and Hercules monitors) to early 386+287 (with early vendor-specific
SVGA) and then even the super fast & pricey 386+387 33 MHz.  (I think 486s
were still subject to CoCom export regulation.)  There was also a Japanese
24 pin dot matrix printer capable of up to 360 dpi, with a decent user's
manual on its escape sequences, so I actually printed graphics in 360 dpi
on it, multi-pass and very slow of course.  My own vector font, too,
created in my own font editor.  Not having much time to debug code on the
actual machines, I initially wrote programs on paper and debugged them
mentally, then typed them in and they had to work right with only minor
changes needed.  (This skill later proved especially helpful for firmware
modification, as well as for exploits.)

It's during this period that I learned 16-bit x86 asm through reading some
books and a printout of the disassembly of KILL.COM, a ~4 KB DOS TSR
program that allowed a user to forcibly kill the currently active program
and return to DOS, with both this tool and the Sourcer disassembler having
been given to me by a friend on a floppy.  Other languages explored
included: BASIC dialects; Fortran for bringing programs (that my father was
using for work) from mainframes to PC; Turbo Pascal, which worked the
smoothest, but couldn't use 386's protected mode yet (unlike one of the
Fortran compilers, which could).  (A bit later, I wrote a Fortran 66 to
Pascal source level translator that would reconstruct program structure
from all those labels.  Many years later, I migrated some of those Pascal
programs to Linux/Alpha, building them with GNU Pascal, mostly for fun.)
I also briefly started with C in 1990 or so, but soon abandoned it because
of inefficient static linking under DOS (too much dead code).

Back then, and in DOS, the command-line felt like it was being obsoleted by
tools such as Norton Commander (and then its many clones) and Borland's or
Microsoft's recently introduced IDEs for their compilers, but somehow not
for the assemblers, nor for Fortran.  By 1992, I had an own IDE developed
for DOS (yes, first written on paper, piece after piece, and then typed in
during those occasional computer sessions), which had its own text editor
(as well as bells and whistles such as a calculator - but no, exploits
didn't pop it up) and it was capable of running the CLI compilers with
their output captured via INT 10 intercept and analyzed, so it would place
the cursor right at the error line, just like those vendors' IDEs did.  Of
course, it could also run the just-compiled program... and it could kill
it, too.  Somehow I felt this was important enough for me to have bothered
with all this effort (or maybe it was just about the challenge, as usual).
Over a few years, I also worked on other TUIs and GUIs for various programs
(ranging from 320x200 CGA to weird VGA ModeX resolutions and to 1024x768
SVGA under DOS, with my own drivers and my port of Borland's Turbo Vision
from text to graphics modes).  (It's only after I discovered Unix that I
realized I am perfectly comfortable using a compiler from the command-line,
and don't really need IDEs.  These days, I am not using any IDE.  Maybe I
also moved to developing different kinds of software, where IDEs are less
helpful.  I don't oppose to using an IDE again for a right project.)

MK-52 with its whopping 512 bytes of EEPROM on top of these calculators'
tiny program and data memories.  Yeggogology, where you explore the
undocumented world of the calculator trying not to hit the darkness (you
have to power-cycle when you do).

Together with my father, buying our first home computer, the Soviet PC/XT
software compatible EC-1841, from its previous owner, for a full bag of
Soviet 5 ruble banknotes weighing a few kilograms.  IIRC, my father got
those earlier the same day as a withdrawal of a very recent payment (so not
yet eaten up by the inflation), which came for a project I contributed to
as well.  Somehow the bank only had sealed packs of 5 ruble bills.

"Snow" on CGA screens, and suppressing it, or choosing not to - for speed.

Low-level formatting a brand new unformatted 20 MB MFM hard drive (ST-225),
for a neighbor's EC-1845, with a program I wrote for this one occasion (OK,
I cheated - used BIOS calls - but not a do-it-all routine, which I was not
aware of and might not have had in my BIOS).  Tuning the interleaving, too.

In 1993, already on a 386 at home, cracking a key floppy protected program,
using nothing but DOS debug, paper and pencil, many reboots and patience.
Since then and until 1996, I went into both cracking and creating "software
protection" systems - initially naive, then smarter, and eventually moving
from simple code encryption and anti-debugging tricks (eventually confusing
non-patched SoftICE alright through inconsistent opcode and ModR/M byte
combinations, handling those on INT 6) to use of VMs (NOR CPU, reinventing
OISC as I realize now).

A couple of years later, a brief encounter into creating key floppies for
software protection, with arbitrarily-numbered different-size sectors on a
track and some decoys.  A Win16 DLL, written in asm and using Win16/DPMI/
BIOS calls, to check this floppy.  BIOS actually allowed for a lot of
flexibility through temporarily patching the diskette parameter table from
a critical section.  Of course, this was easily crackable in software, but
that was OK for the given project.

Game programming, on all devices ranging from the calculators (for
turn-based games, as the only way to provide input without interrupting the
program was via the radian-degree switch) to computers.  Reuse of ChiWriter
printer fonts for good-looking large captions on screen.  Playing some
computer games too.  Eventually own multi-window graphics/sprite editor,
own adventure game engine (both recently reused in DOSBox for my ZeroNights
2014 keynote game, and as a toy for my son, who ended up adding so many
sprites to his game that he triggered a stack overflow in the game engine).

Getting on BBSes via a 2400 bps modem in 1993.

Getting on the Internet and on Unix in 1994 - and revisiting C programming.
FTP sites, Archie.  Then early web sites, AltaVista.  X.25 PADs, mostly as
a means to get to a system that would have Internet.  Linux kernel 1.2.3 on
my 386.  Playing mouse to retain Internet access and development access to
non-x86 boxes, and getting a bit carried away.  Back then, I didn't quite
realize I was merely playing mouse, with cats out there.  I also didn't
realize not all other players treated this as a game.  I did have other
ways to get online, such as when physically visiting places that had
Internet access, as well as by using single-line dialups that friends set
up in such places, but I couldn't reasonably use them as much as I wanted
to and they were not part of the game.

Implementing DES in assembly for 32-bit SPARC to use double-register load
and store instructions (thus, 64-bit), which the C compiler somehow
wouldn't use.  The fun part was debugging this on x86, as I didn't have a
SPARC at home yet and didn't want to do it all online, so I wrote a partial
SPARC to x86 assembly source level translator to let me get the computation
right before testing and optimizing on a remote Sun machine.  (Later I also
wrote similar DES code in assembly for Alpha, but debugged it on the real
thing right away.)

Longwave (a few hundred KHz carrier) radio transmission experiment from my
resistor-based Covox on the 386's printer port.  I could pick up Led
Zeppelin's Immigrant Song, which I had digitized from an audio cassette at
6-bit 20 kHz mono via a two-transistor comparator on the same Covox and was
now transmitting, on a commodity receiver from a few meters away.  So I
totally reinvented software-defined radio on my own, having no idea it was
already a thing (Wikipedia says so).  Now this could be called an airgap
bypass PoC (or not, since the receiver wasn't a computer), but I didn't
think in such terms back then.  (And yes, I didn't have a real soundcard.)

Audio playback via floppy drive motors (2 signal levels: low on 3.5", high
also on 5.25").  Yes, Immigrant Song again.  It's only recently that I
learned others did this too (there are videos on YouTube), albeit
apparently without the 2-level separation (and instead with multiple
channels) and for sheet music rather than for arbitrary audio recordings.

A brief experiment with blueboxing using the same Covox, with little luck:
the line responded to 2600+2400, but seemingly ignored other CCITT #5
signals.  (Apparently, blueboxing with different signaling worked on
ex-USSR lines, but usually wasn't completely free, and I never tried to get
into it.  Arbitrary dual-tone capability was even included in the Russian
Courier modems, which were different hacks of USR modems.)

USR Courier modem firmware hacking: I put a debugger with disassembler and
breakpoint support right in there, available via added AT commands, just
for fun.  (How do you implement breakpoints when the code is in EEPROM and
the CPU lacks hardware breakpoint support?  By keeping the CPU in
single-step mode while there's a breakpoint set!  Is it still fast enough
for the modem to work, then?  Turns out that for the supervisor CPU, not
the DSP, the answer is yes, although the lag is barely bearable.)

The disassembler I wrote had only 164 bytes of native code (could it be the
smallest disassembler ever written for a complete CISC ISA?), with the rest
(over 2 KB) being data: a special-purpose data structure with arbitrary bit
patterns to match and strings to print, and cross-references for reuse of
common patterns and substrings across instruction groups.  Is this possibly
interpreted code in a domain-specific language rather than data?  "What's
the difference?"  (WOPR's answer in WarGames, could be about code vs. data)

Making mostly non-impressive intros, probably not my thing.  I might have
contributed to the smallest categories appearing (128-byte initially) by
advocating this in a Russian FidoNet group where the first such competition
was then carried out (and where my entry shared second place with another
participant's), with other competitions in these sizes appearing
internationally shortly thereafter (as the 20 intros from the first Russian
competition were uploaded to foreign sites).

Winning a contest for smallest "mkdir -p" implementation for DOS, with a 20
bytes entry: BA 82 00 5F B8 5C 39 31 05 47 AE 75 FD 4F 31 05 CD 21 EB F0.
How does this program terminate cleanly?  Self-modifying code, and moreover
letting the program XOR over itself.  (The contest rules were weird: only
documented DOS features and startup register values, yet OK to require
trailing backslash.  19 bytes was demonstrated possible, and less than that
might be, with reliance on undocumented startup register values.)

Being wrong yet over-confident or/and elitist on some occasions - luckily
not many (that I recall).  Not good of me.

In 1997, joining an ISP (by demonstrating a vulnerability, of course) and
starting to play cat to keep mice under control (but not hurt), as well as
not needing to play mouse myself anymore.  A tiny unreleased exfiltration
detector I wrote at the time was called Tom.  There was also, in modern
terms, a metadata analysis tool for traffic to one of the first social
networks - ICQ, which was extremely popular among Windows users here - to
keep track of abusers on dialup lines despite changing accounts, and even
be alerted when a friend-of-abuser shows up.  That tool I never let
anyone else use, and never released, for ethical reasons.  (Of course, I
was "entitled" to use it, right?..  Oh, excuses.)

On a related note, caller IDs were very common at homes in Russia, starting
to appear in early 1990s.  These were based on inexpensive telephones with
most of their original contents thrown out and replaced by a board with a
Soviet clone of 8080 or with an imported Z80 CPU.  They reused in-band
signaling initially intended for use by long-distance exchanges (with the
caller's line disconnected for a moment with a relay at their local phone
exchange, to prevent spoofing), but technically also available to the
called party on local calls (and easily audible and tamperable with by the
caller, since the long distance call's anti-spoofing relay wasn't
triggered).  Despite of their popularity at homes, they were almost never
used on dialup lines.  Similarly, while some late modem firmware hacks
included caller ID functionality for ex-USSR, those were targeted at
consumers (including e.g. FidoNet nodes) rather than ISPs.  It's only with
the move of dialup lines to digital interfaces (E1) reaching into the ISPs
in late 1990s to early 2000s that caller numbers commonly started to appear
in TACACS+ or RADIUS server logs at ISPs.  Until then, it was cheaper to
extract and selectively log ICQ UINs.

Also in 1997, posting a rough non-executable user stack patch for the Linux
kernel to LKML while running it on my very computer, and being told that it
can't work (because signal handlers, which I had already worked around in
the patch I posted, and gcc trampolines, which I had not encountered yet
due to libc5 rather than early glibc).

The ISP's chief sysadmin's reaction when I casually mentioned that my Linux
kernel patch we were about to install on the servers had just started to
use ring 2, in addition to 0 and 3.  (We did install, and it worked great.)

Apparently, forgetting my childhood Darwin lessons and letting a coworker
at the ISP flash my modified firmware (fixing a connection stability
issue) into all 16 of the modems in a Total Control unit without
power-cycling it after the first flash... and getting the checksum wrong.
Oops.  (The modems then worked fine until power-cycle.)  Luckily, recovery
was as easy as for the individual Courier modems, so not a big deal, but it
did cost some downtime for those 16 lines (there were many more already).

Tweaking L2 cache timings of the dying Multia to prolong its life, having
read up on 21066's "internal processor registers".  Then returning it to
its owner and buying 164SX+21164PC of my own in 1998, and tweaking L2 cache
timings via 21164PC's different IPRs the other way for speed (years later,
my tweaks would turn out to reliably result in a specific miscompile when
building our Linux distro, Owl - oops).  Tweaking a Modeline for 2000x1500
on a 21" CRT (worked, but was painful to look at because of low refresh
rate; I actually used 1600x1200).  In general, tweaking lots of things.

Finally playing with VMS on VAX a little bit (and VT420's, with yellow
phosphor for a change), including e.g. mounting a filesystem from tape -
something normally not possible on Unix where tape drives are character
devices.  DECnet between Linux and VMS.

This brings us almost to 2000s.  I'll cover some of the newer stuff below.

|=---=[ Quotes

I have no favorites, but I find these relevant:

"Is this a game or is it real?"  (WarGames)

"If you shame attack research, you misjudge its contribution.  Offense and
defense aren't peers.  Defense is offense's child."  (John Lambert)

|=---=[ What's your opinion about Phrack?

I was about 10 years late to the party.  I think I got my hands on a pack
of Phrack issues for the first time in 1994 or 1995.  Phrack has been
changing: it had already changed by the time I first saw it, and it has
changed since.  I think that's fine.  It doesn't need to revert to the
US-centric phreaking/anarchy zine of 1980s, nor try to play the same role
that it did in 1990s now that there are many other alternatives.

Over the many Phrack issues so far, it captures diversity and evolution of
the underground.  The diversity just among the people prophiled is of such
extent that on one hand they don't quite fit (e.g. I'm mildly offended to
be prophiled after certain other individuals had been some issues before),
but on the other that's how it is in life.  Similarly, the philes range
from utter crap (luckily not much of it, such as the uncalled-for ridicule
in the Loopbacks) to inspirational or capturing the diversity of scene
spirit or (lately) opinions on the scene dying (or maybe not), and to
quality technical content (a lot of it).

Of course, opinions on what constitutes utter crap vary.  For some of your
readers, much of what I wrote above will be whitehat crap (ethics huh?) or
just off-topic (historical software development thoughts in Phrack, huh?
where are all the sploits? yet that's the balance I preferred, as the
prophile is on me and I'm not only into (in)security and colored hats).

As I don't worship Phrack, frankly I've actually read or even skimmed over
only a minority of the issues/philes.  With my Issue #53 article and this
prophile, I've probably already spent more time writing for Phrack than
reading it.  As a Soviet joke goes, I'm a writer and not a reader.

|=---=[ What you would like to see published in Phrack?

I like good people and quality content, but I realize that the diversity is
also what makes Phrack valuable as what it has been so far.

So the diversity should be preserved, albeit not to the extent where us the
"sensitive whitehats" (really, even with some of the risque fiction I wrote
above?) or them the "terrible blackhats" would refuse to contribute to
further issues.  Of course, I don't mean these labels literally - as FX
said and I agree, undef($hat); - oh and Perl is fine with me, but I do
think the editors need to strike a balance between whatever there is.

|=---=[ What do you think is the role of Phrack in the current "scene" that
        is dominated by "cons"?

Phrack is in fact less important now that there are so many other ways to
share one's experience, research, or rants - and by far not only at cons.

What I think Phrack may continue to provide is perspective over an extended
period, including via these prophiles, as well as by soliciting and
selecting for publication articles that are of longer-term relevance.

|=---=[ Who or what inspired you to start hacking?

Friends have helped introduce me to things, and conversely I made friends
while doing things.

Technical challenges.  Curiosity to explore.  Exposure (and addiction?) to
the networked world beyond local BBSes, and survival (will I be on the net
tomorrow?)

|=---=[ We know that no one will ever admit he's part of the underground,
        but, when and how did you enter it? :>

What's underground and what's not is fuzzy, but as it happened in 1994 a
friend I had made on BBSes/FidoNet invited me (as a coder) to a group he
was starting and to private BBSes.  At about the same time, I also got on
the Internet and wanted to retain my access and to explore, and I got in
touch, via IRC and such, with folks in other countries, both demoscene and
software cracking scene.  As I recall, mARQUIS of the recently formed uCF
had released a cracked version of EXE Manager, my software protection
tool.  I joined their channel for a friendly discussion, and ended up
being invited to and joining the group.

|=---=[ What do you consider your most notable technical achievement?

May I list several that I find somewhat notable?  I think all but possibly
the most recent would have been invented by others by now.

I think I helped accelerate the move from shellcode to borrowed code, with
that 1997 posting of first ret2libc exploits.  Initially, this appeared to
have made no effect, but then things started changing, and changing a lot.

In the same posting, I also introduced what later became known as ASCII
armoring (unfortunately, a term that was already used to refer to something
unrelated: binary to text encoding in PGP).  I suggested placing code that
should be out of easy reach of exploits via C strings at addresses that
contain at least one NUL byte in them.  (In that posting, I called this a
"fix", which I now regret.  I should have written "partial mitigation".)

I was first to bring non-executable memory protections to Linux and to x86,
initially just the stack (then extended to much more by PaX Team).  This
was not unique for operating systems in general - there was already Casper
Dik's patch for Solaris on SPARC, and Digital Unix on Alpha had
non-executable stack by default - but it was new to Linux, to x86, and to
free software (Solaris was non-free).  At first, upstream maintainers
opposed this, but later (when I had given up and moved on) it was embraced
by Linux and other free and non-free operating systems.  If I had not
started that discussion/controversy at the time, and someone else did
later, maybe the persuasion timer would start ticking later as well.

JtR's incremental mode, in its initial form introduced right with version
1.0 in 1996 (and tested privately in an unreleased cracker in 1995), was
novel: being able to search a password space exhaustively, yet in a smart
order.  Before JtR, it was one or the other: dumb exhaustive search, or
smart non-exhaustive search.  (I guess NSA and the like must have had
developed approaches like this before and beyond, but I am unaware of
publications or released tools of this kind predating JtR.)  With this
approach, already on computers of the time, it was practical to crack some
non-word-based yet word-like 7- and 8-character Unix passwords.

JtR's built-in ability to train on previously cracked passwords (generate
incremental mode's sorted charsets), IIRC introduced in 1997, was probably
novel as well.  Indeed, people were optimizing wordlists, etc. based on
cracked passwords before, but not with a built-in feature of the cracker.

I was first to apply/extend bitslice DES to descrypt, also in JtR, in 1998,
running especially well on Alphas (the speedup from x86 to Alpha for the
bitslice DES code of the time was comparable to the speedup going from a
CPU to a GPU now).

With a team, we demonstrated that it is practical to have a
fully-functioning Unix-like system without SUID programs, and that it is
possible to do so much more (than others do) within the traditional Unix
permissions model.  Unfortunately, this is, with few exceptions (e.g.,
Vixie Cron is such a lucky exception), not being embraced by others.
*BSD's stay with their SUIDs, and many Linux distros go beyond the
traditional Unix permissions prematurely.

More recently, the concepts of ROM-port-hardness (first presented in my
ZeroNights 2012 talk, with the slides online so I won't explain it here)
and multiply latency hardening for password hashing, KDFs, and
cryptocoins.  Multiply latency hardening is about tying up RAM for a
duration that cannot be made many times smaller through higher bandwidth
alone, but only through also improving integer multiplication latency,
which CPUs are optimized to be very good at.  (Some attack speed
improvement is indeed possible with ASICs anyway, but not as much
improvement as there would have been without such hardening.)  It is
also applicable to other areas, such as timed-release encryption.

The above list might look like a lot done, or like too much bragging, or
like too little done.  My own assessment is too little done per time spent.

|=---=[ Related to the previous question: Can you give us some background
        information? How and why did you come up with this? Can you give us
        an anecdote story related to it?

Regarding the ret2libc exploits, as I mentioned in the 1997 posting some
credit for this goes to Pavel Machek, a Linux kernel hacker who had
challenged me with the possibility of borrowed code attacks (without such
wording at the time, I think) on my non-executable stack mitigation.
Always thinking both defense and offense, I went ahead and implemented
those very first ret2libc exploits, and posted them.

My secondary(?) motivation was "to prove that exploiting buffer overflows
should be an art", as I wrote at the end of that e-mail.  A typical buffer
overflow exploit at the time was copy-paste from Aleph1's Phrack 49
article, even replicating the misindented __asm__("movl %esp,%eax"); line.
That was dull.  Compare this to today's assortment of memory corruption
exploits, which often are pieces of art.

|=---=[ Was your most notable technical achievement also the one that was
        the most fun?

While notability can be (mis)judged through the reception by others, and
this is a reason why I chose to emphasize the ret2libc exploits, I have no
such criteria for "most fun".  These exploits certainly were fun, and there
was that satisfying feeling re-reading their code, but were they absolutely
the most fun?  I'm not sure.  Many things I did were fun.

Exploration of VM-based software obfuscation possibility was fun (even if
possibly of negative ethical value as "intellectual property" protection
might be in general, although there are other potential applications of the
idea, such as for weak "whitebox crypto in the cloud" in modern speak).
Some people liked the PoC, and there were friendly copycats.  I didn't
pursue this further as I fully went into FOSS at about the same time.
A couple of years later, I was surprised to find a disassembly of my PoC in
a printed magazine, with concerns raised that the technique could be picked
up by malware.  I think this hasn't happened, but I suspect that my PoC
might have influenced the creation of VMProtect (IIRC, it also used NOR as
an emulated instruction, but added many other instructions thereby spoiling
the idea).

There were some technical feats that were not notable in terms of influence
(either because they had no such value or because they were not exposed or
were overlooked), but certainly were fun.  I mentioned some among the
"memorable experiences".  A maybe-curious one, implemented in 1995-1996 for
DOS as JMPTRACE.EXE, was guiding a program's user and making and comparing
as many as needed dumps of the program's control flow instructions' status
(not-reached, taken, not-taken, varies) to spot the instructions changing
between two sets of dumps, and automatically generate a patch to force
program behavior to one path or the other.  It was fun to see this produce
cracks in under a minute, removing the need for any manual work in simple
cases like this.  This is extending and re-applying game cheating tools'
old idea of comparing memory dumps to spot the one right variable.  Sounds
obvious, yet I'm not aware of others having done it before.

|=---=[ When you came up with the unlink metadata attack for Mozilla's
        heap, did you look for it in other linked list allocators? Did you
        realize its full potential at that time?

Actually, the attack as originally discovered and demonstrated was not on
Mozilla's allocator, but on whatever allocators of the underlying system
Mozilla used - so yes, as the advisory I published at the time said, the
technique was shown to be applicable to glibc's and Windows' allocators of
the time.  And yes, I did realize, and maybe I should have written a
separate article on just that.  I was trying to make two points at once:
that file format parsers are a major risk, and that "heap overflows" are
exploitable in this generic way.  Arguably, placing them both in one
advisory obscured the latter, but as we see from further publications by
others, including in Phrack, it was not fully missed either.

Want an anecdote on this one as well?  I first triggered the bug when
trying to optimize a JPEG for my website.  I deleted the comment in vi, but
updated the comment length incorrectly.  The browser crashed, and I didn't
let this stay non-investigated.  (These days, I grew older and oftentimes I
just ignore software crashes, letting those bugs live.  What a pity...
although I imagine the pro-bug folks would appreciate that.)

I first exploited the bug into branching to a controlled address in gdb
before having ever looked at the corresponding source code of either
Mozilla or glibc.  It's this low-level / binary approach that enabled me to
see what was possible.  If I had switched to reviewing the source code
sooner, I might not have realized the bug was exploitable.

I only looked at Mozilla's source code and at the relevant place in glibc
for figuring out what exactly was happening in higher-level terms, and for
writing it up for others.  Oh, and for producing a reliable binary patch.

|=---=[ Some of your older publications are "offensive", while in the
        recent years you seem to have focused on more "defensive" research.
        Do you agree with this statement? If yes, what were the reasons for
        this change?

I was always exploring both sides since I got into "software protection"
and (in)security.  It is possible that I alternated my focus between the
two over the years, yet I can't imagine me working on defensive research
without at the same time considering attacks on the solution or mitigation
being designed.  For example, my Phrack 53 article was both defensive and
offensive, and I dropped what later became known as hashDoS in it.

It is true that I mostly quit developing memory corruption exploits after
having published just a few (innovative) ones in late 1990s.  A reason for
this is that the desired effect was achieved, whether due to my work or/and
otherwise: people started producing advanced rather than dull exploits.

Similarly, I was one of the first (possibly the first?) to exploit a buffer
overflow on the Windows platform (in 1996, then published Windows 95 and NT
shellcodes in January 1997), but I quit almost right away as other people
also started bringing the Unix attack knowledge onto Windows.

I still co-maintain John the Ripper, which is an offensive tool.

I recently participated in a project to implement energy-efficient bcrypt
cracking on Epiphany and FPGAs, which is also offensive.

I designed yescrypt, which is defensive, but in the process I went through
lots of attacks on it.

Yes, our Openwall GNU/*/Linux project is defensive.

|=---=[ Related to the previous question: Which of the two do you think
        bears more fruit for a researcher; offensive or defensive research?
        Which of the two increased your learning and understanding more?

I'd say offensive as you need to consider attacks when working on defensive
research.  What may happen in practice is that when you naively go
defensive-only, others break your defenses (e.g., my early and naive
software protection schemes) and make you learn in that way.  If you're
lucky, or if you deliberately provide the incentive (bug bounty?), this
happens early on, before there's too much at stake (and then you start
thinking like an attacker as well... or you fail as a defender).

|=---=[ What's your take on the IT security industry vs. "the underground"?

A large part of today's IT security industry that I'm in contact with grew
from 1990s maybe-underground, so it's people we have a common understanding
with.  It's good.

As to the industry vs. today's underground, I don't know.  I guess there's
some overlap.

There's also some overlap of the civilian IT security industry (and
presumably the underground) with the military, intelligence, and law
enforcement.  Some are contributing to ethically questionable efforts.
(I am not implying that any work for governments is ethically questionable.
A lot of it isn't.  That's where the Internet came from.)

There's also the military rhetoric (such as "cyberwar"), which gets picked
up by non-tech yet powerful people.  This is a theme of my ZeroNights 2014
keynote game: "Yesterday infosec was such an easy game to play.  Now we
need a place to hide away?"  Was it really a game back then?  And is it
still a game now, or is it time to hide away (move on to the many
non-security areas where we can constructively hack useful things without
ethical uncertainty)?  I have no "authoritative answers" to these; I just
like to remind us to ponder on this in our decision-making on what to work
on next.

Finally, there are marketing-mostly companies and activities, which are
leeching funds without doing much else.  These happen to provide a false
sense of security, and vulnerabilities in the security software itself.

Overall, I think most IT security expenditures are not cost-effective, but
it's similar for other large industries.  Wasted money isn't necessarily
bad per se.  Money has no inherent value, it's just an instrument in the
economy and it's voting power.  What matters is whether the expenditures
result in people wasting their and others' lives on unhappily doing useless
work or not.  Unfortunately, they do, but not to as bad an extent as it
might seem at first.  (And yes, this also affects distribution of wealth.)

Besides IT security industry, there's also much increased attention
(compared to 20 years ago) to security elsewhere in IT, as well as much
improved knowledge of how to tackle safer design of IT systems.  This is a
lot more cost-effective than spending on security on its own or as an
afterthought.  It provides not only security, but robustness, and in ways
that impose fewer restrictions on the users.  Speaking of restrictive
security, this reminds me of anti-security and its less reasonable aspects:

Did you possibly mean your question in context of the (arguably eroded)
anti-security movement of 2002-2009 (arguably different from its earlier
form of 2001)?  I think that's a false dichotomy built upon several likely
flawed assumptions.  As I understand, one assumption was that the security
industry's growth was contributing to decline of the underground.  I think
it actually was change and not decline.  Yes, some people were growing up
and moving on and into the industry (no, this didn't make them "enemies"),
but also a new generation was joining the underground.  Phrack largely lost
its anarchy aspect, even prompting "fake Phrack" during that period, but
whatever happened to Phrack, etc. didn't necessarily speak of the entire
underground.  In fact, that very movement exemplified the diversity that
continued to exist and flourish (even if with some aspects I personally
wouldn't condone, since those infringed upon freedom of choice by others).
Another assumption was that the security industry still depended, and in a
"bad way", on sustained scaremongering and on real security threats found
in full disclosure publications.  I think that even if (hypothetically)
those ceased, the industry would grow at roughly the same pace, and it
wouldn't be any more focused on real threats.  On the contrary, I think it
would be spending a larger fraction of resources on people unhappily doing
useless work, with no reduction in total resources spent.

This is my prophile, and thus my opinion; I do not claim it is the ultimate
truth.  I hope I haven't built a strawman, but in case I have please take
the above paragraph on its own merits (not necessarily referring to the
specific movement).  I was mostly not around during those years, so I could
well have missed crucial detail, and I understand that anti-security wasn't
only about those things (and I think initially not about them at all).

|=---=[ What is your stance on full-disclosure vs non-disclosure? Are there
        situations where both are needed, or is it one or the other?

I generally favor full disclosure, but I don't oppose occasional use of
coordinated disclosure prior to the full disclosure.  I do oppose excessive
use of coordinated disclosure, as well as excessive embargo periods.
I also buy into Ted Unangst's suggestion to call this "selective
disclosure", with the negative connotation.  This is why I agreed for
Openwall to host not only the oss-security list (where full disclosure is
practiced), but also the (linux-)distros lists (for advance notification
to distro vendors, PGP re-encrypted).  As someone hosting them, I get to
dictate policy, not letting issues stay in the limbo for too long (and
forcing them to be brought to oss-security).  Obviously, what's
"excessive" and "too long" is subjective (there is a published policy on
that for our lists, but how we came up with this specific policy is
subjective).  And yes, it's necessarily "selective".

I am generally against non-disclosure, but there may be exceptions.  As I
understand, it exists out of intent to use or/and profit off of one's
finding, concerns of others taking advantage (unfair or any at all) of
one's finding defensively (you doing free bug hunting for the vendor),
offensively (use of your recent disclosure for attacks on not-yet-patched
systems), or/and commercially (scaremongering, marketing, actual security
products), concerns of getting oneself in trouble (e.g., the vendor going
after you), not wanting to lock other hackers out, increased appreciation
of the bugs (letting them live just for the sake of it), not wanting to
affect game dynamics, lack of motive (perceived need) to disclose, or/and
just laziness.  This list is probably non-exhaustive.

I think there's rarely an ethical way to profit off of a bug without its
planned public disclosure (remember, this might not be a game anymore) and
there are plenty of other ways to make decent money, including in IT
security, without such ethical compromises.  I can sympathize with many
possible reasons for one's choice not to disclose a bug, especially in
context of jailbreaks or DRM (thus, retaining the essential freedom to
fully utilize one's own devices or content).  However, it should always be
considered that information may leak or be rediscovered by others.

|=---=[ Some claim that the hacking scene is growing old and that there are
        not enough talented young people interested in hacking to replace
        it. What are your thoughts on this?

There are plenty of talented young people interested in hacking.  What may
be changing (or maybe not) is scene spirit.

|=---=[ What is your advice to the new hackers reading this?

I tried to share some maybe-wisdom throughout the pseudo-memoirs and
answers above.

FX's advice of "Try Harder 2 Be Yourself" makes sense to me -
individuality, curiosity, creativity.  Being a hacker is about all of
those things and, whatever the darker undef color folks say, it isn't
necessarily about ever hacking into systems, which might or might not even
be relevant (depending on creativity involved or lack thereof).  Last but
not least, try to be a good person, while at the same time staying
yourself.  (Few people are genuinely bad.)  This means integrity, too.

A hacker shouldn't need guidance.  If you feel like asking an old-timer for
guidance, you're probably on the wrong path.  Rather, it should be about
your own creativity, and you'd find you have more curiosity and more
things to explore than you have time for.

However, it is in fact helpful to be introduced to things you might not yet
have found on your own.  Also, it is OK to bring up specific questions -
not of the sort "what's next", thus not step-by-step guidance, but asking
in appropriate communities for advice on very specific technical issues you
already ran into.

The landscape has changed.  On one hand, the previously low-hanging fruit
has been explored, so the barrier to entry may be higher now.  On the
other, a lot of information and tools are now easily available, and there
are friendly communities that are even easier to reach than before, and
without the elitism too, so the barrier to entry may have lowered.
Overall, it's just different.  There's new low-hanging fruit too - e.g.,
for the coming "Internet of things" you'll end up building upon and
porting over the previously explored attack techniques to this new area,
and hopefully finding something creative about it as well.

It's probably riskier (and less of a game) to explore systems online now,
but on the other hand you can have plenty of rare systems in emulators/
VMs, and you can "hack" in CTFs, which really are just games (good!)  Bug
bounty programs provide you a previously unheard-of opportunity to not
only explore some systems online in some limited ways, but also get paid
for it - and it's a game (also good!)  You don't have to worry about how
you'd get online to connect to a CTF server tomorrow.  There are no such
survival challenges in today's CTFs.  You wouldn't even voluntarily go for
the headache of the network lag and frequent disconnects, even though
technically those could be simulated.  The spirit is probably very
different now.  Times change.  (But maybe not yet by this much in some
developing countries?  Just like USSR/Russia was lagging behind back then.
As a cat, I see a lot of naive mouse activity from Indonesia, so maybe it's
still like that in there, perhaps with wireless in place of dialup?)

Firmware hacking has probably stayed the same, including the spirit, and in
fact the range of opportunities has expanded.  Lots of ethically sound
opportunities there, too.

There are many ways to be a hacker without ever getting into (in)security -
e.g. hacking on non-security aspects of a free operating system - or even
without focusing on computing, although there's a hot and highly relevant
area which does involve computing: bioinformatics.

|=---=[ What is the future of hacking? The future of "the underground"?

Hacking will go on, in all meanings of the word.

The underground, the kind of it that I consider positive, might be getting
blended with other communities, although I hear there are forums that have
sort of replaced private BBSes of before.

There will also remain for-profit groups (and their forums, communities,
etc.) that technically are underground, but that's different - not the
kind of underground I possibly associated with.

Very different kinds of hacktivism will also continue, and I think these
are for human rights, transparency, protests, and attempts to influence the
game (many or most of them misguided).  Also a lot of malicious and just
for fun trolling and stalking, but masquerading as hacktivism - that's not
even hacking, but it can involve e.g. (D)DoS attacks and thus be lumped in
with hacking/hacktivism.  Also manipulation of public opinion via technical
means (automated sockpuppets, etc.), including attributed to state actors.

|=---=[ What do you think the biggest infosec challenges for the next 5
        years are/will be? And what should be done about them?

5 years is not that much, so the challenges will stay mostly the same as
today's.  Attention will be shifted to some specific areas all of a sudden,
like we've seen it happen for SSL/TLS starting with Heartbleed, but this
does not mean those areas actually suddenly started to need more attention
(maybe they needed it before as well, and/or maybe they don't deserve as
much now).

Below are some that will be changing from today's.  This does not mean
they're the absolute biggest challenges - I think the biggest are the same
as today's - but they might be among the biggest that change from today's:

Use of virtualization will increase even further, on all kinds of devices,
including with nested and mixed technologies, which will bring new code and
new bugs with it (such as in front-end software and middleware used to
manage those VMs/containers), and inconsistent/violated security
models/assumptions.  Ideally, there should be demand for under-the-hood
simplicity of such solutions, but unfortunately this demand is lacking, and
so will the supply, likely resulting in some ridiculously complex and
inconsistent systems.

Use of "microservices" will continue to increase, and so will server-side
request forgery attacks - and defenses against those.  With separation of
backend services improving, there will be an unfortunately to-be-missed
opportunity to make it privilege separation rather than merely operational
separation.

For crypto, some of those backend servers could act as HSM-alikes, but this
opportunity will also be missed due to HSM-alikes requiring HSM-like rather
than server-like sysadmin practices.

Use of centralized management will increase - config file management across
all of organization's virtual and physical servers, etc.  This means a
single point of failure, and of security compromises too.  We could have
gained intranet security boundaries through greater separation of backend
services, but instead we'll lose them through greater centralized
management.  This applies to (security) event monitoring, too.

With more levels of abstraction, (live) migration, hosting infrastructure
outsourcing, and increased use of solid-state non-volatile memories
(ranging from "disks" to "RAM"), it will be even harder (and arguably
counter-productive) to keep track of actual devices underlying the logical
assets and, even once located, to securely wipe those devices when they're
to be retired (hard to do for flash memory with over-provisioning and wear
leveling) - but people typically neglect to do this now anyway.

IPv6 deployment will increase more rapidly than it did in prior 5 years.
We'll see more talks about the inadvertent security exposures this brings.

Use of encrypted communications will continue to increase, with technical
pressure put on those who are lagging behind in protocols support (upgrade
or fall off the net).  As a side-effect, this will prevent some legacy
systems from being accessed or from talking to many newer systems.  In
some cases, we'll see fallbacks to unencrypted communications where
previously legacy encryption was being used.  In some other cases, we'll
see software updates stop being installed, thereby leaving systems exposed
to more vulnerabilities for longer.  I'd like to see a saner, case-by-case
approach here - e.g., with opportunistic encryption, there's little point
in insisting on the latest protocols (refusing legacy ones), and a
WordPress updates server isn't really helping security by denying
connections from older systems.  Unfortunately, I don't expect an
improvement in the approach taken (in part because case-by-case is
necessarily more complex than one-size-fits-all guidance), and so there
will be more collateral damage.

With luck, we'll see another spike (after 2013's) in demand and hopefully
supply for line-rate encryption in high-speed network devices, due to a
combination of genuine security-consciousness and hype and marketing
opportunities.  Assuring security of encryption provided by those typically
proprietary devices will be tough (e.g., does this one device actually
provide perfect forward secrecy?)  Ideally, there should also be demand for
at least some openness of such devices for security review.

SCADA will move even more into the spotlight, and will remain with lots of
low-hanging fruit for years.  Cars and IoT will continue to join SCADA
under the spotlight.

Control over end-user devices will continue to be taken away by the
vendors, and jailbreaks will continue too.  Arguably well-intentioned
hardware backdoors (remote management, anti-theft, etc.) will continue to
be introduced, and will remain a concern.  Open hardware projects will
advance, and more of them will be started, including in response and
trying to address these concerns.  Backdooring potential of taped out
designs at chip foundries will become more relevant and thus a topic of
more discussions.

As open CPU designs (such as RISC-V and J Core aka free SuperH) succeed,
there's also good potential for an open FPGA with a FOSS toolchain (perhaps
building upon existing FOSS projects such as Torc and Yosys).  This could
be crowd- or/and VC-funded, and having it would address some concerns.

|=---=[ Open question. Anything more you would like to say to Phrack
        readers?

I can neither confirm nor deny anything stated in this prophile.

I wrote a lot (sorry for your time!) and I included some possibly strong
opinions, but I do not mean to speak with authority.  My involvement in the
underground, if any, has been rather limited and brief, nor am I a true
old-timer (1990s wasn't that long ago).  I also would like to apologize to
past/other(?) Phrack editors as I had refused to be prophiled before on
two(?) occasions.  It felt like too much of a drag and events were too
recent.  Time had to pass so that I could provide perspective, as I tried
now.  Nothing to do with Phrack's editor teams changing, just the timing.


|=[ EOF ]=---------------------------------------------------------------=|