Getting started with software shelling-Chapter 1 of AsProtected Notepad

This article introduces AsProtected Notepad, the original author E. Labir.
Summary
When I read the tutorials on the process dump, I can always find something like this: Press F7 N times

Well, this is the Entry Point of the program )......

Use ProcDump (or other tools) to dump the process

Use the software xxx to recreate the input table ####

After reading these words, I still cannot learn anything! What I want is not a small skill that can only take off a shell, it is far from enough. I want to really learn!

In this article, I will try my best to demonstrate some anti-dump or anti-debugging methods that are commonly used by software protectors. My approach is to debug protected programs, find anti-debugging tricks, solve them, and then analyze how to dump the process (naturally, how to prepare for the process dump ).

As an example, I will use the Demo version of AsProtect to protect some common small programs (such as NotePad or Registry Editor ). This article does not involve any commercial procedures (do not waste time asking me about commercial procedures ).

Statement: use the knowledge in this article to do what is your own business

Keywords: Reverse Engineering Software Protection Technology Software Protection System Effectiveness Analysis and Evaluation

Target
In this article, I use AsProtect Demo (This article uses the English version of AsProtect Demo 1.64 as an example) to shell the Notepad program. As I said at the beginning, I will not provide any information about how to crack commercial programs. This article is intended to explain how to make your software safer, rather than teach you how to crack those paid software.

First, you should download the Demo on the AsProtect website and read the help documentation to get a general idea of how AsProtect protects programs.

When shelling, I set all the protection options:

Resource Protection = Yes

Use Max. compression = Yes

Anti-debugger = Yes

Checksum = Yes

Trial info = Limited Trial:

Number of Days = 30

Number of Executions = 10

Reminder Message = Yes

Expiration Date = 2003/12/31

Press "Protect !" Button to display output similar to this in the log window:

Use CRC check protection...

Use anti-debugger protection...

Use 30 trial days limitation...

Use expiration date (31/12/03 )...

Use 10 executions limitation

Use reminder

Use build-in dialogs...

Protection done.

File size :... Compressed ..., Ratio :... %

Introduction
AsProtect features are rich, such:

The specific part of the protection program;
Protects the imported table and prevents the attacker from dumping it;
Increase the difficulty of analysis by adding junk commands;
Provides anti-debugging and self-verification functions
Hide OEP (Original Entry Point, Original Entry Point)
Save the time limit and registration information in the registry.
Provides some special APIs for programmers, such as GetRegistrationInformation ()
In this article, I will not waste time analyzing RSA protection (the Registration protection provided by AsProtect is based on RSA-1024 ). Even if I find the problem in the algorithm, it is very easy for the author to solve it? Asprotect 1.0/1.1/1.11c [Amenesia // TKM!]).

If you use an encryption algorithm to encrypt the program in the Protection Program, the problem is obvious: either you encrypt an important part of the program, then no one can try your Demo completely; either you only encrypt a simple small function (such as "save"), then the hacker can replace the encrypted part with the code you write. Therefore, the encryption algorithm is not important here.

Prepare the following tools and software:

Debugger. I use OllyDbg, which will be used as an example below.
Hexadecimal editor. I use hiew. Other software, such as UltraEdit and WinHex, can also be used)
Procdump: used to dump a program from the memory into a file. (Note: The OllyDbg has the dump plug-in OllyDumpEx, and LordPE is also a good choice .)
You do not need to prepare the following tools:

Input table reconstruction tool (for example, IAT Reconstructor) Note that you can use some tips to make the entire process easier when practicing shelling:
Write a simple small program, shell it, and try to find the entry point (it is helpful to pop up a dialog box at the beginning of the program ). You should definitely leave some tags (for example, uncommon strings) in proper places in the code, which will help you find the information you want. If you attach the debugger to the program to be debugged (instead of loading the target program using the debugger), the labels are more useful.
Shell the notepad and try shelling again. Let's see if your previous conclusions apply?
Use a real shell program to shell and then compare it.
Try to Add/Remove different protection options (whether to use time limit, whether to compress additional resources, etc ).
From Simplicity to complexity, one step at a time, shelling is not difficult for you. This policy can also indicate that it is not a good idea to provide a demo version for shelling a program, right? But surprisingly, it seems that no one has followed this strategy.