Intel kompilatorer. Hvorfor var det nødvendig med nye kompilatorer?

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

Sammen med standard GNU-kompilatorer for Linux, er Intel C++ og Fortran-kompilatorer installert på klyngene til NIVC-databehandlingskomplekset. For øyeblikket (begynnelsen av 2006) er kompilatorer versjon 9.1 installert på alle klynger. Denne siden er dedikert til å beskrive de viktigste alternativene og innstillingene til disse kompilatorene, samt deres viktigste forskjeller fra GNU-kompilatorene. Siden er hovedsakelig rettet mot brukere av MSU Research Computing Center-klynger, men kan også være nyttig for andre russisktalende brukere. Problemer knyttet til kompilering for IA-64-plattformen behandles ikke her.

Intel-biblioteket er også installert på alle klynger Kernel Math Library(MKL) versjon 8.0.2. Biblioteket ligger i katalogen /usr/mkl. Vær oppmerksom på at underkatalogene 32, 64 og em64t er tilgjengelige i lib-katalogen. På Ant-klyngen må du bruke bibliotekene fra underkatalogen em64t, og på andre klynger - fra underkatalogen 32. All nødvendig dokumentasjon og eksempler kan hentes fra katalogen /usr/mkl/doc.

Hvorfor var det nødvendig med nye kompilatorer?

Behovet for nye kompilatorer oppsto hovedsakelig for å a) støtte programmering i Fortran 90, og også b) for kraftigere optimalisering av Fortran-programmer enn det som er gitt av g77-kompilatoren, som bruker oversettelse til C og deretter kompilering ved hjelp av gcc.

PGI (Portland Group) kompilatorer oppfyller også disse kravene, men utviklerselskapet nektet å levere dem til Russland.

Hvordan å bruke?

Intel-kompilatorer påkalles ved hjelp av kommandoer icc(C eller C++), icpc(C++) og ifort(Fortran 77/90). Kommandoene mpicc, mpiCC og mpif77 for kompilering og sammenstilling av MPI-programmer er også konfigurert til å bruke Intel-kompilatorer.

Det er også mulig å bruke GNU-kompilatorer ved å bruke kommandoene mpigcc, mpig++ og mpig77 (Fortran 90 støttes ikke).

Inndatafiler

Som standard, filer med utvidelsen .cpp Og .cxx regnes som kildetekster på C++-språket, filer med filtypen .c- C-kildekode, og icpc-kompilatoren kompilerer også .c-filer som C++-kildekode.

Filer med utvidelser .f, .ftn Og .til gjenkjennes som kildetekster på Fotran-språket, med en fast form for notasjon, og filene .fpp Og .F i tillegg gått gjennom Fortran-språkforbehandleren. Filer med utvidelsen .f90 anses Fortran 90/95 kildetekster med fri form notasjon. Du kan eksplisitt spesifisere en fast eller fri form for notasjon for Fortran-programmer ved å bruke alternativene -FI Og -FR hhv.

Filer med utvidelsen .s anerkjent som monteringsspråkkode for IA-32.

Intel-kompilatorfunksjoner

Her presenterer vi egenskapene til Intel-kompilatorer som angitt av utvikleren i brukermanualen med noen av våre kommentarer.

• Betydelig optimalisering
  Tilsynelatende betyr dette å optimalisere koden på et høyt nivå, dvs. først og fremst ulike loop-transformasjoner, som nesten alle kompilatorer gjør med større eller mindre suksess
• Flytepunktoptimalisering
  Tilsynelatende betyr dette først og fremst maksimal bruk av kommandoer implementert på maskinvarenivå
• Interprosessuelle optimaliseringer
  de. global optimalisering av hele programmet, i motsetning til vanlig optimalisering, som kun påvirker koden til spesifikke funksjoner
• Profilbasert optimalisering
  de. muligheten til å kjøre et program i testmodus, samle inn data om tiden det tar å sende visse kodefragmenter i ofte brukte funksjoner, og deretter bruke disse dataene for optimalisering
• Støtte for SSE-instruksjonssettet i Pentium III-prosessorer
  merk: for databehandlingsoppgaver er SSE2-kommandoer av mer interesse, dvs. vektorkommandoer over 64-bits reelle tall, men de støttes kun på Pentium 4-prosessorer, som vi ikke har til rådighet ennå
