Biblioteca de links dinâmicos

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar
Biblioteca de links dinâmicos
Ícone DLL (PNG).png
Extensão de nome de arquivo
.dll
Tipo de mídia da Internet
application/vnd.microsoft.portable-executable
Identificador de tipo uniforme (UTI)com.microsoft.windows-dynamic-link-library
número mágicoMZ
Desenvolvido porMicrosoft
Recipiente paraBiblioteca compartilhada

A biblioteca de vínculo dinâmico ( DLL ) é a implementação da Microsoft do conceito de biblioteca compartilhada nos sistemas operacionais Microsoft Windows e OS/2 . Essas bibliotecas geralmente têm a extensão de arquivo , (para bibliotecas que contêm controles ActiveX ) ou (para drivers de sistema legados ). Os formatos de arquivo para DLLs são os mesmos para arquivos EXE do Windows – ou seja, Portable Executable (PE) para Windows de 32 e 64 bits e New Executable (NE) para 16 bits DLLOCXDRVJanelas. Assim como os EXEs, as DLLs podem conter code , data e resources , em qualquer combinação.

Arquivos de dados com o mesmo formato de arquivo que uma DLL, mas com extensões de arquivo diferentes e possivelmente contendo apenas seções de recursos, podem ser chamados de DLLs de recursos . Exemplos de tais DLLs incluem bibliotecas de ícones , às vezes com a extensão ICL, e arquivos de fonteFON , com as extensões e FOT. [1]

Plano de fundo

As primeiras versões do Microsoft Windows executavam programas juntos em um único espaço de endereço . Cada programa foi concebido para cooperar, cedendo a CPU a outros programas, de modo que a interface gráfica do usuário (GUI) pudesse realizar várias tarefas e ser responsiva ao máximo. Todas as operações no nível do sistema operacional foram fornecidas pelo sistema operacional subjacente: MS-DOS . Todos os serviços de nível superior foram fornecidos pelas Bibliotecas do Windows "Biblioteca de Link Dinâmico". A API de desenho , Graphics Device Interface (GDI), foi implementada em uma DLL chamada GDI.EXE, a interface do usuário emUSER.EXE. Essas camadas extras em cima do DOS tinham que ser compartilhadas em todos os programas Windows em execução, não apenas para permitir que o Windows funcionasse em uma máquina com menos de um megabyte de RAM, mas para permitir que os programas cooperassem entre si. O código em GDI precisava traduzir comandos de desenho para operações em dispositivos específicos. Na tela, ele teve que manipular pixels no buffer de quadros. Ao desenhar para uma impressora, as chamadas de API precisavam ser transformadas em solicitações para uma impressora. Embora pudesse ter sido possível fornecer suporte codificado para um conjunto limitado de dispositivos (como a tela do Adaptador gráfico colorido , a linguagem de comando da impressora HP LaserJet ), a Microsoft optou por uma abordagem diferente. GDI funcionaria carregando diferentes pedaços de código, chamados " drivers de dispositivo", para trabalhar com diferentes dispositivos de saída.

O mesmo conceito de arquitetura que permitiu que a GDI carregasse diferentes drivers de dispositivo é aquele que permitia que o shell do Windows carregasse diferentes programas do Windows e que esses programas invocassem chamadas de API das bibliotecas compartilhadas USER e GDI. Esse conceito era "vinculação dinâmica".

Em uma biblioteca estática convencional não compartilhada , as seções de código são simplesmente adicionadas ao programa de chamada quando seu executável é compilado na fase de "vinculação"; se dois programas chamarem a mesma rotina, a rotina será incluída em ambos os programas durante o estágio de vinculação dos dois. Com a vinculação dinâmica, o código compartilhado é colocado em um único arquivo separado. Os programas que chamam esse arquivo estão conectados a ele em tempo de execução, com o sistema operacional (ou, no caso de versões anteriores do Windows, a extensão do SO), realizando a ligação.

Para as primeiras versões do Windows (1.0 a 3.11), as DLLs eram a base de toda a GUI. Como tal, os drivers de exibição eram apenas DLLs com uma extensão .DRV que fornecia implementações personalizadas da mesma API de desenho por meio de uma interface de driver de dispositivo unificada (DDI) e as APIs de desenho (GDI) e GUI (USER) eram apenas as chamadas de função exportadas pelo GDI e USER, DLLs do sistema com extensão .EXE.

