Insidious and terrible sndrec32.exe

In this topic you will find a bit of nostalgia, a drop of anger and a kilogram of reverse engineering. Dedicated to those who are familiar with the Sound Recording program firsthand :)

When the sky was bluer, the Sun was shining brighter and the Internet was so inaccessible ... In short, in early childhood I somehow fell in love with the standard Sound Recording program from Windows 98. Without looking for minimal functionality, I even managed to make the simplest “remixes” of the recorded melodies from games to it.

Years passed. Iron became more powerful, and the OS more functional. But Sound Recorder has not changed. Even in Windows XP, it remained the same as it was then. It's time to upgrade your hardware. 3 gigabytes of RAM - before and to dream of this was not necessary. That certainly should be enough for everyone! So it was, until it came to the very “Sound Recording”. After trying to record a small sound, the program calmly objected that it did not have enough RAM.

Not enough memory available to complete this operation. Quit one or more applications to increase available memory, and then try again.

Which of course outraged me. Closed all programs, tried to reboot - it did not help. A terrible thought about a problem in the program crept into my head, and my fears were justified: Microsoft says that if there are more than 2 gigabytes of RAM, the program reports a lack of memory, and this is a feature of the application architecture. Moreover, no adequate way to solve the problem is proposed, except to reduce the amount of physically available memory. As they say, use what is.

Despite the request of Sound Recorder to complete unnecessary applications, I tried to take up more free RAM. Oddly enough, as soon as the free memory mark fell below two gigabytes, the error disappeared.

Obviously, in the code for checking the amount of free memory, the developer declared a variable:

int AvailableMemory;

Because of what, the number of free bytes is considered as a signed number. When the amount of free memory is more than two gigabytes, the first bit is set to one, so the number looks like a negative. To fix the error, it would be enough to write:

unsigned int AvailableMemory;

But Microsoft is not doing this, probably to stimulate the transition to Windows Vista or 7 ( just kidding) , where Sound Recording, alas, is a completely different program.

So let's try to solve the problem on our own.

Denial of responsibility

The work was carried out exclusively for educational purposes, and in no case is a call for a violation of applicable law. The author does not bear any responsibility for the illegal use of the submitted materials.

Tools

IDA Pro - for disassembling and researching applications
Flat Assembler - to generate the necessary machine codes
Hexplorer - to make changes to the finished executable file
Resource Hacker - for exploring resources

More details about these programs can be found in the previous article on the topic of reverse engineering " Extending the functionality of finished programs ."

Study

To determine the number of free bytes in RAM, the obsolete GlobalMemoryStatus function is used - we see it in the “Sound Recordings” import table . Since this function is used in several places, the line number in the resources displayed on error will help us more accurately determine the desired section of code — this is line number 6Eh.

Fun fact - the GlobalMemoryStatus function, for compatibility purposes, returns no more than 2GB of free RAM, regardless of how much you actually have. That is, the high-order bit of the number of free bytes in any case should not be set to one, and the number should not be interpreted as negative. In order to find a problem, you need to understand that there are different types of conditional jumps - for signed and unsigned data.

Consider the first condition. As you can see, the result of the GlobalMemoryStatus function is compared with a value equivalent to 1MB. And without looking at using a sign-dependent jump command JGE, this code, in light of the limited result of GlobalMemoryStatus, always works correctly. A problem pops up when checking the second condition. The program calculates the sum of the memory already occupied by the recorded sound and free memory (which sets the most significant bit of the number), and compares the resulting number with the number of bytes needed for allocation. Naturally, the transition command for signed data JLEwill not work correctly, and for correct operation it must be replaced with a command JBE(for unsigned data). That is, our task is to replace one team.

Patch

Physical offset of the team we are interested in: 6BD5h. The machine code JLEis 7Eh. To get the machine code for the command, JBEcompile the following code in Flat Assembler:

use32 jbe fake fake:

We get a file in which the first byte is the code of the desired command - 76h. The only thing left is to make the necessary changes to the executable file. To do this, use the HEX editor.

Result

sndrec32.zip (119 Kb) - the original and revised version of the program from the English Windows XP SP3.

Why was this needed

Just for fun. You should not look for any rationalistic motives here. There are many other very worthy and more convenient programs for recording and editing audio. Just the very ability to run and work in the “same program” warms the soul :)

Tags: