Intel kompilatorer. Varför behövdes nya kompilatorer?

Intel C++ och Fortran-kompilatorer och MKL-bibliotek

Tillsammans med standard GNU-kompilatorer för Linux, installeras Intel C++ och Fortran-kompilatorer på klustren av NIVC-komplexet. För närvarande (början av 2006) är kompilatorversion 9.1 installerad på alla kluster. Den här sidan är tillägnad att beskriva de viktigaste alternativen och inställningarna för dessa kompilatorer, såväl som deras huvudsakliga skillnader från GNU-kompilatorerna. Sidan riktar sig främst till användare av MSU Research Computing Center-kluster, men kan även vara användbar för andra rysktalande användare. Frågor relaterade till kompilering för IA-64-plattformen tas inte upp här.

Dessutom är Intel-biblioteket installerat på alla kluster Kernel Math Library(MKL) version 8.0.2. Biblioteket finns i katalogen /usr/mkl. Observera att underkatalogerna 32, 64 och em64t är tillgängliga i lib-katalogen. På Ant-klustret måste du använda biblioteken från underkatalogen em64t, och på andra kluster - från underkatalogen 32. All nödvändig dokumentation och exempel kan erhållas från katalogen /usr/mkl/doc.

Varför behövdes nya kompilatorer?

Behovet av nya kompilatorer uppstod främst för att a) stödja programmering i Fortran 90, och även b) för mer kraftfull optimering av Fortran-program än vad som tillhandahålls av g77-kompilatorn, som använder översättning till C och sedan kompilering med gcc.

PGI (Portland Group) kompilatorer uppfyller också dessa krav, men utvecklarföretaget vägrade att leverera dem till Ryssland.

Hur man använder?

Intel-kompilatorer anropas med hjälp av kommandon icc(C eller C++), icpc(C++) och ifort(Fortran 77/90). Kommandona mpicc, mpiCC och mpif77 för att kompilera och montera MPI-program är också konfigurerade för att använda Intel-kompilatorer.

Det är också möjligt att använda GNU-kompilatorer med kommandona mpigcc, mpig++ och mpig77 (Fortran 90 stöds inte).

Inmatningsfiler

Som standard, filer med tillägget .cpp Och .cxx anses källtexter på C++-språket, filer med filtillägget .c- C-källkod, och icpc-kompilatorn kompilerar också .c-filer som C++-källkod.

Filer med tillägg .f, .ftn Och .förär igenkända som källtexter på Fotran-språket, med en fast form av notation, och filerna .fpp Och .F gick dessutom genom Fortran-språkförprocessorn. Filer med tillägget .f90 anses Fortran 90/95 källtexter med fri form notation. Du kan uttryckligen ange en fast eller fri form av notation för Fortran-program med hjälp av alternativen -FI Och -FR respektive.

Filer med tillägget .s erkänd som assemblerspråkkod för IA-32.

Intels kompilatorfunktioner

Här presenterar vi egenskaperna hos Intel-kompilatorer som anges av utvecklaren i användarmanualen med några av våra kommentarer.

• Betydande optimering
  Tydligen innebär detta att optimera koden på hög nivå, d.v.s. först och främst olika looptransformationer, vilket nästan alla kompilatorer gör med större eller mindre framgång
• Flyttalsoptimering
  Tydligen betyder detta först och främst maximal användning av kommandon implementerade på hårdvarunivå
• Interprocedurella optimeringar
  de där. global optimering av hela programmet, till skillnad från vanlig optimering, som endast påverkar koden för specifika funktioner
• Profilbaserad optimering
  de där. möjligheten att köra ett program i testläge, samla in data om den tid det tar att skicka vissa kodfragment i ofta använda funktioner och sedan använda dessa data för optimering
• Stöd för SSE-instruktionsuppsättningen i Pentium III-processorer
  notera: för beräkningsuppgifter är SSE2-kommandon av mer intresse, d.v.s. vektorkommandon över 64-bitars reella tal, men de stöds bara på Pentium 4-processorer, som vi inte har till vårt förfogande ännu
