Converting shellcode to executable files using InlineEgg

Posted in Pentesting with tags , on 9 February, 2010 by __fastcall

I like small utils, gadget ones, this article can be found at Breaking Code blog does not have that important functionality but it’s really cute!.

EDITED at 10/2/2010 in order to prevent any misunderstandings. Thanks goes to a visitor’s comment which alerted me about how to write the reposts in order not to look like as my own.

There is URL where you can convert a shellcode directly to an executable. The guy in Breaking Code blog wrote this quick Python script using CORE’s InlineEgg package. According to the author it may be buggy

Enjoy! :)


What is IRQL?

Posted in Windows API with tags on 9 February, 2010 by __fastcall

I remember 2 years ago I read an article in phrack 65 written  by ivanlef0u. It used the word IRQL it was the first time I was hearing that word and tried to find out what it means. Today looking at my RSS I found this article describing what IRQL really is. The article is written by Jake Oshins and published in “A hole in my head” blog and can be found here

Computers have many things within them that can interrupt a processor.  These include timers, I/O devices, other processors, internal processor performance counters, etc.  All processors have an instruction for disabling interrupts, somehow, but that instruction (cli in x64 processors) isn’t selective about which interrupts it disables.

The people who built DEC’s VMS operating system also helped design the processors that DEC used, and many of them came to Microsoft and designed Windows NT, which was the basis for modern versions of Windows, including Windows XP and Windows 7.  These guys wanted a way to disable (very quickly) just some of the interrupts in the system.  They considered it useful to hold off interrupts from some sources while servicing interrupts from other sources.

They also realized that, just as you must acquire locks in the same order everywhere in your code to avoid deadlocks, you must also service interrupts with the same relative priority every time.  It doesn’t work if the clock interrupts are sometimes more important than the IDE controller’s interrupts and sometimes they aren’t.

Interrupts are frequently called “Interrupt ReQuests” and the priority of a specific IRQ is its Level.  These letters, all run together, are IRQL. Continue reading

Matching pool tags in Windows drivers

Posted in Uncategorized on 9 February, 2010 by __fastcall

I love small posts especially those notes that could help you when banging your head at the wall after facing a strange error on Windows API. When MSDN mentions nothing your last hope is to be in your notes. Original link can be found here.

This is a note to myself, mainly. If the PROTECTED_POOL flag is set on a pool tag, freeing it will require the use of the same tag as when allocating it. For all other purposes the tag will be ignored when freeing.

Microsoft states for the Tag parameter in ExAllocatePoolWithTag:

Specifies the pool tag for the allocated memory. Specify the pool tag as a character literal of up to four characters delimited by single quotation marks (for example, ‘Tag1′). The string is usually specified in reverse order (for example, ‘1gaT’). The ASCII value of each character in the tag must be between 0 and 127. Every allocation code path should use a unique pool tag to ensure that debuggers and verifiers identify a distinct allocated block.

Presumably most tags used by system components themselves will have that flag set, but to be honest I haven’t checked the pooltag.txt lately ;)

// Oliver

Ruby, Nmap XML, and Databases

Posted in Pentesting with tags on 9 February, 2010 by __fastcall

Ok it’s been a while. I found a very useful article when performing large nmap scans. Original article  here

So I had a requirement to take some output from nmap scans, shove it into a database and then be able to run some queries on that data.

Wait, isn’t there something that already does that?!

Actually PBNJ and will do this but uses (eeeek!) perl to do it. I wanted to do it in Ruby.
Continue reading

Windows 7 GodMode

Posted in Uncategorized with tags , on 8 January, 2010 by __fastcall

This on is a cool easter-egg I suppose, from Redmond. It is an about:config (see Firefox) of Windows in a folder. I’d like to add that this one is know as early as nWin95. Random name.{guid of shell namespace provider} will give you a folder with that namespace. There are many such providers in the system. For example, you could create “Bin.{645FF040-5081-101B-9F08-00AA002F954E}”, which is a new recycle bin. For others, the NameSpace folder is located in Registry at HLKM\Softwares\Microsoft\Windows\CurrentVersion\Explorer\NameSpace. The post can be found here

Continue reading

Safeboot keys

Posted in Windows API with tags , on 7 January, 2010 by __fastcall

