인텔 컴파일러. 새로운 컴파일러가 필요한 이유는 무엇입니까?

Intel C++ 및 Fortran 컴파일러와 MKL 라이브러리

Linux용 표준 GNU 컴파일러와 함께 Intel C++ 및 Fortran 컴파일러가 NIVC 컴퓨팅 컴플렉스의 클러스터에 설치됩니다. 현재(2006년 초) 컴파일러 버전 9.1이 모든 클러스터에 설치되어 있습니다. 이 페이지는 이러한 컴파일러의 가장 중요한 옵션과 설정뿐만 아니라 GNU 컴파일러와의 주요 차이점을 설명하는 데 전념합니다. 이 페이지는 주로 MSU 연구 컴퓨팅 센터 클러스터 사용자를 대상으로 하지만 다른 러시아어를 사용하는 사용자에게도 유용할 수 있습니다. IA-64 플랫폼의 컴파일과 관련된 문제는 여기서 다루지 않습니다.

또한 Intel 라이브러리는 모든 클러스터에 설치됩니다. 커널 수학 라이브러리(MKL) 버전 8.0.2. 라이브러리는 /usr/mkl 디렉토리에 있습니다. 하위 디렉터리 32, 64 및 em64t는 lib 디렉터리에서 사용할 수 있습니다. Ant 클러스터에서는 em64t 하위 디렉토리의 라이브러리를 사용해야 하고 다른 클러스터에서는 32 하위 디렉토리의 라이브러리를 사용해야 합니다. 필요한 모든 문서와 예제는 /usr/mkl/doc 디렉토리에서 얻을 수 있습니다.

새로운 컴파일러가 필요한 이유는 무엇입니까?

새로운 컴파일러에 대한 필요성은 주로 a) Fortran 90의 프로그래밍을 지원하고 b) C로 변환한 다음 gcc를 사용하여 컴파일하는 g77 컴파일러에서 제공하는 것보다 더 강력한 Fortran 프로그램 최적화를 위해 발생했습니다.

PGI(포틀랜드 그룹) 컴파일러도 이러한 요구 사항을 충족하지만 개발사에서는 러시아에 공급을 거부했습니다.

사용하는 방법?

Intel 컴파일러는 명령을 사용하여 호출됩니다. ICC(C 또는 C++), ICPC(C++) 및 만약에(포트란 77/90). MPI 프로그램을 컴파일하고 어셈블하기 위한 mpicc, mpiCC 및 mpif77 명령도 Intel 컴파일러를 사용하도록 구성됩니다.

mpigcc, mpig++ 및 mpig77 명령을 사용하여 GNU 컴파일러를 사용하는 것도 가능합니다(Fortran 90은 지원되지 않음).

입력 파일

기본적으로 확장자를 가진 파일은 .cpp그리고 .cxx C++ 언어의 소스 텍스트로 간주되며 확장자를 가진 파일은 .씨- C 소스 코드 및 icpc 컴파일러는 .c 파일을 C++ 소스 코드로 컴파일합니다.

확장자가 있는 파일 .에프, .ftn그리고 .을 위한고정된 형태의 표기법을 사용하여 Fotran 언어의 소스 텍스트로 인식되며 파일은 .fpp그리고 .에프추가적으로 Fortran 언어 전처리기를 통과했습니다. 확장자를 가진 파일 .f90자유 형식 표기법을 사용하는 Fortran 90/95 소스 텍스트로 간주됩니다. 옵션을 사용하여 Fortran 프로그램에 대한 고정 또는 자유 형식의 표기법을 명시적으로 지정할 수 있습니다. -FI그리고 -정말로각기.

확장자를 가진 파일 .에스 IA-32의 어셈블리 언어 코드로 인식됩니다.

인텔 컴파일러 기능

여기에서는 개발자가 사용자 설명서에 언급한 일부 의견과 함께 인텔 컴파일러의 특성을 제시합니다.

• 상당한 최적화
  분명히 이는 높은 수준에서 코드를 최적화하는 것을 의미합니다. 우선, 거의 모든 컴파일러가 어느 정도 성공을 거두는 다양한 루프 변환입니다.
• 부동 소수점 최적화
  분명히 이는 우선 하드웨어 수준에서 구현되는 명령의 최대 사용을 의미합니다.
• 절차간 최적화
  저것들. 특정 기능의 코드에만 영향을 미치는 일반적인 최적화와 달리 전체 프로그램의 전역 최적화
