These are tools that let one run a process and, in a sense, selectively debug by telling the tool to perform analysis when conditions are met in the kernel, such as when a certain argument is sent to sendto() one could replace it on the stack with their own value. You could write your own version of functions and hijack them with with LD_PRELOAD but being able to script instead of compile is significantly better for debugging.

There are several frameworks for such debugging available.  DTrace with RE:Trace (osx, sun), SystemTap on linux and vtrace for win32+linux, all scriptable.  My favorate as yet is Subterfugue though old its keep-it-simple-stupid methods have kept me coming back. Here is an example that changes the argument passed to a write() into rot13 ascii:

trans = string.maketrans('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ',
                         'nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM')

class Rot13(Trick):
    def callbefore(self, pid, call, args):
        m = getMemory(pid)
        address = args[1]
        size = args[2]
        data = m.peek(address, size)
        m.poke(address, string.translate(data, trans), self)

    def callmask(self):
        return { 'write' : 1 }

And the output:

bash-2.03$ sf --tri=Rot13 date
Jrq Sro  2 02:55:34 PFG 2000
bash-2.03$ sf --tri=Rot13 --tri=Rot13 date
Wed Feb  2 02:55:37 CST 200

So because Im too lazy to make a CVS commit, ill explain how you can revive it yourself. Hey! Really this is better. Its future proof: You wont have to worry about the software dieing if I go off to work at some draconian anti-opensource company just like all the other wonderful security engineers out there (Im looking at you Boomerang Decompiler). You wont have to worry because… within the next 5 minutes youll know how to maintain it yourself, kinda.

1. Downgrade python:
   download and install python 1.5.2. You could try your luck with later versions but the object c methods are different and subterfugue needs these for heavy use of ptrace() hooking. Lets race to see who recodes them first. Anyway, whatever version to try be sure you have the Makefile.pre.in from the python install sources.