• Automatisk vektorisering
  de där. igen, med hjälp av SSE- och SSE2-kommandona, infogade automatiskt av kompilatorn
• OpenMP-stöd för programmering på SMP-system
  notera: på ett kluster rekommenderas att primärt använda MPI-gränssnittet; utbredd användning av OpenMP på klustret förväntas inte och sådana experiment har ännu inte utförts; men det är förmodligen vettigt att använda bibliotek (BLAS, etc.) som är parallelliserade för delat minne.
• Dataförhämtning
  de där. Tydligen, användningen av förladdningskommandon från minnet till datacachen, vilket kommer att behövas efter en tid
• "Dispatching"-kod för olika processorer
  de där. möjligheten att generera kod för olika processorer i en enda körbar fil, vilket gör att du kan dra nytta av de senaste processorerna för att uppnå högsta prestanda på dem, samtidigt som binär kompatibilitet för program med tidigare processorer bibehålls; På vårt kluster är detta inte relevant än, eftersom endast Pentium III-processorer används, och program kompilerade på klustret är inte tänkta att överföras och köras på andra maskiner

Grundläggande kompilatoralternativ

Det mest intressanta är förstås kodoptimeringsalternativen. De flesta av alternativen är gemensamma för C++- och Fortran-kompilatorerna. Mer detaljerad beskrivning alternativ i engelska bruksanvisningar.

Prestanda

Enligt resultaten av att köra SPEC CPU2000-testerna, publicerade på ixbt.com-servern, var Intels kompilatorversion 6.0 nästan allmänt bättre jämfört med gcc-kompilatorversionerna 2.95.3, 2.96 och 3.1 och PGI version 4.0.2. Dessa tester utfördes 2002 på en dator med en Pentium 4/1,7 GHz-processor och RedHat Linux 7.3.

Enligt tester utförda av Polyhedron var Intel Fortran-kompilatorversion 7.0 nästan universellt överlägsen andra Fortran 77-kompilatorer för Linux (Absoft, GNU, Lahey, NAG, NAS, PGI). Endast i vissa tester är Intel-kompilatorn något sämre än Absoft-, NAG- och Lahey-kompilatorerna. Dessa tester utfördes på en dator med en Pentium 4/1,8 GHz-processor och Mandrake Linux 8.1.

Intels kompilatorer version 9.1 överträffar också gcc-kompilatorer och visar prestanda jämförbara med Absoft, PathScale och PGI.

Vi kommer att vara tacksamma för de användare och läsare som skickar oss data om inverkan av valet av kompilator (GCC eller Intel) och optimeringsalternativ på hastigheten på arbetet med deras verkliga problem.

Bibliotek

C-språkkompilatorn använder ett runtime-bibliotek utvecklat inom GNU-projektet ( libc.a).

Följande bibliotek levereras med Intel C++-kompilatorn:

• libcprts.a- Runtime C++ språkbibliotek utvecklat av Dinkumware.
• libcxa.a- Ytterligare runtime-bibliotek för C++-utveckling av Intel.
• libimf.a- ett bibliotek med matematiska funktioner utvecklat av Intel, som inkluderar optimerade och högprecisionsimplementeringar av trigonometriska, hyperboliska, exponentiella, speciella, komplexa och andra funktioner (för mer information, se listan över funktioner).
• libirc.a- Runtime-stöd för profilering (PGO) och kodutskick beroende på processor (se ovan).
• libguide.a- OpenMP implementering.

Denna lista innehåller statiska bibliotek, men för de flesta av dem finns det även dynamiska, d.v.s. alternativ anslutna under start ( .så).

Följande bibliotek levereras med Fortran-kompilatorn: libCEPCF90.a, libIEPCF90.a, libintrins.a, libF90.a, biblioteket med matematiska funktioner libimf.a används också.

Bygger den körbara filen

Bibliotek kan anslutas statiskt (under byggandet) eller dynamiskt (under programstart). Den dynamiska metoden låter dig minska storleken på den körbara filen och låter dig dela samma kopia av biblioteket i minnet, men för detta måste du installera en komplett uppsättning dynamiska bibliotek som används på varje nod där programmen kommer att startas .