• 프로필 기반 최적화
  저것들. 테스트 모드에서 프로그램을 실행하고, 자주 사용되는 함수 내에서 특정 코드 조각을 전달하는 데 걸리는 시간에 대한 데이터를 수집한 다음 이 데이터를 최적화에 사용하는 기능
• 펜티엄 III 프로세서의 SSE 명령어 세트 지원
  참고: 컴퓨팅 작업의 경우 SSE2 명령이 더 중요합니다. 64비트 실수에 대한 벡터 명령은 아직 처리할 수 없는 Pentium 4 프로세서에서만 지원됩니다.
• 자동 벡터화
  저것들. 다시, 컴파일러에 의해 자동으로 삽입된 SSE 및 SSE2 명령을 사용하여
• SMP 시스템 프로그래밍을 위한 OpenMP 지원
  참고: 클러스터에서는 주로 MPI 인터페이스를 사용하는 것이 좋습니다. 클러스터에서 OpenMP의 광범위한 사용은 예상되지 않으며 그러한 실험은 아직 수행되지 않았습니다. 하지만 공유 메모리용으로 병렬화된 라이브러리(BLAS 등)를 사용하는 것이 합리적일 수 있습니다.
• 데이터 프리페칭
  저것들. 분명히 메모리에서 데이터 캐시로 사전 로드 명령을 사용하는 것은 시간이 지나면 필요할 것입니다.
• 다양한 프로세서에 대한 "디스패칭" 코드
  저것들. 단일 실행 파일에서 다양한 프로세서에 대한 코드를 생성하는 기능을 통해 다음과 같은 이점을 얻을 수 있습니다. 최신 프로세서이전 프로세서와 프로그램의 바이너리 호환성을 유지하면서 최고의 성능을 달성합니다. 우리 클러스터에서는 아직 관련이 없습니다. 왜냐하면 Pentium III 프로세서만 사용되며 클러스터에서 컴파일된 프로그램은 다른 컴퓨터에서 전송 및 실행될 수 없습니다.

기본 컴파일러 옵션

물론 가장 흥미로운 것은 코드 최적화 옵션입니다. 대부분의 옵션은 C++ 및 Fortran 컴파일러에 공통됩니다. 더 상세 설명영어 사용자 설명서의 옵션.

성능

ixbt.com 서버에 게시된 SPEC CPU2000 테스트 실행 결과에 따르면 Intel 컴파일러 버전 6.0은 gcc 컴파일러 버전 2.95.3, 2.96 및 3.1, PGI 버전 4.0.2에 비해 거의 보편적으로 더 뛰어났습니다. 이 테스트는 2002년에 Pentium 4/1.7GHz 프로세서와 RedHat Linux 7.3이 설치된 컴퓨터에서 수행되었습니다.

Polyhedron에서 실시한 테스트에 따르면 Intel Fortran 컴파일러 버전 7.0은 다른 Linux용 Fortran 77 컴파일러(Absoft, GNU, Lahey, NAG, NAS, PGI)보다 거의 보편적으로 우수했습니다. 일부 테스트에서만 Intel 컴파일러는 Absoft, NAG 및 Lahey 컴파일러보다 약간 열등합니다. 이 테스트는 Pentium 4/1.8 GHz 프로세서와 Mandrake Linux 8.1이 설치된 컴퓨터에서 수행되었습니다.

Intel 컴파일러 버전 9.1은 또한 gcc 컴파일러보다 성능이 뛰어나며 Absoft, PathScale 및 PGI에 필적하는 성능을 보여줍니다.

컴파일러(GCC 또는 Intel) 선택과 최적화 옵션이 실제 문제에 대한 작업 속도에 미치는 영향에 대한 데이터를 보내주신 사용자와 독자에게 감사드립니다.

도서관

C 언어 컴파일러는 GNU 프로젝트 내에서 개발된 런타임 라이브러리( libc.a).

인텔 C++ 컴파일러에는 다음 라이브러리가 제공됩니다.

• libcprts.a- Dinkumware에서 개발한 C++ 언어의 런타임 라이브러리입니다.
• libcxa.a- Intel의 C++ 개발을 위한 추가 런타임 라이브러리.
• libimf.a- 삼각법, 쌍곡선, 지수 함수, 특수 함수, 복합 함수 및 기타 함수의 최적화되고 고정밀 구현을 포함하는 Intel에서 개발한 수학 함수 라이브러리입니다(자세한 내용은 함수 목록 참조).
• libirc.a- 프로세서에 따라 프로파일링(PGO) 및 코드 디스패치를 ​​위한 런타임 지원(위 참조)
• libguide.a- OpenMP 구현.

