Компајлери на Интел. Зошто беа потребни нови компајлери?

Компајлери на Intel C++ и Fortran и библиотека MKL

Заедно со стандардните GNU компајлери за Linux, компајлери на Intel C++ и Fortran се инсталирани на кластерите на компјутерскиот комплекс NIVC. Во моментов (почеток на 2006 година), верзијата 9.1 на компајлери се инсталирани на сите кластери. Оваа страница е посветена на опишување на најважните опции и поставки на овие компајлери, како и нивните главни разлики од компајлерите на GNU. Страницата е наменета главно за корисниците на кластерите на MSU Research Computing Centre, но може да биде корисна и за другите корисници кои зборуваат руски. Прашањата поврзани со компилацијата за платформата IA-64 не се опфатени овде.

Исто така, библиотеката на Интел е инсталирана на сите кластери Математичка библиотека на јадрото(MKL) верзија 8.0.2. Библиотеката се наоѓа во директориумот /usr/mkl. Ве молиме имајте предвид дека поддиректориумите 32, 64 и em64t се достапни во директориумот lib. На кластерот Ant треба да ги користите библиотеките од поддиректориумот em64t, а на другите кластери - од поддиректориумот 32. Целата потребна документација и примери може да се добијат од директориумот /usr/mkl/doc.

Зошто беа потребни нови компајлери?

Потребата за нови компајлери се појави главно за а) поддршка на програмирање во Fortran 90, а исто така и б) за помоќна оптимизација на програмите Fortran отколку што е обезбедена од компајлерот g77, кој користи превод во C, а потоа компилација користејќи gcc.

Компајлерите на PGI (Portland Group), исто така, ги исполнуваат овие барања, но компанијата за развој одби да ги достави во Русија.

Како да се користи?

Компајлерите на Интел се повикуваат со помош на команди ицц(C или C ++), icpc(C++) и ифорт(Фортран 77/90). Наредбите mpicc, mpiCC и mpif77 за компајлирање и склопување на MPI програми се исто така конфигурирани да користат компајлери на Интел.

Исто така, можно е да се користат GNU компајлери со помош на командите mpigcc, mpig++ и mpig77 (Fortran 90 не е поддржан).

Внесете датотеки

Стандардно, датотеките со наставката .cppИ .cxxсе сметаат за изворни текстови на јазикот C++, датотеки со наставката .в- Изворниот код C, а компајлерот icpc, исто така, компајлира датотеки .c како изворен код во C++.

Датотеки со екстензии .ѓ, .ftnИ .засе препознаваат како изворни текстови на јазикот Фотран, со фиксна форма на нотација и датотеките .fppИ .Фдополнително помина низ препроцесорот на јазикот Fortran. Датотеки со наставката .f90се сметаат за изворни текстови на Фортран 90/95 со нотација во слободна форма. Можете експлицитно да наведете фиксна или слободна форма на нотација за програмите Fortran користејќи ги опциите -ФИИ -ФРсоодветно.

Датотеки со наставката .спризнат како код на асемблерски јазик за IA-32.

Карактеристики на компајлерот на Интел

Овде ги презентираме карактеристиките на компајлерите на Интел како што е наведено од развивачот во упатството за употреба со некои од нашите коментари.

• Значајна оптимизација
  Очигледно, ова значи оптимизирање на кодот на високо ниво, т.е. пред сè, различни трансформации на јамки, кои речиси сите компајлери ги прават со помал или поголем успех
• Оптимизација на подвижна точка
  Очигледно, ова значи, пред сè, максимална употреба на команди имплементирани на хардверско ниво
• Меѓупроцедурални оптимизации
  тие. глобална оптимизација на целата програма, за разлика од обичната оптимизација, која влијае само на кодот на одредени функции
• Оптимизација базирана на профил
  тие. способноста да се изврши програма во режим на тестирање, да се собираат податоци за времето потребно за да се пренесат одредени фрагменти од код во често користените функции и потоа да се користат овие податоци за оптимизација
