다이내믹 링크 라이브러리

Dynamic-link library
이 문서에서는 OS/2 및 Windows 구현에 대해 설명합니다.일반적으로 라이브러리의 동적 링크에 대해서는 동적 링커를 참조하십시오.
동적으로 로드된 라이브러리와 혼동하지 마십시오.
동적 링크 라이브러리
DLL Icon (PNG).png
파일 이름 확장자
.disclosed(비활성화)
인터넷 미디어 유형
application/vnd.flash. 포터블
Uniform Type Identifier(UTI; 균일 유형 식별자)com.discloss.conf를 클릭합니다.윈도 다이내믹링크 링크 삭제
매직 넘버MZ
개발자마이크로소프트
컨테이너:공유 라이브러리

DLL(Dynamic Link Library)은 Microsoft Windows 및 OS/2 운영체제에서 공유 라이브러리의 개념을 구현한 것입니다.이러한 라이브러리는 일반적으로 파일 확장자를 가집니다. DLL,OCX(ActiveX 컨트롤이 포함된 라이브러리의 경우) 또는DRV(레거시 시스템 드라이버의 경우).DLL의 파일 형식은 Windows EXE 파일의 형식과 동일합니다.즉, 32비트 및 64비트 Windows의 경우 Portable Executable(PE; 포터블 실행 파일), 16비트 Windows의 경우 New Executable(NE; 신규 실행 파일)입니다.EXE와 마찬가지로 DLL은 코드, 데이터 및 리소스를 임의의 조합으로 포함할 수 있습니다.

파일 형식이 DLL과 동일하지만 파일 확장자가 다르고 리소스 섹션만 포함하는 데이터 파일을 리소스 DLL이라고 할 수 있습니다.이러한 DLL의 예로는 아이콘 라이브러리가 있으며 확장자가 있을 수 있습니다.ICL확장자를 가진 , 및 글꼴파일FON그리고.FOT를 클릭합니다.[1]

배경

Microsoft Windows 의 초기 버전은, 1 개의 주소 공간에서 프로그램을 함께 실행했습니다.모든 프로그램은 그래픽 사용자 인터페이스(GUI)가 멀티태스킹을 수행하고 응답성을 극대화할 수 있도록 CPU를 다른 프로그램에 양보함으로써 상호 운용되도록 설계되었습니다.모든 운영 체제 수준의 작업은 기본 운영 체제인 MS-DOS에서 제공되었습니다.모든 고급 서비스는 Windows 라이브러리 "Dynamic Link Library"에 의해 제공되었습니다.Drawing API, 그래픽 디바이스 인터페이스(GDI)는 DLL에 구현되었습니다.GDI.EXE의 사용자 인터페이스USER.EXEDOS 위에 있는 이러한 추가 레이어는 RAM이 1메가바이트 미만인 머신에서 Windows가 동작할 수 있도록 하기 위해서뿐만 아니라 프로그램 간의 상호 운용을 가능하게 하기 위해서도 실행 중인 모든 Windows 프로그램 간에 공유되어야 했습니다.그리기 명령어를 특정 디바이스의 조작으로 변환하기 위해 필요한 GDI의 코드.디스플레이에서는 프레임 버퍼 내의 픽셀을 조작해야 했습니다.프린터에 그릴 때 API 호출을 프린터에 대한 요청으로 변환해야 했습니다.한정된 디바이스 세트(컬러 그래픽스 어댑터 디스플레이, HP LaserJet Printer Command Language 등)에 대해 하드 코드화된 지원을 제공할 수 있었지만 Microsoft는 다른 방법을 선택했습니다.GDI는, 「디바이스 드라이버」라고 불리는 다른 코드를 로드해, 다른 출력 디바이스와 함께 동작합니다.

GDI가 다른 디바이스 드라이버를 로드할 수 있게 한 아키텍처의 개념은 Windows 쉘이 다른 Windows 프로그램을 로드할 수 있게 하고 이러한 프로그램이 공유 USER 및 GDI 라이브러리에서 API 호출을 호출하도록 한 것입니다.그 개념은 "동적 링크"였습니다.