This one will be quick. I just read in Didier Stevens blog about the SafeBoot key. It seems that some malware removes the specific registry key (HKLM\System\CurrentControlSet\Control\Safeboot)  in order to prevent the system booting in Safe Mode. Didier uploaded some pure SafeBoot reg files from default Windows installations. I have uploaded the files here, (remove the .ppt extension WordPress does not allow .zip file upload). Moreover Didier suggests to remove the “delete” permission from Administrators in order to prevent injected malware from deleting this key. I love this quick neat and clean tips I also love this sadistic malware defense mechanisms. 😉

PDF file loader to extract and analyse shellcode

Posted in Reversing with tags , , on 7 January, 2010 by __fastcall

Ok happy new year!
This one is preaty cool I found it in HexBlog, you know the blog about IDA pro. So here it is…

One of the new features in IDA Pro 5.6 is the possibility to write file loaders using scripts such as IDC or Python.
To illustrate this new feature, we are going to explain how to write a file loader using IDC and then we will write a file loader (in Python) that can extract shell code from malicious PDF files.

Writing a loader script for BIOS images

Before writing file loaders we need to understand the file format in question. For demonstration purposes we chose to write a loader for BIOS image files statisfying these conditions:

  • Should be no more than 64kb in size
  • Contain the far jump instruction at 0xFFF0
  • Contain a date string at 0xFFF5

Each file loader should define at least the two functions: accept_file() and load_file(). The former decides whether the file format is supported and the latter loads the previously accepted file and populates the database. Continue reading

HTTP POST -> HTTPS = Bad Idea®

Posted in Uncategorized with tags , , , on 28 December, 2009 by __fastcall

Cool taken from Paul Makowski of my 20% blog.

This will be a quick post (pun not intended) on why you should never allow anything sensitive to be sent from an unsecured page to an SSL-encrypted page. Many, many websites do this (Digg & Facebook quickly come to mind), and it’s a serious problem that has an easy solution.

When a user logs into a service, she has a reasonable expectation her credentials will be secured in transit. In the context of web applications, this means SSL.

A typical Facebook login goes like this:
1. Adam requests
2. Facebook sends a response with:

<form method=“POST” action=”″name=“menubar_login” id=“menubar_login”>

3. Adam enters his credentials and hits Login.

The problem with this is how does Adam know that the form he intends to submit to is actually destined for As stated in step 2, will return code to instruct Adam’s browser to post to an SSL secured page owned by Facebook. But what kind of assurance does Adam have that this is the code he received?

Consider the following scenario: Mallory uses something like ettercap on her university’s dorm network: she poisons the subnet traffic (her entire dorm building), tricking her fellow students’ computers to send all internet-bound traffic through her.

Mallory then uses Moxie Marlinspike’s sslstrip to automate an attack against Facebook. sslstrip will replace any responses from with something like:

<form method=“POST” action=“”>

Unless Adam looked at the source code of the alleged response from, he would be unaware that his credentials were actually going to be send to Mallory’s malicious web host.

After harvesting the credentials, Mallory continues employing sslstrip to make (possiblly SSL-secured) page requests on behalf of Adam, staying in the middle of the conversation and reading everything unencrypted on the wire. Or she could just reset the connection, forcing Adam to legitimately log in. After all, she got what she set out for; why let Adam continue to consume her resources?

The solution? Only offer login pages over SSL. Pretty simple 🙂

DKOM Opens Door to Malware Rootkits

Posted in Rootkits with tags , , on 27 December, 2009 by __fastcall

I love this one found it in McAfee’s blog posted by Romain Levy

Much malware comes with a kernel rootkit component. Subverting the Windows kernel is indeed the best way to conceal malicious activities on infected systems. To achieve this, many types of malware load malicious device drivers that enjoy full access to all kernel objects. However, this technique is somewhat noisy, and loading a new driver is not really stealthy.

At McAfee Labs we recently ran across a W32/ sample that uses Direct Kernel Object Manipulation (DKOM) to hide itself without loading a new driver. This technique seems impossible at first sight because modifying kernel memory pages from userland is not allowed. However, W32/ takes advantage of an undocumented function exported by ntdll.dll that provides debugging functionalities at the kernel level.

NtSystemDebugControl(), despite being undocumented, has been known for many years. It provides simple functions such as reading from and writing to any location within the kernel memory. And this is exactly what a piece of malware needs to manipulate kernel objects.

W32/ starts by checking what version of Windows it’s running on. This technique won’t work under Windows Vista or Windows 7. If the infected machine is not running Windows XP, W32/ gives up and doesn’t try to hide itself.