• Поддршка за сет на инструкции SSE во процесорите Pentium III
  забелешка: за пресметковни задачи, командите SSE2 се од поголем интерес, т.е. векторски команди преку 64-битни реални броеви, но тие се поддржани само на процесорите Pentium 4, кои сè уште ги немаме на располагање
• Автоматска векторизација
  тие. повторно, користејќи ги командите SSE и SSE2, вметнати автоматски од компајлерот
• OpenMP поддршка за програмирање на SMP системи
  забелешка: на кластерот се препорачува првенствено да се користи интерфејсот MPI; не се очекува широка употреба на OpenMP на кластерот и такви експерименти сè уште не се извршени; но веројатно има смисла да се користат библиотеки (BLAS, итн.) кои се паралелизирани за споделена меморија.
• Преземање податоци
  тие. Очигледно, употребата на команди за претходно вчитување од меморијата во кешот на податоци, што ќе биде потребно по некое време
• Код за „испраќање“ за различни процесори
  тие. способноста да се генерира код за различни процесори во една извршна датотека, што ви овозможува да ги искористите предностите најновите процесорида се постигнат највисоки перформанси на нив, додека се одржува бинарна компатибилност на програмите со претходните процесори; На нашиот кластер ова сè уште не е релевантно, бидејќи се користат само процесори Pentium III, а програмите компајлирани на кластерот не треба да се префрлаат и работат на други машини

Основни опции за компајлерот

Најинтересни, се разбира, се опциите за оптимизација на кодот. Повеќето од опциите се заеднички за компајлерите C++ и Fortran. Повеќе Детален описопции во англиските прирачници за употреба.

Изведба

Според резултатите од извршувањето на тестовите SPEC CPU2000, објавени на серверот ixbt.com, верзијата 6.0 на компајлерите на Intel беа речиси универзално подобри во споредба со верзиите на компајлери gcc 2.95.3, 2.96 и 3.1 и PGI верзијата 4.0.2. Овие тестови беа спроведени во 2002 година на компјутер со процесор Pentium 4/1,7 GHz и RedHat Linux 7.3.

Според тестовите спроведени од Polyhedron, верзијата 7.0 на компајлерот на Intel Fortran беше речиси универзално супериорна во однос на другите компајлери Fortran 77 за Linux (Absoft, GNU, Lahey, NAG, NAS, PGI). Само во некои тестови компајлерот на Интел е малку инфериорен во однос на компајлерите Absoft, NAG и Lahey. Овие тестови беа извршени на компјутер со процесор Pentium 4/1,8 GHz и Mandrake Linux 8.1.

Интел компајлери верзијата 9.1, исто така, ги надминуваат gcc компајлерите и покажуваат перформанси споредливи со Absoft, PathScale и PGI.

Ќе им бидеме благодарни на оние корисници и читатели кои ни испраќаат податоци за влијанието на изборот на компајлерот (GCC или Intel) и опциите за оптимизација на брзината на работа на нивните реални проблеми.

Библиотеки

Компајлерот на јазикот C користи библиотека за траење развиена во рамките на проектот GNU ( libc.a).

Следниве библиотеки се испорачуваат со компајлерот на Intel C++:

• libcprts.а- библиотека за јазик C++ за траење развиена од Dinkumware.
• libcxa.а- дополнителна библиотека за траење за развој на C++ од Intel.
• libimf.а- библиотека со математички функции развиена од Интел, која вклучува оптимизирани и високопрецизни имплементации на тригонометриски, хиперболични, експоненцијални, специјални, сложени и други функции (за повеќе детали, видете ја листата на функции).
• libirc.а- Поддршка за време на траење за профилирање (PGO) и испраќање код во зависност од процесорот (види погоре).
• libguide.а- Имплементација на OpenMP.

Оваа листа содржи статични библиотеки, но за повеќето од нив има и динамични, т.е. опции поврзани при стартување ( .така).

Следниве библиотеки се испорачуваат со компајлерот Fortran: libCEPCF90.а, libIEPCF90.а, либинтрини.а, libF90.а, се користи и библиотеката на математички функции libimf.a.