기존의 비공유 스태틱 라이브러리에서는, 그 실행 파일이 「링크」단계에서 구축되면, 코드 섹션이 호출 프로그램에 간단하게 추가된다.두 프로그램이 같은 루틴을 호출하면, 그 루틴은, 그 둘의 링크 스테이지중에 양쪽의 프로그램에 포함된다.동적 링크를 사용하면 공유 코드가 단일 개별 파일에 배치됩니다.이 파일을 호출하는 프로그램은 런타임에 OS(또는 이전 버전의 Windows의 경우 OS 확장)와 함께 바인딩이 실행되어 연결됩니다.

Windows의 초기 버전(1.0~3.11)에서는 DLL이 GUI 전체의 기반이 되었습니다.따라서 디스플레이 드라이버는 를 탑재한 DLL에 불과했습니다.Unified Device Driver Interface(DDI; Unified Device Driver Interface), Drawing(GDI; 도면) API 및 GUI(USER; 사용자) API를 통해 동일한 도면 API를 커스텀 구현한 DRV 확장은 GDI 및 USER 시스템 DLL에서 내보낸 함수 호출에 불과했습니다.EXE 확장자

동적으로 로드된 라이브러리의 집합에서 운영 체제를 구축한다는 이 개념은 2015년 현재 지속되고 있는 Windows의 핵심 개념입니다.DLL은 모듈화와 같은 공유 라이브러리의 표준 이점을 제공합니다.모듈화를 통해 여러 응용 프로그램이 공유하는 단일 자체 포함 DLL에서 코드와 데이터를 변경할 수 있으며 응용 프로그램 자체를 변경하지 않아도 됩니다.

모듈러형의 또 다른 장점은 플러그인에 범용 인터페이스를 사용하는 것입니다.애플리케이션 자체를 변경하지 않고 런타임에 오래된 모듈과 새로운 모듈을 기존 애플리케이션에 심리스하게 통합할 수 있는 단일 인터페이스를 개발할 수 있습니다.이 동적 확장성의 개념은 ActiveX의 기반인 Component Object Model을 통해 극단적으로 확장됩니다.

Windows 1.x, 2.x 및 3.x에서는 모든 Windows 응용 프로그램이 동일한 메모리뿐만 아니라 동일한 주소 공간을 공유했습니다.DLL은 이 주소 공간에 한 번만 로드되었습니다. 이때부터 라이브러리를 사용하는 모든 프로그램이 DLL에 액세스했습니다.도서관의 데이터는 모든 프로그램에서 공유되었다.이것은 프로세스 간 통신의 간접적인 형태로 사용되거나 실수로 다른 프로그램이 손상될 수 있습니다.Windows 95에 32비트 라이브러리가 도입되면서 모든 프로세스가 자체 주소 공간에서 실행되었습니다.DLL 코드는 공유할 수 있지만 공유 데이터가 라이브러리에서 명시적으로 요청되는 경우를 제외하고 데이터는 비공개입니다.즉, Windows 95, Windows 98 및 Windows Me의 대규모 패키지는 16비트 라이브러리에서 구축되어 출시 시 Pentium Pro 마이크로프로세서의 성능을 제한하고 궁극적으로 DOS 기반 버전의 안정성과 확장성을 제한했습니다.

DLL은 Windows 아키텍처의 핵심이지만 집합적으로 "DLL 지옥"[2]이라고 불리는 몇 가지 단점이 있습니다.2015년 현재 Microsoft는 프로모션을 진행하고 있습니다.NET Framework는 DLL Hell 문제에 대한 하나의 솔루션으로서 Microsoft Virtual PC 및 Microsoft Application Virtualization 등의 가상화 기반 솔루션을 추진하고 있습니다.이러한 솔루션은 애플리케이션 간에 뛰어난 분리를 제공하기 때문입니다.DLL Hell을 경감하기 위한 대안으로 병렬 어셈블리를 구현하는 것이 있습니다.

특징들

DLL은 기본적으로 EXE와 동일하기 때문에 링크 프로세스의 일부로서 생성할 것을 선택하는 것은 명확성을 위해서입니다.이는 어느쪽이든 함수와 데이터를 내보낼 수 있기 때문입니다.

