ResEdit Named Entries Two Buffer Overflow Vulnerabilities

In this post, i will discuss two vulnerabilities that i have found in ResEdit 1.5.11-win32, a known resource editor. Since they are very similar, i will discuss them as if it is only one vulnerability.

It is a buffer overflow but what is different in this vulnerability is that the buffer is located in the .data section of ResEdit.exe. It is neither a stack-based nor a heap-based buffer.

The vulnerability occurs when ResEdit tries to copy names of named resource entries to an inadequate buffer.

In the image below, You can see how a normal named entry looks like.

You can see that the length field holds 0xC, which is the number of unicode characters of the string "KNOWNRESTYPE" ( no null terminators are used).

By placing a higher value in the length field and extending the string to be of matching length, we then have a buffer overflow. In the image below, i have used 0xF63 as the malicious length field.

Let's have a look at code in OllyDbg.

As you can see in the image above, there is a loop at 0x46A93F. In this loop, named entries are processed and each name is copied in an unsafe manner to the buffer at 0x4EB118 by calling the "_wcsncpy" function with the "count" parameter set to the value of the length field.

N.B. The second vulnerability exists at 0x46A5CD.

POC for the first vulnerability can be found here.

POC for the second vulnerability can be found here.

You can follow me on Twitter @waleedassar

PE Explorer Heap Overflow Vulnerability

I have found a vulnerability in PE Explorer v1.99 R6. This heap overflow can be exploited to execute code arbitrarily. It is similar to the one of Resource Tuner shown in a previous post.


The vulnerability occurs due to an insufficient check for the size of memory to be allocated. It can be triggered by manipulating the "Size" field of any RT_STRING resource. Other resource types may also be subject to the same vulnerability.

If we change the "Size" field to a value like 0x7FFFFFFF, we can easily corrupt the heap.

Now let's have a quick look at this in Olly.

I will dissect this vulnerability into 5 parts for sake of clarification.

Step (1)

The value of the "size" field is fetched and stored locally at [ebp-48] . So, we now have 0x7FFFFFFF at [ebp-48].

Step (2)

The value of the "size" field is then passed to the function at 0x571CD4 (in disassembly in the image below, i named it as "AdjustInteger"). Upon return of the "AdjustInteger" function, we have 0x80000000 as the new size. The new size is stored locally at [ebp-44].

Step (3)


The new size value (0x80000000 from step 2) is then incremented and passed to the function at 0x4026A8 (the one responsible for heap allocation). This function converts its input value into an index. The index is then used to extract a memory block of corresponding size. At the point of converting the requested size into an index, the huge value is truncated into a smaller value and a much smaller memory block than requested is returned.

Step (4)

The function at 0x402B14 ("memset" equivalent) is then called with the huge value as its "num" parameter. Luckily, the function quickly returns if the "num" parameter is a signed value.

 Step (5)

The function at 0x4027E0 ("memcpy" equivalent) is called with the "num" parameter set to the huge integer stored at [ebp-48] (from step 1) causing heap corruption.

A Proof Of Concept can be found here. Tested on XP SP3.

N.B. Increasing the size of the resource increases chances of corrupting the heap, something that can kill all functionalities of PE Explorer.

You can follow me on Twitter @waleedassar

Resource Hacker Heap Overflow Vulnerability

I have discovered a vulnerability in Resource Hacker 3.6.0.92. The vulnerability occurs due an improper way of reading strings of RT_STRING resources.

In the images below, you can see how the string table looks like.

At address 0x457C6F, there is a loop that goes through strings in the string table one by one.

The "readStringIntoBuffer" function converts the unicode string into its ASCII form. The new ASCII string is stored in a heap-based memory block. After the "readStringIntoBuffer" function returns, the "parseIndiv_string" function is called to parse and format strings in order to be display them properly.

N.B. I have assigned the names, readStringIntoBuffer and parseIndiv_string for functions at 0x45FAE4 and 0x451C00 for sake of simplification.

We have to go abit deeper and look at the "parseIndiv_string" function since it is the vulnerable function.

The "parseIndiv_string" function allocates a new heap-based memory block with size equal to the ASCII string length plus 0x32. A question arises here, why 0x32?

After the new block is allocated, a loop is entered. Inside this loop, the ASCII string is copied to the new block byte by byte. But if a TAB character (0x09) or line feed character (0x0A) is found, the two characters "\t" in case of 0x09 or "\n" in case of 0x0A are copied to the new block.

So, if we have a string with more than 0x19 (0x32/2) TABs (or line feeds), we will have a heap overflow.

A POC can be found here.

You can follow me on Twitter @waleedassar

Resource Tuner Heap Overflow Vulnerability

In this post, i will be talking about a heap overflow vulnerability that i found in Resource Tuner v1.99 R6. This heap overflow can be exploited to execute code arbitrarily. The vulnerability occurs despite checks implemented by Resource Tuner.

As you see in the image below, the string (RT_STRING) resource has the RVA (relative virtual address) and size of the strings set to 0x3060 and 0x36.

If we change the "size" field to something like 0x7FFFFFFD, we can corrupt the heap.

Now let's have a quick look at this in OllyDbg.

I will dissect the vulnerability into 5 parts for sake of clarification.

Step (1)
The value of the "size" field is fetched and stored locally at dword ptr[ebp-60] .

Step (2)

The value of the "size" field is then passed to the function at 0x5330F0 (in disassembly in the image below, i named it as "AdjustInteger"). Upon return of the "AdjustInteger" function, we have 0x80000000 as the new size.

Step (3)

The new size value (0x80000000 from step 2) is then incremented and passed to the function at 0x4026A8 (let me name it as "allocateHeapCached"). The "allocateHeapCached" function converts its input value into an index. The index is then used to extract a memory block of corresponding size. At the point of converting the requested size into an index, the huge value is truncated into a smaller value and a much smaller memory block than requested is returned.

Step (4)

The function at 0x00402B14 ("memset" equivalent) is then called with the huge value as its "num" parameter. Luckily, the function quickly returns if the "num" parameter is a signed value. Cool!!!.

Step (5)

The function at 0x004027E0 ("memcpy" equivalent) is called with the "num" parameter set to the huge integer stored at dword ptr[ebp-60] (from step 1) causing heap corruption.

A Proof Of Concept can be found here. Tested on XP SP3.

You can follow me on Twitter @waleedassar