Градење на извршна датотека

Библиотеките може да се поврзат статички (за време на изградбата) или динамички (за време на стартување на програмата). Динамичниот пристап ви овозможува да ја намалите големината на извршната датотека и ви овозможува да ја споделите истата копија од библиотеката во меморијата, но за ова треба да инсталирате целосен сет на динамични библиотеки што се користат на секој јазол каде што ќе се извршуваат програмите .

Така, ако сте го инсталирале компајлерот Интел на вашата машина со Линукс и сакате да ги извршувате компајлираните извршни датотеки на други машини, тогаш треба или да користите статична градба (што е полесно) или да ги копирате динамичните библиотеки на Интел на овие машини (обично од директориум како /opt/intel /compiler70/ia32/lib) на еден од директориумите наведени во датотеката /etc/ld.so.conf, а исто така проверете дали истиот сет на динамички библиотеки GNU/Linux се инсталирани на овие машини.

Стандардно, сите библиотеки за развој на Интел (освен libcxa.so) се статички поврзани, а сите системски библиотеки на Linux и GNU библиотеки се поврзани динамично. Користење на опцијата -статичкиможете да го принудите колекторот (уредувач на врски) статички да ги поврзе сите библиотеки (што ќе ја зголеми јачината на звукот извршна датотека), и користејќи ја опцијата -i_dynamicМожете динамички да ги поврзете сите библиотеки за развој на Интел.

Кога поврзувате дополнителни библиотеки користејќи ја опцијата за преглед -библиотекаможеби ќе треба да ја користите опцијата -Директориумда ја одредите патеката каде што се наоѓаат библиотеките.

Користење на опции -БстатикИ -Бдинамичнаможете експлицитно да наведете динамично или статичко поврзување на секоја од библиотеките наведени во командна линија.

Користење на опцијата -всклопувањето на извршната датотека е оневозможено и се врши само компилација (генерирање на модул на објект).

Споделување модули во Fortran и C

За да споделите модули напишани во Fortran и C, треба да се договорите за именување на процедурите во објектните модули, пренесување на параметри и пристап до глобалните променливи, доколку ги има.

Стандардно, компајлерот Intel Fortran ги конвертира имињата на процедурите во мали букви и додава долна црта на крајот од името. Компајлерот C никогаш не ги менува имињата на функциите. Така, ако сакаме да повикаме функција или постапка FNNAME имплементирана во C од Fortran модул, тогаш во модулот C треба да се вика fnname_.

Компајлерот Fortran ја поддржува опцијата -nus [име на датотека], што ви овозможува да го оневозможите додавањето на долните црти на имињата на внатрешните процедури. Ако е наведено име на датотека, тоа се прави само за имињата на процедурите наведени во наведената датотека.

Стандардно, во Fortran параметрите се пренесуваат со референца, а во C тие секогаш се пренесуваат по вредност. Така, кога повикуваме процедура Fortran од C модул, мора да пренесеме покажувачи на соодветните променливи кои ги содржат вредностите на вистинските параметри како параметри. Кога пишувате функција во C која ќе треба да се повика од Fortran модул, мора да ги опишеме формалните параметри како покажувачи на соодветните типови.

Во модулите C, можно е да се користат ЗАЕДНИЧКИ блокови дефинирани во модулите на Fortran (за повеќе информации, видете во Упатството за корисникот на компајлерот на Intel Fortran, поглавје Мешање C и Fortran).

Споделување на компајлери на Intel и GCC

Модулите за C објект произведени од компајлерот Intel C++ се компатибилни со модулите произведени од компајлерот на GCC и библиотеката GNU C. Така, овие модули може да се користат заедно во една програма составена со помош на командите icc или gcc, но се препорачува да се користи icc за правилно вклучување на библиотеките на Интел.

Компајлерот на Интел поддржува голем број нестандардни екстензии на јазикот C што се користат од проектот GNU и поддржани од компајлерот на GCC (но не сите, видете овде за повеќе детали).

Упатството за корисникот не кажува ништо за компатибилноста на објектните модули на јазиците C++ и Fortran; очигледно, тоа не е поддржано.

