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 program " Sound Recording " firsthand :)

When the sky was bluer, the sun was shining brighter, and the Internet was so inaccessible ... In short, in early childhood, for some reason, I fell in love with the standard Sound Recorder program from Windows 98. Without looking at the minimum functionality, I even managed to do the simplest remixes she also recorded melodies from games.

Years went by. Iron was becoming more powerful, and the OS is more functional. But "Sound Recording" 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 dream about this was not necessary. This 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 countered that it did not have enough RAM.


Which of course angered me. I closed all the programs, tried to reboot - it did not help. The terrible thought about the problem in the program crept into my head, and my fears were justified: Microsoft states that if there is more than 2 gigabytes of RAM, the program reports about its shortage, and this is a feature of the application architecture. Moreover, no adequate way to solve the problem is proposed, except for reducing the amount of physically available memory. As they say, use what you have.
')


Contrary to the request of Sound Recordings 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 sign 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 one. To correct 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 (joke) , where Sound Recording, alas, is a completely different program.


So try to solve the problem yourself.

Denial of responsibility

The work was carried out solely for educational purposes, and in no case is it a call for violation of the current legislation. 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 learning resources

More information about these programs can be found in the previous article on the topic of reverse engineering " Expansion of the functionality of ready-made programs ."

Study

To determine the number of free bytes in RAM, the outdated GlobalMemoryStatus function is used - that is what we see in the “Sound Recording” import table . Since this function is used in several places, the line number in the resources will help us to more precisely determine the required code segment, the error number is the line number 6Eh.

The funny thing is that the GlobalMemoryStatus function for compatibility purposes returns no more than 2GB of free RAM, regardless of how much you actually have. That is, the most significant 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 transitions - 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 the use of the JGE branching command, this code always works correctly in light of the result constraint of GlobalMemoryStatus. The problem comes up when checking the second condition. The program calculates the amount of 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 the allocation. Naturally, the transition command for JLE data JLE will not work correctly, and for correct operation it must be replaced with the JBE command (for unsigned data). That is, our task is to replace one team.

Patching

The physical offset of the team of interest to us: 6BD5h. JLE machine code is 7Eh. To get the JBE machine code, JBE compile the following code in Flat Assembler:

use32
jbe fake
fake:

Get the file in which the first byte is the code of the desired command - 76h. It remains the case for small - to make the necessary changes to the executable file. To do this, use HEX editor.

Result

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

Why was it necessary

Just for fun. You should not look for any rationalistic motives here. There are many other very decent and more convenient programs for recording and editing audio. It's just that the very opportunity to launch and work in “that very program” warms the soul :)