Essa noção de construir o sistema operacional a partir de uma coleção de bibliotecas carregadas dinamicamente é um conceito central do Windows que persiste a partir de 2015 . DLLs fornecem os benefícios padrão de bibliotecas compartilhadas , como modularidade . A modularidade permite que sejam feitas alterações no código e nos dados em uma única DLL independente compartilhada por vários aplicativos sem nenhuma alteração nos próprios aplicativos.

Outro benefício da modularidade é o uso de interfaces genéricas para plug-ins. Uma única interface pode ser desenvolvida, permitindo que módulos antigos e novos sejam integrados sem problemas em tempo de execução em aplicativos pré-existentes, sem qualquer modificação no aplicativo em si. Este conceito de extensibilidade dinâmica é levado ao extremo com o Component Object Model , a base do ActiveX .

No Windows 1.x, 2.xe 3.x, todos os aplicativos do Windows compartilhavam o mesmo espaço de endereço e a mesma memória. Uma DLL foi carregada apenas uma vez nesse espaço de endereço; a partir de então, todos os programas que usavam a biblioteca a acessavam. Os dados da biblioteca foram compartilhados em todos os programas. Isso pode ser usado como uma forma indireta de comunicação entre processos ou pode corromper acidentalmente os diferentes programas. Com a introdução de bibliotecas de 32 bits no Windows 95 , cada processo foi executado em seu próprio espaço de endereço. Embora o código DLL possa ser compartilhado, os dados são privados, exceto quando os dados compartilhados são explicitamente solicitados pela biblioteca. Dito isto, grandes faixas do Windows 95 , Windows 98 e Windows Meforam construídos a partir de bibliotecas de 16 bits, o que limitava o desempenho do microprocessador Pentium Pro quando lançado e, por fim, limitava a estabilidade e a escalabilidade das versões do Windows baseadas em DOS.

Embora as DLLs sejam o núcleo da arquitetura do Windows, elas têm várias desvantagens, chamadas coletivamente de " Dll ​​hell ". [2] A partir de 2015 , a Microsoft promove o .NET Framework como uma solução para os problemas do inferno da DLL, embora agora promova soluções baseadas em virtualização, como o Microsoft Virtual PC e o Microsoft Application Virtualization , porque oferecem isolamento superior entre aplicativos. Uma solução alternativa de mitigação para o inferno da DLL foi implementar o assembly lado a lado .

Características

Como as DLLs são essencialmente iguais aos EXEs, a escolha de qual produzir como parte do processo de vinculação é para maior clareza, pois é possível exportar funções e dados de ambos.

Não é possível executar diretamente uma DLL, pois requer um EXE para o sistema operacional carregá-la através de um ponto de entrada , daí a existência de utilitários como RUNDLL.EXE ou RUNDLL32.EXE que fornecem o ponto de entrada e estrutura mínima para DLLs que contêm funcionalidade suficiente para executar sem muito suporte.

As DLLs fornecem um mecanismo para código e dados compartilhados, permitindo que um desenvolvedor de código/dados compartilhados atualize a funcionalidade sem exigir que os aplicativos sejam revinculados ou recompilados. Do ponto de vista do desenvolvimento de aplicativos, Windows e OS/2 podem ser pensados ​​como uma coleção de DLLs que são atualizadas, permitindo que aplicativos para uma versão do SO funcionem em uma versão posterior, desde que o fornecedor do SO tenha garantido que o interfaces e funcionalidades são compatíveis.

As DLLs são executadas no espaço de memória do processo chamador e com as mesmas permissões de acesso, o que significa que há pouca sobrecarga em seu uso, mas também que não há proteção para o programa chamador se a DLL tiver algum tipo de bug.

Gerenciamento de memória

Na API do Windows , os arquivos DLL são organizados em seções . Cada seção tem seu próprio conjunto de atributos, como ser gravável ou somente leitura, executável (para código) ou não executável (para dados) e assim por diante.

O código em uma DLL geralmente é compartilhado entre todos os processos que usam a DLL; ou seja, ocupam um único lugar na memória física e não ocupam espaço no arquivo de paginação . O Windows não usa código independente de posição para suas DLLs; em vez disso, o código é realocadoà medida que é carregado, fixando endereços para todos os seus pontos de entrada em locais que estão livres no espaço de memória do primeiro processo para carregar a DLL. Nas versões mais antigas do Windows, nas quais todos os processos em execução ocupavam um único espaço de endereço comum, uma única cópia do código da DLL sempre seria suficiente para todos os processos. No entanto, em versões mais recentes do Windows que usam espaços de endereço separados para cada programa, só é possível usar a mesma cópia realocada da DLL em vários programas se cada programa tiver os mesmos endereços virtuais livres para acomodar o código da DLL. Se alguns programas (ou sua combinação de DLLs já carregadas) não tiverem esses endereços livres, uma cópia física adicional do código da DLL precisará ser criada, usando um conjunto diferente de pontos de entrada realocados.

Em contraste com as seções de código, as seções de dados de uma DLL geralmente são privadas; ou seja, cada processo que usa a DLL tem sua própria cópia de todos os dados da DLL. Opcionalmente, as seções de dados podem ser compartilhadas, permitindo a comunicação entre processos através desta área de memória compartilhada. No entanto, como as restrições do usuário não se aplicam ao uso de memória DLL compartilhada, isso cria uma falha de segurança ; ou seja, um processo pode corromper os dados compartilhados, o que provavelmente fará com que todos os outros processos de compartilhamento se comportem de forma indesejável. Por exemplo, um processo executado em uma conta de convidado pode corromper outro processo executado em uma conta privilegiada. Esse é um motivo importante para evitar o uso de seções compartilhadas em DLLs.

Se uma DLL for compactada por determinados compactadores executáveis ​​(por exemplo , UPX ), todas as suas seções de código serão marcadas como lidas e gravadas e não serão compartilhadas. As seções de código de leitura e gravação, assim como as seções de dados privados, são particulares para cada processo. Assim, DLLs com seções de dados compartilhadas não devem ser compactadas se forem usadas simultaneamente por vários programas, pois cada instância do programa teria que carregar sua própria cópia da DLL, resultando em maior consumo de memória.

Importar bibliotecas

Assim como as bibliotecas estáticas, as bibliotecas de importação para DLLs são indicadas pela .libextensão do arquivo. Por exemplo, kernel32.dll , a biblioteca dinâmica primária para as funções básicas do Windows, como criação de arquivos e gerenciamento de memória, é vinculada via kernel32.lib. A maneira usual de diferenciar uma biblioteca de importação de uma biblioteca estática adequada é por tamanho: a biblioteca de importação é muito menor, pois contém apenas símbolos referentes à DLL real, a ser processada no momento do link. Ambos, no entanto, são arquivos de formato Unix ar .

A vinculação a bibliotecas dinâmicas geralmente é feita vinculando-se a uma biblioteca de importação ao compilar ou vincular para criar um arquivo executável. O executável criado contém uma tabela de endereços de importação (IAT) pela qual todas as chamadas de função DLL são referenciadas (cada função DLL referenciada contém sua própria entrada no IAT). Em tempo de execução, o IAT é preenchido com endereços apropriados que apontam diretamente para uma função na DLL carregada separadamente. [3]

No Cygwin/MSYS e MinGW, as bibliotecas de importação recebem convencionalmente o sufixo .dll.a, combinando o sufixo DLL do Windows e o sufixo ar do Unix. O formato do arquivo é semelhante, mas os símbolos usados ​​para marcar as importações são diferentes ( _head_foo_dllvs __IMPORT_DESCRIPTOR_foo). [4] Embora sua cadeia de ferramentas GNU Binutils possa gerar bibliotecas de importação e vincular a elas, é mais rápido vincular diretamente à DLL. [5] Uma ferramenta experimental no MinGW chamada genlib pode ser usada para gerar libs de importação com símbolos no estilo MSVC.

Resolução e encadernação do símbolo

Cada função exportada por uma DLL é identificada por um ordinal numérico e, opcionalmente, um nome. Da mesma forma, as funções podem ser importadas de uma DLL por ordinal ou por nome. O ordinal representa a posição do ponteiro de endereço da função na tabela de endereços de exportação de DLL. É comum que as funções internas sejam exportadas apenas por ordinal. Para a maioria das funções da API do Windows, apenas os nomes são preservados em diferentes versões do Windows; os ordinais estão sujeitos a alterações. Assim, não é possível importar de forma confiável as funções da API do Windows por seus ordinais.

Importar funções por ordinal fornece um desempenho apenas um pouco melhor do que importá-las por nome: as tabelas de exportação de DLLs são ordenadas por nome, portanto, uma pesquisa binária pode ser usada para localizar uma função. O índice do nome encontrado é então usado para pesquisar o ordinal na tabela Export Ordinal. No Windows de 16 bits, a tabela de nomes não era classificada, portanto, a sobrecarga de pesquisa de nomes era muito mais perceptível.

Também é possível vincular um executável a uma versão específica de uma DLL, ou seja, resolver os endereços das funções importadas em tempo de compilação. Para importações vinculadas, o vinculador salva o carimbo de data/hora e a soma de verificação da DLL à qual a importação está vinculada. Em tempo de execução, o Windows verifica se a mesma versão da biblioteca está sendo usada e, em caso afirmativo, o Windows ignora o processamento das importações. Caso contrário, se a biblioteca for diferente daquela à qual estava vinculada, o Windows processa as importações normalmente.

Os executáveis ​​vinculados carregam um pouco mais rápido se forem executados no mesmo ambiente para o qual foram compilados e exatamente ao mesmo tempo se forem executados em um ambiente diferente, portanto, não há desvantagem em vincular as importações. Por exemplo, todos os aplicativos padrão do Windows estão vinculados às DLLs do sistema de suas respectivas versões do Windows. Uma boa oportunidade para vincular as importações de um aplicativo ao seu ambiente de destino é durante a instalação do aplicativo. Isso mantém as bibliotecas "vinculadas" até a próxima atualização do sistema operacional. No entanto, altera a soma de verificação do executável, portanto não é algo que possa ser feito com programas assinados ou programas gerenciados por uma ferramenta de gerenciamento de configuração que usa somas de verificação (como MD5checksums) para gerenciar versões de arquivos. À medida que as versões mais recentes do Windows deixaram de ter endereços fixos para cada biblioteca carregada (por motivos de segurança), a oportunidade e o valor de vincular um executável estão diminuindo.

Vinculação explícita em tempo de execução

Os arquivos DLL podem ser carregados explicitamente em tempo de execução, um processo referido simplesmente como vinculação dinâmica em tempo de execução pela Microsoft, usando a função de API LoadLibrary(ou ). LoadLibraryExA GetProcAddressfunção API é usada para pesquisar símbolos exportados por nome e FreeLibrary– para descarregar a DLL. Essas funções são análogas a dlopen, dlsyme dlclosena API padrão POSIX .

O procedimento para vinculação explícita em tempo de execução é o mesmo em qualquer linguagem que ofereça suporte a ponteiros para funções , pois depende da API do Windows em vez de construções de linguagem.

Carregamento atrasado

Normalmente, um aplicativo vinculado à biblioteca de importação de uma DLL falhará ao iniciar se a DLL não puder ser encontrada, porque o Windows não executará o aplicativo a menos que possa localizar todas as DLLs de que o aplicativo possa precisar. No entanto, um aplicativo pode ser vinculado a uma biblioteca de importação para permitir o carregamento atrasado da biblioteca dinâmica. [6] Nesse caso, o sistema operacional não tentará localizar ou carregar a DLL quando o aplicativo for iniciado; em vez disso, um stub é incluído no aplicativo pelo vinculador que tentará localizar e carregar a DLL por meio LoadLibrarye GetProcAddressquando uma de suas funções for chamada. Se a DLL não puder ser encontrada ou carregada, ou a função chamada não existir, o aplicativo gerará uma exceção, que podem ser capturados e manuseados adequadamente. Se o aplicativo não tratar a exceção, ele será capturado pelo sistema operacional, que encerrará o programa com uma mensagem de erro.

O mecanismo de carregamento atrasado também fornece ganchos de notificação , permitindo que o aplicativo execute processamento adicional ou tratamento de erros quando a DLL é carregada e/ou qualquer função DLL é chamada.

Considerações sobre compilador e linguagem

Delphi

Em um arquivo de origem, a palavra-chave libraryé usada em vez de program. No final do arquivo, as funções a serem exportadas estão listadas na exportscláusula.

Delphi não precisa LIBde arquivos para importar funções de DLLs; para vincular a uma DLL, a externalpalavra-chave é usada na declaração da função para sinalizar o nome da DLL, seguida namede nomear o símbolo (se diferente) ou indexpara identificar o índice.

Microsoft Visual Basic

No Visual Basic (VB), há suporte apenas para vinculação em tempo de execução; mas além de usar LoadLibrarye GetProcAddressfunções de API, são permitidas declarações de funções importadas.

Ao importar funções DLL por meio de declarações, o VB gerará um erro em tempo de execução se o DLLarquivo não puder ser encontrado. O desenvolvedor pode detectar o erro e tratá-lo adequadamente.

Ao criar DLLs em VB, o IDE só permitirá a criação de DLLs ActiveX, porém métodos foram criados [7] para permitir que o usuário diga explicitamente ao linker para incluir um arquivo .DEF que define a posição ordinal e o nome de cada função exportada . Isso permite que o usuário crie uma DLL padrão do Windows usando o Visual Basic (versão 6 ou inferior) que pode ser referenciada por meio de uma instrução "Declare".

C e C++

O Microsoft Visual C++ (MSVC) fornece várias extensões ao C++ padrão que permitem que funções sejam especificadas como importadas ou exportadas diretamente no código C++; estes foram adotados por outros compiladores Windows C e C++, incluindo versões Windows do GCC . Essas extensões usam o atributo __declspecantes de uma declaração de função. Observe que quando as funções C são acessadas de C++, elas também devem ser declaradas como extern "C"no código C++, para informar ao compilador que a ligação C deve ser usada. [8]

Além de especificar funções importadas ou exportadas através __declspecde atributos, elas podem ser listadas na seção IMPORT ou EXPORTS do DEFarquivo utilizado pelo projeto. O DEFarquivo é processado pelo vinculador, em vez do compilador e, portanto, não é específico para C++.

A compilação de DLL produzirá arquivos DLLe . LIBO LIBarquivo (biblioteca de importação) é usado para vincular uma DLL em tempo de compilação; não é necessário para vinculação em tempo de execução. A menos que a DLL seja um servidor COM ( Component Object ModelDLL ), o arquivo deve ser colocado em um dos diretórios listados na variável de ambiente PATH, no diretório padrão do sistema ou no mesmo diretório do programa que o utiliza. As DLLs do servidor COM são registradas usando regsvr32.exe, que coloca a localização da DLL e seu ID global exclusivo ( GUID ) no registro. Os programas podem usar a DLL procurando seu GUID no registropara encontrar sua localização ou criar uma instância do objeto COM indiretamente usando seu identificador de classe e identificador de interface.

Exemplos de programação

Usando importações de DLL

Os exemplos a seguir mostram como usar associações específicas de idioma para importar símbolos para vincular a uma DLL em tempo de compilação.

Delfos

{$APPTYPE CONSOLE}

 Exemplo de programa ;

// importa a função que adiciona dois números 
function  AddNumbers ( a ,  b  :  Double ) :  Double ;  StdCall ;  externo  'Example.dll' ;

// programa principal 
var 
   R :  Double ;

begin 
  R  :=  AddNumbers ( 1 ,  2 ) ; 
  Writeln ( 'O resultado foi: ' ,  R ) ; 
fim .

C

O arquivo Example.lib deve ser incluído (supondo que Example.dll seja gerado) no projeto (opção Add Existing Item for Project!) antes da vinculação estática. O arquivo Example.lib é gerado automaticamente pelo compilador ao compilar a DLL. Não executar a instrução acima causaria um erro de vinculação, pois o vinculador não saberia onde encontrar a definição de AddNumbers. A DLL Example.dll também pode precisar ser copiada para o local onde o arquivo .exe seria gerado pelo código a seguir.

#include <windows.h> 
#include <stdio.h> 

// Função de importação que soma dois números 
extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b );       

int main ( int argc , char * argv [])    
{
    double resultado = AddNumbers ( 1 , 2 );    
    printf ( "O resultado foi: %f \n " , resultado ); 
    retorna 0 ; 
}

Usando vinculação explícita em tempo de execução

Os exemplos a seguir mostram como usar os recursos de carregamento e vinculação em tempo de execução usando associações de API do Windows específicas do idioma.

