How to open exe application code. How to open a .DLL or .EXE file in the resource editor. Error: The file is not an EXE or DLL file. At all

With help Resource Tuner you can open executable files such as .EXE, .DLL, .OCX, screensavers (.SCR) and many others. By opening the file, you gain access to the file's resources and can replace icons, cursors and graphics in various formats, change lines in menus, dialog boxes and other user interface elements.

However, it is worth keeping in mind that the resources in the executable file are separate from the program code, and by changing the program interface, you do not gain access to the program code. Using the resource editor, you can change program controls. The program code cannot be changed using the resource editor.

For more serious changes (which, however, will not lead to anything good without sufficient experience in programming applications for Windows), we recommend using PE Explorer (PE file structure editor) or FlexHex (hex editor for binary files).

Opening an EXE or DLL file in Resource Tuner

Supports multiple ways to open files. To open a file for viewing and editing, click the button Open File on the toolbar or select the command File > Open from the menu. The drop-down menu next to the button on the toolbar gives you quick access to a list of recently opened files. The same list can be obtained with the command File > Recent Files from the program menu. The number of files in the list is configured in the dialog Customize.

You can also open the file using Resource Tuner directly from Windows Explorer by right-clicking the file and selecting Open with Resource Tuner from the context menu.

Or you can simply drag and drop the file icon from Windows Explorer onto the Resource Tuner icon on the desktop or onto the window of the running Resource Tuner.

You can also open the file from the command line.
For example: restuner.exe filename.exe

When opening a file, Resource Tuner performs several automatic operations: unpacks the file if it is detected that it was packed using UPX, then checks the structure and resources of the file for possible errors, and finally rebuilds damaged resources in accordance with the executable file format specification.

Errors when opening a file

If an error occurs when opening a file, it is most likely for three reasons: the file is protected, the file is 16-bit, or it is not an executable file at all.

1. Error: The file is damaged, compressed by a packer or protected by a protector.

There is a very good chance that the file has been compressed to reduce its size. There are dozens of packers and protectors for executable files, and new ones appear all the time. Resource Tuner supports unpacking of only one, but the most common packer - UPX. Other packers are not supported, and you will have to unpack the file yourself before you can open the file for viewing or editing.

This situation is not considered a program error. We are not going to fight the attempts of other program authors to protect their creations from hacking, nor support the unpacking of several dozen different packagers, including both commercial products and homemade products.

2. Error: The file is defined as 16-bit NE Executable. This format is not supported!

Our programs only work with 32- and 64-bit PE files. The NE format (short for "New Executable") is a 16-bit application format left over from older versions of Windows 3.xx. With the advent of Windows 95, this format is considered obsolete and is not used, although it can be executed on modern platforms from Microsoft. We do not support 16-bit files and do not intend to support them.

3. Error: The file is not an EXE or DLL file. At all!

Resource Tuner does not detect a file by extension. If you rename the extension of an executable file, say, correct .EXE to .TXT, or remove the extension altogether, Resource Tuner will not be fooled by this: when opening a file, the program analyzes the file header inside the file, and does not look at the extension at all.

Therefore, if Resource Tuner tells you that the file is not executable, then it is so. If for some reason someone added a .DLL extension to a text file in a game package, then the file does not cease to be text and does not become a dynamic library. Don't be fooled by the file extension.

Which files do not make sense to open in the resource editor?

Despite the fact that Resource Tuner is designed to open and edit any 32/64-bit executable files, there are some types of EXE files that have virtually no resources.

1. Files created using Visual Basic.

In such files, there is nothing in the resources section except an icon and version information. Lines and dialogue in programs written in Visual BASIC are stored in their own proprietary format, and they do not use the standard resource section.

2. EXE files of gigabytes or more in size.

Since Resource Tuner is a 32-bit program, there are natural limitations for placing the image of the file being opened in virtual memory within the first gigabyte. A file of a gigabyte or more in size simply will not fit there.

3. Self-extracting archives in the form of EXE files.

In such files, there is nothing in the resources except an icon and version information, and maybe even that. Essentially, this is archived data equipped with a subroutine for unpacking.

4. Installers of other programs.

In such files, there is nothing in the resources except an icon and version information. Very similar to point 3. An installer file can be thought of as a container that contains another .EXE file in compressed form and a routine to extract it. In addition, programs for creating installers use different algorithms to store archived data within themselves.

Download your free trial!

Resource Tuner runs on all versions of Windows
from 2000 and XP to 8 and 10.

Minimum system requirements:
Intel Pentium® or AMD K5 166 MHz processor
16 MB RAM

Sometimes CODE.EXE and other EXE system errors can be related to problems in the Windows registry. Several programs can use the CODE.EXE file, but when those programs are uninstalled or modified, sometimes "orphaned" (incorrect) EXE registry entries are left behind.