If it does find Windows XP, W32/ opens the current process’ token to ensure it has the SeDebugPrivilege, which is required to call NtSystemDebugControl().

To find the process list in the kernel memory, W32/ retrieves the address of the global variable PsInitialSystemProcess, which points to the EPROCESS structure of the system process.

W32/ can now find the process list in memory and go through it to find its own process. It then removes itself from the process list by calling NtSystemDebugControl() to write to kernel memory.

The malicious process is no longer visible in the Windows Task Manager or other tools such as Process Explorer. However, monitoring TCP connections will quickly reveal the presence of an offending process whose name can’t be found.

Rootkit Detective also detects processes hidden via DKOM.

Accessing kernel memory from userland is really bad, but it appears this hole has been plugged in later versions of Windows. Using this method of calling NtSystemDebugControl() to access kernel memory is not trivial, and we don’t expect this technique to be used widely. And this is a good thing because according to Artemis, Windows XP is still the most widely deployed operating system in corporate environments. My colleagues Igor Muttik and Dmitry Gryaznov, and Joel Yonts of Advanced Auto Parts demonstrated this during McAfee’s Focus 09 conference.

Nevertheless, I offer another reminder that the bad guys never hesitate to exploit any feature, whether documented or not, as long as they can gain control over innocent machines.

Log into privileged user accounts only when required, and keep your anti-virus software up to date!

TCP Portals: The Handshake’s a Lie!

Posted in Uncategorized with tags , , on 27 December, 2009 by __fastcall

A friend of mine recently demonstrated during a lunch break (two cheeseburgers I think) a tool sending only a SYN as a response to another SYN to initialize a reverse TCP connection. I really hate protocols, I prefer application stuff, exploits or subverting kernel always look like a magic to me, but there is a protocol that I really love, TCP. Whenever I read a real practical hack that can work I stick with it for days. Anywayz I dont know who discovered it first this guy from BreakingPoint Labs or my buddy. I will reference only BreakingPoint Labs because the other guy actually is working on it so it is a closed work for now.

Posted by Tod Beardsley (2009/11/11)

If you’ve spent any reasonable amount of time around network protocols, you’re probably familiar with some version of this diagram:

3 way handshake

Here, we see the client on the left starting up a conversation with the server on the right. All pretty normal and familar, right? Well, when I was reviewing the RFC again, I noticed something very, very, odd. Disturbing, even. Allow me to quote at some length:

  The synchronization requires each side to send its own initial
  sequence number and to receive a confirmation of it in acknowledgment
  from the other side.  Each side must also receive the other side's
  initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

  Because steps 2 and 3 can be combined in a single message this is
  called the three-way (or three message) handshake.

Do you see what I see? Because I’m thinking, “this is not a three-way handshake. This is a four-way handshake.” The handshake is a lie, born of coalescing steps 2 and 3.

Now, surely, if I just decided to ACK a SYN, then send my own SYN, that couldn’t possibly work, right? Enter PacketFu, my little Ruby library for crafting packets. Turns out, 28 years or so after this RFC was written, clients behave rather strangely when you decide to actually honor ol’ RFC 793. After some experimentation, I have a pretty decent proof-of-concept stack that behaves like so:

4 way handshake

This is the point where things get a little weird. What’s happening here is:

    1) A --> B  SYN my sequence number is X
    2) That's nice. I'm not going to bother to ack that, because...
    3) A <-- B  SYN my sequence number is Y.
    4) A --> B  ACK your sequence number is Y, and my sequence number is X.
    5) A <-- B ACK your sequence number is X

Does this work? You betcha! Take a look at the packet captures, collected from Linux (stock Ubuntu), Apple (stock OSX), and Microsoft (stock Windows XP). These three desktop operating systems are all totally cool with this crazy backwards TCP portal.

But what does it mean? Is this simply a parlor trick, where you can reverse the roles of client and server? How does this affect stateful firewalls? How about inspection devices like IPSes, which often need to have an idea of who the “real” client and server are? How about NAT devices, where the idea of “relatedness” is absolutely tied up with where SYN packets come from.

Clearly, there is a ton of testing work to be done here. Lucky for me, I happen to work at a really advanced testing equipment manufacturer, so I’ve dropped this nugget in the next StrikePack. Now, strikes can employ the “SneakAckHandshake” TCP override option, and all servers simulated will behave in accordance with this crazy backwards handshake. We’ll see how well network inspection gear detects clientside attacks when the client is tricked into behaving like a server.