• Automatisk vektorisering
  de. igjen, ved å bruke SSE- og SSE2-kommandoene, satt inn automatisk av kompilatoren
• OpenMP-støtte for programmering på SMP-systemer
  merk: på en klynge anbefales det å primært bruke MPI-grensesnittet; utbredt bruk av OpenMP på klyngen forventes ikke, og slike eksperimenter har ennå ikke blitt utført; men det er sannsynligvis fornuftig å bruke biblioteker (BLAS, etc.) som er parallellisert for delt minne.
• Forhåndshenting av data
  de. Tilsynelatende bruk av forhåndsinnlastningskommandoer fra minnet til databufferen, som vil være nødvendig etter en stund
• "Dispatching"-kode for forskjellige prosessorer
  de. muligheten til å generere kode for forskjellige prosessorer i en enkelt kjørbar fil, som lar deg dra nytte av de nyeste prosessorene for å oppnå den høyeste ytelsen på dem, samtidig som binær kompatibilitet av programmer med tidligere prosessorer opprettholdes; På vår klynge er ikke dette aktuelt ennå, pga bare Pentium III-prosessorer brukes, og programmer kompilert på klyngen skal ikke overføres og kjøres på andre maskiner

Grunnleggende kompilatoralternativer

Det mest interessante er selvfølgelig alternativene for kodeoptimalisering. De fleste alternativene er felles for C++- og Fortran-kompilatorene. Mer Detaljert beskrivelse alternativer i engelske brukerhåndbøker.

Opptreden

I følge resultatene av å kjøre SPEC CPU2000-testene, publisert på ixbt.com-serveren, var Intel-kompilatorer versjon 6.0 nesten universelt bedre sammenlignet med gcc-kompilatorer versjoner 2.95.3, 2.96 og 3.1, og PGI versjon 4.0.2. Disse testene ble utført i 2002 på en datamaskin med en Pentium 4/1,7 GHz prosessor og RedHat Linux 7.3.

I følge tester utført av Polyhedron var Intel Fortran-kompilatorversjon 7.0 nesten universelt overlegen andre Fortran 77-kompilatorer for Linux (Absoft, GNU, Lahey, NAG, NAS, PGI). Bare i noen tester er Intel-kompilatoren litt dårligere enn Absoft-, NAG- og Lahey-kompilatorene. Disse testene ble utført på en datamaskin med en Pentium 4/1,8 GHz-prosessor og Mandrake Linux 8.1.

Intel-kompilatorer versjon 9.1 overgår også gcc-kompilatorer, og viser ytelse som kan sammenlignes med Absoft, PathScale og PGI.

Vi vil være takknemlige for de brukerne og leserne som sender oss data om innvirkningen av valget av kompilator (GCC eller Intel) og optimaliseringsalternativer på hastigheten på arbeidet med deres virkelige problemer.

Biblioteker

C-språkkompilatoren bruker et kjøretidsbibliotek utviklet i GNU-prosjektet ( libc.a).

Følgende biblioteker leveres med Intel C++-kompilatoren:

• libcprts.a- runtime C++ språkbibliotek utviklet av Dinkumware.
• libcxa.a- ekstra kjøretidsbibliotek for C++-utvikling av Intel.
• libimf.a- et bibliotek med matematiske funksjoner utviklet av Intel, som inkluderer optimaliserte og høypresisjonsimplementeringer av trigonometriske, hyperbolske, eksponentielle, spesielle, komplekse og andre funksjoner (for mer detaljer, se listen over funksjoner).
• libirc.a- Runtime-støtte for profilering (PGO) og kodesending avhengig av prosessoren (se ovenfor).
• libguide.a- OpenMP implementering.

Denne listen inneholder statiske biblioteker, men for de fleste av dem finnes det også dynamiske, dvs. alternativer tilkoblet under oppstart ( .så).

Følgende biblioteker leveres med Fortran-kompilatoren: libCEPCF90.a, libIEPCF90.a, libintrins.a, libF90.a, biblioteket med matematiske funksjoner libimf.a brukes også.