Basically, this means that while the actual path of the file may have changed, its incorrect former location is still recorded in the Windows Registry. When Windows tries to look up these incorrect file references (file locations on your PC), CODE.EXE errors can occur. Additionally, a malware infection may have corrupted the registry entries associated with Game Cracker. Thus, these corrupt EXE registry entries need to be fixed to fix the problem at the root.

Manually editing the Windows registry to remove invalid CODE.EXE keys is not recommended unless you are PC service professional. Mistakes made when editing the registry can render your PC inoperable and cause irreparable damage to your operating system. In fact, even one comma placed in the wrong place can prevent your computer from booting!

Because of this risk, we highly recommend using a trusted registry cleaner such as %%product%% (Developed by Microsoft Gold Certified Partner) to scan and repair any CODE.EXE-related registry problems. Using a registry cleaner, you can automate the process of finding corrupt registry entries, missing file references (like the one causing the CODE.EXE error), and broken links within the registry. Before each scan, a backup copy is automatically created, allowing you to undo any changes with one click and protecting you from possible damage to your computer. The best part is that eliminating registry errors can dramatically improve system speed and performance.

Warning: Unless you are an experienced PC user, we DO NOT recommend manually editing the Windows Registry. Using Registry Editor incorrectly may cause serious problems that may require you to reinstall Windows. We do not guarantee that problems resulting from incorrect use of Registry Editor can be corrected. You use Registry Editor at your own risk.

Before you manually repair your Windows registry, you need to create a backup by exporting a portion of the registry associated with CODE.EXE (eg. Game Cracker):

Click on the button Begin.
Enter " command" V search bar... DON'T CLICK YET ENTER!
While holding down the keys CTRL-Shift on your keyboard, press ENTER.
A dialog box for access will be displayed.
Click Yes.
The black box opens with a blinking cursor.
Enter " regedit" and press ENTER.
In the Registry Editor, select the CODE.EXE-related key (eg. Game Cracker) you want to back up.
On the menu File select Export.
On the list Save to select the folder where you want to save the Game Cracker key backup.
In field File name Enter a name for the backup file, for example "Game Cracker backup".
Make sure the field Export range value selected Selected branch.
Click Save.
The file will be saved with extension .reg.
You now have a backup of your CODE.EXE-related registry entry.

The following steps for manually editing the registry will not be described in this article, as they are likely to damage your system. If you would like more information about editing the registry manually, please check out the links below.

*** EVERYTHING WRITTEN SHOULD BE USED FOR EDUCATIONAL PURPOSES ONLY! ***

-Tools-
OLLYDBG
The application into which we will insert our code.
It will be NOTEPAD.EXE.
It is advisable to make a copy of the file.
This is all

-Start-
Our goal is to paste our code into Notepad.EXE.
We will paste a simple MessageBox for launch Notepad.
Let's launch Notebook, and make sure that it starts normally.

If you're sure it's original Notepad.exe, open it in Olly.
The following window will appear:

In order to insert our code, we need a place for this in the program code.
There are a lot of things in exe files CodeCaves. These are bytes ( DB 00).
You just need to scroll the program code a little below the beginning and you will see CodeCave:

The red rectangle highlights the piece with CodeCave"ami?
You can insert any code here, and your program will not crash.
If you know the API function to call MessageBox just skip these lines.

***** BEGIN QUOTE FROM THE WIN32 PROGRAMMER'S MANUAL
The MessageBox function creates, displays, and operates a message box.
The message box contains an application-defined message and title,
plus any combination of predefined icons and push buttons.
Int MessageBox(
HWND hWnd, // handle of owner window
LPCTSTR lpText, // address of text in message box
LPCTSTR lpCaption, // address of title of message box
UINT uType // style of message box
);
***** END QUOTE FROM THE WIN32 PROGRAMMER'S MANUAL
Click to expand...

That's all you need to know about MessageBox.
Let's do something with CodeCaves.
In order to use MessageBox, we need to create the text that we will display in
MessageBox. In the next picture I have highlighted a couple of lines with CodeCaves And
showed the menu BinaryEdit for you (we will need it).

If you pressed Binary=>Edit or (CTRL+E) you will see the following window.
Just fill out the top field the same way I did.
Click OK and you will see the modified code (highlighted in red):
Now press CTRL+A to re-analyze the code.
OK! Now, if you want to make the title of the message different, duplicate this line
(this is like the second parameter of a procedure call).

-A little assembler-

The time has come for A.S.M. A
Here's a good example!

PUSH 0 ; BUTTONS =<ТОЛЬКО КНОПКА OK>
PUSH 1008751 ; CAPTION = OUR ADDRESS "INJECTED NOTEPAD"
PUSH 1008751 ; MESSAGE = THE SAME.
PUSH 0 ; ICON =<БЕЗ ИКОНКИ>
CALL MessageBoxA; Call MessageBoxA with the specified parameters.
Click to expand...