운영체제가 진입점을 통해 DLL을 로드하려면 EXE가 필요하기 때문에 DLL을 직접 실행할 수 없습니다.따라서 RUNDLL과 같은 유틸리티가 존재합니다.EXE 또는 RUNDLL32.많은 지원 없이 실행하기에 충분한 기능을 포함하는 DLL에 대한 진입점과 최소한의 프레임워크를 제공하는 EXE.

DLL은 공유 코드와 데이터를 위한 메커니즘을 제공하여 공유 코드/데이터 개발자가 애플리케이션을 재연결하거나 다시 컴파일할 필요 없이 기능을 업그레이드할 수 있도록 합니다.애플리케이션 개발의 관점에서는 Windows와 OS/2는 업그레이드된 DLL의 집합이라고 생각할 수 있습니다.OS 벤더가 인터페이스와 기능의 호환성을 보증하고 있는 한 OS의 한 버전용 애플리케이션을 최신 버전으로 동작시킬 수 있습니다.

DLL은 호출 프로세스의 메모리 공간에서 동일한 접근 권한으로 실행됩니다.즉, DLL 사용 시 오버헤드가 거의 발생하지 않을 뿐만 아니라 DLL에 버그가 있는 경우에도 호출 프로그램을 보호할 수 없습니다.

메모리 관리

Windows API에서는 DLL 파일이 섹션으로 구성됩니다.각 섹션에는 쓰기 가능 또는 읽기 전용, 실행 파일(코드용) 또는 실행 불가능(데이터용) 등의 고유한 속성 세트가 있습니다.

DLL 내의 코드는 일반적으로 DLL을 사용하는 모든 프로세스 간에 공유됩니다.즉, 물리 메모리의 단일 위치를 차지하기 때문에 페이지 파일의 공간을 차지하지 않습니다.Windows 에서는, DLL 에 대해서 위치에 의존하지 않는 코드를 사용하지 않습니다.그 대신에, 코드는 로드시에 재배치되어 DLL 를 로드하는 최초의 프로세스의 메모리 공간에 있는 모든 엔트리 포인트의 주소를 고정합니다.실행 중인 모든 프로세스가 하나의 공통 주소 공간을 차지했던 이전 버전의 Windows에서는 DLL 코드 복사본 하나로 모든 프로세스에 항상 충분했습니다.그러나 각 프로그램에 대해 별도의 주소 공간을 사용하는 새로운 버전의 Windows에서는 각 프로그램이 DLL 코드를 수용하기 위해 사용할 수 있는 가상 주소가 동일한 경우에만 여러 프로그램에서 동일한 재배치된 DLL 복사본을 사용할 수 있습니다.일부 프로그램(또는 이미 로드된 DLL의 조합)에 사용 가능한 주소가 없는 경우 재배치된 다른 진입점 세트를 사용하여 DLL 코드의 물리적 복사본을 추가로 생성해야 합니다.코드 섹션이 점유하고 있는 물리 메모리를 회수하는 경우, 그 내용은 폐기되고 나중에 필요에 따라 DLL 파일에서 직접 새로고침됩니다.

코드 섹션과 달리 DLL의 데이터 섹션은 일반적으로 비공개입니다. 즉, DLL을 사용하는 각 프로세스는 모든 DLL 데이터의 고유한 복사본을 가집니다.선택적으로 데이터 섹션을 공유할 수 있으므로 이 공유 메모리 영역을 통해 프로세스 간 통신이 가능합니다.다만, 공유 DLL 메모리의 사용에는 유저 제한이 적용되지 않기 때문에, 시큐러티 홀이 생깁니다.즉, 1개의 프로세스로 공유 데이터가 파손되어 다른 모든 공유 프로세스가 바람직하지 않게 동작할 가능성이 있습니다.예를 들어 게스트 계정으로 실행 중인 프로세스가 이러한 방식으로 권한 계정으로 실행 중인 다른 프로세스를 손상시킬 수 있습니다.이는 DLL에서 공유 섹션 사용을 피하는 중요한 이유입니다.

DLL이 특정 실행 파일패커(UPX 등)로 압축되어 있는 경우, 그 코드 섹션은 모두 읽기 및 쓰기로 표시되어 공유되지 않습니다.읽기/쓰기 코드 섹션은 개인 데이터 섹션과 마찬가지로 각 프로세스에 대해 비공개입니다.따라서 공유 데이터 섹션이 있는 DLL은 여러 프로그램에서 동시에 사용할 경우 압축하지 마십시오. 각 프로그램인스턴스가 DLL의 자체 복사본을 전송해야 하므로 메모리 사용량이 증가하기 때문입니다.

라이브러리 Import

스태틱 라이브러리와 마찬가지로 DLL Import 라이브러리는.lib파일 확장자예를 들어 파일 작성이나 메모리 관리 등 Windows의 기본 기능을 위한 기본 동적 라이브러리인 kernel32.dll은 다음을 통해 링크됩니다.kernel32.libImport 라이브러리와 적절한 정적 라이브러리를 구별하는 일반적인 방법은 크기입니다. Import 라이브러리는 링크 시 처리되는 실제 DLL을 참조하는 기호만 포함되므로 크기가 훨씬 작습니다.둘 다 Unix ar 형식 파일입니다.

동적 라이브러리로의 링크는 일반적으로 실행 파일을 작성하거나 작성할 때 Import 라이브러리에 링크함으로써 처리됩니다.작성된 실행 파일에는 Import Address Table(IAT; Import 주소 테이블)이 포함되어 있습니다.IAT 에는 모든 DLL 함수 콜이 참조됩니다(참조된 각 DLL 함수는 IAT 내의 독자적인 엔트리를 포함합니다).런타임에 IAT는 개별적으로 로드된 [3]DLL의 함수를 직접 가리키는 적절한 주소로 채워집니다.

Cygwin/MSYS 및 MinGW에서는 Import 라이브러리는 일반적으로 접미사가 붙습니다..dll.aWindows DLL 서픽스와 Unix ar 서픽스를 모두 조합합니다.파일 형식은 비슷하지만 Import 마킹에 사용되는 기호가 다릅니다._head_foo_dll대__IMPORT_DESCRIPTOR_foo). GNU Binutils 툴체인은 Import 라이브러리를 생성하여 링크할 수 있지만 DLL에 [5]직접 링크하는 것이 더 빠릅니다.[4]genlib라고 하는 MinGW의 실험 도구를 사용하여 MSVC 스타일의 기호를 사용하여 Import lib를 생성할 수 있습니다.

기호 해상도 및 바인딩

DLL에 의해 내보낸 각 함수는 숫자 순서 및 옵션으로 이름으로 식별됩니다.마찬가지로 함수를 DLL에서 서수 또는 이름으로 가져올 수 있습니다.서수는 DLL 내보내기 주소 테이블에서 함수의 주소 포인터 위치를 나타냅니다.일반적으로 내부 함수는 서수를 통해서만 내보냅니다.대부분의 Windows API 함수에서는 이름만 다른 Windows 릴리스에 걸쳐 유지되며 서수는 변경될 수 있습니다.따라서 Windows API 함수를 서수별로 확실하게 Import할 수 없습니다.

함수를 서수로 Import하면 이름으로 Import하는 것보다 성능이 약간 향상됩니다.DLL 내보내기 테이블은 이름으로 정렬되므로 바이너리 검색을 사용하여 함수를 찾을 수 있습니다.그런 다음 검색된 이름의 인덱스를 사용하여 [Export Ordinal]테이블에서 서수를 검색합니다.16비트 Windows에서는 이름 테이블이 정렬되지 않았기 때문에 이름 검색 오버헤드가 훨씬 두드러졌습니다.

실행 파일을 특정 버전의 DLL에 바인드할 수도 있습니다.즉, 컴파일 시에 Import된 함수의 주소를 해결할 수도 있습니다.바인드 Import의 경우 링커는 Import가 바인드된 DLL의 타임스탬프와 체크섬을 저장합니다.런타임에 Windows는 동일한 버전의 라이브러리가 사용되고 있는지 확인하고, 사용되고 있는 경우 Windows는 Import 처리를 바이패스합니다.그렇지 않으면 라이브러리가 바인딩된 라이브러리와 다른 경우 윈도우즈는 가져오기를 일반 방식으로 처리합니다.