이 목록에는 정적 라이브러리가 포함되어 있지만 대부분 동적 라이브러리도 있습니다. 시작 중에 연결된 옵션( .그래서).

Fortran 컴파일러에는 다음 라이브러리가 제공됩니다. libCEPCF90.a, libIEPCF90.a, libintrins.a, libF90.a, 수학 함수 libimf.a 라이브러리도 사용됩니다.

실행 파일 빌드

라이브러리는 정적으로(빌드 중) 또는 동적으로(프로그램 시작 중) 연결할 수 있습니다. 동적 접근 방식을 사용하면 실행 파일의 크기를 줄일 수 있고 메모리에서 동일한 라이브러리 복사본을 공유할 수 있지만 이를 위해서는 프로그램이 실행될 각 노드에 사용되는 전체 동적 라이브러리 세트를 설치해야 합니다. .

따라서 Linux 시스템에 인텔 컴파일러를 설치하고 다른 시스템에서 컴파일된 실행 파일을 실행하려는 경우 정적 빌드(더 쉬움)를 사용하거나 인텔 동적 라이브러리를 이러한 시스템에 복사해야 합니다(일반적으로 다음 위치에서). /opt/intel /compiler70/ia32/lib와 같은 디렉토리)를 /etc/ld.so.conf 파일에 나열된 디렉토리 중 하나로 복사하고 동일한 GNU/Linux 동적 라이브러리 세트가 이러한 시스템에 설치되어 있는지 확인하십시오. .

기본적으로 모든 Intel 개발 라이브러리(libcxa.so 제외)는 정적으로 링크되며 모든 Linux 시스템 라이브러리와 GNU 라이브러리는 동적으로 링크됩니다. 옵션 사용 -공전컬렉터(링크 편집기)가 모든 라이브러리를 정적으로 연결하도록 강제할 수 있습니다(이렇게 하면 볼륨이 증가합니다). 실행 가능 파일) 및 옵션을 사용하여 -i_dynamic모든 Intel 개발 라이브러리를 동적으로 연결할 수 있습니다.

보기 옵션을 사용하여 추가 라이브러리를 연결하는 경우 -도서관옵션을 사용해야 할 수도 있습니다 -L디렉토리라이브러리가 있는 경로를 지정합니다.

옵션 사용 -B정적그리고 -Bdynamic다음에 지정된 각 라이브러리의 동적 또는 정적 연결을 명시적으로 지정할 수 있습니다. 명령줄.

옵션 사용 -씨실행 파일의 어셈블리는 비활성화되고 컴파일만 수행됩니다(객체 모듈 생성).

Fortran과 C에서 모듈 공유

Fortran과 C로 작성된 모듈을 공유하려면 개체 모듈의 프로시저 이름 지정, 매개변수 전달, 전역 변수에 대한 액세스(있는 경우)에 동의해야 합니다.

기본적으로 인텔 포트란 컴파일러는 프로시저 이름을 소문자로 변환하고 이름 끝에 밑줄을 추가합니다. C 컴파일러는 함수 이름을 변경하지 않습니다. 따라서 Fortran 모듈에서 C로 구현된 함수나 프로시저 FNNAME을 호출하려면 C 모듈에서 fnname_을 호출해야 합니다.

Fortran 컴파일러는 다음 옵션을 지원합니다. -nus [파일 이름], 내부 프로시저 이름에 밑줄 추가를 비활성화할 수 있습니다. 파일 이름이 지정되면 지정된 파일에 나열된 프로시저 이름에 대해서만 수행됩니다.

기본적으로 Fortran에서는 매개변수가 참조로 전달되고 C에서는 항상 값으로 전달됩니다. 따라서 C 모듈에서 Fortran 프로시저를 호출할 때 실제 매개변수의 값이 포함된 해당 변수에 대한 포인터를 매개변수로 전달해야 합니다. Fortran 모듈에서 호출해야 하는 함수를 C로 작성할 때 형식 매개변수를 해당 유형에 대한 포인터로 설명해야 합니다.

C 모듈에서는 포트란 모듈 내부에 정의된 COMMON 블록을 사용할 수 있습니다(자세한 내용은 인텔 포트란 컴파일러 사용자 안내서의 C와 포트란 혼합 장 참조).

Intel 및 GCC 컴파일러 공유

Intel C++ 컴파일러에서 생성된 C 개체 모듈은 GCC 컴파일러 및 GNU C 라이브러리에서 생성된 모듈과 호환됩니다. 따라서 이러한 모듈은 icc 또는 gcc 명령을 사용하여 컴파일된 단일 프로그램에서 함께 사용할 수 있지만 Intel 라이브러리를 올바르게 포함하려면 icc를 사용하는 것이 좋습니다.

인텔 컴파일러는 GNU 프로젝트에서 사용하고 GCC 컴파일러에서 지원하는 다양한 비표준 C 언어 확장을 지원합니다(그러나 전부는 아닙니다. 자세한 내용은 여기를 참조하십시오).

사용자 매뉴얼에는 C++ 및 Fortran 언어의 개체 모듈 호환성에 대한 언급이 없으며 분명히 지원되지 않습니다.

표준 지원

Linux용 인텔 C++ 컴파일러 7.0은 ANSI/ISO C 언어 표준(ISO/IEC 9899/1990)을 지원합니다. ANSI C 표준과 엄격한 호환성을 확립하는 것이 가능합니다( -안시) 또는 확장된 ANSI C 방언( -Xa). 옵션 사용 시 -c99

잡지의 이전 호에서 우리는 Intel VTune 성능 분석기 제품군의 제품에 대해 논의했습니다. 이는 응용 프로그램 개발자들 사이에서 당연히 인기가 있고 코드에서 감지할 수 있는 성능 분석 도구입니다. 팀 애플리케이션, 이는 너무 많은 CPU 리소스를 낭비하므로 개발자에게 잠재적인 가능성을 식별하고 제거할 수 있는 기회를 제공합니다. 좁은 장소, 유사한 코드 섹션과 연관되어 애플리케이션 개발 프로세스 속도를 높입니다. 그러나 애플리케이션의 성능은 개발에 사용되는 컴파일러의 효율성과 기능에 따라 크게 달라집니다. 하드웨어기계어 코드를 생성할 때 사용됩니다.

Windows 및 Linux용 인텔 인텔 C++ 및 인텔 포트란 컴파일러의 최신 버전을 사용하면 다음 기반 시스템에 대한 애플리케이션 성능 이점을 얻을 수 있습니다. 인텔 프로세서아이태니엄 2, 인텔 제온 및 인텔 펜티엄 4 하이퍼-스레딩 기술과 같은 프로세서 기능을 사용하므로 다른 제조업체의 기존 컴파일러에 비해 최대 40% 향상됩니다.

이 컴파일러 제품군의 코드 최적화와 관련된 차이점에는 부동 소수점 연산을 수행하기 위한 스택 사용, 프로시저 간 최적화(IPO), 애플리케이션 프로필에 따른 최적화(PGO(Profile Guided Optimization)), 캐시에 데이터 사전 로드( 데이터 프리페칭), 메모리 액세스와 관련된 대기 시간 방지, Intel 프로세서의 특징적인 기능 지원(예: 스트리밍 데이터 처리를 위한 확장 Intel Streaming SIMD Extensions 2, Intel Pentium 4의 특징), 코드 실행의 자동 병렬화, 애플리케이션 생성, 여러 환경에서 실행 다른 유형그 중 하나를 최적화할 때 프로세서, 후속 코드를 "예측"하기 위한 도구(분기 예측), 실행 스레드 작업에 대한 지원 확장.

Intel 컴파일러는 Alias/Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM과 같은 잘 알려진 회사에서 사용됩니다. 여러 회사에서 실시한 독립적인 테스트에 따르면 Intel 컴파일러의 성능은 다른 제조업체의 컴파일러 성능보다 훨씬 높습니다(예: http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf 참조). .pdf).

아래에서는 몇 가지 기능을 살펴보겠습니다. 최신 버전데스크탑 및 서버용 Intel 컴파일러 운영체제.

Microsoft Windows 플랫폼용 컴파일러

Windows용 인텔 C++ 컴파일러 7.1

Intel C++ Compiler 7.1은 Intel Centrino 기술을 사용하는 Intel Itanium, Intel Itanium 2, Intel Pentium 4 및 Intel Xeon 프로세서는 물론 Intel Pentium M 프로세서에 고도로 최적화된 코드를 제공하는 올해 초에 출시된 컴파일러입니다. 모바일 장치.

지정된 컴파일러는 Microsoft Visual C++ 6.0 및 Microsoft Visual Studio .NET 개발 도구와 완벽하게 호환됩니다. 해당 컴파일러는 해당 개발 환경에 구축될 수 있습니다.

이 컴파일러는 ANSI 및 ISO C/C++ 표준을 지원합니다.

Windows용 인텔 포트란 컴파일러 7.1