Поддршка за стандарди

Intel C++ Compiler 7.0 за Linux го поддржува јазичниот стандард ANSI/ISO C (ISO/IEC 9899/1990). Можно е да се воспостави строга компатибилност со стандардот ANSI C ( -анси) или продолжен дијалект ANSI C ( -Ха). При користење на опцијата -c99

Во претходниот број на списанието, разговаравме за производи од семејството Intel VTune Performance Analyzer - алатки за анализа на перформанси кои се заслужено популарни меѓу развивачите на апликации и овозможуваат откривање во кодот тимски апликации, кои трошат премногу ресурси на процесорот, давајќи им на програмерите можност да го идентификуваат и елиминираат потенцијалот тесни места, поврзани со слични делови од кодот, со што се забрзува процесот на развој на апликации. Забележете, сепак, дека перформансите на апликациите во голема мера зависи од тоа колку се ефикасни компајлерите што се користат во нивниот развој и кои карактеристики хардвертие се користат при генерирање машински код.

Најновите верзии на компајлерите Intel C++ и Intel Fortran за Windows и Linux ви овозможуваат да стекнете придобивки од перформансите на апликацијата за системи базирани на Интел процесори Itanium 2, Intel Xeon и Интел Пентиум 4 до 40% во споредба со постоечките компајлери од други производители поради употребата на такви карактеристики на овие процесори како технологијата Hyper-Threading.

Разликите поврзани со оптимизацијата на кодот од оваа фамилија на компајлери вклучуваат употреба на стек за извршување операции со подвижна запирка, интерпроцедурална оптимизација (IPO), оптимизација во согласност со профилот на апликацијата (Profile Guided Optimization (PGO), претходно вчитување податоци во кешот ( Преземање на податоци), со што се избегнува латентност поврзана со пристап до меморијата, поддршка за карактеристичните карактеристики на процесорите на Intel (на пример, екстензии за обработка на податоци со стриминг Intel Streaming SIMD Extensions 2, карактеристика на Intel Pentium 4), автоматска паралелизација на извршување на кодот, апликација создавање, работи на неколку различни типовипроцесори при оптимизирање за еден од нив, алатки за „предвидување“ на последователен код (предвидување на гранка), проширена поддршка за работа со нишки за извршување.

Забележете дека компајлерите на Интел се користат во познати компании како Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. Според независното тестирање спроведено од голем број компании, перформансите на компајлерите на Интел се значително повисоки од перформансите на компајлерите од други производители (видете, на пример, http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf .pdf).

Подолу ќе разгледаме некои карактеристики најновите верзииИнтел компајлери за десктоп и сервер оперативни системи.

Компајлери за платформата Microsoft Windows

Интел C++ компајлер 7.1 за Windows

Intel C++ Compiler 7.1 е компајлер објавен претходно оваа година кој обезбедува високо оптимизиран код за процесорите Intel Itanium, Intel Itanium 2, Intel Pentium 4 и Intel Xeon, како и процесорот Intel Pentium M кој користи технологија Intel Centrino и е наменет за употреба во Мобилни уреди.

Наведениот компајлер е целосно компатибилен со развојните алатки Microsoft Visual C++ 6.0 и Microsoft Visual Studio .NET: може да се вгради во соодветните развојни околини.

Овој компајлер поддржува ANSI и ISO C/C++ стандарди.

Интел Фортран компајлер 7.1 за Windows

Intel Fortran Compiler 7.1 за Windows, исто така објавен претходно оваа година, ви овозможува да креирате оптимизиран код за процесорите Intel Itanium, Intel Itanium 2, Intel Pentium 4 и Intel Xeon, Intel Pentium M.

Овој компајлер е целосно компатибилен со алатките за развој на Microsoft Visual C++ 6.0 и Microsoft Visual Studio .NET, односно може да се вгради во соодветните развојни околини. Покрај тоа, овој компајлер ви овозможува да развивате 64-битни апликации за оперативни системи кои работат на процесори Itanium/Itanium 2 користејќи Microsoft Visual Studio на 32-битен процесор Pentium со помош на 64-битен компајлер Intel Fortran. При дебагирање на код, овој компајлер ви овозможува да користите дебагер за да Microsoft платформи.НЕТ.

Ако го имате инсталирано производот Compaq, Visual Fortran 6.6 може да се користи наместо оригиналниот Intel Fortran Compiler 7.1, бидејќи овие компајлери се компатибилни на ниво изворен код.

Интел Фортран компајлер 7.1 за Windows е целосно компатибилен со стандардот ISO Fortran 95 и поддржува создавање и дебагирање на апликации што содржат код на два јазика: C и Fortran.

Компајлери за платформата Линукс

Интел C++ компајлер 7.1 за Linux

Друг компајлер што беше објавен на почетокот на годината, Intel C++ Compiler 7.1 за Linux, ви овозможува да постигнете висок степен на оптимизација на кодот за процесорите Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Овој компајлер е целосно компатибилен со GNU C компајлерот во изворниот код и објектните модули, што ви овозможува да мигрирате апликации создадени со користење на GNU C без дополнителни трошоци. под Линукс контролакомпајлиран код за други платформи како што се раните оперативни системи на SCO, раните верзии Sun Solaris, итн.), што значи целосна компатибилност со компајлерот gcc 3.2 на ниво на бинарен код. Конечно, со Intel C++ Compiler 7.1 за Linux, можете дури и да го прекомпајлирате кернелот на Linux со правење неколку мали промени во неговиот изворен код.

Интел Фортран компајлер 7.1 за Линукс

Компајлерот Intel Fortran 7.1 за Linux ви овозможува да креирате оптимизиран код за процесорите Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Овој компајлер е целосно компатибилен со компајлерот Compaq Visual Fortran 6.6 на ниво на изворен код, што ви овозможува да ги прекомпајлирате апликациите користејќи ги создадени со помош на Compaq Visual Fortran, а со тоа да ги зголемите нивните перформанси.

Дополнително, наведениот компајлер е компатибилен со такви алатки што ги користат програмерите како што се уредникот на emacs, дебагерот на gdb и алатката за изработка на апликацијата make.

Како и верзијата за Windows на овој компајлер, Intel Fortran Compiler 7.1 за Linux е целосно компатибилен со стандардот ISO Fortran 95 и поддржува креирање и дебагирање на апликации кои содржат код на два јазика: C и Fortran.

Посебно треба да се нагласи дека значаен придонес во создавањето на наведените компајлери на Интел дадоа специјалисти од Рускиот центар за развој на софтвер Интел во Нижни Новгород. Повеќе детални информацииИнформации за компајлерите на Интел може да се најдат на веб-страницата на Интел на www.intel.com/software/products/.

Вториот дел од оваа статија ќе биде посветен на компајлери на Интел кои создаваат апликации за мобилни уреди.

Примери на вистински хакови: Компајлер на Intel C++ 7.0 - Архива WASM.RU

...компајлерот Intel C++ 7.0 преземен доцна навечер, околу пет часот наутро. Многу сакав да спијам, но ме растргна и љубопитноста: дали заштитата е зајакната или не. Одлучувајќи дека додека не ја сфатам заштитата, сè уште нема да заспијам, отворив нова конзола, и ресетирање на системските променливи TEMP и TMP во директориумот C:\TEMP, набрзина напишан непристојно долго имеинсталерот W_CC_P_7.0.073.exe на командната линија (потребата да се постават променливите TEMP и TMP се објаснува со фактот дека во Windows 2000 тие стандардно укажуваат на многу длабоко вгнезден директориум, а инсталерот на Intel C++ - и не само него - не поддржува патеки со толку огромна големина).

Веднаш стана јасно дека политиката за заштита е радикално ревидирана и сега присуството на лиценца беше проверено веќе во фазата на инсталирање на програмата (во верзијата 5.x инсталацијата беше извршена без проблеми). Во ред, ја даваме командата dir и ја гледаме содржината на она со што сега треба да се бориме:

Содржина на папката C:\TMP\IntelC++Compiler70

17.03.2003 05:10

html

17.03.2003 05:11

x86

17.03.2003 05:11

Итаниум

17.03.2003 05:11

белешки

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 поставување.mwg

19 датотеки 2.519.238 бајти

6 папки 886.571.008 бајти бесплатни

Да! Програмата за инсталација setup.exe трае само четириесет и непарни килобајти. Многу добро! Малку е веројатно дека можете да скриете сериозна заштита во таков волумен, па дури и ако е така, оваа мала датотека не вреди ништо за да се анализира во целост - до последниот бајт од списокот за расклопување. Сепак, не е факт дека безбедносен кодлоциран точно во setup.exe, може да се наоѓа на друго место, на пример... ChkLic.dll/ChkLic.exe, кои заедно зафаќаат нешто помалку од седумстотини килобајти. Чекај, што е ChkLic? Дали е ова кратенка за Check License или што?! Хм, момците од Интел очигледно имаат сериозни проблеми со смислата за хумор. Подобро би било оваа датотека искрено да ја наречат „Хакни ме“! Во ред, судејќи според јачината на звукот, ChkLic е истиот FLEX lm, а ние веќе го сретнавме (види „Intel C++ 5.0 Compiler“) и имаме груба идеја како да го скршиме.

Ја даваме командата „dumpbin /EXPORTS ChkLic.dll“ за да ги испита извезените функции и... цврсто држете се до Клава за да не падне од столчето:

Депонија на датотека ChkLic.dll

1. Делот го содржи следниов извоз за ChkLic.dll

   0 карактеристики

   3DB438B4 печат за временски датум Пон 21 октомври 21:26:12 2002 г.

3. 1 број на функции

   1 број на имиња

   редовна навестување RVA име

   1 0 000010A0 _CheckValidLicense

По ѓаволите! Заштитата извезува само една единствена функција со прекрасното име CheckValidLicense. „Прекрасно“ - затоа што целта на функцијата станува јасна од нејзиното име и станува возможно да се избегне макотрпна анализа на кодот за расклопување. Па, изгубија секаков интерес... подобро би било да го извезат ординално или нешто слично, или барем да го крстат со некакво застрашувачко име како DES Decrypt.

...сонување! Добро, да се вратиме на нашите овци. Ајде да размислиме логично: ако целиот безбедносен код е концентриран директно во ChkLic.dll (и, судејќи според „закачената“ природа на заштитата, ова е навистина така), тогаш целата „заштита“ се сведува на повикување CheckValidLicense од Setup. exe и проверка на резултатот вратен од него. Затоа, за „хакирање“ доволно е само да се изгуби ChkLic.dll, принудувајќи ја функцијата ChekValidLicense секогаш да се враќа... и, патем, што треба да врати? Поточно: која точно е повратната вредност што одговара на успешна проверка на лиценцата? Не, не брзајте да го расклопите setup.exe за да го одредите, бидејќи можни опциивеќе не толку: или ЛАЖНО или ВИСТИНИ. Дали се обложувате на ВИСТИНА? Па, во извесна смисла, ова е логично, но од друга страна: зошто всушност одлучивме дека функцијата CheckValidLicense го враќа точно знамето на успешноста на операцијата, а не кодот за грешка? На крајот на краиштата, тоа мора некако да ги мотивира причините за одбивање да се инсталира компајлерот: датотеката со лиценцата не е пронајдена, датотеката е оштетена, лиценцата е истечена и така натаму? Добро, ајде да се обидеме да вратиме нула, а ако тоа не успее, ќе вратиме една.

Во ред, тока, ајде да одиме! Го лансираме HIEW, ја отвораме датотеката ChkLic.dll (ако не се отвори, запомнете ги Gophers три пати, привремено копирајте го во root или кој било друг директориум што не содржи специјални знаци во неговото име што не ги сака hiew) Потоа, свртувајќи се повторно кон табелата за извоз, добиена со употреба на dumpbin, ја одредуваме адресата на функцијата CheckValidLicense (во овој случај 010A0h) и преку „10A0“ одиме на нејзиниот почеток. Сега, ја сечеме „во живо“, препишувајќи стара шифра „XOR EAX, EAX/RETN 4“. Зошто токму „REN 4“, а не само „RET“? Да, бидејќи функцијата ја поддржува конвенцијата stdcall, која можете да ја дознаете гледајќи го нејзиниот епилог во HIEW"e ( само скролувајте надолу по екранот на расклопувачот додека не се сретнете со RET).

Ајде да провериме... Работи!!! И покрај недостатокот на лиценца, инсталерот ја започнува инсталацијата без да поставува прашања! Затоа, одбраната падна. О, не можеме да веруваме дека сè е толку едноставно и, за да не седиме глупаво зјапајќи во мониторот чекајќи да заврши процесот на инсталација на програмата, го користиме нашиот омилен расклопувач на IDA на setup.exe. Првото нешто што ви привлекува внимание е отсуството на CheckValidLicense во списокот со увезени функции. Можеби некако ја лансира датотеката ChkLic.exe? Се обидуваме да ја најдеме соодветната врска меѓу автоматски препознаените линии: „~View aNames“, „ChkLic“... да, линијата „Chklic.exe“ воопшто ја нема, но „Chklic.dll“ е откриена. Да, гледам, тоа значи дека библиотеката ChkLic е вчитана со експлицитно поврзување преку LoadLibrary. И следењето на вкрстената референца го потврдува ова:

Текст:0040175D push offset aChklic_dll ; lpLibИме на датотека

Текст:00401762 јавете се на ds:LoadLibraryA

Текст:00401762 ; вчитај ChkLic.dll ^^^^^^^^^^^^^^^^^^

Текст:00401762 ;

Текст:00401768 mov esi, eax

Текст:0040176A push offset a_checkvalidlic ; lpProcName

Текст:0040176F push esi ; hМодул

Текст:00401770 јавете се на ds:GetProcAddress

Текст:00401770 ; добијте ја адресата на функцијата CheckValidLicense

Текст:00401770 ;

Текст:00401776 cmp esi, ebx

Текст:00401778 jz loc_40192E

Текст:00401778 ; ако не постои таква библиотека, тогаш излезете од програмата за инсталација

Текст:00401778 ;

Текст:0040177E cmp eax, ebx

Текст:00401780 jz loc_40192E

Текст:00401780 ; ако нема таква функција во библиотеката, тогаш излезете од инсталацијата

Текст:00401780 ;

Текст:00401786 притисни ebx

Текст:00401787 јавете се на eax

Текст:00401787 ; повикајте ја функцијата ChekValidLicense

Текст:00401787 ;

Текст:00401789 тест eax, eax

Текст:0040178B jnz loc_4019A3

Текст:0040178 ; ако функцијата се врати без нула, тогаш излезете од програмата за инсталација

Неверојатно, оваа страшно примитивна одбрана е изградена токму вака! Покрај тоа, датотеката со половина метар ChkLic.exe воопшто не е потребна! И зошто вредеше да се влече од Интернет? Патем, ако одлучите да ја зачувате дистрибуцијата на компајлерот (внимание: не реков „дистрибуирајте“!), тогаш за да заштедите простор на дискот, ChkLic.* може да се избрише: или со бришење на setup.exe, засекогаш одвикнување од пристап до нив или со едноставно создавање на сопствен ChkLic.dll, извезување на функцијата stdcall CheckValidLicence од формата: int CheckValidLicence(int some_flag) (врати 0;)

Па, додека го дискутиравме сето ова, инсталерот го заврши инсталирањето на компајлерот и успешно ја заврши својата работа. Дали е интересно дали компајлерот ќе започне или целата забава допрва почнува? Трескавично се спуштаме по разгранетата хиерархија на подпапки, наоѓаме icl.exe, кој, како што би се очекувало, се наоѓа во директориумот за бин, кликнуваме и... Компајлерот природно не започнува, наведувајќи го фактот дека „icl: error: не можеше да ја наплати лиценцата FLEX lm“, без која не може да продолжи со својата работа.