바인드된 실행 파일은 컴파일 대상과 동일한 환경에서 실행되는 경우, 그리고 다른 환경에서 실행되는 경우 정확히 동일한 시간에 로딩되므로 Import 바인딩에 문제가 없습니다.예를 들어 모든 표준 Windows 응용 프로그램은 해당 Windows 릴리스의 시스템 DLL에 바인딩됩니다.애플리케이션의 Import를 타겟 환경에 바인드 할 수 있는 좋은 기회는, 애플리케이션의 인스톨중에 있습니다.이것에 의해, 다음의 OS 업데이트까지 라이브러리가 「바인드」인 채로 있습니다.그러나 실행 파일의 체크섬은 변경되지 않으므로 서명된 프로그램이나 체크섬(MD5 체크섬 등)을 사용하여 파일버전을 관리하는 구성관리툴에 의해 관리되는 프로그램에서는 실행할 수 없습니다.최신 Windows 버전이 (보안상의 이유로) 로드된 모든 라이브러리에 고정 주소를 할당하는 것에서 벗어나면서 실행 파일을 바인딩할 기회와 가치가 감소하고 있습니다.

명시적 런타임 링크

DLL 파일은 런타임에 명시적으로 로드할 수 있습니다.이 프로세스는 Microsoft에 의해 단순히 런타임 다이내믹 링크라고 불립니다.LoadLibrary(또는LoadLibraryEx) API 함수입니다.그GetProcAddressAPI 함수는 내보낸 기호를 이름으로 조회할 때 사용합니다.FreeLibrary– DLL을 언로드합니다.이러한 함수는 다음과 같습니다.dlopen,dlsym,그리고.dlclosePOSIX 표준 API에서 확인할 수 있습니다.

명시적 런타임 링크 절차는 언어 구조가 아닌 Windows API에 따라 달라지기 때문에 함수에 대한 포인터를 지원하는 모든 언어에서 동일합니다.

로드 지연

일반적으로 DLL을 찾을 수 없는 경우 DLL 가져오기 라이브러리에 링크된 응용 프로그램은 시작되지 않습니다. 응용 프로그램에 필요한 모든 DLL을 찾을 수 있어야 Windows가 응용 프로그램을 실행할 수 있기 때문입니다.단, 어플리케이션은 Import 라이브러리에 링크되어 다이내믹 [6]라이브러리의 로드가 지연될 수 있습니다.이 경우 운영시스템은 응용 프로그램 시작 시 DLL 검색 또는 로드를 시도하지 않습니다.대신 링커에 의해 스텁이 응용 프로그램에 포함되어 DLL을 검색 및 로딩합니다.LoadLibrary그리고.GetProcAddress그 기능 중 하나가 호출되었을 때.DLL을 검출 또는 로드할 수 없거나 호출된 함수가 존재하지 않는 경우 응용 프로그램은 예외를 생성합니다.이 예외는 검출되어 적절히 처리될 수 있습니다.응용 프로그램이 예외를 처리하지 않으면 운영 체제에 의해 탐지되고 오류 메시지와 함께 프로그램이 종료됩니다.

지연된 로드 메커니즘은 알림 후크도 제공하여 DLL이 로드되거나 DLL 함수가 호출될 때 응용 프로그램이 추가 처리 또는 오류 처리를 수행할 수 있도록 합니다.

컴파일러 및 언어에 관한 고려사항

델파이

소스 파일에서 키워드는library대신 사용됩니다.program. 파일 끝에 내보낼 함수가 나열됩니다.exports절을 클릭합니다.

델파이는 필요 없습니다.LIBDLL에서 함수를 Import하기 위한 파일, DLL에 링크하기 위해external키워드는 함수 선언에서 DLL 이름을 시그널링하기 위해 사용됩니다.name(다른 경우) 기호의 이름을 지정하거나index인덱스를 확인하기 위해.

Microsoft Visual Basic

VisualBasic(VB)에는, 런타임 연동;그러나 사용한 표현 법 외에 지원된다.LoadLibrary그리고.GetProcAddressAPI함수, 수입된 기능의 서약이 허용된다.

언제 선언을 통해 DLL기능을 수입하고는 VB 런타임 오류를 생성할 것입니다.DLL파일을 찾을 수 없습니다.그 개발하고 적절하게 감당한 오류를 잡을 수 있다.