Observe que todas as quatro amostras são vulneráveis ​​a ataques de pré-carregamento de DLL , pois example.dll pode ser resolvido para um local não pretendido pelo autor (o diretório de trabalho atual vai antes dos locais da biblioteca do sistema) e, portanto, para uma versão maliciosa da biblioteca. Consulte a referência para orientação da Microsoft sobre carregamento seguro de bibliotecas: deve-se usar SetDllDirectoryWin kernel32para remover a pesquisa do diretório atual antes que qualquer biblioteca seja carregada. [9]

Microsoft Visual Basic

Opção  Explicit 
Declare  Function  AddNumbers  Lib  "Example.dll" _
 ( ByVal  a  As  Double ,  ByVal  b  As  Double )  As  Double

Sub  Main () 
	Dim  Result  As  Double 
	Result  =  AddNumbers ( 1 ,  2 ) 
	Debug . Imprimir  "O resultado foi: "  &  Resultado 
End  Sub

Delphi

 Exemplo de programa ; 
  {$APPTYPE CONSOLE} 
  usa  Windows ; 
  var 
  AddNumbers : function  ( a ,  b :  integer ) :  Double ;  StdCall ; 
  LibHandle : HMODULE ; 
begin 
  LibHandle  :=  LoadLibrary ( 'example.dll' ) ; 
  se  LibHandle  <>  0  então 
    AddNumbers  :=  GetProcAddress ( LibHandle ,  'AddNumbers' ); 
  se  Atribuído ( AddNumbers )  então 
    Writeln (  '1 + 2 =' ,  AddNumbers (  1 ,  2  )  ) ; 
  Readln ; 
fim .

C

#include <windows.h> 
#include <stdio.h> 

// Assinatura da função DLL 
typedef double ( * importFunction )( double , double );   

int main ( int argc , char ** argv )    
{
	importFunction addNumbers ; 
	resultado duplo ; 
	HINSTANCE hinstLib ; 

	// Carregar arquivo DLL 
hinstLib = LoadLibrary ( TEXT ( "Example.dll" ));	  
	if ( hinstLib == NULL ) {    
		printf ( "ERRO: nao foi possivel carregar DLL \n " );
		retorno 1 ; 
	}

	// Obter ponteiro de função 
addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" );	    
	if ( addNumbers == NULL ) {    
		printf ( "ERRO: nao foi possivel encontrar a funcao DLL \n " );
		FreeLibrary ( hinstLib );
		retorno 1 ; 
	}

	// Chama a função. 
resultado = addNumeros ( 1 , 3 );	   

	// Descarrega o arquivo DLL 
FreeLibrary ( hinstLib );	

	// Mostra o resultado 
printf ( "O resultado foi: %f \n " , resultado );	 

	retorna 0 ; 
}

Python

A ligação Python ctypes usará a API POSIX em sistemas POSIX.

importar  tipos de c

my_dll  =  ctypes . cdll . LoadLibrary ( "Example.dll" )

# A seguinte especificação do método "restype" é necessária para fazer 
# Python entender qual tipo é retornado pela função. 
meu_dll . Adicionar Números . restype  =  ctypes . c_double

p  =  minha_dll . AddNumbers ( ctypes . c_double ( 1.0 ),  ctypes . c_double ( 2.0 ))

print ( "O resultado foi:" ,  p )

Modelo de Objeto Componente

O Component Object Model (COM) define um padrão binário para hospedar a implementação de objetos em arquivos DLL e EXE. Ele fornece mecanismos para localizar e versionar esses arquivos, bem como uma descrição da interface independente de idioma e legível por máquina. Hospedar objetos COM em uma DLL é mais leve e permite que eles compartilhem recursos com o processo do cliente. Isso permite que objetos COM implementem back-ends poderosos para front-ends de GUI simples, como Visual Basic e ASP. Eles também podem ser programados a partir de linguagens de script. [10]

Sequestro de DLL

Devido a uma vulnerabilidade comumente conhecida como sequestro de DLL, falsificação de DLL, pré-carregamento de DLL ou plantio binário, muitos programas carregam e executam uma DLL maliciosa contida na mesma pasta que um arquivo de dados aberto por esses programas. [11] [12] [13] [14] A vulnerabilidade foi descoberta por Georgi Guninski em 2000. [15] Em agosto de 2010 ganhou publicidade mundial depois que a ACROS Security a redescobriu novamente e muitas centenas de programas foram considerados vulneráveis. [16] Programas executados em locais inseguros, ou seja, pastas graváveis ​​pelo usuário, como o diretório Downloads ou Temp , quase sempre são suscetíveis a essa vulnerabilidade. [17][18] [19] [20] [21] [22] [23]