Излегува дека Интел користел заштита на повеќе нивоа и првото ниво се покажало како сурова заштита од будали. Па! Го прифаќаме овој предизвик и, врз основа на нашето претходно искуство, автоматски ја бараме датотеката LMGR*.DLL во директориумот на компајлерот. Бескорисно! Овој пат нема таква датотека овде, но излегува дека icl.exe се здебелил многу, надминувајќи ја границата од шестотини килобајти... Стоп! Нели програмерите на компајлерот го поврзаа истиот FLEX lm со статичко поврзување? Ајде да видиме: во Intel C++ 5.0, збирот на големини на lmgr327.dll и icl.exe беше 598 KB, а сега само icl.exe зафаќа 684 KB. Земајќи го предвид прилагодувањето за природната сенилна „дебелина“, бројките многу добро се согласуваат. Значи, на крајот на краиштата, FLEX lm! О, ох! Но, сега, без симболични имиња на функции, ќе биде многу потешко да се скрши заштитата... Сепак, да не паничиме пред време! Ајде да размислиме, само мирно! Малку е веројатно дека тимот за развој целосно го преработил целиот код што е во интеракција со оваа заштита од „плико“. Најверојатно, неговото „подобрување“ заврши само со промена на видот на распоредот. И ако е така, тогаш шансите за хакирање на програмата се уште се големи!

Сеќавајќи се дека последниот пат кога безбедносната шифра беше во главната функција, ние, откако ја одредивме неговата адреса, едноставно поставивме точка на прекин и, чекајќи да се појави дебагерот, глупаво го следиме кодот, наизменично гледајќи во дебагерот, потоа во излезот на програмата прозорец: има Дали има експлозивна порака? Во исто време, ги означуваме сите условни транзиции што ги среќаваме на посебен лист хартија (или ги ставаме во сопствената меморија, ако сакате), не заборавајќи да означиме дали секоја условна транзиција е извршена или не... Стоп! Јас и ти разговаравме за нешто, но веќе се појави навредлива порака! Добро добро! Ајде да видиме каква условна транзиција одговараше на тоа. Нашите записи покажуваат дека последниот скок со кој се сретнавме беше условниот скок JNZ, кој се наоѓа на адресата 0401075h и „реагира“ на резултатот вратен од sub_404C0E:

Текст:0040107F loc_40107F: ; КОД XREF: _main+75^j

Текст:0040107F mov eax, offset aFfrps ; "FFrps"

Текст:00401084 mov edx, 21ч

Текст:00401089 јавете се на sub_404C0E

Текст:0040108E тест eax, eax

Текст:00401090 jnz краток loc_40109A

Очигледно, sub_404C0E е самата заштитна процедура која ја проверува лиценцата за нејзино присуство. Како да ја измамите? Па, има многу опции... Прво, можете смислено и скрупулозно да ја анализирате содржината на sub_404C0E за да дознаете што точно проверува и како точно проверува. Второ, можете едноставно да го замените JNZ краток loc_40107F со JZ краток loc_40107F или дури и NOP, NOP. Трето, командата за проверка на резултатот за враќање TEST EAX, EAX може да се претвори во нулта команда: XOR EAX, EAX. Четврто, можеш да направиш самиот sub_404C0E да исчезне за секогаш да враќа нула. Не знам за вас, но најмногу ми се допадна методот број три. Променуваме два бајта и го стартуваме компајлерот. Ако нема други проверки за неговото „лиценцирање“ во заштитата, тогаш програмата ќе работи и, соодветно, обратно. (Како што се сеќаваме, во петтата верзија имаше две такви проверки). Зачудувачки, компајлерот повеќе не се жали и работи!!! Навистина, како што би се очекувало, неговите програмери воопшто не ја зајакнале заштитата, туку, напротив, дури и ја ослабнале! Крис Касперски

Ти не си роб!
Затворен едукативен курс за деца од елитата: „Вистинското уредување на светот“.
http://noslave.org

Материјал од Википедија - слободната енциклопедија