언제 VB로 DLL을 만드는 하지만 방법은 사용자를 명확히 포함하기 위해 링커 알려 줄 수 있도록 created[7] 되어 있어 IDE만, ActiveXDLL의 설립을 허용할 것이다.각 수출 함수의 순서 위치와 이름을 정의합니다 우식 파일입니다.이것은 사용자가 표준 WindowsDLLVisualBasic의 경우(버전 6이하)을 사용해 만든"선포하다"성명을 통해 참조될 수 있음을 만들 수 있습니다.

C 및 C++

MicrosoftVisualC++(MSVC)에 여러 확장을 제공한다 표준 C++은 허용하는 기능에 지정한 대로 수입이나 수출 직접적으로 C++코드, 이들을 가지고에 의해 입양된 다른 WindowsC와 C++컴파일러에서는 포함하여 Windows버전의 GCC.확장들은 특성을 사용합니다.__declspec함수 선언 전에.유의 C기능 C++에서 액세스 된다, 또한으로 신고해야 한다.extern "C"C++코드에서는 컴파일러는 C연계 사용되야 할 것 같소.[8]

게다가 또는 수출되는 기능을 사용해를 지정합니다.__declspec특성은, 그들은의 수입 또는 EXPORTS 섹션에서 명시할 수 있다.DEF프로젝트에서 사용하는 파일입니다.그DEF파일은 컴파일러가 아닌 링커에 의해 처리되므로 C++에 고유하지 않습니다.

DLL 컴파일은 양쪽 모두를 생성합니다.DLL그리고.LIB파일.LIB파일(Import Library)은 컴파일 시 DLL에 대한 링크에 사용됩니다.실행시 링크에는 필요하지 않습니다.DLL이 Component Object Model(COM; 컴포넌트 오브젝트 모델) 서버가 아닌 한DLL파일은 PATH 환경변수에 나열된 디렉토리 중 하나, 기본 시스템 디렉토리 또는 이를 사용하는 프로그램과 동일한 디렉토리에 배치해야 합니다.COM 서버 DLL은 레지스트리에 DLL 위치와 GUID(Global Unique ID)를 배치하는 regsvr32.exe를 사용하여 등록됩니다.그런 다음 레지스트리에서 해당 GUID를 검색하여 DLL을 사용하여 위치를 찾거나 클래스 ID 및 인터페이스 ID를 사용하여 간접적으로 COM 개체의 인스턴스를 만들 수 있습니다.

프로그래밍 예시

DLL 가져오기 사용

다음으로 언어 고유의 바인딩을 사용하여 컴파일 시에 DLL에 링크하기 위한 기호를 Import하는 예를 나타냅니다.

델파이 

{$APPTYPE CONSOLE}  프로그램. 예;  // 두 숫자를 추가하는 가져오기 함수 기능. Add Numbers(추가 번호)(a, b : 더블): 더블; 표준 통화; 외부의 '예.dll';  // 메인 프로그램 변화하다    R: 더블;  시작한다.   R := Add Numbers(추가 번호)(1, 2);   쓰기("결과는 다음과 같습니다., R); 끝..

C

정적 링크 전에 Example.lib 파일(Example.dll이 생성된 것으로 가정)을 프로젝트에 포함해야 합니다(프로젝트의 경우 기존 항목 추가 옵션).Example.lib 파일은 DLL을 컴파일할 때 컴파일러에 의해 자동으로 생성됩니다.위의 스테이트먼트를 실행하지 않으면 링커는 AddNumbers의 정의를 찾을 수 없기 때문에 링크 오류가 발생합니다.DLL Example.dll은 다음 코드로 .exe 파일이 생성되는 위치에 복사해야 할 수도 있습니다. 

#실패하다 <윈도우>h> #실패하다 <stdio.h>  // 2개의 숫자를 추가하는 Import 함수 외부 'C' __declspec(dll Import) 이중으로 하다 Add Numbers(추가 번호)(이중으로 하다 a, 이중으로 하다 b);  인트 주된(인트 argc, 차 *argv[]) {     이중으로 하다 결과 = Add Numbers(추가 번호)(1, 2);     인쇄물("결과: %f\n", 결과);     돌아가다 0; }

명시적 런타임 링크 사용

다음으로 언어 고유의 Windows API 바인딩을 사용하여 런타임로드 및 링크패실리티를 사용하는 예를 나타냅니다.