Bygger den kjørbare filen

Biblioteker kan kobles statisk (under bygging) eller dynamisk (under programoppstart). Den dynamiske tilnærmingen lar deg redusere størrelsen på den kjørbare filen og lar deg dele den samme kopien av biblioteket i minnet, men for dette må du installere et komplett sett med dynamiske biblioteker som brukes på hver node der programmene skal kjøres .

Derfor, hvis du installerte Intel-kompilatoren på Linux-maskinen din og ønsker å kjøre de kompilerte kjørbare filene på andre maskiner, må du enten bruke en statisk build (som er enklere) eller kopiere Intels dynamiske biblioteker til disse maskinene (vanligvis fra en katalog som /opt/intel /compiler70/ia32/lib) til en av katalogene som er oppført i filen /etc/ld.so.conf, og sørg også for at det samme settet med GNU/Linux dynamiske biblioteker er installert på disse maskiner.

Som standard er alle Intel-utviklingsbiblioteker (unntatt libcxa.so) koblet statisk, og alle Linux-systembiblioteker og GNU-biblioteker er koblet dynamisk. Bruker alternativet -statisk du kan tvinge samleren (lenkeredigering) til å koble alle biblioteker statisk (noe som vil øke volumet kjørbar fil), og bruke alternativet -i_dynamic Du kan dynamisk koble alle Intels utviklingsbiblioteker.

Når du kobler til flere biblioteker ved å bruke visningsalternativet -bibliotek kan det hende du må bruke alternativet -Lkatalog for å angi banen der bibliotekene er plassert.

Bruker alternativer -Bstatisk Og -Bdynamic du kan eksplisitt spesifisere dynamisk eller statisk tilkobling for hvert av bibliotekene spesifisert i kommandolinje.

Bruker alternativet -c montering av den kjørbare filen er deaktivert og kun kompilering utføres (generering av objektmodul).

Dele moduler i Fortran og C

For å dele moduler skrevet i Fortran og C, må du bli enige om navngivning av prosedyrer i objektmoduler, overføring av parametere og tilgang til globale variabler, hvis noen.

Som standard konverterer Intel Fortran-kompilatoren prosedyrenavn til små bokstaver og legger til en understreking på slutten av navnet. C-kompilatoren endrer aldri funksjonsnavn. Derfor, hvis vi ønsker å kalle en funksjon eller prosedyre FNNAME implementert i C fra en Fortran-modul, bør den i C-modulen hete fnname_.

Fortran-kompilatoren støtter alternativet -nus [filnavn], som lar deg deaktivere tillegg av understreking til interne prosedyrenavn. Hvis et filnavn er spesifisert, gjøres dette kun for prosedyrenavn som er oppført i den angitte filen.

Som standard sendes parametere i Fortran ved referanse, og i C sendes de alltid etter verdi. Når vi kaller en Fortran-prosedyre fra en C-modul, må vi derfor sende pekere til de tilsvarende variablene som inneholder verdiene til de faktiske parameterne som parametere. Når du skriver en funksjon i C som må kalles fra en Fortran-modul, må vi beskrive de formelle parameterne som pekere til de tilsvarende typene.

