ZProtect
Code_Confusion er en kode utenfor rekkefølge kryptografisk tagg som lar deg velge en del av koden som er ute av rekkefølge
Sett inn kode ({ 235, 8, 83, 84, 95, 83, 84, 65, 82, 84 }) ' Code_Confusion for å starte
Sett inn kode ({ 235, 8, 83, 84, 95, 83, 84, 69, 78, 68 }) ' Code_Confusion slutten av merket
Code_Elimination er en kodepurge-markør som lar deg velge en del av koden som skal fjernes fra minnet etter kjøring; Formålet med å bruke denne markupen er å forhindre at crackere dumper hele programkoden fra minnet.
Sett inn kode ({ 235, 8, 79, 67, 95, 83, 84, 65, 82, 84 }) ' Code_Elimination tagg begynner
Sett inn kode ({ 235, 8, 79, 67, 95, 79, 67, 69, 78, 68 }) ' Code_Elimination merke på slutten
Decode_onExec er en dynamisk dekodingsmarkering som lar deg velge en del av koden som kun dekrypteres når den kjøres; Denne delen av koden dekodes kun når den må kjøres, og krypteres før og etter kjøring
Sett inn kode ({ 235, 8, 68, 89, 95, 83, 84, 65, 82, 84 }) // Decode_onExec tagg starter
Sett inn kode ({ 235, 8, 68, 89, 95, 68, 89, 69, 78, 68 }) // Decode_onExec markere slutten
Decode_onReg er en registreringsdekodingstagg som lar deg velge en del av koden som er dekryptert med en gyldig nøkkel; Hvis registreringsnøkkelen er feil, vil denne delen av koden alltid være kryptert. Enkelt sagt kjøres denne delen av koden kun i den registrerte versjonen
Et hvilket som helst antall Decode_onReg tagger kan brukes i kildekoden, men disse kodebitene dekrypteres samtidig som de kjøres. Registreringsdekodingstaggen brukes hovedsakelig til å aktivere begrensede funksjoner i den uregistrerte versjonen for å registrere den som en fullversjon.
Sett inn kode ({ 235, 8, 82, 68, 95, 83, 84, 65, 82, 84 }) // Decode_onReg tagg begynner
Sett inn kode ({ 235, 8, 82, 68, 95, 82, 68, 69, 78, 68 }) // Decode_onReg markerer slutten
Zprotect_VM er en krypteringstagg for virtuell maskin som lar deg velge en del av koden som skal legges inn i den virtuelle maskinen for å kjøre; Den virtuelle maskinens instruksjonssystem er helt annerledes enn de eksisterende x86-instruksjonene, noe som effektivt kan forhindre kodegjenoppretting og analyse
Sett inn kode ({ 235, 8, 86, 77, 95, 83, 84, 65, 82, 84 }) // Zprotect_VM for å starte
Sett inn kode ({ 235, 8, 86, 77, 95, 86, 77, 69, 78, 68 }) // Zprotect_VM merke slutt
----------- for ZProtect V1.4.9.0-versjonen---------
VMProtect
Sett inn koden ({ 235, 16, 86, 77, 80, 114, 111, 116, 101, 99, 116, 32, 98, 101, 103, 105, 110, 0 }) ' VMP beskyttelsesstartflagg
'Nøkkelkode
Sett inn koden ({ 235, 14, 86, 77, 80, 114, 111, 116, 101, 99, 116, 32, 101, 110, 100, 0 }) ' VMP-beskyttelsesflagget slutt
SDK-en til Enigma-krypteringsspråket
Sett inn kode ({ 235, 10, 69, 67, 82, 79, 78, 69, 88, 69, 69, 69, 69, 67, 66 })' merke i begynnelsen
'Nøkkelkode
Sett inn kode ({ 235, 10, 69, 67, 82, 79, 78, 69, 88, 69, 69, 67, 69 })' merke på slutten av merket
NoobyProtect SDK for krypteringsspråket
Sett inn kode ({ 235, 6, 78, 80, 66, 69, 71, 78 })'-merket i begynnelsen
'Nøkkelkode
Sett inn kode ({ 235, 6, 78, 80, 69, 78, 68, 80 })'-merke på slutten
Pangolin kaller DEMO-en til det funksjonelle krypteringsspråket SDK
Plasser koden ({ 235, 3, 214, 215, 1 })'-merket i begynnelsen
'Nøkkelkode
Plasserkode ({ 235, 3, 214, 215, 0 })' merke på slutten av merket
ASP-krypteringsspråk SDK
Sett inn kode ({ 235, 4, 235, 5, 25, 1, 233, 37, 0 })-merke i begynnelsen
'Nøkkelkode
Sett inn kode ({ 235, 4, 235, 5, 41, 1, 233, 133, 0, })' på slutten av merket
Shielden 2.0.1.0
Sett inn kode ({ 235, 7, 83, 69, 66, 69, 71, 78, 0 }) ' SE_PROTECT_START
' Nøkkelkode
Sett inn kode ({ 235, 7, 83, 69, 69, 78, 68, 80, 0 }) ' SE_PROTECT_END
Sett inn kode ({ 235, 7, 83, 69, 66, 69, 71, 78, 77 }) ' SE_PROTECT_START_MUTATION
Nøkkelkode
Sett inn kode ({ 235, 7, 83, 69, 69, 78, 68, 80, 0 }) ' SE_PROTECT_END
Sett inn kode ({ 235, 7, 83, 69, 66, 69, 71, 78, 85 }) ' SE_PROTECT_START_ULTRA
Nøkkelkode
Sett inn kode ({ 235, 7, 83, 69, 69, 78, 68, 80, 0 }) ' SE_PROTECT_END
Sett inn kode ({ 235, 7, 83, 69, 66, 69, 71, 78, 86 }) '
' Nøkkelkode
Sett inn kode ({ 235, 7, 83, 69, 69, 78, 68, 80, 0 }) ' SE_PROTECT_END
Enkel SDK-konverteringsmetode ↓
Med støtte fra E5.0 statisk kompilering for standard PE-formater har det blitt en realitet å introdusere krypteringsskal-SDK-er i E-programmer for å forbedre kvaliteten på programvarebeskyttelsen.
Krypteringsshell-SDK-er kan grovt deles inn i to kategorier, én er funksjonell SDK og den andre er beskyttende SDK.
1. Funksjonelt SDK.
Functional SDK brukes til å håndtere detSerienummerValidering, godkjenningstidsverifisering og andre funksjonelle operasjoner. Denne typen SDK har ulike funksjoner direkte anvendt i skallet, som WL; Det finnes også eksterne DLL-er som må introduseres, som pangoliner.
For DLL-er uten utdatatabeller, ved å bruke import av ekstern SDK, må vi laste DLL-en, adressere funksjonen i SDK-en, og kalle subprogram ()-kommandoen i E for enkelt å fullføre operasjonen med å sende parametere og få returverdien til SDK-funksjonen.
For DLL-er med utdatatabeller er det greit å kalle dem med DLL-kommandoen E.
For de som allerede vet hvordan man kaller DLL-er, kan driften av funksjonelle SDK-er sies å være enkel å kontrollere, bare ta en titt på den spesifikke API-manualen til skallet.
2. Kryptert SDK
Etter at krypteringsskallet oppdager en spesifikk SDK-tagg i programvaren, vil det bruke en målrettet metode for å behandle dette kodestykket for å forbedre sikkerheten til det spesifikke kodesegmentet. Denne typen markup er naturlig nok en pardefinert assemblerkode!
I den enkle kan vi enkelt kalle assemblerkoden ved å bruke kommandoen insert code (). Spesifikt for krypteringsskallet ved bruk av denne delen, følger vi følgende metode.
Åpne SDK-en som følger med krypteringsskallet og finn en SDK-headerfil som du kan lese. For eksempel headerfilen til LCC-en nedenfor.
Følgende er programkoden:
1 #elif definert(__LCC__)
2 /* Levert av Rubem Pechansky, 26. februar 2003 */
3 #define SECUREBEGIN _asm(".byte 0xEB,0x03,0xD6,0xD6,0x00");
4 #define SECUREEND _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
5 #define SECUREBEGIN_A _asm(".byte 0xEB,0x03,0xD6,0xD6,0x01");
6 #define SECUREEND_A _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
7 #define SECUREBEGIN_B _asm(".byte 0xEB,0x03,0xD6,0xD6,0x02");
8 #define SECUREEND_B _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
9 #define SECUREBEGIN_C _asm(".byte 0xEB,0x03,0xD6,0xD6,0x03");
10 #define SECUREEND_C _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
11 #define SECUREBEGIN_D _asm(".byte 0xEB,0x03,0xD6,0xD6,0x04");
12 #define SECUREEND_D _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
13 #define SECUREBEGIN_E _asm(".byte 0xEB,0x03,0xD6,0xD6,0x05");
14 #define SECUREEND_E _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
15 #define SECUREBEGIN_F _asm(".byte 0xEB,0x03,0xD6,0xD6,0x06");
16 #define SECUREEND_F _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
17 #define SECUREBEGIN_G _asm(".byte 0xEB,0x03,0xD6,0xD6,0x07");
18 #define SECUREEND_G _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
19 #define SECUREBEGIN_H _asm(".byte 0xEB,0x03,0xD6,0xD6,0x08");
20 #define SECUREEND_H _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
21 #define SECUREBEGIN_I _asm(".byte 0xEB,0x03,0xD6,0xD6,0x09");
22 #define SECUREEND_I _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
23 #define SECUREBEGIN_J _asm(".byte 0xEB,0x03,0xD6,0xD6,0x0A");
24 #define SECUREEND_J _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
25 #define SECUREBEGIN_K _asm(".byte 0xEB,0x03,0xD6,0xD6,0x0B");
26 #define SECUREEND_K _asm(".byte 0xEB,0x03,0xD6,0xD6,0xFF");
27 #define NANOBEGIN _asm(".byte 0xEB,0x03,0xD6,0xD7,0x01");
28 #define NANOEND _asm(".byte 0xEB,0x03,0xD6,0xD7,0x00");
For å forklare i de to siste setningene: NANOBEGIN og NANOEND er CC-kodesnippet-markeringer på C-språket, og kodesnippetene som pakkes inn i disse to markupene vil være CC-beskyttet av krypteringsskallet. NANOBEGIN representeres av assemblerkode som 0xEB, 0x03, 0xD6, 0xD7, 0x01, setningen hans er den heksadesimale representasjonen av C, og assembly-uttalelsen representeres i desimaldesimal i E. Det vil si, vi må oversette denne koden.
0xEB = 235
0x03 = 3
0xD6 = 214
0xD7 = 215
0x01 = 1
Da uttrykkes NANOBEGIN i E som en innsettingskode ({235, 3, 214, 215, 1}).
|