2. Update system call map:
   grab the strace sources. The system call map that subterfugue is using is dated from 2001 or so and needs to be updated for newer kernels. compare the syscallmap.py in subterfugue to the syscallent.h of strace. From about array index 250+ is where the new entries start. To add them I just cut and paste to a new file, ran a replace routine for line in f.readlines(): print line.translate(string.maketrans(’{}/*’,'()##’)). Also needed to be sure there there was no more than one flag in each array.
3. make install and then test with a trick from /usr/lib/subterfugue/tricks/: sf –tri=Count date

If time permits I would like to rewrite the ptrace c shell using python 2+ methods. Until then, this works.

Update: added routine to print out hex data for blocks where entropy passes a given threshold. Tidied up code.

Ero Carrera responded yesterday to a request on OpenRCE concerning using entropy analysis to find RSA keys and other random blocks of data in binaries. Here in is a full wrapper for the code he gives. We use matplotlib instead of Mathematica to generate the graph. Also if you plan to scan files larger than 100k I’d highly recommend downloading the modified progressBar class included here.

example output:

Target data:

data = ''.join (
  [chr (random.randint (0, 64)) for x in xrange (1024)] +
  [chr (random.randint (0, 255)) for x in xrange (1024)] +
  [chr (random.randint (0, 64)) for x in xrange (1024)] )

[==================================100%=====================================]
     949 7.00: 1a060113050c2d0d 17302e091d2d0117 →♠☺‼♣♀- ↨0. ↔-☺↨

entropy_graph.py

""" Entropy scan
    H() and entropy_scan() originally by Ero Carrera (blog.dkbza.org)
    Modified May 2007 by cyphunk (deadhacker.com)

    USAGE:
    cmd [target_path]
    """

# FLAGS:
SHOWPROGRESS = 1       # Show console progress bar?
PRINTONTHRESHOLD = 7 # When block is > than threshold
                       # print first 16 bytes in both
                       # hex and ascii.  Set to 0 to turn
                       # off.
ONLYFIRSTBLOCK = 1     # Set to 1 it will only print the first
                       # block that goes over threshold and not
                       # blocks > threshold that are only offset
                       # by 1.  By setting to zero block windows
                       # that match will be printed.
BLOCKSIZE = 256        # size of blocks scanned.

import math
import random
from pylab import *
import tkFileDialog
from Tkinter import *
from progressBar import *
from binascii import hexlify

def H(data):
  if not data:
    return 0
  entropy = 0
  for x in range(256):
    p_x = float(data.count(chr(x)))/len(data)
    if p_x > 0:
      entropy += - p_x*math.log(p_x, 2)
  return entropy

def entropy_scan (data, block_size) :
  if SHOWPROGRESS:
      progress = progressBar(0, len(data) - block_size, 77)
  # creates blocks of block_size for all possible offsets ('x'):
  blocks = (data[x : block_size + x] for x in range (len (data) - block_size))
  i = 0
  for block in (blocks) :
    i += 1
    if SHOWPROGRESS:
        progress(i)
    yield H (block)

# get target file as argument var or from dialog:
filename = ""
if sys.argv[1:]:
    filename = sys.argv[1]
else:
    root = Tk()
    root.withdraw()
    filename = tkFileDialog.askopenfilename(title="Target binary",
                                        filetypes=[("All files", "*")])

# run, print graph:

if filename:
    # Open and scan for entropy:
    data = open(filename, 'rb')
    raw = data.read()
    results = list( entropy_scan(raw,BLOCKSIZE) )

    # Print blocks that are above a defined threshold of entropy:
    if PRINTONTHRESHOLD > 0:
        print
        found = 0
        for i in range(len(results)):
            if results[i] > PRINTONTHRESHOLD:
                if found == 0:
                    table = string.maketrans("rnt", '   ') # don't like newlines
                    blockstr = string.translate(str(raw[i : i+16]), table)
                    print "%8d %.2f: %s %s %s" % (i, results[i], hexlify(raw[i : i+8]),
                                                     hexlify(raw[i+8 : i+16]), blockstr)
                    #%.3f - %016X / %s" % (i, results[i], raw[i : i + 16], raw[i : i + 16])
                    found = ONLYFIRSTBLOCK
            else:
                found = 0

    # Plot
    plot(results)
    xlabel('block')
    ylabel('entropy')
    title('Entropy levels')
    grid(True)
    show()

progressBar.py (originally from active state but modified for our use)

import sys

class progressBar:
    """ Creates a text-based progress bar. Call the object with the `print'
        command to see the progress bar, which looks something like this:

        [=======>        22%                  ]

        You may specify the progress bar's width, min and max values on init.
    """
    def __init__(self, minValue = 0, maxValue = 100, totalWidth=80):
        self.progBar = "[]"   # This holds the progress bar string
        self.min = minValue
        self.max = maxValue
        self.span = maxValue - minValue
        self.width = totalWidth
        self.amount = 0       # When amount == max, we are 100% done
        self.updateAmount(0)  # Build progress bar string
        self._old_pbar = ""   # used to track change
        self.pbar_str = ""

    def updateAmount(self, newAmount = 0):
        """ Update the progress bar with the new amount (with min and max
            values set at initialization; if it is over or under, it takes the
            min or max value as a default. """
        if newAmount > self.max: newAmount = self.max
        self.amount = newAmount

        # Figure out the new percent done, round to an integer
        diffFromMin = float(self.amount - self.min)
        percentDone = (diffFromMin / float(self.span)) * 100.0
        percentDone = int(round(percentDone))

        # Figure out how many hash bars the percentage should be
        allFull = self.width - 2
        numHashes = (percentDone / 100.0) * allFull
        numHashes = int(round(numHashes))

        # Build a progress bar with an arrow of equal signs; special cases for
        # empty and full
        if numHashes == 0:
            self.progBar = "[>%s]" % (' '*(allFull-1))
        elif numHashes == allFull:
            self.progBar = "[%s]" % ('='*allFull)
        else:
            self.progBar = "[%s>%s]" % ('='*(numHashes-1),
                                        ' '*(allFull-numHashes))

        # figure out where to put the percentage, roughly centered
        percentPlace = (len(self.progBar) / 2) - len(str(percentDone))
        percentString = str(percentDone) + "%"

        # slice the percentage into the bar
        self.progBar = ''.join([self.progBar[0:percentPlace], percentString,
                                self.progBar[percentPlace+len(percentString):]
                                ])

    def __str__(self):
        return str(self.progBar)

    def __call__(self, value):
        """ Updates the amount, and writes to stdout. Prints a carriage return
            first, so it will overwrite the current line in stdout."""

        self.updateAmount(value)
        self.pbar_str = str(self)
        if self.pbar_str != self._old_pbar:
            self._old_pbar = self.pbar_str
            sys.stdout.write(self.pbar_str + 'r')
            sys.stdout.flush()

Update: added seperate feeds for updated and new-only articles

One of the resources I use to monitor for current cryptography papers is the Cryptology ePrint Archive, a routinely updated repository of all cryptography papers. Recently the Archive setup their own RSS feeds. Their feed provides a link to the article summaries. For me this isn’t enough and for a while I’ve had my own bot building an RSS feed listing the latest additions to the archive including their full summary inside the feed itself, not just a link to it. It was too buggy to link publicly so last night I fixed what should be the last of the problems to providing a stable feed. I have a feed for just newly published articles and another for all articles new or updated. 

Formal aspects of mobile code security – Chapter 5
PhD thesis for Richard Drews Dean
23 page chapter.

Incomplete: Need to discuss how the author discovered attacks. Need to check my description using the detailed equations provided. I must illustrate the attack methods.

The interest in this thesis is due to its reference in Heard Hash Functions and many other papers relating to hash algorithms. In Chapter 5 a fixed point attack against hash algorithms is discussed. Methods are given for overcoming the appended message length specified in Merkle-Damgård (cache) constructed hash functions.

What is a Fixed Point Attack?
A Fixed Point Attack involves finding a random block whose properties allow the attacker to insert the block into the original message without changing the final hash. As a result two different messages are created with the same hash (the original message and the original+the special block). To produce this special block first make note of all the internal hash states produced after each block is compressed (see: SHA-1 Illustrated). Next generate random blocks (Xi) until you find one that meets two properties:

1. The hash state before compression of block Xi is the same as the hash state returned after compression.
2. The hash state of Xi equals one of the internal hash states of the original message.

After finding such a block it can be inserted into the message directly after the message block whose internal hash state it matched.

Overcoming Message Length
MD5, MD4 and SHA use Merkle-Damgård construction (cache) which specifies that the length of the entire message be appended to it. Therefor, a simple Fixed Point Attack will not do because the message length will change when the special block is inserted. This intern changes the hash of the last block thereby changing the final hash returned. The paper gives 3 methods to overcome this.

1. The length is a 64 bit integer so add the special block 2^64 times, in affect causing the number to loop. This does not work on SHA because SHA does not cover messages greater than 2^64 bits.

2. Look for any two internal hash states in the message that equal each other. If you are lucky enough to have such a message you can delete all the blocks between the two and then expand the message back to the original size using the Fixed Point Attack.

3. Run a Fixed Point Attack and make note of the place in the original message where you can insert the special block. Now, remember that the block compression function adds the resulting hash state to the previous hash state. That means that compression is a function of the current block and the previous blocks hash state. With that understood, we want to find another random block that means the following two requirements:

• The hash state before compression of block Xj is set to the first hash state of the original message.
• The resulting hash state of Xj equals one of the internal hash states of the original message which is less than the hash state matched by the Fixed Point attack.

You’ll notice that this block uses the same method as the Fixed Point only it initializes the incoming hash state to the compression function to be that of the first hash state of the message.

Now we can insert the Xj into the message directly after the message block whose internal hash state it matched. Since the compression of Xj takes the first hash state of the message we delete all the blocks up until that point, effectively making Xj the first block and reducing the size of the message. Now the Fixed Point block Xi can be inserted into the message directly after the message block whose internal hash state it matched and can be repeated to bring the message back to it’s original size.

This chapter also discusses how the attack was found as well as possible solutions. which I still need to cover.

References
References I must find:

• [PvO95] Bart Preneel and Paul C. van Oorschot. MDx-MAC and building fast MACs from hash functions. In Don Coppersmith, editor, Proc. CRYPTO 95, pages 1–14. Springer, 1995. Lecture Notes in Computer Science No. 963.

To find the attacks the author used Binary Decision Diagrams to look at the logical structure of MD5,MD5,SHA-1. References I must find:

• [Bry92] Randal E. Bryant. Symbolic boolean manipulation with ordered binary decision diagrams. ACM Computing Surveys, 24(3):293–318, September 1992.
• [Hu97] Alan J. Hu. Formal hardware verification with BDDs: An introduction. In IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing, pages 677–682, 1997.

By Nathan Fain

Incomplete: must create detailed diagram for compression functions.

The following simplifies the specification of SHA-1 in an easy to digest form. First we will cover the general structure of the algorithm. Detail of the expansion and compression routines are covered separately.

First we start with a message. The message is padded and the length of the message is added to the end. It is then split into blocks of 512 bits (Figure 2).

(Figure 2)

The blocks are then processed one at a time. Each block must be expanded and compressed. The value after each compression is added to a 160bit buffer called the current hash state. After the last block is processed the current hash state is returned as the final hash. A overview of this procedure can be seen in Figure 3.

(Figure 3)

Let’s look more closely at the expansion and compression functions. For expansion each 512 bit message block is separated into chunks of 32 bits. As you can see in Figure 3 these 16 chunks are then used to create 64 more chunks for a total of 80. Details of how this is done are described later.

(Figure 4)

Now all 80 of these chunks are compressed into a 160 bit value which is added to the current hash state (Figure 5):

(Figure 5)

Figure 5 shows one block being processed. The expansion and compression functions are repeated for each block with the return constantly being added to the current hash state buffer. Once all blocks have been processed it is this value that is returned as the hash of the message.

3 tasks were generalized above: How the message is prepared before processing, how exactly the block is expanded to 80 chunks (Figure 4) and how those chunks are compressed (Figure 5). It is not essential to understand them in detail but should you desire, here are the details.

Message Preparation

The message is prepared in 4 steps:

1. Append a single binary 1 bit to the message
2. Split into blocks of 512 bits each (Figure 2 above)
3. The last block must be equal to 448 so that we can append the message length (next step). If it is under pad with binary 0 bits until equal to 448. If over, pad until it is 512 bits and create an additional block of 448 binary 0 bits.
4. Append the length of the original message to the last block. Represent this length as a 64 bit integer (making the last block equal to 512 bits).

I should also mention that before we process any blocks we must initiate the hash state buffer. The buffer is actually 5 separate 32 bit integers:

• h0 = 67452301
• h1 = EFCDAB89
• h2 = 98BADCFE
• h3 = 10325476
• h4 = C3D2E1F0

Block expansion
Each 512 bit block is split further into 32 bit chunks (”words“) as seen in Figure 4. These 16 chunks are then expanded to a total of 80. The processes of expansion is a simple XOR of 4 values. For instance, the next chunk, chunk 17, is created by XOR’ing together chunk 17-3, 17-8, 17-14 and 17-16. For chunk 18 run the same processes but subtracting from 18 instead of 17. This continues until all 80 have been created. This can clearly be seen in the animation to the right. (If the animation is not playing reload the page.)

Block compression

This work is licensed under a Creative Commons Public Domain License and may be used however you wish.  For sources to Dia based diagrams, contact me.

An Illustrated Guide to Cryptographic Hashes
by Steve Friedl
15 pages of text

Update 2006.02.11: clearer explanation of CTFP preimage resistance.

This is a very good introduction to what a hash algorithm is, what it is for and what collisions are all about. It does not cover specific details, only the general understanding. It’s a quick read so I’ll forgo summarizing the contents.

The article explains the common terms used in most papers that discuss collisions. These terms are used to classify the type of collision attacks possible and are necessary to understand when reading other papers:

• Collision resistance measures how difficult it is to create two inputs which produce any hash value which is the same for both inputs. In this scenario the attacker can control both inputs.
• Preimage resistance measures how difficult it is to create one input which matches the hash value of an unknown input. Here the attacker does not know the other input and is restricted by needing to create a specific hash value.
• Second preimage resistance measures how difficult it is to create one input which matches the hash value of a known input. Here the attacker can see both inputs but only controls one. Attacker is still restricted by having to create an input which matches the specific hash value of the other. However, knowing the input that produced the hash might be of assistance.

Both preimage and second preimage are similar in that the objective is to get one input to match a predefined hash which is not controlled by the attacker. Also, in the Herding Hash Functions by John Kelsey and Tadayoshi Kohno they that there is a 4rth resistance value:

• Chosen Target Forced Prefix preimage resistance measures how difficult it is to create a collision when the first input is known while the second input is not know yet. This is similar to preimage resistance except that here the attacker controls the first input and not the second. Well, almost. The attacker is permitted to append data to the second input. The attacker must determine the hash first using the first input and then “herd” the second input to the same hash. Herding is done by adding data to the second input to make it collide. Is a process that involves carefully predetermining the first input and using internal states from its hash generation in the appended data to the second.

Visual Basic Reversed – A Decompiling Approach
by Andrea Geddon
27 pages, 20 of code.

Update 2006.02.11: more intuitive structure list and directions of use.

This is would have made for a good introduction to reversing Visual Basic if it were not for a few errors. One can still learn a bit about the data structure used by the runtime engine but towards the end when trying to find objects the author mixes names he gave structures, or isn’t clear enough to keep them in order to. Regardless, a great deal of the structure is described and some of it in a coherent manner.

The author looks at an example VB program with the objective of finding the serial generation code. He starts from the very first data structure (RT_MainStruct). Here is a bulleted list of the different levels in the vb structure which should make it easier to follow. The author is looking for the onClickCheck event handler. The handlers are not named but can be found working through various levels. 1. First we must find the form name of interest. 2. Then we find the control (button) name of interest (perhaps “Check Serial”). 3. We find the onClick event handle for that button.

1. The form names can be found under ProjectStruct.Tree.ModulesList. Each ModulesList represents values of either a form or a module object and contains a ObjName which is the internal ASCII name of the Form/Module.
2. For Forms you will find a FormDescriptor structure referenced. This structure contains substructures for each control in the form. Buttons, text boxes, labels, etc. The author named them FD0_ControlsList[*]. Inside each of these structures you will find the ASCII name (aText_2_0) given to each control, such as “btnSerialChk”, etc.
3. Inside the structure with the control/button you wish to examine you will find a LocalDispatcher structure referenced. And finally, it is here that you will find references to the functions for each event handler (onClick, onChange, etc). They are not named, only appearing as raw references. So, to determine what is onClick, onChange, onOver, etc… you can either look for familiar signs in the disassembly (such as calls to message box functions) or build an example project that has every event defined and compare the disassembly of each to it. Once the onSerialClick event handler is found you can follow its value to the serial check function.

Programmable Logic: What’s it to Ya?
by Michael Barr from Embedded Systems Programming, June 1999
6 pages

This document gives a basic overview of common programmable logic hardware: FPGA’s, CPLD’s and PLD. (Hold the mouse over links and acronyms to see their full definition or click to follow to their wikipedia entries).

PLD
In the beginning there was PLD, and it was good. PLD let you take simple Logic Gate (AND/OR/NOT, etc.) TTL components and combine them into one chip. It is also known as GAL, PLA and PAL.

CPLD
PLD * n. CPLD’s combine various common PLD configurations into one component. A switch matrix is used to control IO between, to and from each. A CPLD differers from an FPGA in that not all logical components are equal in a CPLD. Because of this you must choose their CPLD wisely according to their application. The benefit it provides however is that an application could run faster on an optimized CPLD than it would on the ever flexible FPGA.

FPGA
Unlike a CPLD the logical unit of an FPGA is much smaller containing only a few small logic gates. The structure of the hardware itself separates tasks into IO blocks around the perimeter of the chip with the Logic blocks residing in a matrix inside. FPGA’s are measured by the number of logical gates (gate count), I/O pins and use of ROM or RAM.

VHDL or Verilog are used to describe a highlevel architecture for use in an FPGA. These languages are general enough however to be applied to CPLD’s. They are used in general ASIC design as well. Typically one then uses simulation tools (such as those provided by Cadence) to simulate the high level logic. After simulation one would move to compilation.

Synthesis, the next step, is the process of taking a high level design and producing a Netlist. The netlist is still device independent. It is stored in a format called EDIF.

Place & Route, the step after producing a netlist, involves “mapping the logical structures described in the netlist onto actual macrocells, interconnections and input and output pins.” The result is a bitstream downloaded to the actual device. The bitstream format is device dependent.

Download to the device of the bitstream format is a process which depends on the features of the device. For FPGA’s that use EPROM to store their definitions one might either need to place the FPGA in a programmer or use JTAG, if the FPGA has separate logic defined for supporting this onboard. For FPGA’s that use RAM instead of ROM they must support some dynamic programming. An advantage of RAM based FPGA’s is that definitions can be changed on the fly (swap out DES logic for AES as you please). However they do consume more power and the original definition/bitstream must be reloaded on every power refresh.

Herding Hash Functions and the Nostradamus Attack (presentation slides)
by John Kelsey and Tadayoshi Kohno
8 pages of text

The paper describes an attack that would allow an attacker to massage (”herd”) an object to a point where it matches a hash value chosen by the attacker prior. What appears to be an important restriction is that the hash value has to be defined by the attacker prior to attack. This is important because in most uses of hash algorithms the victim would be the one defining the hash, not the attacker. Hence, this attack will not help you construct a message that matches a password hash.

The steps required for the attack are:

1. Attacker runs a collision finding attack on a hash algorithm and creates an array of intermediate hash states. In the paper this array is referred to as the “diamond structure”. It is not clear to me how the size of this structure is determined but half of the intermediate hash states in this structure can be used in creating message blocks (next step) to be imposed on the victim object in order to allow the attacker to edit that object and still produce the same hash as the original.
2. After having the diamond structure made the attacker then runs an exhaustive search for a string which collides with one of the intermediate hash states in the structure. Once found the attacker can “construct a sequence of message blocks” in order to build the proper suffix which will be added to the original object and the attackers edited version.

Questions I have concerning the above process are:

• After finding a collision how does one build the intermediate hash states. For this I will need to read up more on current collision finding methods: Multicollisions in iterated has functions by Antoine Joux (need to find), Formal aspects of mobile code security by Richard Drews Dean (attached). Learning more about hash states in a few hash algorithms should also help.
• How is the size of the diamond structure determined?
• What is the relation of the message blocks (used to create the final suffix added to the two different objects that collide) and the intermediate hash states?
• Finally, how does the attacker determine which message blocks are to be used with the suffix, and what is the function for creating the suffix.

Perhaps some of the above questions can be answered with another read, if I can find the time. Also would like to find is “How to Swindle Rabin” by Gideon Yuval.

One example application mentioned is abusing trust in a manner similar to social engineering. A malicious programmer writing a piece of code for a project which manages the code trust based on hash values. The attacker first runs a computation for building a diamond like structure/list of hash values that are optimum for collision. They then write some legitimate unsuspecting code which hashes to one of the chosen values. An auditor reviews the code and enters it into the code repository. The attacker can now edit that code and add a small back door.

All in all this paper reminds me in some way of Dan Kaminsky’s exploit of the MD5 collision examples which he describes in his paper MD5 To Be Considered Harmful Someday (attached). He constructed files that included the example collision messages within and continued to produce MD5 collisions. The difference with the Hash herding described here is that the message used can look coherent and unsuspecting. The method differs from Dan’s in that hash herding uses the internal messages produced at different stages of the hash algorithm to give the attack the flexibility required to have greater control on the message.

]]> http://deadhacker.com/2006/02/01/herding-hash-functions/feed/ 3 cyphunk http://deadhacker.com/2006/01/22/paper-bugger-the-debugger/ http://deadhacker.com/2006/01/22/paper-bugger-the-debugger/#comments Sun, 22 Jan 2006 12:15:14 +0000 cyphunk http://cyphunk.wordpress.com/2006/01/22/paper-bugger-the-debugger/ ]]>


Bugger The Debugger, Pre Interaction Debugger Code Execution
By Brett Moore, CTO Security-Assessment.com. 10 pages of text, 3 of which are code.

This paper describes a method to construct a binary which can run code before control is passed to a debugger. The method requires changing the PE header of an executable to reference your own dll. This could be your own DLL or you could create a malicious version of kernel32.dll. In both cases you will need to edit the import PE header section to reference your DLL. In the case of using a kernel32.dll copy you must change the name of the dll to a unique name and replace the import reference in the PE headers for kernel32.dll to that of your DLL.

The document describes how to impliment both methods, including how to create your own malicious version of kernel32.dll. Edit a copy of kernel32.dll to construct on injection of your own code:

7C598934 FF 15 4C 13 57 7C call dword ptr ds:[7C57134Ch]
7C59893A FF 55 08 call dword ptr [ebp+8]
7C59893D 50 push eax
7C59893E EB 27 jmp 7C598967
7C598940 8B 45 EC mov eax,dword ptr [ebp-14h]

With

7C598934 FF 15 4C 13 57 7C call dword ptr ds:[7C57134Ch]
7C59893A 8B 5D 08 mov ebx,[ebp+08]
7C59893D 66 BB 00 10 mov bx,1000h
7C59893E FF E3 jmp ebx
7C598940 8B 45 EC mov eax,dword ptr [ebp-14h]

The mov bx,1000h sets the place for the start of your malicious code. The document also describes how construct the referenced code so that after injecting itself it reloads the original kernel32.dll should any other DLL’s need to import their own instances of kernel32 functions.

]]> http://deadhacker.com/2006/01/22/paper-bugger-the-debugger/feed/ 2 cyphunk