Således, om du installerade Intel-kompilatorn på din Linux-maskin och vill köra de kompilerade körbara filerna på andra maskiner, måste du antingen använda en statisk build (vilket är enklare) eller kopiera Intels dynamiska bibliotek till dessa maskiner (vanligtvis från en katalog som /opt/intel /compiler70/ia32/lib) till en av katalogerna listade i filen /etc/ld.so.conf, och se även till att samma uppsättning dynamiska GNU/Linux-bibliotek är installerade på dessa maskiner.

Som standard är alla Intels utvecklingsbibliotek (förutom libcxa.so) länkade statiskt, och alla Linux-systembibliotek och GNU-bibliotek är länkade dynamiskt. Använder alternativet -statisk du kan tvinga samlaren (länkredigeraren) att ansluta alla bibliotek statiskt (vilket kommer att öka volymen körbar fil), och använder alternativet -i_dynamic Du kan dynamiskt länka alla Intels utvecklingsbibliotek.

När du ansluter ytterligare bibliotek med visningsalternativet -bibliotek du kan behöva använda alternativet -Lkatalog för att ange sökvägen där biblioteken finns.

Använder alternativ -Bstatisk Och -Bdynamic du kan uttryckligen ange dynamisk eller statisk anslutning för vart och ett av de bibliotek som anges i kommandorad.

Använder alternativet -c montering av den körbara filen är inaktiverad och endast kompilering utförs (generering av objektmodul).

Dela moduler i Fortran och C

För att dela moduler skrivna i Fortran och C måste du komma överens om namngivning av procedurer i objektmoduler, överföring av parametrar och tillgång till globala variabler, om några.

Som standard konverterar Intel Fortran-kompilatorn procedurnamn till gemener och lägger till ett understreck i slutet av namnet. C-kompilatorn ändrar aldrig funktionsnamn. Således, om vi vill anropa en funktion eller procedur FNNAME implementerad i C från en Fortran-modul, bör den i C-modulen heta fnname_.

Fortran-kompilatorn stöder alternativet -nus [filnamn], som låter dig inaktivera tillägg av understreck till interna procedurnamn. Om ett filnamn anges görs detta endast för procedurnamn som anges i den angivna filen.

Som standard skickas parametrar i Fortran genom referens, och i C skickas de alltid med värde. Sålunda, när vi anropar en Fortran-procedur från en C-modul, måste vi skicka pekare till motsvarande variabler som innehåller värdena för de faktiska parametrarna som parametrar. När vi skriver en funktion i C som kommer att behöva anropas från en Fortran-modul måste vi beskriva de formella parametrarna som pekare till motsvarande typer.

