Archive for the Uncategorized Category

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

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

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 🙂

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.

Building an Anti-Virus engine

Posted in Uncategorized on 27 December, 2009 by __fastcall

This one is taken from Megapanzer

Building an Anti-Virus engine (by Markus Schmall, 2002)

The article will describe the basic ideas, concepts, components and approaches involved in developing an anti-virus program from scratch from a developer’s/software engineer’s point of view. It will focus on the main elements of an anti-virus engine (hereafter referred to as AV engine) and will exclude aspects like graphical user interfaces, real-time monitors, file system drivers and plug-ins for certain application software like Microsoft Exchange or Microsoft Office. Although AV engines running/scanning for single platforms (such as Palm OS or EPOC/Symbian OS) can be designed in the same way, this article will focus on designing multi-platform scanning engines, which are far more complex.


Currently, innovations in AV engines consist primarily of minor changes to existing engines. Complete redesigns of overall engine concepts are rarely seen. One exception is the highly respected Kaspersky AntiVirus (AVP) version 4.0, which was released in early 2002.

The main parts of an AV engine are typically compiled based on the same source code for various platforms, which may have differences in the byte order (little/big endian), CPUs and general requirements on aligned code. All of these considerations must be kept in mind when developing the concept of an AV engine, as the platform on which the engine is designed to run will be a central design consideration. As well, when developing a new AV engine from the ground up, the following consideration or requirements must be considered:

  • Targeted platforms
  • Programming language
  • File access
  • Required modularity.

Targeted Platforms
Continue reading

Hello world!

Posted in Uncategorized on 26 December, 2009 by __fastcall

Welcome to This is your first post. Edit or delete it and start blogging!