올해 초에 출시된 Windows용 인텔 포트란 컴파일러 7.1을 사용하면 Intel Itanium, Intel Itanium 2, Intel Pentium 4 및 Intel Xeon, Intel Pentium M 프로세서에 최적화된 코드를 생성할 수 있습니다.

이 컴파일러는 Microsoft Visual C++ 6.0 및 Microsoft Visual Studio .NET 개발 도구와 완벽하게 호환됩니다. 즉, 해당 개발 환경에 구축될 수 있습니다. 또한 이 컴파일러를 사용하면 64비트 Intel Fortran 컴파일러를 사용하는 32비트 Pentium 프로세서에서 Microsoft Visual Studio를 사용하여 Itanium/Itanium 2 프로세서에서 실행되는 운영 체제용 64비트 응용 프로그램을 개발할 수 있습니다. 코드를 디버깅할 때 이 컴파일러를 사용하면 디버거를 사용하여 다음을 수행할 수 있습니다. 마이크로소프트 플랫폼.그물.

Compaq 제품이 설치되어 있는 경우 원본 Intel Fortran Compiler 7.1 대신 Visual Fortran 6.6을 사용할 수 있습니다. 이러한 컴파일러는 해당 레벨에서 호환되기 때문입니다. 소스 코드.

Windows용 인텔 포트란 컴파일러 7.1은 ISO Fortran 95 표준과 완벽하게 호환되며 C와 Fortran의 두 가지 언어로 된 코드가 포함된 응용 프로그램의 생성 및 디버깅을 지원합니다.

Linux 플랫폼용 컴파일러

Linux용 인텔 C++ 컴파일러 7.1

올해 초에 출시된 또 다른 컴파일러인 Linux용 Intel C++ Compiler 7.1을 사용하면 Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M 프로세서에 대해 높은 수준의 코드 최적화를 달성할 수 있습니다. 소스 코드 및 개체 모듈에서 GNU C 컴파일러와 호환되므로 추가 비용 없이 GNU C를 사용하여 생성된 응용 프로그램을 마이그레이션할 수 있습니다. 인텔 C++ 컴파일러는 C++ ABI(Linux 커널에 추가된 기능으로 다음을 실행할 수 있음)를 지원합니다. 아래에 리눅스 제어초기 SCO 운영 체제와 같은 다른 플랫폼용으로 컴파일된 코드, 초기 버전 Sun Solaris 등) 이는 바이너리 코드 수준에서 gcc 3.2 컴파일러와의 완전한 호환성을 의미합니다. 마지막으로, Linux용 인텔 C++ 컴파일러 7.1을 사용하면 소스 코드를 약간만 변경하여 Linux 커널을 다시 컴파일할 수도 있습니다.

Linux용 인텔 포트란 컴파일러 7.1

Linux용 인텔 포트란 컴파일러 7.1을 사용하면 인텔 아이테니엄, 인텔 아이테니엄 2, 인텔 펜티엄 4, 인텔 펜티엄 M 프로세서에 최적화된 코드를 생성할 수 있습니다. 이 컴파일러는 소스 코드 수준에서 Compaq Visual Fortran 6.6 컴파일러와 완벽하게 호환되므로 다음을 수행할 수 있습니다. Compaq Visual Fortran을 사용하여 만든 응용 프로그램을 다시 컴파일하여 성능을 향상시킵니다.

또한 지정된 컴파일러는 emacs 편집기, gdb 디버거 및 make 애플리케이션 빌드 유틸리티와 같이 개발자가 사용하는 유틸리티와 호환됩니다.

이 컴파일러의 Windows 버전과 마찬가지로 Linux용 인텔 포트란 컴파일러 7.1은 ISO Fortran 95 표준과 완벽하게 호환되며 C와 Fortran의 두 가지 언어로 된 코드가 포함된 응용 프로그램의 생성 및 디버깅을 지원합니다.

나열된 인텔 컴파일러 생성에 중요한 기여를 한 것은 니즈니노브고로드에 있는 인텔 러시아 소프트웨어 개발 센터의 전문가들이 수행했다는 점을 특히 강조해야 합니다. 더 자세한 정보인텔 컴파일러에 대한 정보는 인텔 웹사이트 www.intel.com/software/products/에서 확인할 수 있습니다.

이 기사의 두 번째 부분은 모바일 장치용 응용 프로그램을 만드는 Intel 컴파일러에 대해 다룹니다.

실제 해킹의 예: Intel C++ 7.0 컴파일러 - 아카이브 WASM.RU