example.dll은 작성자가 의도하지 않은 장소(현재 작업 디렉토리는 시스템라이브러리 위치보다 우선)로 해결되어 라이브러리의 악의적인 버전에 도달할 수 있으므로 4개의 샘플 모두 DLL 프리로드 공격에 취약합니다.안전한 라이브러리의 로드에 관한 Microsoft 의 가이던스에 대해서는, 다음의 문서를 참조해 주세요.SetDllDirectoryW에kernel32라이브러리를 [9]로드하기 전에 현재 디렉토리 조회를 삭제합니다.

Microsoft Visual Basic

옵션 명시적 선언 함수 AddNumbers Lib "Example.dll" _ (ByVal a As Double, ByVal b As Double) As Double Sub Main() Dim Result = AddNumbers(1, 2) 디버깅"결과:" & Result End Sub를 인쇄합니다.

델파이

프로그램. 예;   {$APPTYPE CONSOLE}   사용하다 창문들;   변화하다   Add Numbers(추가 번호):기능. (a, b: 정수): 더블; 표준 통화;   리브핸들:모듈; 시작한다.   리브핸들 := 로드 라이브러리('contract.contract');   한다면 리브핸들 << 고객명 >>님 0 그리고나서     Add Numbers(추가 번호) := Get Proc Address(프로세서 주소)(리브핸들, 'Add Numbers');   한다면 맡겨진(Add Numbers(추가 번호)) 그리고나서     쓰기( '1 + 2 = ', Add Numbers(추가 번호)( 1, 2 ) );   판독; 끝..

C

#실패하다 <윈도우>h> #실패하다 <stdio.h>  // DLL 함수 시그니처 유형화된 이중으로 하다 (*Import 기능)(이중으로 하다, 이중으로 하다);  인트 주된(인트 argc, 차 **argv) {  Import 기능 addNumbers;  이중으로 하다 결과;  인스턴스 hinstLib;   // DLL 파일 로드  hinstLib = 로드 라이브러리(본문("example.dll"));  한다면 (hinstLib == 특수한 순서) {   인쇄물("ERROR: DLL을 로드할 수 없습니다.\n");   돌아가다 1;  }   // 함수 포인터 가져오기  addNumbers = (Import 기능) Get Proc Address(프로세서 주소)(hinstLib, "Add Numbers");  한다면 (addNumbers == 특수한 순서) {   인쇄물("ERROR: DLL 함수를 찾을 수 없습니다.\n");   프리 라이브러리(hinstLib);   돌아가다 1;  }   // 콜 함수  결과 = addNumbers(1, 3);   // DLL 파일 언로드  프리 라이브러리(hinstLib);   // 결과 표시  인쇄물("결과: %f\n", 결과);   돌아가다 0; }

파이썬

Python ctypes 바인딩은 POSIX 시스템에서 POSIX API를 사용합니다. 

수입품 ctype  my_my_my_my_my_my_my = ctype.CDLL.로드 라이브러리("example.dll")  # 다음 "재입력" 방법 지정이 필요합니다. # Python은 함수에 의해 반환되는 유형을 파악합니다. my_my_my_my_my_my_my.Add Numbers(추가 번호).재입력 = ctype.c_double  p = my_my_my_my_my_my_my.Add Numbers(추가 번호)(ctype.c_double(1.0), ctype.c_double(2.0))  인쇄물("결과는 다음과 같습니다.", p)

컴포넌트 객체 모델

Component Object Model(COM; 컴포넌트 오브젝트 모델)은 DLL 및 EXE 파일에서 오브젝트 구현을 호스트하기 위한 바이너리 표준을 정의합니다.이러한 파일을 검색 및 버전화하는 메커니즘과 더불어 인터페이스에 대한 언어에 의존하지 않고 기계에서 읽을 수 있는 설명을 제공합니다.DLL에서 COM 개체를 호스팅하는 것이 더 가볍고 클라이언트 프로세스와 리소스를 공유할 수 있습니다.이를 통해 COM 오브젝트는 Visual Basic이나 ASP 등의 간단한 GUI 프런트 엔드에 강력한 백엔드를 구현할 수 있습니다.스크립팅 [10]언어로 프로그래밍할 수도 있습니다.

DLL 하이잭