I C-moduler är det möjligt att använda COMMON-block definierade inuti Fortran-moduler (för mer information, se Intel Fortran Compiler User's Guide, kapitlet Blanda C och Fortran).

Dela Intel- och GCC-kompilatorer

C-objektmoduler som produceras av Intel C++-kompilatorn är kompatibla med moduler som produceras av GCC-kompilatorn och GNU C-biblioteket. Således kan dessa moduler användas tillsammans i ett enda program kompilerat med icc- eller gcc-kommandon, men det rekommenderas att använda icc för att korrekt inkludera Intel-bibliotek.

Intel-kompilatorn stöder ett antal icke-standardiserade C-språktillägg som används av GNU-projektet och stöds av GCC-kompilatorn (men inte alla, se här för mer information).

Användarmanualen säger inget om kompatibiliteten för objektmoduler i språken C++ och Fortran; uppenbarligen stöds den inte.

Stöd för standarder

Intel C++ Compiler 7.0 för Linux stöder språkstandarden ANSI/ISO C (ISO/IEC 9899/1990). Det är möjligt att etablera strikt kompatibilitet med ANSI C-standarden ( -ansi) eller utökad ANSI C-dialekt ( -Xa). När du använder alternativet -c99

I det förra numret av tidningen diskuterade vi produkter från Intel VTune Performance Analyzer-familjen - prestandaanalysverktyg som är välförtjänt populära bland applikationsutvecklare och tillåter upptäckt i kod lagansökningar, som slösar för mycket CPU-resurser, vilket ger utvecklare möjlighet att identifiera och eliminera potential trånga platser, associerad med liknande avsnitt av kod, vilket påskyndar. Observera dock att applikationernas prestanda till stor del beror på hur effektiva kompilatorerna som används i deras utveckling är och vilka funktioner hårdvara de används vid generering av maskinkod.

De senaste versionerna av Intel Intel C++- och Intel Fortran-kompilatorerna för Windows och Linux låter dig få fördelar med applikationsprestanda för system baserade på Intel-processorer Itanium 2, Intel Xeon och Intel Pentium 4 upp till 40 % jämfört med befintliga kompilatorer från andra tillverkare på grund av användningen av sådana funktioner hos dessa processorer som Hyper-Threading-teknik.

Skillnader förknippade med kodoptimering av denna familj av kompilatorer inkluderar användningen av en stack för att utföra flyttalsoperationer, interprocedurell optimering (IPO), optimering i enlighet med applikationsprofilen (Profile Guided Optimization (PGO), förladdning av data i cachen ( Dataförhämtning), som undviker latens förknippad med minnesåtkomst, stöd för de karakteristiska egenskaperna hos Intel-processorer (till exempel tillägg för strömmande databehandling Intel Streaming SIMD Extensions 2, karakteristisk för Intel Pentium 4), automatisk parallellisering av kodexekvering, applikation skapande, kör på flera olika typer processorer vid optimering för en av dem, verktyg för att "förutsäga" efterföljande kod (branch prediction), utökat stöd för att arbeta med exekveringstrådar.

Observera att Intel-kompilatorer används i så välkända företag som Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. Enligt oberoende tester utförda av ett antal företag är prestanda hos Intel-kompilatorer betydligt högre än prestanda för kompilatorer från andra tillverkare (se till exempel http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf .pdf).

Nedan kommer vi att titta på några funktioner senaste versionerna Intel-kompilatorer för skrivbord och server operativsystem.

Kompilatorer för Microsoft Windows-plattformen

Intel C++ Compiler 7.1 för Windows

Intel C++ Compiler 7.1 är en kompilator som släpptes tidigare i år och som tillhandahåller högoptimerad kod för Intel Itanium-, Intel Itanium 2-, Intel Pentium 4- och Intel Xeon-processorerna, samt Intel Pentium M-processorn som använder Intel Centrino-teknik och avsedd för användning i Mobil enheter.

Den angivna kompilatorn är helt kompatibel med utvecklingsverktygen Microsoft Visual C++ 6.0 och Microsoft Visual Studio .NET: den kan byggas in i motsvarande utvecklingsmiljöer.

Den här kompilatorn stöder ANSI- och ISO C/C++-standarder.

Intel Fortran Compiler 7.1 för Windows

Intel Fortran Compiler 7.1 för Windows, som också släpptes tidigare i år, låter dig skapa optimerad kod för Intel Itanium, Intel Itanium 2, Intel Pentium 4 och Intel Xeon, Intel Pentium M-processorer.

Denna kompilator är helt kompatibel med Microsoft Visual C++ 6.0 och Microsoft Visual Studio .NET utvecklingsverktyg, det vill säga den kan byggas in i motsvarande utvecklingsmiljöer. Dessutom låter den här kompilatorn dig utveckla 64-bitarsapplikationer för operativsystem som körs på Itanium/Itanium 2-processorer med hjälp av Microsoft Visual Studio på en 32-bitars Pentium-processor med 64-bitars Intel Fortran Compiler. När du felsöker kod låter den här kompilatorn dig använda en debugger för att Microsofts plattformar.NETTO.

Om du har Compaq-produkten installerad kan Visual Fortran 6.6 användas istället för den ursprungliga Intel Fortran Compiler 7.1, eftersom dessa kompilatorer är kompatibla på nivån källkod.

Intel Fortran Compiler 7.1 för Windows är helt kompatibel med ISO Fortran 95-standarden och stöder skapande och felsökning av applikationer som innehåller kod på två språk: C och Fortran.

Kompilatorer för Linux-plattformen

Intel C++ Compiler 7.1 för Linux

En annan kompilator som släpptes i början av året, Intel C++ Compiler 7.1 för Linux, låter dig uppnå en hög grad av kodoptimering för processorer Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Denna kompilator är helt kompatibel med GNU C-kompilatorn vid källkods- och objektmodulerna, vilket gör att du kan migrera applikationer skapade med GNU C till den utan extra kostnader. Intel C++-kompilatorn stöder C++ ABI (ett tillägg till Linux-kärnan som låter dig köra under Linux kontroll kompilerad kod för andra plattformar som tidiga SCO-operativsystem, tidiga versioner Sun Solaris, etc.), vilket innebär full kompatibilitet med gcc 3.2-kompilatorn på binär kodnivå. Slutligen, med Intel C++ Compiler 7.1 för Linux, kan du till och med kompilera om Linux-kärnan genom att göra några mindre ändringar i dess källkod.

Intel Fortran Compiler 7.1 för Linux

Intel Fortran Compiler 7.1 för Linux låter dig skapa optimerad kod för processorer Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Denna kompilator är helt kompatibel med Compaq Visual Fortran 6.6-kompilatorn på källkodsnivå, vilket gör att du att kompilera om applikationer med hjälp av det skapade med Compaq Visual Fortran, och därigenom öka deras prestanda.

Dessutom är den angivna kompilatorn kompatibel med sådana verktyg som används av utvecklare som emacs-redigeraren, gdb-felsökaren och verktyget make application build.

Liksom Windows-versionen av denna kompilator är Intel Fortran Compiler 7.1 för Linux helt kompatibel med ISO Fortran 95-standarden och stöder skapande och felsökning av applikationer som innehåller kod på två språk: C och Fortran.

Det bör särskilt betonas att ett betydande bidrag till skapandet av de listade Intel-kompilatorerna gjordes av specialister från Intel Russian Software Development Center i Nizhny Novgorod. Mer detaljerad information Information om Intel-kompilatorer finns på Intels webbplats på www.intel.com/software/products/.

Den andra delen av denna artikel kommer att ägnas åt Intel-kompilatorer som skapar applikationer för mobila enheter.

Exempel på riktiga hack: Intel C++ 7.0-kompilator - Arkiv WASM.RU

...kompilatorn Intel C++ 7.0 laddades ner sent på natten, ungefär klockan fem på morgonen. Jag ville verkligen sova, men jag slets också av nyfikenhet: om skyddet hade stärkts eller inte. Jag bestämde mig för att tills jag kom på skyddet att jag fortfarande inte skulle somna, öppnade jag ny konsol, och återställer systemvariablerna TEMP och TMP till C:\TEMP-katalogen, hastigt inskrivet oanständigt långt namn installationsprogrammet W_CC_P_7.0.073.exe på kommandoraden (behovet av att ställa in TEMP- och TMP-variablerna förklaras av det faktum att de i Windows 2000 som standard pekar på en mycket djupt kapslad katalog, och Intel C++-installationsprogrammet - och inte bara det - stöder inte vägar av så stor storlek).

Det blev omedelbart klart att skyddspolicyn hade reviderats radikalt och nu kontrollerades närvaron av en licens redan vid installationsstadiet (i version 5.x genomfördes installationen utan problem). OK, vi ger dir kommandot och tittar på innehållet i det vi nu måste kämpa med:

Innehållet i mappen C:\TMP\IntelC++Compiler70

17.03.2003 05:10

html

17.03.2003 05:11

x86

17.03.2003 05:11

Itanium

17.03.2003 05:11

anteckningar

06/05/2002 10:35 45 056 AutoRun.exe

07/10/2001 12:56 27 autorun.inf

29.10.2002 11:25 2 831 ccompindex.htm

2002-10-24 08:12 126 976 ChkLic.dll

10/18/2002 22:37 552 960 chklic.exe

10/17/2002 16:29 28 663 CLicense.rtf

17.10.2002 16:35 386 credist.txt

16.10.2002 17:02 34 136 Crellnotes.htm

2002-03-19 14:28 4 635 PLSuite.htm

2002-02-21 12:39 2 478 register.htm

02.10.2002 14:51 40 960 Setup.exe

02.10.2002 10:40 151 Setup.ini

07/10/2001 12:56 184 setup.mwg

19 filer 2 519 238 byte

6 mappar 886 571 008 byte gratis

Ja! Installationsprogrammet setup.exe tar bara fyrtio kilobyte. Mycket bra! Det är osannolikt att du kan gömma seriöst skydd i en sådan volym, och även om så är fallet, är den här lilla filen inte värd att analysera i sin helhet - ner till den sista byten i disassemblerlistan. Det är dock inte ett faktum att säkerhetskod ligger exakt i setup.exe, den kan finnas på en annan plats, till exempel... ChkLic.dll/ChkLic.exe, som tillsammans upptar lite mindre än sjuhundra kilobyte. Vänta, vad är ChkLic? Är detta förkortning för Check License eller vad?! Hmm, killarna från Intel har uppenbarligen allvarliga problem med humor. Det skulle vara bättre om de kallade den här filen "Hack Me" ärligt! Okej, att döma av volymen är ChkLic samma FLEX lm, och vi har redan stött på den (se "Intel C++ 5.0 Compiler") och har en ungefärlig uppfattning om hur man bryter den.

Vi ger kommandot "dumpbin /EXPORTS ChkLic.dll" för att undersöka de exporterade funktionerna och...håll hårt i Klava för att inte ramla av stolen:

Dumpa filen ChkLic.dll

1. Avsnittet innehåller följande exporter för ChkLic.dll

   0 egenskaper

   3DB438B4 tidsdatumstämpel mån 21 okt 21:26:12 2002

3. 1 antal funktioner

   1 antal namn

   ordningsled RVA-namn

   1 0 000010A0 _CheckValidLicense

Helvete! Skyddet exporterar bara en enda funktion med det underbara namnet CheckValidLicense. "Underbart" - eftersom syftet med funktionen framgår av dess namn och det blir möjligt att undvika noggrann analys av demonteringskoden. Tja, de har tappat allt intresse... det vore bättre om de exporterade det normalt eller något, eller åtminstone döpte det till något slags skrämmande namn som DES Decrypt.

...dagdrömma! Okej, låt oss gå tillbaka till våra får. Låt oss tänka logiskt: om all säkerhetskod är koncentrerad direkt i ChkLic.dll (och, att döma av skyddets "gångjärnsförsedda" natur, så är detta verkligen fallet), så handlar allt "skydd" om att anropa CheckValidLicense från Setup. exe och kontrollera resultatet som returneras av det. Därför räcker det för att "hacka" bara att förlora ChkLic.dll, vilket tvingar ChekValidLicense-funktionen att alltid återvända... och förresten, vad ska den returnera? Mer exakt: vad exakt är returvärdet som motsvarar en lyckad licenskontroll? Nej, skynda dig inte att ta isär setup.exe för att avgöra det, eftersom möjliga alternativ inte så mycket längre: antingen FALKT eller SANT. Satsar du på TRUE? Tja, på sätt och vis är detta logiskt, men å andra sidan: varför bestämde vi oss för att CheckValidLicense-funktionen returnerar exakt flaggan för framgången för operationen, och inte felkoden? När allt kommer omkring måste det på något sätt motivera skälen till att vägra att installera kompilatorn: filen med licensen hittades inte, filen är skadad, licensen har gått ut och så vidare? Okej, låt oss försöka returnera noll, och om det inte fungerar, returnerar vi en.

Okej, spänn fast, låt oss gå! Vi startar HIEW, öppnar filen ChkLic.dll (om den inte öppnas, kom ihåg gophers tre gånger, kopiera den tillfälligt till roten eller någon annan katalog som inte innehåller specialtecken i namnet som inte gillar) . Sedan, genom att återgå till exporttabellen som erhållits med dumpbin, bestämmer vi adressen till CheckValidLicense-funktionen (i detta fall 010A0h) och genom "10A0" går vi till dess början. Nu klipper vi den "live", skriver över gammal kod "XOR EAX, EAX/RETN 4". Varför just "REN 4" och inte bara "RET"? Ja, eftersom funktionen stöder stdcall-konventionen, som du kan ta reda på genom att titta på dess epilog i HIEW"e ( scrolla bara ned på demonteringsskärmen tills du möter RET).

Låt oss kolla... Det fungerar!!! Trots avsaknaden av en licens påbörjar installationsprogrammet installationen utan att ställa några frågor! Därför föll försvaret. Åh, vi kan inte tro att allt är så enkelt och för att inte sitta dumt och stirra på bildskärmen och vänta på att programinstallationsprocessen ska slutföras, använder vi vår favorit IDA-disassembler på setup.exe. Det första som fångar ditt öga är frånvaron av CheckValidLicense i listan över importerade funktioner. Kanske det på något sätt startar filen ChkLic.exe? Vi försöker hitta motsvarande länk bland de automatiskt igenkända raderna: "~View aNames", "ChkLic"... ja, raden "Chklic.exe" finns inte där alls, men "Chklic.dll" detekteras. Ja, jag förstår, det betyder att ChkLic-biblioteket laddas genom explicit länkning via LoadLibrary. Och efter korshänvisningen bekräftar detta:

Text:0040175D push offset aChklic_dll ; lpLibFileName

Sms:00401762 ring ds:LoadLibraryA

Text:00401762 ; ladda ChkLic.dll ^^^^^^^^^^^^^^^^^

Text:00401762 ;

Sms:00401768 mov esi, eax

Text:0040176A push offset a_checkvalidlic ; lpProcName

Text:0040176F push esi ; hModule

Sms:00401770 ring ds:GetProcAddress

Text:00401770 ; hämta adressen till CheckValidLicense-funktionen

Text:00401770 ;

Text:00401776 cmp esi, ebx

Text: 00401778 jz loc_40192E

Text:00401778 ; om det inte finns något sådant bibliotek, avsluta sedan installationsprogrammet

Text:00401778 ;

Text:0040177E cmp eax, ebx

Text: 00401780 jz loc_40192E

Text:00401780 ; om det inte finns någon sådan funktion i biblioteket, avsluta sedan installationen

Text:00401780 ;

Sms:00401786 push ebx

Sms:00401787 ring eax

Text:00401787 ; anropa ChekValidLicense-funktionen

Text:00401787 ;

Sms:00401789 test eax, eax

Text:0040178B jnz loc_4019A3

Text:0040178 ; om funktionen returnerade från noll, avsluta sedan installationsprogrammet

Otroligt nog är detta fruktansvärt primitiva försvar byggt precis så här! Dessutom behövs inte halvmetersfilen ChkLic.exe alls! Och varför var det värt att dra det från Internet? Förresten, om du bestämmer dig för att spara kompilatordistributionen (obs: jag sa inte "distribuera"!), då kan ChkLic.* raderas för att spara diskutrymme: antingen genom att radera setup.exe, för alltid att avvänja den från komma åt dem, eller genom att helt enkelt skapa din egen ChkLic.dll, exportera stdcall-funktionen CheckValidLicence i formen: int CheckValidLicence(int some_flag) (retur 0;)

Tja, medan vi diskuterade allt detta, avslutade installationsprogrammet med att installera kompilatorn och slutförde sitt arbete framgångsrikt. Är det intressant om kompilatorn kommer att starta eller börjar allt det roliga bara? Vi går febrilt ner i den grenade hierarkin av undermappar, hittar icl.exe, som, som man kan förvänta sig, finns i bin-katalogen, klickar och... Kompilatorn startar naturligtvis inte, med hänvisning till det faktum att "icl: error: kunde inte checka ut FLEX lm licens" , utan vilken han inte kan fortsätta sitt arbete.

Det visar sig att Intel använde flernivåskydd och den första nivån visade sig vara ett grovt skydd mot dårar. Väl! Vi antar denna utmaning och, baserat på vår tidigare erfarenhet, letar vi automatiskt efter LMGR*.DLL-filen i kompilatorkatalogen. Onyttig! Den här gången finns det ingen sådan fil här, men det visar sig att icl.exe har gått upp mycket i vikt, överstigande sexhundra kilobyte... Sluta! Länkade inte kompilatorutvecklarna samma FLEX lm med statisk länkning? Låt oss se: i Intel C++ 5.0 var summan av storlekarna lmgr327.dll och icl.exe 598 KB, och nu upptar bara icl.exe 684 KB. Med hänsyn till justeringen för naturlig senil "fetma" stämmer siffrorna mycket väl överens. Så trots allt, FLEX lm! Åh åh! Men nu, utan symboliska funktionsnamn, blir det mycket svårare att bryta skyddet... Men låt oss inte få panik i förväg! Låt oss tänka, bara lugnt! Det är osannolikt att utvecklingsteamet helt har skrivit om all kod som interagerar med detta "envelope"-skydd. Troligtvis slutade dess "förbättring" med bara en förändring av typen av layout. Och i så fall är chanserna att hacka programmet fortfarande stora!

När vi kom ihåg att förra gången säkerhetskoden var i huvudfunktionen, satte vi, efter att ha bestämt dess adress, helt enkelt en brytpunkt och, i väntan på att debuggern ska dyka upp, spårar vi dumt koden, växelvis tittar vi på debuggern och sedan på programutgången fönster: har meddelandet Finns det ett expleterande meddelande? Samtidigt markerar vi alla villkorliga övergångar vi möter på ett separat papper (eller lägg det i vårt eget minne, om du vill), utan att glömma att ange om varje villkorad övergång utfördes eller inte... Sluta! Du och jag pratade om något, men ett kränkande meddelande har redan dykt upp! Okej bra! Låt oss se vilken villkorlig övergång som motsvarade det. Våra register visar att det sista hoppet som påträffades var det villkorade JNZ-hoppet, beläget på adress 0401075h och "reagerar" på resultatet som returneras av sub_404C0E:

Text:0040107F loc_40107F: ; KOD XREF: _main+75^j

Text:0040107F mov eax, offset aFfrps ; "FFrps"

Text: 00401084 mov edx, 21h

Sms:00401089 ring sub_404C0E

Text:0040108E test eax, eax

Text:00401090 jnz kort loc_40109A

Uppenbarligen är sub_404C0E själva skyddsproceduren som kontrollerar licensen för dess närvaro. Hur kan man lura henne? Tja, det finns många alternativ... För det första kan du eftertänksamt och noggrant analysera innehållet i sub_404C0E för att ta reda på exakt vad den kontrollerar och exakt hur den kontrollerar. För det andra kan du helt enkelt ersätta JNZ short loc_40107F med JZ short loc_40107F eller till och med NOP, NOP. För det tredje kan returresultatkontrollkommandot TEST EAX, EAX omvandlas till ett nollkommando: XOR EAX, EAX. För det fjärde kan du få sub_404C0E att försvinna så att den alltid returnerar noll. Jag vet inte om dig, men jag gillade metod nummer tre mest. Vi ändrar två byte och startar kompilatorn. Om det inte finns några andra kontroller av dess "licensiering" i skyddet, kommer programmet att fungera och följaktligen vice versa. (Som vi minns fanns det två sådana kontroller i den femte versionen). Otroligt nog klagar inte kompilatorn längre och fungerar!!! I själva verket, som man kunde förvänta sig, stärkte dess utvecklare inte skyddet alls, utan tvärtom, till och med försvagade det! Chris Kaspersky

Du är inte en slav!
Sluten utbildningskurs för barn i eliten: "Världens sanna arrangemang."
http://noslave.org

Material från Wikipedia - den fria encyklopedin