Archive for the Windows API Category

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


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. 😉

Blackhat Demo Explained

Posted in Exploits, Windows API with tags , , on 27 December, 2009 by __fastcall

It was a hot morning approx. 9 in Vegas waiting for the John’s McDonald and Chris’ Valasek lecture about Heap Exploitation, it was an advanced lecture, and dizzy I was, so I didn’t understand much. Those guys posted a demo explanation about the attack. You can also download their paper. BHUSA09-McDonald-WindowsHeap-PAPER

Posted by Chris Valasek on December 09, 2009 at 11:08 AM EST.


As several of you may or may not remember, John McDonald and I did a presentation this year at BlackHat on Practical Windows Heap Exploitation. In this presentation we had a video that claimed to show reliable heap exploitation on Windows Server 2003 lacking a fully controlled environment. Now that our advisory is published we can finally prove to you that the video was not fake; explaining the vulnerability and some of our techniques. Continue reading

Reflecting on NTLM Reflection

Posted in Windows API with tags , , on 27 December, 2009 by __fastcall

I found an interesting article this morning about NTLM reflection attack on IBM security blog

Posted by Takehiro Takahashi on December 17, 2009 at 2:51 PM EST.

Since late 2008, Microsoft has been releasing updates for ‘NTLM reflection attack’ which allows an attacker to use a victim’s NTLM credentials in order to gain access to the victim’s shared resources. These updates correct programs’ behavior to use Microsoft’s protection mechanism against the reflection attack. Here is a quick list of applications fixed in last 12 months:

MS08-068 SMB remote code execution
MS08-076 Windows media component remote code execution
MS09-013 Windows HTTP Service remote code execution
MS09-042 Telnet remote code execution

After reviewing MS08-076, we spent some time auditing other applications that support the NTLM authentication protocol, and discovered Mozilla Firefox, Opera and Google Chrome were all vulnerable to the reflection attack. As of 12/17/09, all three vendors have already released updates for their products, and a security advisory has been published from Mozilla.

Unfortunately, none of these patches, as pointed out by H D Moore, protects users from reflection attacks when multiple victims are involved (i.e. attacker’s server relays VictimA’s credential to VictimB). This happens because the scope Microsoft’s NTLM reflection attack protection is local only, and the NTLM protocol provides no provision for protecting users from the reflection attack. One can imagine any Active Directory based networks are seriously affected by this issue.

In this article we discuss the internals of NTLM authentication in detail in order to understand the full extent of the problem. For readers’ convenience, we refer to two types of reflection attacks as two-party reflection attack and multi-host reflection attack. In a two-party reflection attack, attacker uses a stolen credential against the same victim, where as in a multi-host reflection attack, the credential is forwarded to a host other than the original victim. Last but not least, IBM ISS customers have been protected against both types of reflection attack by NTLM_MultiProto_Reflection since April 14, 2009.
Continue reading

Uniquely Identifying a Module’s Build

Posted in Windows API with tags on 27 December, 2009 by __fastcall

I remember once having a conversation with tweekier whether there is an effective way to verify if a build is valid and compiled from a trusted source. Surfing around found this post on Johannes’ Passing blog

It is common practice to embed a version resource (VS_VERSIONINFO) into PE images such as DLL and EXE files. While this resource mainly serves informational purposes, the version information is occasionaly used to perform certain checks, such as verifying the module’s suitability for a particular purpose.

Under certain circumstances, however, this versioning information may be too imprecise: Versions are not necessarily incremented after each build, so it is possible that two copies of a module carry the same versioning information, yet differ significantly in their implementation. In such situations, identifying the actual build of the module might become neccessary.

The most common, but by no means the only situation in which this applies in practice concerns debugging — to identify the PDB file exactly matching a given module, the debugger must be able to recognize the specific build of a module. It thus does not come as a surprise that all images for which debugging information has been generated contain a dedicated identifier for this purpose: The CodeView signature GUID.

Summarizing what Oleg Starodumov has covered in more detail, cl, when directed to generate a PDB file, implicitly creates this GUID and, along with the path to the PDB file, embeds this data into the PE image. For current versions, the relevant structure used to encode this information is CV_INFO_PDB70, which seems to have been documented once, but not any more:

    typedef struct _CV_INFO_PDB70
      ULONG CvSignature;
      GUID Signature;
      ULONG Age;
      UCHAR PdbFileName[ ANYSIZE_ARRAY ];

In order to be able to locate the structure within the PE image, a directory entry of type IMAGE_DEBUG_TYPE_CODEVIEW is written to the image’s debug directory. The following code listing demonstrates how to obtain the signature GUID of an image:

    #define PtrFromRva( base, rva ) ( ( ( PUCHAR ) base ) + rva )

    static PIMAGE_DATA_DIRECTORY GetDebugDataDirectory(
      __in ULONG_PTR LoadAddress
      PIMAGE_DOS_HEADER DosHeader =
        ( PIMAGE_DOS_HEADER ) ( PVOID ) LoadAddress;
        PtrFromRva( DosHeader, DosHeader->e_lfanew );
      ASSERT ( IMAGE_NT_SIGNATURE == NtHeader->Signature );

      return &NtHeader->OptionalHeader.DataDirectory

    NTSTATUS GetDebugGuid(
      __in ULONG_PTR ModuleBaseAddress,
      __out GUID *Guid
      PIMAGE_DATA_DIRECTORY DebugDataDirectory;
      ULONG Index;
      ULONG NumberOfDebugDirs;
      ULONG_PTR ModuleBaseAddress;
      NTSTATUS Status;

      DebugDataDirectory  = DebugDataDirectory( ModuleBaseAddress );
      DebugHeaders    = ( PIMAGE_DEBUG_DIRECTORY ) PtrFromRva(
        DebugDataDirectory->VirtualAddress );

      ASSERT( ( DebugDataDirectory->Size % sizeof( IMAGE_DEBUG_DIRECTORY ) ) == 0 );
      NumberOfDebugDirs = DebugDataDirectory->Size / sizeof( IMAGE_DEBUG_DIRECTORY );

      // Lookup CodeView record.
      for ( Index = 0; Index CvSignature != 'SDSR' )
          // Weird, old PDB format maybe.

        *Guid = CvInfo->Signature;
        return STATUS_SUCCESS;


Self delete program

Posted in Windows API with tags , on 26 December, 2009 by __fastcall

Ok this one is for my friend tweekier. There are many ways to do this just choose one. Surprisingly I ‘ve seen one in Megapanzer that is quite simple, not sophisticated, I don’t like it at all for coding anywayz here it is.

void deleteYourself()
  char lCommand[MAX_BUF_SIZE + 1];
  char lFile[MAX_BUF_SIZE + 1];

  ZeroMemory(lCommand, sizeof(lCommand));

  if((GetModuleFileName(0, lFile, sizeof(lFile)) != 0) && (GetShortPathName(lFile, lFile, MAX_BUF_SIZE) != 0))
    _snprintf(lCommand, sizeof(lCommand) - 1, "/c del %s >> NUL", lFile);
    GetEnvironmentVariable("ComSpec", lFile, MAX_PATH) && ShellExecute(0, 0, lFile, lCommand, 0, SW_HIDE);
  }// else

If you want to look for more neat, complex and l33t ways to do this go here

If you are nuts enough please check this one too