Analysis of a CAD Drawing Control

[Article Title]: Analysis of a cad Drawing Control
[Author]: LiXMX
[Protection method]: serial number
[Language]: Borland Delphi 6.0-7.0
[Tools]: PEiD, Regmon_fix, DEDE, UltraEdit
[Operating platform]: Win XP
[Software description]: A plug-in for vector graph rendering tool in Delphi and C ++ Builder environments. It has simple functions but is more practical.
[Author's statement]: I am a newbie. I posted a post because I haven't published a decent article since I registered it. I have been registering for many years. I am ashamed to say that I am not a technical expert. If it conflicts with the version rules, please delete it as an administrator. Thank you.
[Cause]: the reason for this analysis is that the software authorization method makes me uncomfortable (PS: I have already paid for it >_< ). Currently, serial number authorization is used. You must re-apply each time you reinstall the system.
 
However, the dongle is provided, but the dongle only supports Delphi and cannot be used in C ++ Builder. Therefore, only C/C ++'s local dish is hurt, and discrimination is deeply felt, so it is cracked.
 
-------------------------------------------------------------------------------
 
[Process ]:
 
The program provided by the other party is divided into three parts: the control installation program, the machine code generation program, and the dongle.
 
Dongle:
I will not talk about this. Wait for a while to study it.
 
 
Machine code generator program:
After the program runs, an 8-bit machine code is generated. Generally, the machine code is CpuID, the partition volume number, and so on.
Then, the CpuID is excluded by means of "the Code is the same every time as long as the system is not reinstalled", and the partition volume number is initially determined.
Then you can use PEiD to view the Import and find that the GetVolumeInformation function is called, and it is almost determined that it is the partition volume number.
The most funny thing is that when I input the dir command in CMD, I found that the serial number of drive C is the generated machine code, dizzy, clear text ......
Let's see where he put my registration number?
I monitored it using Regmon_fix and found that the Registry was written.
 
Then you can determine his workflow:
1. Obtain the serial number of drive C and send it as the machine code to the author;
2. The author calculates the registration code based on the machine code provided by the user and sends it to the user;
3. the user uses "machine code generator program" to import the registration code to the local registry;
4. When the control is started, it checks whether the serial number of drive C matches the registration code in the registry.
 
So here, the first method of cracking is already available: you only need to change the serial number of your drive C to the same as that of a genuine user to use the control normally.
 
 
Control Installer:
After learning about the authorization process, we can see from the four steps of the authorization process that the control also needs to obtain the serial number of the C disk at startup, while using the serial number and registration code of drive C for some kind of verification.
So we started from the control program itself. First, we checked all the DCU files in the control installation directory to see if there are any DCU files available.
So we found two files: Encryption. hpp and Encryption. dcu (a very straightforward file name ).
Now let's look at him first to see if it's a bait or fruit.
The Encryption. hpp header file contains three function definitions:
Extern PACKAGE AnsiString _ fastcall GetDiskSerialID (char cDriveName );
Extern PACKAGE AnsiString _ fastcall Encrypt (const AnsiString str );
Extern PACKAGE AnsiString _ fastcall Decrypt (const AnsiString str );
I went here. This is not exactly the three steps of getting the disk serial number, encoding, and decoding (it seems that the author has never thought about anti-cracking, hey, no money)
 
Then, the dede dcu Dump function is used to obtain the disassembly code of the DCU.
 
The following statements are found in USES in DCU:
Windows
{
T: DWORD, A: SetErrorMode,
A: SEM_FAILCRITICALERRORS,
A: MAX_PATH,
A: GetVolumeInformation
}
GetVolumeInformation appears. It seems that the correct location is found.
 
Now that GetVolumeInformation is available, Encrypt and Decrypt should be used to Encrypt and Decrypt the C drive serial number and registration code.
 
At first, my idea was to modify the DCU to determine whether the registration code was correctly redirected. I tried to crack it, But I continued to look down and found that the author gave me another surprise here ......
 
The disassembly of the extern PACKAGE AnsiString _ fastcall Encrypt (const AnsiString str) function is as follows:
 
PS: I have to feel that DEDE is indeed a nightmare for DELPHI programmers !!!
 
Function Encrypt (str: System. AnsiString): System. AnsiString;
Var
Result Result: System. AnsiString;
I: System. Integer;
Sn: System. AnsiString;
Begin
00000000: 55 PUSH EBP
00000001: 8B ec mov ebp, ESP
00000003: 83 C4 ec add esp,-20
00000006: 53 PUSH EBX
00000007: 33 C9 xor ecx, and ECX/ECX is cleared
00000009: 89 4D ec mov dword ptr [EBP-20], ECX // initialized to 0, which should be the temp Temporary Variable generated by the compiler, storing the result of a password exception or
2017000c: 89 4D F0 mov dword ptr [EBP-16 {sn}], ECX // sn initialized to 0 (used to store VolumeSerial after processing)
0000000F: 89 55 F8 mov dword ptr [EBP-8 {Result}], EDX // result is used to return the Result
00000012: 89 45 fc mov dword ptr [EBP-4 {str}], EAX // str is the input VolumeSerial
00000015: 33 C0 xor eax, EAX // EAX clear
00000017: 55 PUSH EBP
00000018: 68 (79 00 00 00 PUSH Encrypt {0x3A} + 121
Pushed 001d: 64 FF 30 push dword ptr fs: [EAX]
00000020: 64 89 20 mov dword ptr fs: [EAX], ESP
00000023: C7 45 F4 01 00 00 00 mov dword ptr [EBP-12 {I}], $00000001 // I counter initial value is 1, should be the starting position of a for Loop
2017002a: 8D 45 ec lea eax, dword ptr [EBP-20]
2017002d: 8A 55 F4 mov dl, byte ptr [EBP-12 {I}] // I put into DL
00000030: 8B 4D F4 mov ecx, dword ptr [EBP-12 {I}] // counter I put into ECX
00000033: 8B 5D fc mov ebx, dword ptr [EBP-4 {str}] // put the first address of str into EBX
00000036: 32 54 0B ff xor dl, byte ptr [EBX + ECX-1] // str [I] and DL exclusive or
10000003a: E8 (00 00 00 00 CALL @ LStrFromChar {0x21} // convert the result to char type
Limit 003f: 8B 55 ec mov edx, dword ptr [EBP-20] // @ LStrCat parameter, fastcall call uses the EDX register
00000042: 8D 45 F0 lea eax, dword ptr [EBP-16 {sn}] // @ LStrCat parameter, fastcall call uses the EAX register
00000045: E8 (00 00 00 00 CALL @ LStrCat {0x22} // append the content in EDX to the end of the string sn
0000004A: FF 45 F4 inc dword ptr [EBP-12 {I}] // I counter auto Increment
2017004d: 83 7D F4 09 cmp dword ptr [EBP-12 {I}], 9 // I counter and 9 Comparison
00000051: 75 D7 JNE-41; (0x2A) // whether the value is smaller than 9. If the value is less than 9, the loop is continued. If the value is greater than or equal to 9, the cycle is terminated (because VolumeSerial is 8 characters in length)
00000053: 8B 45 F8 mov eax, dword ptr [EBP-8 {Result}] // @ LStrAsg parameter, fastcall call uses the EAX register
00000056: 8B 55 F0 mov edx, dword ptr [EBP-16 {sn}] // @ LStrAsg parameter, fastcall call uses the EDX register
00000059: E8 (00 00 00 00 CALL @ LStrAsg {0x26} // @ LStrAsg is used to assign the string sn to Result
2017005e: 33 C0 xor eax, EAX
00000060: 5A POP EDX
00000061: 59 POP ECX
00000062: 59 POP ECX
00000063: 64 89 10 mov dword ptr fs: [EAX], EDX
00000066: 68 (80 00 00 00 PUSH Encrypt {0x3A} + 128
2017006b: 8D 45 ec lea eax, dword ptr [EBP-20]
2017006e: BA 02 00 00 00 mov edx, $00000002
00000073: E8 (00 00 00 00 CALL @ LStrArrayClr {0x29}
00000078: C3 RET NEAR
00000079: E9 (00 00 00 00 JMP @ HandleFinally {0x23}
2017007e: eb jmp-21; (0x6B)
00000080: 5B POP EBX
00000081: 8B E5 mov esp, EBP
00000083: 5D POP EBP
00000084: C3 RET NEAR
End;
 
By reading the code, we can find that the key encoding part is a for loop, and the xor operation is used ......
In this case, the Decrypt function does not need to be read. The key code must be the same, because A xor B =
 
The core code of the above assembly is changed to C ++, which is probably:
 
AnsiString _ fastcall Encrypt (AnsiString str)
{
String sn = "";
For (int I = 1; I <9; I ++)
{
Sn. cat_sprintf ("% c", str [I] ^ (char) I ));
}
Return sn;
}
 
If the str in the function entry stores the serial number of drive C, the return value is the registration code,
If the str of the function entry stores the registration code, the system returns the serial number of drive C.
 
So we finally found that the algorithm of the registration code only performs an exclusive or operation on each character of the serial number of drive C and its own offset in the string. To create a registration machine, it is enough to use the above function.