...인텔 C++ 7.0 컴파일러는 늦은 밤, 대략 새벽 5시에 다운로드되었습니다. 정말 자고 싶었지만 보호 기능이 강화되었는지 여부에 대한 호기심도 찢어졌습니다. 보호 장치를 찾을 때까지는 잠들지 않을 거라 생각하고 문을 열었어요 새 콘솔, 그리고 시스템 변수 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

노트

2002년 6월 5일 10:35 45 056 AutoRun.exe

2001년 7월 10일 12:56 27 autorun.inf

2002년 10월 29일 11:25 2 831 ccompindex.htm

2002년 10월 24일 08:12 126 976 ChkLic.dll

2002년 10월 18일 22:37 552 960 chklic.exe

2002년 10월 17일 16:29 28 663 CLicense.rtf

2002년 10월 17일 16:35 386 credist.txt

2002년 10월 16일 17:02 34 136 Crellnotes.htm

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

2002년 2월 21일 12:39 2 478 Register.htm

2002년 10월 2일 14:51 40 960 Setup.exe

2002년 10월 2일 10:40 151 Setup.ini

2001년 7월 10일 12:56 184 setup.mwg

19개 파일 2,519,238바이트

6개 폴더 886,571,008바이트 무료

응! setup.exe 설치 프로그램은 40KB 정도만 사용합니다. 매우 좋은! 그러한 볼륨에 심각한 보호 기능을 숨길 수 있는 가능성은 거의 없으며, 설사 그렇더라도 이 작은 파일은 디스어셈블러 목록의 마지막 바이트까지 전체적으로 분석할 가치가 없습니다. 그러나 그것은 사실이 아니다. 보안 코드정확히 setup.exe에 위치하지만 다른 위치에 위치할 수도 있습니다. 예를 들어 ChkLic.dll/ChkLic.exe는 모두 합쳐서 700KB 미만의 공간을 차지합니다. 잠깐, ChkLic이 뭐죠? 이것은 Check License의 약어인가요? 흠, 인텔 직원들은 유머 감각에 심각한 문제가 있는 게 분명합니다. 이 파일을 솔직히 "Hack Me"라고 부르면 더 좋을 것 같아요! 좋아, 볼륨으로 판단하면 ChkLic은 동일한 FLEX lm이고 우리는 이미 그것을 접했고("Intel C++ 5.0 컴파일러" 참조) 그것을 깨는 방법에 대한 대략적인 아이디어를 가지고 있습니다.

내보낸 기능을 검사하기 위해 "dumpbin /EXPORTS ChkLic.dll" 명령을 내리고... 의자에서 떨어지지 않도록 Klava를 단단히 잡으십시오.

ChkLic.dll 파일 덤프

1. 섹션에는 ChkLic.dll에 대한 다음 내보내기가 포함되어 있습니다.

   0 특성

   3DB438B4 시간 날짜 스탬프 2002년 10월 21일 월요일 21:26:12

3. 1개의 기능

   이름 1개

   서수 힌트 RVA 이름

   1 0 000010A0 _CheckValidLicense

젠장! 보호 기능은 CheckValidLicense라는 멋진 이름을 가진 하나의 함수만 내보냅니다. "훌륭하다" - 함수의 목적이 이름에서 명확해지고 디스어셈블러 코드에 대한 힘든 분석을 피할 수 있기 때문입니다. 글쎄, 그들은 모든 관심을 잃었습니다... 일반적으로 내보내거나 적어도 DES Decrypt와 같은 위협적인 이름으로 명명하는 것이 더 나을 것입니다.

...백일몽! 좋아, 우리 양에게로 돌아가자. 논리적으로 생각해 보겠습니다. 모든 보안 코드가 ChkLic.dll에 직접 집중되어 있는 경우(그리고 보호의 "힌지형" 특성으로 판단하면 실제로 그렇습니다) 모든 "보호"는 설치 프로그램에서 CheckValidLicense를 호출하는 것으로 귀결됩니다. exe를 실행하여 반환된 결과를 확인합니다. 따라서 "해킹"하려면 ChkLic.dll을 잃어버리고 ChekValidLicense 함수가 항상 반환되도록 하는 것만으로도 충분합니다... 그런데 무엇을 반환해야 합니까? 보다 정확하게는 성공적인 라이센스 확인에 해당하는 반환 값이 정확히 무엇입니까? 아니요, 확인하기 위해 setup.exe를 서둘러 분해하지 마십시오. 가능한 옵션더 이상은 FALSE 또는 TRUE가 아닙니다. 당신은 TRUE에 베팅하고 있습니까? 글쎄, 어떤 의미에서 이것은 논리적이지만 반면에 실제로 CheckValidLicense 함수가 오류 코드가 아닌 작업 성공 플래그를 정확하게 반환하도록 결정한 이유는 무엇입니까? 결국 컴파일러 설치를 거부하는 이유(라이센스가 있는 파일을 찾을 수 없음, 파일이 손상됨, 라이센스가 만료됨 등)에 동기를 부여해야 합니까? 좋아요, 0을 반환하도록 해보고, 그래도 작동하지 않으면 1을 반환하겠습니다.