I C-moduler er det mulig å bruke COMMON-blokker definert inne i Fortran-moduler (for mer informasjon, se Intel Fortran Compiler User's Guide, kapittel Blanding av C og Fortran).

Deler Intel- og GCC-kompilatorer

C-objektmoduler produsert av Intel C++-kompilatoren er kompatible med moduler produsert av GCC-kompilatoren og GNU C-biblioteket. Dermed kan disse modulene brukes sammen i et enkelt program kompilert ved hjelp av icc- eller gcc-kommandoene, men det anbefales å bruke icc for å inkludere Intel-biblioteker korrekt.

Intel-kompilatoren støtter en rekke ikke-standardiserte C-språkutvidelser som brukes av GNU-prosjektet og støttes av GCC-kompilatoren (men ikke alle, se her for flere detaljer).

Brukerhåndboken sier ikke noe om kompatibiliteten til objektmoduler i C++- og Fortran-språkene; tilsynelatende støttes den ikke.

Støtte for standarder

Intel C++ Compiler 7.0 for Linux støtter ANSI/ISO C-språkstandarden (ISO/IEC 9899/1990). Det er mulig å etablere streng kompatibilitet med ANSI C-standarden ( -ansi) eller utvidet ANSI C-dialekt ( -Xa). Når du bruker alternativet -c99

I forrige utgave av magasinet diskuterte vi produkter fra Intel VTune Performance Analyzer-familien - ytelsesanalyseverktøy som er fortjent populære blant applikasjonsutviklere og tillater deteksjon i kode teamsøknader, som kaster bort for mye CPU-ressurser, noe som gir utviklere muligheten til å identifisere og eliminere potensial trange steder, assosiert med lignende seksjoner av kode, og dermed fremskynde applikasjonsutviklingsprosessen. Vær imidlertid oppmerksom på at ytelsen til applikasjoner i stor grad avhenger av hvor effektive kompilatorene som brukes i utviklingen deres er, og hvilke funksjoner maskinvare de brukes ved generering av maskinkode.

De nyeste versjonene av Intel Intel C++ og Intel Fortran-kompilatorene for Windows og Linux lar deg oppnå ytelsesfordeler for applikasjoner for systemer basert på Intel-prosessorer Itanium 2, Intel Xeon og Intel Pentium 4 opptil 40 % sammenlignet med eksisterende kompilatorer fra andre produsenter på grunn av bruken av slike funksjoner til disse prosessorene som Hyper-Threading-teknologi.

Forskjeller knyttet til kodeoptimalisering av denne familien av kompilatorer inkluderer bruk av en stabel for å utføre flyttalloperasjoner, interprosedyreoptimalisering (IPO), optimalisering i samsvar med applikasjonsprofilen (Profile Guided Optimization (PGO), forhåndslaste data inn i hurtigbufferen ( Dataforhåndshenting), som unngår ventetid knyttet til minnetilgang, støtte for de karakteristiske egenskapene til Intel-prosessorer (for eksempel utvidelser for streaming databehandling Intel Streaming SIMD Extensions 2, karakteristisk for Intel Pentium 4), automatisk parallellisering av kodeutførelse, applikasjon opprettelse, kjører på flere forskjellige typer prosessorer når du optimaliserer for en av dem, verktøy for å "forutsi" påfølgende kode (grenprediksjon), utvidet støtte for å jobbe med utførelsestråder.

Merk at Intel-kompilatorer brukes i så velkjente selskaper som Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. I følge uavhengige tester utført av en rekke selskaper, er ytelsen til Intel-kompilatorer betydelig høyere enn ytelsen til kompilatorer fra andre produsenter (se for eksempel http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf .pdf).

Nedenfor skal vi se på noen funksjoner siste versjoner Intel-kompilatorer for skrivebord og server operativsystemer.

Kompilatorer for Microsoft Windows-plattformen

Intel C++ Compiler 7.1 for Windows

Intel C++ Compiler 7.1 er en kompilator utgitt tidligere i år som gir svært optimalisert kode for Intel Itanium-, Intel Itanium 2-, Intel Pentium 4- og Intel Xeon-prosessorene, samt Intel Pentium M-prosessoren som bruker Intel Centrino-teknologi og beregnet for bruk i mobile enheter.

Den angitte kompilatoren er fullt kompatibel med utviklingsverktøyene Microsoft Visual C++ 6.0 og Microsoft Visual Studio .NET: den kan bygges inn i de tilsvarende utviklingsmiljøene.

Denne kompilatoren støtter ANSI og ISO C/C++ standarder.

Intel Fortran Compiler 7.1 for Windows

Intel Fortran Compiler 7.1 for Windows, også utgitt tidligere i år, lar deg lage optimalisert kode for Intel Itanium, Intel Itanium 2, Intel Pentium 4 og Intel Xeon, Intel Pentium M-prosessorer.

Denne kompilatoren er fullt kompatibel med Microsoft Visual C++ 6.0 og Microsoft Visual Studio .NET utviklingsverktøy, det vil si at den kan bygges inn i de tilsvarende utviklingsmiljøene. I tillegg lar denne kompilatoren deg utvikle 64-bits applikasjoner for operativsystemer som kjører på Itanium/Itanium 2-prosessorer ved å bruke Microsoft Visual Studio på en 32-bits Pentium-prosessor ved å bruke 64-bit Intel Fortran Compiler. Når du feilsøker kode, lar denne kompilatoren deg bruke en debugger for å Microsoft-plattformer.NETT.

Hvis du har Compaq-produktet installert, kan Visual Fortran 6.6 brukes i stedet for den originale Intel Fortran Compiler 7.1, siden disse kompilatorene er kompatible på nivået kildekode.

Intel Fortran Compiler 7.1 for Windows er fullt kompatibel med ISO Fortran 95-standarden og støtter oppretting og feilsøking av programmer som inneholder kode på to språk: C og Fortran.

Kompilatorer for Linux-plattformen

Intel C++ Compiler 7.1 for Linux

En annen kompilator som ble utgitt i begynnelsen av året, Intel C++ Compiler 7.1 for Linux, lar deg oppnå en høy grad av kodeoptimalisering for prosessorene Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Denne kompilatoren er fullstendig kompatibel med GNU C-kompilatoren ved kildekode- og objektmodulene, som lar deg migrere applikasjoner opprettet med GNU C til den uten ekstra kostnader. Intel C++-kompilatoren støtter C++ ABI (et tillegg til Linux-kjernen som lar deg kjøre under Linux-kontroll kompilert kode for andre plattformer som tidlige SCO-operativsystemer, tidlige versjoner Sun Solaris, etc.), som betyr full kompatibilitet med gcc 3.2-kompilatoren på binærkodenivå. Til slutt, med Intel C++ Compiler 7.1 for Linux, kan du til og med rekompilere Linux-kjernen ved å gjøre noen få mindre endringer i kildekoden.

Intel Fortran Compiler 7.1 for Linux

Intel Fortran Compiler 7.1 for Linux lar deg lage optimalisert kode for prosessorene Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Denne kompilatoren er fullt kompatibel med Compaq Visual Fortran 6.6-kompilatoren på kildekodenivå, slik at du å rekompilere applikasjoner ved å bruke den opprettet med Compaq Visual Fortran, og dermed øke ytelsen.

I tillegg er den spesifiserte kompilatoren kompatibel med slike verktøy som brukes av utviklere som emacs-editoren, gdb-debuggeren og verktøyet make application build.

I likhet med Windows-versjonen av denne kompilatoren, er Intel Fortran Compiler 7.1 for Linux fullt kompatibel med ISO Fortran 95-standarden og støtter oppretting og feilsøking av programmer som inneholder kode på to språk: C og Fortran.

Det bør spesielt understrekes at et betydelig bidrag til opprettelsen av de listede Intel-kompilatorene ble gitt av spesialister fra Intel Russian Software Development Center i Nizhny Novgorod. Mer detaljert informasjon Informasjon om Intel-kompilatorer finnes på Intels nettsted på www.intel.com/software/products/.

Den andre delen av denne artikkelen vil bli viet til Intel-kompilatorer som lager applikasjoner for mobile enheter.

Eksempler på ekte hacks: Intel C++ 7.0 Compiler - Arkiv WASM.RU

... Intel C++ 7.0-kompilatoren lastet ned sent på kvelden, omtrent fem om morgenen. Jeg ville egentlig sove, men jeg ble også revet av nysgjerrighet: om beskyttelsen var styrket eller ikke. Jeg bestemte meg for at inntil jeg fant ut beskyttelsen jeg fortsatt ikke ville sovne, åpnet jeg ny konsoll, og tilbakestille systemvariablene TEMP og TMP til C:\TEMP-katalogen, raskt skrevet uanstendig langt navn installasjonsprogrammet W_CC_P_7.0.073.exe på kommandolinjen (behovet for å angi TEMP- og TMP-variablene er forklart av det faktum at i Windows 2000 peker de som standard til en veldig dypt nestet katalog, og Intel C++-installasjonsprogrammet - og ikke bare det - støtter ikke stier av en så stor størrelse).

Det ble umiddelbart klart at beskyttelsespolicyen var radikalt revidert, og nå ble tilstedeværelsen av en lisens kontrollert allerede på installasjonsstadiet (i versjon 5.x ble installasjonen utført uten problemer). OK, vi gir dir kommandoen og ser på innholdet i det vi nå må kjempe med:

Innholdet 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

notater

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

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

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

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

17.10.2002 16:35 386 credist.txt

16.10.2002 17:02 34 136 Crellnotes.htm

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

21.02.2002 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 oppsett.mwg

19 filer 2 519 238 byte

6 mapper 886 571 008 byte gratis

Ja! Installasjonsprogrammet setup.exe tar bare 40 kilobyte. Veldig bra! Det er usannsynlig at du kan skjule seriøs beskyttelse i et slikt volum, og selv om det er tilfelle, er denne lille filen ikke verdt å analysere i sin helhet - helt ned til siste byte i disassembler-oppføringen. Det er imidlertid ikke et faktum at sikkerhetskode ligger nøyaktig i setup.exe, kan den ligge et annet sted, for eksempel... ChkLic.dll/ChkLic.exe, som til sammen opptar litt mindre enn syv hundre kilobyte. Vent, hva er ChkLic? Er dette en forkortelse for Check License eller hva?! Hmm, gutta fra Intel har åpenbart alvorlige problemer med sans for humor. Det ville vært bedre om de kalte denne filen "Hack Me" ærlig! Ok, etter volumet å dømme, er ChkLic den samme FLEX lm, og vi har allerede møtt den (se "Intel C++ 5.0 Compiler") og har en grov ide om hvordan vi kan bryte den.

Vi gir kommandoen "dumpbin /EXPORTS ChkLic.dll" for å undersøke de eksporterte funksjonene og... hold godt fast i Klava for ikke å falle av stolen:

Dump av filen ChkLic.dll

1. Seksjonen inneholder følgende eksporter for ChkLic.dll

   0 egenskaper

   3DB438B4 tidsdatostempel man 21. okt 21:26:12 2002

3. 1 antall funksjoner

   1 antall navn

   ordinært hint RVA-navn

   1 0 000010A0 _CheckValidLicense

Faen! Beskyttelsen eksporterer bare én enkelt funksjon med det fantastiske navnet CheckValidLicense. "Fantastisk" - fordi formålet med funksjonen blir tydelig fra navnet og det blir mulig å unngå møysommelig analyse av demonteringskoden. Vel, de har mistet all interesse... det ville vært bedre om de eksporterte det vanlig eller noe, eller i det minste døpte det med et slags skremmende navn som DES Decrypt.

...dagdrømming! Ok, la oss gå tilbake til sauene våre. La oss tenke logisk: hvis all sikkerhetskoden er konsentrert direkte i ChkLic.dll (og, å dømme etter beskyttelsens "hengslede" natur, er dette faktisk tilfellet), så kommer all "beskyttelse" ned til å kalle CheckValidLicense fra Setup. exe og sjekke resultatet returnert av det. Derfor, for å "hakke" er det nok bare å miste ChkLic.dll, og tvinge ChekValidLicense-funksjonen til alltid å returnere ... og forresten, hva skal den returnere? Mer presist: hva er egentlig returverdien som tilsvarer en vellykket lisenssjekk? Nei, ikke skynd deg å demontere setup.exe for å finne ut det, fordi mulige alternativer ikke så mye lenger: enten USANT eller SANN. Satser du på TRUE? Vel, på en måte er dette logisk, men på den annen side: hvorfor bestemte vi oss for at CheckValidLicense-funksjonen returnerer nøyaktig flagget for suksessen til operasjonen, og ikke feilkoden? Tross alt må det på en eller annen måte motivere årsakene til å nekte å installere kompilatoren: filen med lisensen ble ikke funnet, filen er skadet, lisensen er utløpt, og så videre? Ok, la oss prøve å returnere null, og hvis det ikke fungerer, returnerer vi en.

OK, fest deg, la oss gå! Vi starter HIEW, åpner filen ChkLic.dll (hvis den ikke åpnes, husk gopherne tre ganger, kopier den midlertidig til roten eller en annen katalog som ikke inneholder spesialtegn i navnet som hiew ikke liker) . Deretter, ved å snu igjen til eksporttabellen hentet med dumpbin, bestemmer vi adressen til CheckValidLicense-funksjonen (i dette tilfellet 010A0h) og gjennom "10A0" går vi til begynnelsen. Nå kutter vi den "live", og overskriver over gammel kode "XOR EAX, EAX/RETN 4". Hvorfor akkurat "REN 4" og ikke bare "RET"? Ja, fordi funksjonen støtter stdcall-konvensjonen, som du kan finne ut ved å se på epilogen i HIEW"e ( bare bla nedover demonteringsskjermen til du møter RET).

La oss sjekke... Det fungerer!!! Til tross for mangelen på lisens, starter installatøren installasjonen uten å stille noen spørsmål! Derfor falt forsvaret. Å, vi kan ikke tro at alt er så enkelt, og for ikke å sitte dumt og stirre på skjermen og vente på at programinstallasjonsprosessen skal fullføres, bruker vi vår favoritt IDA-demontering på setup.exe. Det første som fanger oppmerksomheten er fraværet av CheckValidLicense i listen over importerte funksjoner. Kanskje det på en eller annen måte starter ChkLic.exe-filen? Vi prøver å finne den tilsvarende lenken blant de automatisk gjenkjente linjene: "~View aNames", "ChkLic"... ja, linjen "Chklic.exe" er ikke der i det hele tatt, men "Chklic.dll" er oppdaget. Ja, jeg skjønner, det betyr at ChkLic-biblioteket lastes ved eksplisitt kobling via LoadLibrary. Og å følge kryssreferansen bekrefter dette:

Tekst:0040175D push offset aChklic_dll ; lpLibFileName

Tekst:00401762 ring ds:LoadLibraryA

Tekst:00401762 ; last ChkLic.dll ^^^^^^^^^^^^^^^^^

Tekst:00401762 ;

Tekst:00401768 mov esi, eax

Tekst:0040176A push offset a_checkvalidlic ; lpProcName

Tekst:0040176F push esi ; hModul

Tekst:00401770 ring ds:GetProcAddress

Tekst:00401770 ; få adressen til funksjonen CheckValidLicense

Tekst:00401770 ;

Tekst:00401776 cmp esi, ebx

Tekst:00401778 jz loc_40192E

Tekst:00401778 ; hvis det ikke finnes et slikt bibliotek, avslutter du installasjonsprogrammet

Tekst:00401778 ;

Tekst:0040177E cmp eax, ebx

Tekst:00401780 jz loc_40192E

Tekst:00401780 ; hvis det ikke er en slik funksjon i biblioteket, avslutter du installasjonen

Tekst:00401780 ;

Tekst:00401786 push ebx

SMS:00401787 ring eax

Tekst:00401787 ; kall opp ChekValidLicense-funksjonen

Tekst:00401787 ;

Tekst:00401789 test eax, eax

Tekst:0040178B jnz loc_4019A3

Tekst:0040178 ; hvis funksjonen returnerte ikke-null, avslutter du installasjonsprogrammet

Utrolig nok er dette fryktelig primitive forsvaret bygget akkurat slik! Dessuten er halvmetersfilen ChkLic.exe ikke nødvendig i det hele tatt! Og hvorfor var det verdt å dra det fra Internett? Forresten, hvis du bestemmer deg for å lagre kompilatordistribusjonen (obs: jeg sa ikke "distribuer"!), så kan ChkLic.* slettes for å spare diskplass: enten ved å slette setup.exe, for alltid å avvenne den fra få tilgang til dem, eller ved ganske enkelt å lage din egen ChkLic.dll, eksportere stdcall-funksjonen CheckValidLicence av skjemaet: int CheckValidLicence(int some_flag) (retur 0;)

Vel, mens vi diskuterte alt dette, fullførte installasjonsprogrammet installasjonen av kompilatoren og fullførte arbeidet. Er det interessant om kompilatoren starter, eller er all moroa bare begynt? Vi går febrilsk ned i det forgrenede hierarkiet av undermapper, finner icl.exe, som, som man kunne forvente, ligger i bin-katalogen, klikker og... Kompilatoren starter naturligvis ikke, med henvisning til det faktum at "icl: error: kunne ikke sjekke ut FLEX lm-lisens", uten hvilken han ikke kan fortsette arbeidet sitt.

Det viser seg at Intel brukte flernivåbeskyttelse og det første nivået viste seg å være en grov beskyttelse mot idioter. Vi vil! Vi aksepterer denne utfordringen og, basert på vår tidligere erfaring, ser vi automatisk etter LMGR*.DLL-filen i kompilatorkatalogen. Ubrukelig! Denne gangen er det ingen slik fil her, men det viser seg at icl.exe har gått opp mye i vekt, over seks hundre kilobyte... Stopp! Linket ikke kompilatorutviklerne denne samme FLEX lm med statisk kobling? La oss se: i Intel C++ 5.0 var summen av størrelsene til lmgr327.dll og icl.exe 598 KB, og nå opptar icl.exe alene 684 KB. Tatt i betraktning justeringen for naturlig senil "fedme", stemmer tallene veldig godt. Så, tross alt, FLEX lm! Åh åh! Men nå, uten symbolske funksjonsnavn, vil det være mye vanskeligere å bryte beskyttelsen... La oss imidlertid ikke få panikk på forhånd! La oss tenke, bare rolig! Det er usannsynlig at utviklingsteamet fullstendig omskrev all koden som samhandler med denne "konvoluttbeskyttelsen". Mest sannsynlig endte dens "forbedring" med bare en endring i type layout. Og i så fall er sjansene for å hacke programmet fortsatt store!

Når vi husker at forrige gang sikkerhetskoden var i hovedfunksjonen, satte vi, etter å ha bestemt adressen, ganske enkelt et bruddpunkt og, mens vi venter på at feilsøkeren skal dukke opp, sporer vi dumt koden, vekselvis ser på debuggeren og deretter på programutgangen vindu: har Er det en eksplosjonsmelding? Samtidig markerer vi alle de betingede overgangene vi møter på et eget stykke papir (eller legg det i vårt eget minne, hvis du vil), og glemmer ikke å angi om hver betinget overgang ble utført eller ikke... Stopp! Du og jeg pratet om noe, men en støtende melding har allerede dukket opp! Ok vel! La oss se hvilken betinget overgang som tilsvarte det. Våre registreringer viser at det siste hoppet som ble oppdaget var JNZ betinget hopp, lokalisert på adressen 0401075h og "reagerer" på resultatet returnert av sub_404C0E:

Tekst:0040107F loc_40107F: ; KODE XREF: _main+75^j

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

Tekst:00401084 mov edx, 21t

Tekst:00401089 ring sub_404C0E

Tekst:0040108E test eax, eax

Tekst:00401090 jnz short loc_40109A

Åpenbart er sub_404C0E selve den beskyttende prosedyren som sjekker lisensen for dens tilstedeværelse. Hvordan lure henne? Vel, det er mange alternativer... For det første kan du gjennomtenkt og nøye analysere innholdet i sub_404C0E for å finne ut nøyaktig hva den sjekker og nøyaktig hvordan den sjekker. For det andre kan du ganske enkelt erstatte JNZ short loc_40107F med JZ short loc_40107F eller til og med NOP, NOP. For det tredje kan returresultatkontrollkommandoen TEST EAX, EAX gjøres om til en nullkommando: XOR EAX, EAX. For det fjerde kan du få sub_404C0E til å forsvinne slik at den alltid returnerer null. Jeg vet ikke med deg, men jeg likte metode nummer tre mest. Vi endrer to byte og starter kompilatoren. Hvis det ikke er andre kontroller av "lisensieringen" i beskyttelsen, vil programmet fungere og følgelig omvendt. (Som vi husker, var det i den femte versjonen to slike kontroller). Utrolig nok klager ikke kompilatoren lenger og fungerer!!! Faktisk, som man kunne forvente, styrket ikke utviklerne beskyttelsen i det hele tatt, men tvert imot svekket den til og med! Chris Kaspersky

Du er ikke en slave!
Lukket utdanningskurs for barn av eliten: "Verdens sanne ordning."
http://noslave.org

Materiale fra Wikipedia - det frie leksikonet