일반적으로 DLL 하이잭, DLL 스푸핑, DLL 프리로드 또는 바이너리 플랜팅으로 알려진 취약성으로 인해 많은 프로그램이 이러한 [11][12][13][14]프로그램에 의해 열린 데이터 파일과 같은 폴더에 포함된 악의적인 DLL을 로드하고 실행합니다.이 취약성은 2000년에 [15]Georgi Guninski에 의해 발견되었습니다.2010년 8월 ACROS 보안에 의해 재발견되어 수백 개의 프로그램이 [16]취약한 것으로 판명된 후, 전 세계에 널리 알려졌습니다.Downloads 나 Temp 디렉토리와 같이 사용자가 쓸 수 있는 폴더 등 안전하지 않은 위치에서 실행되는 프로그램은 거의 항상 이 [17][18][19][20][21][22][23]취약성에 취약합니다.

「 」를 참조해 주세요.

레퍼런스

  • 하트, 존슨.Windows System Programming Third Edition.애디슨 웨슬리, 2005년 ISBN0-321-25619-0.
  • 렉터, 브렌트 등Win32 프로그래밍애디슨 웨슬리 개발자 프레스, 1997.ISBN 0-201-63492-9.

외부 링크

  1. ^ Microsoft Corporation. "Creating a Resource-Only DLL". Microsoft Developer Network Library.
  2. ^ "The End of DLL Hell". Microsoft Corporation. Archived from the original on 2008-05-06. Retrieved 2009-07-11.
  3. ^ "Understanding the Import Address Table".
  4. ^ "Building and Using DLLs". The import library is a regular UNIX-like .a library, but it only contains the tiny bit of information needed to tell the OS how the program interacts with ("imports") the dll. This information is linked into .exe.
  5. ^ "ld and WIN32". ld documentation.
  6. ^ "Linker Support for Delay-Loaded DLLs". Microsoft Corporation. Retrieved 2009-07-11.
  7. ^ Petrusha, Ron (2005-04-26). "Creating a Windows DLL with Visual Basic". O'Reilly Media. Retrieved 2009-07-11.
  8. ^ MSDN, 외부 사용 링크 지정
  9. ^ "Secure loading of libraries to prevent DLL preloading attacks". Microsoft Support. Retrieved 28 October 2019.
  10. ^ Satran, Michael. "Component Object Model (COM)". msdn.microsoft.com.
  11. ^ Windows에서의 DLL 스푸핑
  12. ^ "DLL Preloading Attacks". msdn.com. Retrieved 25 March 2018.
  13. ^ "More information about the DLL Preloading remote attack vector". technet.com. Retrieved 25 March 2018.
  14. ^ "An update on the DLL-preloading remote attack vector". technet.com. Retrieved 25 March 2018.
  15. ^ "Double clicking on MS Office documents from Windows Explorer may execute arbitrary programs in some cases". www.guninski.com. Retrieved 25 March 2018.
  16. ^ "Binary Planting - The Official Web Site of a Forgotten Vulnerability . ACROS Security". www.binaryplanting.com. Retrieved 25 March 2018.
  17. ^ 카펫 폭파 및 디렉토리 중독
  18. ^ "Dev to Mozilla: Please dump ancient Windows install processes". theregister.co.uk. Retrieved 25 March 2018.
  19. ^ "Gpg4win - Security Advisory Gpg4win 2015-11-25". www.gpg4win.org. Retrieved 25 March 2018.
  20. ^ "McAfee KB - McAfee Security Bulletin: Security patch for several McAfee installers and uninstallers (CVE-2015-8991, CVE-2015-8992, and CVE-2015-8993) (TS102462)". service.mcafee.com. Retrieved 25 March 2018.
  21. ^ "fsc-2015-4 - F-Secure Labs". www.f-secure.com. Archived from the original on 31 July 2017. Retrieved 25 March 2018.
  22. ^ "ScanNow DLL Search Order Hijacking Vulnerability and Deprecation". rapid7.com. 21 December 2015. Retrieved 25 March 2018.
  23. ^ Team, VeraCrypt. "oss-sec: CVE-2016-1281: TrueCrypt and VeraCrypt Windows installers allow arbitrary code execution with elevation of privilege". seclists.org. Retrieved 25 March 2018.