Formato executável e vinculável
Na computação, o Formato executável e vinculável (ELF, anteriormente denominado Extensible Linking Format), é um formato de arquivo padrão comum para arquivos executáveis arquivos, código de objeto, bibliotecas compartilhadas e dumps principais. Publicado pela primeira vez na especificação para a interface binária do aplicativo (ABI) da versão do sistema operacional Unix chamada System V Release 4 (SVR4), e posteriormente no Tool Interface Standard, foi rapidamente aceito entre diferentes fornecedores de sistemas Unix. Em 1999, foi escolhido como o formato de arquivo binário padrão para sistemas Unix e semelhantes em processadores x86 pelo projeto 86open.
Por design, o formato ELF é flexível, extensível e multiplataforma. Por exemplo, ele oferece suporte a diferentes endiannesses e tamanhos de endereço, de modo que não exclui nenhuma unidade de processamento central (CPU) específica ou arquitetura de conjunto de instruções. Isso permitiu que ele fosse adotado por muitos sistemas operacionais diferentes em muitas plataformas de hardware diferentes.
Layout do arquivo
Cada arquivo ELF é composto de um cabeçalho ELF, seguido pelos dados do arquivo. Os dados podem incluir:
- Tabela de cabeçalho do programa, descrevendo zero ou mais segmentos de memória
- Tabela de cabeçalho da seção, descrevendo zero ou mais seções
- Dados referidos por entradas na tabela de cabeçalho do programa ou tabela de cabeçalho da seção
Os segmentos contêm informações necessárias para a execução do arquivo em tempo de execução, enquanto as seções contêm dados importantes para vinculação e realocação. Qualquer byte no arquivo inteiro pode pertencer a uma seção no máximo, e podem ocorrer bytes órfãos que não pertencem a nenhuma seção.
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 c5 48 40 00 00 00 00 00 |..>......H@.....|
Exemplo hexdump de cabeçalho de arquivo ELF
Cabeçalho do arquivo
O cabeçalho ELF define se deve usar endereços de 32 ou 64 bits. O cabeçalho contém três campos que são afetados por essa configuração e compensam outros campos que os seguem. O cabeçalho ELF tem 52 ou 64 bytes de comprimento para binários de 32 e 64 bits, respectivamente.
Desligado | Tamanho (bytes) | Campo | Propósito | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 bits | 64 bits | 32 bits | 64 bits | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x00 | 4 | e_ident[EI_MAG0] através de e_ident[EI_MAG3] | 0x7F seguido por ELF (45 4c 46 ) em ASCII; estes quatro bytes constituem o número mágico.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | 1 | E_ident[EI_CLASS] | Este byte está definido para qualquer 1 ou 2 para significar formato de 32 ou 64 bits, respectivamente.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x05 | 1 | e_ident[EI_DATA] | Este byte está definido para qualquer 1 ou 2 significar pouca ou grande resistência, respectivamente. Isso afeta a interpretação de campos multi-byte começando com deslocamento 0x10 .
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x06 | 1 | e_ident[EI_VERSION] | Definir para 1 para a versão original e atual de ELF.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x07 | 1 | E_ident[EI_OSABI] | Identifica o sistema operacional alvo ABI.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | 1 | e_ident[EI_ABIVERSION] | Mais especifica a versão ABI. Sua interpretação depende do alvo ABI. O kernel do Linux (depois de pelo menos 2.6) não tem definição disso, por isso é ignorado para executáveis ligados estaticamente. Nesse caso, o deslocamento e o tamanho do EI_PAD são 8 .
glibc 2.12+ no caso E_ident[EI_OSABI] 3 trata este campo como versão ABI do linker dinâmico: define uma lista de características dinâmicas do linker, trata e_ident[EI_ABIVERSION] como um nível de recurso solicitado pelo objeto compartilhado (biblioteca execrável ou dinâmica) e se recusa a carregá-lo se um recurso desconhecido for solicitado, ou seja,. e_ident[EI_ABIVERSION] é maior do que a maior característica conhecida. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x09 | 7 | E_ident[EI_PAD] | bytes de remo reservados. Atualmente não usado. Deve ser preenchido com zeros e ignorado quando lido. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 2 | e_type | Identifica o tipo de arquivo de objeto.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x12 | 2 | e_máquina | Especifica a arquitetura de conjunto de instruções de destino. Alguns exemplos são:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x14 | 4 | e_versão | Definir para 1 para a versão original do ELF.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 4 | 8 | E_entry | Este é o endereço de memória do ponto de entrada de onde o processo começa a executar. Este campo é de 32 ou 64 bits de comprimento, dependendo do formato definido anteriormente (byte 0x04). Se o arquivo não tiver um ponto de entrada associado, então isso mantém zero. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x1C | 0x20 | 4 | 8 | Pontos para o início da tabela de cabeçalho do programa. Geralmente segue o cabeçalho do arquivo imediatamente após este, fazendo o deslocamento 0x34 ou 0x40 para executáveis ELF de 32 e 64 bits, respectivamente.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 0x28 | 4 | 8 | Pontos para o início da tabela de cabeçalho da seção. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x24 | 0x30 | 4 | E_flags | A interpretação deste campo depende da arquitetura alvo. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x28 | 0x34 | 2 | E_ehsize | Contém o tamanho deste cabeçalho, normalmente 64 Bytes para 64 bits e 52 Bytes para formato de 32 bits. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2A | 0x36 | 2 | e_fentsize | Contém o tamanho de uma entrada de tabela de cabeçalho do programa. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2C | 0x38 | 2 | e_ | Contém o número de entradas na tabela de cabeçalho do programa. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2E | 0x3A | 2 | O que é? | Contém o tamanho de uma entrada de tabela de cabeçalho de seção. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x30 | 0x3C | 2 | Contém o número de entradas na tabela de cabeçalho da seção. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x32 | 0x3E | 2 | O que é? | Contém índice da entrada da tabela de cabeçalho da seção que contém os nomes da seção. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x34 | 0x40 | Fim do cabeçalho ELF (tamanho). |
Cabeçalho do programa
A tabela de cabeçalho do programa informa ao sistema como criar uma imagem de processo. Ele é encontrado no deslocamento do arquivo e_phoff e consiste em entradas e_phnum, cada uma com tamanho e_phentsize . O layout é um pouco diferente no ELF de 32 bits e no ELF de 64 bits, porque as p_flags estão em um local de estrutura diferente por motivos de alinhamento. Cada entrada é estruturada como:
Desligado | Tamanho (bytes) | Campo | Propósito | |||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 bits | 64 bits | 32 bits | 64 bits | |||||||||||||||||||||||||||||||||||||||
0x00 | 4 | p_tipo | Identifica o tipo do segmento.
| |||||||||||||||||||||||||||||||||||||||
0x04 | 4 | P_flags | Bandeiras dependentes de segmento (posição para estrutura de 64 bits). | |||||||||||||||||||||||||||||||||||||||
0x04 | 0x08 | 4 | 8 | p_offset | Offset do segmento na imagem de arquivo. | |||||||||||||||||||||||||||||||||||||
0x08 | 0x10 | 4 | 8 | POLÍTICA | Endereço virtual do segmento em memória. | |||||||||||||||||||||||||||||||||||||
0x0C | 0x18 | 4 | 8 | P_paddr | Em sistemas onde o endereço físico é relevante, reservado para o endereço físico do segmento. | |||||||||||||||||||||||||||||||||||||
0x10 | 0x20 | 4 | 8 | p_filesz | Tamanho em bytes do segmento na imagem de arquivo. Pode ser 0. | |||||||||||||||||||||||||||||||||||||
0x14 | 0x28 | 4 | 8 | P_memsz | Tamanho em bytes do segmento em memória. Pode ser 0. | |||||||||||||||||||||||||||||||||||||
0x18 | 4 | P_flags | Bandeiras dependentes de segmento (posição para estrutura de 32 bits). | |||||||||||||||||||||||||||||||||||||||
0x1C | 0x30 | 4 | 8 | p_align | 0 e 1 Não especifique nenhum alinhamento. Caso contrário deve ser um poder positivo, integral de 2, com POLÍTICA igualando p_offset Modulus p_align.
| |||||||||||||||||||||||||||||||||||||
0x20 | 0x38 | Fim do programa Header (tamanho). |
Cabeçalho da seção
Desligado | Tamanho (bytes) | Campo | Propósito | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32 bits | 64 bits | 32 bits | 64 bits | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x00 | 4 | O que é? | Um deslocamento para uma string no . seção que representa o nome desta seção. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | 4 | Tipo: | Identifica o tipo deste cabeçalho.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | 4 | 8 | O que é? | Identifica os atributos da seção.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0C | 0x10 | 4 | 8 | Não. | Endereço virtual da seção em memória, para seções carregadas. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 0x18 | 4 | 8 | Não. | Offset da seção na imagem do arquivo. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x14 | 0x20 | 4 | 8 | O tamanho | Tamanho em bytes da seção na imagem do arquivo. Pode ser 0. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 0x28 | 4 | O que é? | Contém o índice de seção de uma seção associada. Este campo é usado para várias finalidades, dependendo do tipo de seção. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x1C | 0x2C | 4 | O que é? | Contém informações adicionais sobre a seção. Este campo é usado para várias finalidades, dependendo do tipo de seção. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 0x30 | 4 | 8 | O que é isto? | Contém o alinhamento necessário da seção. Este campo deve ser um poder de dois. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x24 | 0x38 | 4 | 8 | O que é? | Contém o tamanho, em bytes, de cada entrada, para seções que contêm entradas de tamanho fixo. Caso contrário, este campo contém zero. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x28 | 0x40 | Fim do cabeçalho da seção (tamanho). |
Ferramentas
readelf
é um utilitário binário Unix que exibe informações sobre um ou mais arquivos ELF. Uma implementação gratuita de software é fornecida pelo GNU Binutils.elfutils
fornece ferramentas alternativas para GNU Binutils puramente para Linux.elfdump
é um comando para visualização de informações ELF em um arquivo ELF, disponível em Solaris e FreeBSD.objdump
fornece uma ampla gama de informações sobre arquivos ELF e outros formatos de objetos.objdump
usa a biblioteca Binary File Descritor como um back-end para estruturar os dados ELF.- O Unix
file
O utilitário pode exibir algumas informações sobre arquivos ELF, incluindo a arquitetura de conjunto de instruções para a qual o código em um arquivo de objeto relocatável, executável ou compartilhado é destinado, ou em que um dump do núcleo ELF foi produzido.
Aplicativos
Sistemas tipo Unix
O formato ELF substituiu os formatos executáveis mais antigos em vários ambientes. Ele substituiu os formatos a.out e COFF em sistemas operacionais do tipo Unix:
- Linux
- Solaris / Illumos
- IRIX
- FreeBSD
- NetBSD
- OpenBSD
- Redox
- DragonFly BSD
- Syllable
- HP-UX (exceto para programas PA-RISC de 32 bits que continuam a usar SOM)
- QNX Neutrino
- MINIX
Adoção não Unix
ELF também viu alguma adoção em sistemas operacionais não-Unix, como:
- OpenVMS, em suas versões Itanium e amd64
- BeOS Revision 4 e mais tarde para computadores baseados em x86 (onde substituiu o formato Executável Portátil; a versão PowerPC ficou com Formato Executável Preferido)
- Haiku, uma reimplementação open source de BeOS
- OS RISC
- Stratus VOS, em versões PA-RISC e x86
- SkyOS
- Sistema de Fuchsia
- Z/TPF
- Sistema operacional HPE NonStop
- Deos
O Microsoft Windows também usa o formato ELF, mas apenas para seu sistema de compatibilidade Windows Subsystem for Linux.
Consolas de jogos
Alguns consoles de jogos também usam ELF:
- PlayStation Portable, PlayStation Vita, PlayStation 2, PlayStation 3, PlayStation 4, PlayStation 5
- GP2X
- Sonho
- GameCube
- Nintendo 64
- Wii.
- Wii U
PowerPC
Outros sistemas (operacionais) rodando em PowerPC que usam ELF:
- AmigaOS 4, o executável ELF substituiu o anterior Extended Hunk Format (EHF) que foi usado em Amigas equipado com cartões de expansão do processador PPC.
- Morphos
- A AROS
- Café OS (O sistema operacional funcionou em Wii U)
Telefones celulares
Alguns sistemas operacionais para celulares e dispositivos móveis usam ELF:
- Symbian OS v9 usa E32 Formato de imagem que é baseado no formato de arquivo ELF;
- Sony Ericsson, por exemplo, o W800i, W610, W300, etc.
- Siemens, as plataformas SGOLD e SGOLD2: da Siemens C65 para S75 e BenQ-Siemens E71/EL71;
- Motorola, por exemplo, o E398, SLVR L7, v360, v3i (e todo o telefone LTE2 que tem o patch aplicado).
- Bada, por exemplo, o Samsung Wave S8500.
- Telefones ou tablets Nokia que executam o Maemo ou o Meego OS, por exemplo, o Nokia N900.
- Android usa ELF .so (objeto compartilhado) bibliotecas para o Java Native Interface. Com o Android Runtime (ART), o padrão desde o Android 5.0 "Lollipop", todas as aplicações são compiladas em binários ELF nativos na instalação.
Alguns telefones podem executar arquivos ELF por meio do uso de um patch que adiciona código de montagem ao firmware principal, que é um recurso conhecido como ELFPack na cultura underground de modding. O formato de arquivo ELF também é usado com o Atmel AVR (8 bits), AVR32 e com arquiteturas de microcontrolador Texas Instruments MSP430. Algumas implementações do Open Firmware também podem carregar arquivos ELF, principalmente a implementação da Apple usada em quase todas as máquinas PowerPC produzidas pela empresa.
Especificações
- Genéricos:
- Aplicação do sistema V Interface binária Edição 4.1 (1997-03-18)
- Atualização do sistema V ABI (Outubro de 2009)
- AMD64:
- Sistema V ABI, AMD64 Suplemento
- Braço:
- ELF para a arquitetura ARM
- IA-32:
- Sistema V ABI, Suplemento do processador de arquitetura Intel386
- IA-64:
- Convenções de Software de Itanium e Guia de Runtime (Setembro de 2000)
- M32R:
- Suplemento M32R ELF ABI Versão 1.2 (2004-08-26)
- MIPS:
- Sistema V ABI, MIPS RISC Processor Supplement
- Documentação MIPS EABI (2003-2006)
- Motorola 6800:
- Motorola 8- e 16- bit Embedded ABI
- PA-RISC:
- Suplemento ELF para PA-RISC Versão 1.43 (6 de outubro de 1997)
- PowerPC:
- Sistema V ABI, Suplemento PPC
- PowerPC Embedded Application Binary Interface 32-Bit Implementação (1995-10-01)
- 64-bit PowerPC ELF Aplicação Binary Interface Suplemento Versão 1.9 (2004)
- RISC-V:
- Especificação RISC-V ELF
- SPARC:
- Sistema V ABI, SPARC Suplemento
- S/390:
- S/390 32bit ELF ABI Suplemento
- Categorias:
- Suplemento do ELF da série 64bit
- Symbian OS 9:
- Formato de arquivo E32Image no Symbian OS 9
O Linux Standard Base (LSB) suplementa algumas das especificações acima para arquiteturas nas quais é especificado. Por exemplo, esse é o caso do System V ABI, AMD64 Supplement.
86aberto
86open foi um projeto para formar consenso sobre um formato de arquivo binário comum para sistemas operacionais Unix e semelhantes a Unix na arquitetura x86 compatível com PC comum, para encorajar os desenvolvedores de software a portar para a arquitetura. A ideia inicial era padronizar um pequeno subconjunto de Spec 1170, um predecessor da Single UNIX Specification, e a GNU C Library (glibc) para permitir que binários não modificados rodassem em sistemas operacionais x86 semelhantes ao Unix. O projeto foi originalmente designado como "Spec 150".
O formato eventualmente escolhido foi o ELF, especificamente a implementação Linux do ELF, depois que se tornou um padrão de fato suportado por todos os fornecedores e sistemas operacionais envolvidos.
O grupo iniciou as discussões por e-mail em 1997 e se reuniu pela primeira vez nos escritórios da Operação Santa Cruz em 22 de agosto de 1997.
O comitê de direção foi Marc Ewing, Dion Johnson, Evan Leibovitch, Bruce Perens, Andrew Roach, Bryan Wayne Sparks e Linus Torvalds. Outras pessoas no projeto foram Keith Bostic, Chuck Cranor, Michael Davidson, Chris G. Demetriou, Ulrich Drepper, Don Dugger, Steve Ginzburg, Jon "maddog" Hall, Ron Holt, Jordan Hubbard, Dave Jensen, Kean Johnston, Andrew Josey, Robert Lipe, Bela Lubkin, Tim Marsland, Greg Page, Ronald Joe Record, Tim Ruckle, Joel Silverstein, Chia-pi Tien e Erik Troan. Os sistemas operacionais e empresas representadas foram BeOS, BSDI, FreeBSD, Intel, Linux, NetBSD, SCO e SunSoft.
O projeto progrediu e, em meados de 1998, a SCO começou a desenvolver lxrun, uma camada de compatibilidade de código aberto capaz de executar binários Linux em OpenServer, UnixWare e Solaris. A SCO anunciou o suporte oficial do lxrun no LinuxWorld em março de 1999. A Sun Microsystems começou a oferecer suporte oficial ao lxrun para Solaris no início de 1999 e, posteriormente, mudou para o suporte integrado do formato binário do Linux por meio do Solaris Containers for Linux Applications.
Com os BSDs suportando binários Linux há muito tempo (através de uma camada de compatibilidade) e os principais fornecedores x86 Unix adicionando suporte para o formato, o projeto decidiu que Linux ELF era o formato escolhido pela indústria e "declara[ d] se dissolveu" em 25 de julho de 1999.
FatELF: binários universais para Linux
FatELF é uma extensão de formato binário ELF que adiciona recursos binários gordos. Destina-se a Linux e outros sistemas operacionais semelhantes ao Unix. Além da abstração da arquitetura da CPU (ordem de bytes, tamanho da palavra, conjunto de instruções da CPU, etc.), existe a vantagem potencial da abstração da plataforma de software, por exemplo, binários que suportam várias versões ABI do kernel. A partir de 2021, o FatELF não foi integrado ao kernel Linux principal.
Contenido relacionado
Amiga 500
Páginas de Servidor Ativas
Serviço de Informação Knowbot