알았어, 버클 채우고 가자! HIEW를 시작하고 ChkLic.dll 파일을 엽니다(열리지 않으면 고퍼를 세 번 기억하고 임시로 루트나 이름에 hiew가 좋아하지 않는 특수 문자가 포함되지 않은 다른 디렉터리에 복사합니다) 그런 다음 dumpbin을 사용하여 얻은 내보내기 테이블로 다시 돌아가서 CheckValidLicense 함수의 주소(이 경우 010A0h)를 결정하고 "10A0"을 통해 시작 부분으로 이동합니다. 이제 "라이브"로 잘라내어 덮어씁니다. 이전 코드 "XOR EAX, EAX/RETN 4". 왜 정확히 "RET"가 아닌 "REN 4"입니까? 예, 함수가 stdcall 규칙을 지원하기 때문입니다. 이는 HIEW"e( RET를 만날 때까지 디스어셈블러 화면을 아래로 스크롤하세요.

확인해 봅시다... 작동합니다!!! 라이센스가 없음에도 불구하고 설치 프로그램은 아무런 질문도 없이 설치를 시작합니다! 그래서 수비가 떨어졌다. 아, 우리는 모든 것이 그렇게 간단하다는 것을 믿을 수 없으며 프로그램 설치 프로세스가 완료되기를 기다리면서 모니터를 멍청하게 쳐다보지 않기 위해 setup.exe에서 우리가 가장 좋아하는 IDA 디스어셈블러를 사용합니다. 가장 먼저 눈에 띄는 것은 가져온 기능 목록에 CheckValidLicense가 없다는 것입니다. 어쩌면 ChkLic.exe 파일이 실행될 수도 있나요? 자동으로 인식된 줄 중에서 해당 링크를 찾으려고 합니다: "~View aNames", "ChkLic"... 예, "Chklic.exe" 줄은 전혀 없지만 "Chklic.dll"은 감지됩니다. 예, 알겠습니다. 이는 ChkLic 라이브러리가 LoadLibrary를 통한 명시적 연결에 의해 로드된다는 의미입니다. 그리고 상호 참조를 따르면 이를 확인할 수 있습니다.

텍스트:0040175D 푸시 오프셋 aChklic_dll ; lpLib파일 이름

텍스트:00401762 전화 ds:LoadLibraryA

텍스트:00401762 ; ChkLic.dll 로드 ^^^^^^^^^^^^^^^^^^^

텍스트:00401762 ;

텍스트:00401768 mov esi, eax

텍스트:0040176A 푸시 오프셋 a_checkvalidlic ; lpProc이름

텍스트:0040176F 푸시 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 ; 함수가 0이 아닌 값을 반환하면 설치 프로그램을 종료합니다.

놀랍게도, 이 끔찍할 정도로 원시적인 방어 시설은 정확히 이렇게 만들어졌습니다! 또한 반 미터 파일 ChkLic.exe는 전혀 필요하지 않습니다! 그리고 왜 인터넷에서 끌어올 가치가 있었나요? 그런데 컴파일러 배포판을 저장하기로 결정한 경우(주의: "배포"라고 말하지 않았습니다!) 디스크 공간을 절약하기 위해 ChkLic.*를 지울 수 있습니다. 액세스하거나 단순히 자신만의 ChkLic.dll을 생성하여 다음 형식의 stdcall 함수 CheckValidLicence를 내보냅니다. int CheckValidLicence(int some_flag)( return 0;)

글쎄, 우리가 이 모든 것에 대해 논의하는 동안 설치 프로그램은 컴파일러 설치를 마치고 작업을 성공적으로 완료했습니다. 컴파일러가 시작될 것인지 아니면 모든 재미가 이제 막 시작될 것인지가 흥미롭습니까? 우리는 열성적으로 하위 폴더의 분기 계층 구조를 따라 내려가서 예상대로 bin 디렉토리에 있는 icl.exe를 찾아 클릭하고... 컴파일러는 "icl: 오류: FLEX lm 라이센스를 체크아웃할 수 없습니다." 라이센스가 없으면 작업을 계속할 수 없습니다.