These lines entered in Ollie will look like this:

Do you see the arrow?! IT IS VERY IMPORTANT!
After all, if we just run the program, nothing will happen. Why?
Because our little procedure hasn't been called anywhere yet!
You need to write down the address of its beginning, i.e. address " PUSH 0", because we need to make a jump
to our procedure and come back
Great. Now go back to the beginning of the program ( button C on the toolbar Ollie, or as in the figure).

Now we are on the very first line that will be executed.
You still remember that our goal is to insert your code?
Then we will continue!
Select a couple of lines from the beginning and copy them to the clipboard.

Paste them into any text reactor - they will be useful to us later.
Return to the beginning of the program again.
(The picture above is PUSH 70).
Double clicking on this line will show us the following window.
You need to enter " JMP<адрес PUSH 0, который мы записывали ранее> "
Click the Assemble button and the program code will change again, i.e. changes will be highlighted in red.

Look at the red rectangle! This is the address we need to jump to when our code is complete.
But if we jump here after the injection, the program will execute as if without it
So there's one more thing to do!
Compare the new beginning of the program with the old one that we copied into a text editor.
You will see that two lines have been rewritten! But we need them for normal operation.
programs without errors. Find the lines that have been overwritten.
In my case it was the following code:

PUSH 70
PUSH NOTEPAD.01001898
Click to expand...

Click on the first line of code (our JMP) and press ENTER.
You will be taken to the inserted MessageBox calling code!
After CALL MessageBoxA we will need to insert these two lines AND jump back!

THAT'S ALL!
(It’s easy to check if the jump is working correctly - Click on it ENTER!)
To save our “modified” Notepad, follow the steps as in the picture:
Then press Copy All. In the window that appears, you need to right-click
select menu item Save File and save under a new name. Run the file:

The added function should not be called directly, as it is written in the article, but in a slightly different way.

First, after adding the procedure to the imports, you need to know it FT (FirstThunk "IAT"). It is displayed here:

Remember it!(I'll call him TrueAddress)

Now let's move on to the place where we will write our code ( Code Caves).
Now let's add the correct call to our function MessageBoxA. To do this we write:

JMP [[B]TrueAddress]

If Olly automatically identified the new code as a procedure call - this is very, very good! So it will be easier further. If not, then you calculated the import address incorrectly. Double check!
Write down the address of this JMP(I'll call him TrueCall).

Now we do everything as in the article (inserting lines, PUSH, etc.), but instead of:

Call MessageBoxA

you need to write:

Call[B]TrueCall

The rest remains the same.

Click to expand...

It is impossible to disclose the source code if they have tried to ensure security (especially if it is a proprietary item).

But there are ways to fully or partially reveal the code.

IDA Pro is the best free cracker, some macros may allow you to convert the code back. But not always. Borland products are especially good.
Hiew.Exe is a free utility, very small, that allows you to edit assembly language code. You can edit text and integer constants. You can even use it to “translate” the program into another language, erase the name of the company, etc.
If there is a PDB file, or debug-info is attached to the file, then the code can be obtained in the development environment (if debug-info is complete) it can rarely be used. It is impossible to get the source code, but you can get “line numbers and source names”, as well as the names/values of all constants, local variables, avoid “function fragmentation” and also get classes with class filling (almost all structures except the program text) that will greatly simplify your understanding of how the program works. For some libraries (dlls), pdb files can be downloaded separately. It is unlikely that a self-respecting company will allow the PDB of its valuable product to leak.
Debug info, there is DebugInfo information built into the exe. If there is such information and the corresponding utility (For example, Delphi is compiled on Borland, and it is available), then you can do something similar to the previous point. But it is unlikely that a self-respecting company will make such a “stupid” mistake (similar to pdb).
If the file is written in C#, it can be almost completely viewed in code using disSharp (such programs “include” only mscorlib in the import table and that’s all). DisSharp is bad at disassembling some parts of the program, but perhaps its paid version or paid versions of similar utilities reveal the code better.
If the file is written in FoxPro, clipper and other similar byte-code languages, it is opened by special utilities (Refox for example).
The exescope.exe utility ResourceHacker.exe and similar utilities allow you to view the header, connected libraries (using them you can understand what the program is written in) and edit program resources (resource forms including Delphi, icons, pictures, tables of resource strings).
If it is known how the code was created, I think there are special utilities that can open it (they are paid and inaccessible).

Again, this is provided that there is no code packer (then you need to first apply a depacker), encryptor/self-modifying code. If it is not broken by an obfuscator, it cannot be unraveled. The larger the code, the more difficult it is to understand.

P.S. My personal opinion is that everything is revealed and hacked, but it takes a lot, a lot of time. Perhaps a year or more (depending on experience and tools, there are no good tools freely available).