Veja também

Referências

  • Hart, Johnson. Programação do Sistema Windows Terceira Edição . Addison-Wesley, 2005. ISBN  0-321-25619-0 .
  • Rector, Brent et ai. Programação Win32 . Addison-Wesley Developers Press, 1997. ISBN 0-201-63492-9 . 

Links externos

  1. ^ Microsoft Corporation. "Criando uma DLL somente de recursos" . Biblioteca Microsoft Developer Network .
  2. ^ "O Fim do Inferno DLL" . Corporação Microsoft. Arquivado a partir do original em 2008-05-06 . Recuperado em 2009-07-11 .
  3. ^ "Compreendendo a Tabela de Endereços de Importação" .
  4. ^ "Construindo e usando DLLs" . A biblioteca de importação é uma biblioteca .a comum, semelhante ao UNIX, mas contém apenas a pequena quantidade de informações necessárias para informar ao sistema operacional como o programa interage com ("importa") a dll. Essas informações estão vinculadas ao .exe.
  5. ^ "ld e WIN32" . documentação ld .
  6. ^ "Suporte do Linker para DLLs carregadas com atraso" . Corporação Microsoft . Recuperado em 2009-07-11 .
  7. ^ Petrusha, Ron (2005-04-26). "Criando uma DLL do Windows com Visual Basic" . Mídia O'Reilly . Recuperado em 2009-07-11 .
  8. ^ MSDN , Usando externo para especificar a ligação
  9. ^ "Carregamento seguro de bibliotecas para evitar ataques de pré-carregamento de DLL" . Suporte Microsoft . Recuperado em 28 de outubro de 2019 .
  10. ^ Satran, Michael. "Modelo de Objeto Componente (COM)" . msdn.microsoft . com .
  11. ^ Falsificação de DLL no Windows
  12. ^ "Ataques de pré-carregamento de DLL" . msdn . com . Recuperado em 25 de março de 2018 .
  13. ^ "Mais informações sobre o vetor de ataque remoto DLL Preloading" . technet . com . Recuperado em 25 de março de 2018 .
  14. ^ "Uma atualização no vetor de ataque remoto de pré-carregamento de DLL" . technet . com . Recuperado em 25 de março de 2018 .
  15. ^ "Clicar duas vezes em documentos do MS Office a partir do Windows Explorer pode executar programas arbitrários em alguns casos" . www.guninski.com . Recuperado em 25 de março de 2018 .
  16. ^ "Plantar binário - o Web site oficial de uma vulnerabilidade esquecida. Segurança do ACROS" . www.binaryplanting.com . Recuperado em 25 de março de 2018 .
  17. ^ Bombardeio de tapete e envenenamento de diretório
  18. ^ "Dev to Mozilla: Por favor, descarte processos antigos de instalação do Windows" . theregister.co.uk . Recuperado em 25 de março de 2018 .
  19. ^ "Gpg4win - Aviso de Segurança Gpg4win 2015-11-25" . www.gpg4win.org . Recuperado em 25 de março de 2018 .
  20. ^ "McAfee KB - McAfee Security Bulletin: Patch de segurança para vários instaladores e desinstaladores da McAfee (CVE-2015-8991, CVE-2015-8992 e CVE-2015-8993) (TS102462)" . service.mcafee . com . Recuperado em 25 de março de 2018 .
  21. ^ "fsc-2015-4 - F-Secure Labs" . www.f-secure.com . Arquivado a partir do original em 31 de julho de 2017 . Recuperado em 25 de março de 2018 .
  22. ^ "Vulnerabilidade e depreciação de seqüestro de ordem de pesquisa de DLL do ScanNow" . rapid7 . com . 21 de dezembro de 2015 . Recuperado em 25 de março de 2018 .
  23. ^ Equipe, VeraCrypt. "oss-sec: CVE-2016-1281: Os instaladores do Windows TrueCrypt e VeraCrypt permitem a execução de código arbitrário com elevação de privilégio" . seclists.org . Recuperado em 25 de março de 2018 .