Intel은 다단계 보호를 사용했으며 첫 번째 수준은 바보에 대한 조잡한 보호로 판명되었습니다. 잘! 우리는 이 문제를 받아들이고 이전 경험을 바탕으로 컴파일러 디렉터리에서 LMGR*.DLL 파일을 자동으로 찾습니다. 쓸모 없는! 이번에는 여기에 그런 파일이 없지만 icl.exe가 600KB를 초과하여 무게가 많이 늘어난 것으로 나타났습니다... 중지하세요! 컴파일러 개발자들이 이 동일한 FLEX 작품을 정적 링크로 링크하지 않았나요? 살펴보겠습니다: Intel C++ 5.0에서 lmgr327.dll과 icl.exe의 크기 합계는 598KB였으며 이제 icl.exe만 684KB를 차지합니다. 자연적인 노인성 "비만"에 대한 조정을 고려하면 수치는 매우 잘 일치합니다. 그래서 결국 FLEX lm! 오, 오! 하지만 이제 상징적인 함수 이름이 없으면 보호를 깨는 것이 훨씬 더 어려울 것입니다... 하지만 미리 당황하지 마세요! 침착하게 생각해보자! 개발팀이 이 "봉투" 보호와 상호 작용하는 모든 코드를 완전히 다시 작성했을 가능성은 거의 없습니다. 아마도 "개선"은 레이아웃 유형의 변경으로 끝났을 것입니다. 그렇다면 프로그램을 해킹할 가능성은 여전히 ​​높습니다!

마지막으로 보안 코드가 기본 함수에 있었음을 기억하고 해당 주소를 결정한 후 중단점을 설정하고 디버거가 나타날 때까지 어리석게도 코드를 추적하고 디버거를 본 다음 프로그램 출력을 번갈아 살펴봅니다. 창: 나타났나요? 욕설 메시지가 있나요? 동시에 우리는 각 조건부 전환이 수행되었는지 여부를 표시하는 것을 잊지 않고 별도의 종이에 (또는 원하는 경우 자체 메모리에 저장) 발생하는 모든 조건부 전환을 표시합니다... 중지하세요! 너랑 나랑 뭔가 얘기를 나누던 중, 욕설이 벌써 떴어! 알았어! 이에 해당하는 조건부 전환이 무엇인지 살펴 보겠습니다. 우리 기록에 따르면 마지막 점프는 주소 0401075h에 위치한 JNZ 조건부 점프였으며 sub_404C0E에서 반환된 결과에 "반응"했습니다.

텍스트:0040107F loc_40107F: ; 코드 외부 참조: _main+75^j

텍스트:0040107F mov eax, 오프셋 aFfrps ; "FFrps"

텍스트:00401084 mov edx, 21시간

문자:00401089 전화 sub_404C0E

텍스트:0040108E 테스트 eax, eax

텍스트:00401090 jnz short loc_40109A

분명히 sub_404C0E는 라이센스의 존재 여부를 확인하는 매우 보호적인 절차입니다. 그녀를 속이는 방법? 글쎄, 많은 옵션이 있습니다... 첫째, sub_404C0E의 내용을 신중하고 꼼꼼하게 분석하여 정확히 무엇을 확인하고 어떻게 확인하는지 알아낼 수 있습니다. 둘째, JNZ short loc_40107F를 JZ short loc_40107F 또는 NOP, NOP로 간단히 바꿀 수 있습니다. 세 번째로, 반환 결과 확인 명령 TEST EAX, EAX는 XOR EAX, EAX라는 0 명령으로 바뀔 수 있습니다. 넷째, sub_404C0E 자체가 사라지도록 만들어 항상 0을 반환하도록 할 수 있습니다. 당신은 어떨지 모르겠지만 저는 세 번째 방법이 가장 마음에 들었습니다. 2바이트를 변경하고 컴파일러를 시작합니다. 보호에 "라이센스"에 대한 다른 확인이 없으면 프로그램이 작동하고 그에 따라 그 반대도 마찬가지입니다. (우리가 기억하는 것처럼 다섯 번째 버전에는 두 가지 검사가 있었습니다). 놀랍게도 컴파일러는 더 이상 불평하지 않고 작동합니다!!! 실제로 예상대로 개발자는 보호 기능을 전혀 강화하지 않았지만 반대로 약화시키기까지 했습니다! 크리스 카스퍼스키

당신은 노예가 아닙니다!
엘리트 자녀를 위한 비공개 교육 과정: "세계의 진정한 배열"
http://noslave.org

Wikipedia의 자료 - 무료 백과사전