UNIJUÍ – UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UM DRIVE VIRTUAL:
MOUSE E TECLADO
TIAGO MALLMANN ROHDE
Ijuí – RS, 2014
TIAGO MALLMANN ROHDE
DESENVOLVIMENTO DE UM DRIVE VIRTUAL:
MOUSE E TECLADO
Trabalho de Conclusão do Curso de Ciência da Computação da UNIJUÍ – Universidade Regional do Noroeste do Estado do Rio Grande do Sul para obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Me. Marcos Ronaldo Melo Cavalheiro
Ijuí – RS, 2014
TIAGO MALLMANN ROHDE
DESENVOLVIMENTO DE UM DRIVE VIRTUAL:
MOUSE E TECLADO
Trabalho de Conclusão de Curso apresentado ao Curso de Ciência da Computação da UNIJUÍ – Universidade Regional do Noroeste do Estado do Rio Grande do Sul para obtenção do título de Bacharel em Ciência da Computação.
Banca Examinadora:
___________________________________________ Prof. Me. Marcos Ronaldo Melo Cavalheiro (Orientador)
___________________________________________ Prof. Me. Rogério Samuel de Moura Martins
3
“No mundo há quatro animais que
são pequenos, mas muito espertos:
As formigas, que são fracas, mas
ajuntam a sua comida no verão.
Os coelhos selvagens, que também
não são fortes, mas fazem as suas
casas nas pedras. Os gafanhotos,
que não têm rei, mas avançam em
bandos. As lagartixas que
qualquer um pode pegar com a
mão, mas podem ser encontradas
até nos palácios”.
RESUMO
Este trabalho tem por objetivo principal fornecer um automatizador computacional, por meio de um simulador de hardware também conhecido como um drive virtual, para o sistema operacional Windows Seven da Microsoft, sendo este um teclado e um mouse. Primeiramente, o leitor é informado sobre as teorias necessárias para a compreensão do trabalho como um todo como, por exemplo, a diferença entre drive e driver. Logo após, são abordados assuntos pertinentes a sua utilização na atualidade e a seguir são explanados os materiais e métodos necessários para o seu desenvolvimento. Além disso, este trabalho visa proporcionar um framework para programadores, auxiliando-os no desenvolvimento de softwares que requerem esta ferramenta.
ABSTRACT
This paper has the main objective of provide a computational automator using a hardware simulator also known as virtual drive for the Microsoft Windows Seven operating system, which is a keyboard and a mouse drive. Firstly the reader is informed about the required theories for the research as a whole, for instance the difference between drive and driver. Right after, relevant subjects and their use nowadays are discussed and the materials and necessary methods for its developing are explained. Furthermore, this research aims to provide a framework for programmers, assisting them in the developing of software which require this tool.
LISTA DE ABREVIATURAS E SIGLAS
BUG Defeito
CD Compact Disc – Disco Compacto
CPU Central Processing Unit – Unidade Central de Processamento DLL Dynamic Link Library – Biblioteca de Vínculo Dinâmico
DVD Digital Versatile Disc – Disco de Vídeo Digital HD Hard Disk – Disco Rígido
HID Human Interface Device – Dispositivo de Interface Humana
IDE Integrated Development Environment – Ambiente Integrado de Desenvolvimento
IO Input Output – Entrada e Saída
IOCTL Device Input and Output Control – Controle de Entrada e Saída de Dispositivo
IRQL Interrupt Request Level – Nível de Solicitação de Interrupção RAM Random Access Memory – Memória de Acesso Aleatório ROM Read Only Memory – Memória Apenas de Leitura
SO Sistema Operacional
USB Universal Serial Bus – Barramento de Série Universal WDK Windows Driver Kit – Kit de Drivers Windows
LISTA DE TABELAS
8
LISTA DE FIGURAS
SUMÁRIO
INTRODUÇÃO ... 10
1 ASPECTOS GERAIS DE COMPONENTES DE HARDWARE E SOFTWARE . 13 1.1 Device ... 14
1.2 Driver ... 14
1.2.1 Virtual device ... 14
1.2.2 Máquina Virtual ... 15
1.2.2.1 Exemplos de Máquina Virtual ... 16
1.2.3 Dispositivos Físicos Isolados ... 16
1.2.3.1 Drive de CD/DVD ... 16
1.2.3.2 Memória RAM ... 17
2 MATERIAIS E MÉTODOS ... 18
2.1 Computador e Sistema Operacional ... 18
2.2 Linguagem utilizada para o desenvolvimento ... 18
2.3 Ide – Plataforma ... 19
2.4 Extensão ... 19
2.5 Modelagem ... 19
2.5.1 Protocolos ... 21
3 DESENVOLVIMENTO DE UM DRIVE VIRTUAL E SUA UTILIZAÇÃO ... 28
3.1 Inteligência Artificial ... 28
3.2 Desenvolvimento e Testes ... 29
3.2.1 Configurações Técnicas de Comunicação com o Driver ... 33
3.2.2 Economia de Recursos e Aperfeiçoamento do Algoritmo ... 36
3.2.3 Instalação do Dispositivo ... 38
3.2.4 Testes em Softwares com Proteção à Automação ... 40
CONSIDERAÇÕES FINAIS ... 42
INTRODUÇÃO
A existência de um sistema que faça a automatização dos principais periféricos de entrada e saída de forma a prover funções automáticas estritamente humanas não foi encontrada na literatura, existindo apenas softwares que suprem parte desta necessidade. Além disso, a crescente procura por sistemas automatizados e eficazes faz com que seja necessário o desenvolvimento de novos produtos que atendam a essa demanda Sakurada e Miyake (2009, p. 1) descrevem um pouco da importância da utilização de softwares, que fazem o papel de simular alguma atividade. Conforme o conceito dos autores:
A grande variedade de softwares de simulação disponíveis no mercado, alguns específicos para determinados processos, outros de caráter mais generalista, favorecem a aplicação da simulação de uma forma geral. A competição entre as empresas fabricantes de softwares de simulação tem impulsionado o lançamento de “pacotes” cada vez mais poderosos que oferecem novas facilidades tais como ferramentas de suporte ao processo de modelagem, recursos de análise estatística e interfaces gráficas intuitivas (user-friendly).
Por este motivo, buscou-se o desenvolvimento de um drive virtual voltado à programação e automatização de um mouse e um teclado, desenvolvido para funcionar em sistemas operacionais da Microsoft, mais especificadamente o Windows Seven.
Neste trabalho se abordará alguns conceitos fundamentais para a compreensão e aplicabilidade de determinados softwares, tendo como um de seus objetivos demonstrar a necessidade e a usabilidade de tal programa.
A fundamentação teórica é essencial para o desenvolvimento de um simulador virtual e, sendo assim, a conceitualização de hardware e software, será abordada primeiramente para que seja possível embasar o leitor sobre as teorias e conceitos necessários à compreensão do trabalho no geral.
A seguir são expostas as diferenças entre os drives e os drivers que estão presentes nos computadores, bem como a contextualização da utilização deles na área da informática e a importância de utilizar drives virtuais, tanto como economia de recursos e também para a segurança computacional.
Okumura (2008, p. 7) deixa bem claro a importância da utilização de teclados virtuais para a segurança da informação em seu trabalho, dizendo que “esses teclados virtuais têm evoluído, mas ainda nota-se que é possível um atacante explorá-los de forma a capturar informações”.
Mais adiante, a partir do capítulo 3, são abordados aspectos referentes ao desenvolvimento de um drive virtual e explanados as dificuldades encontradas para que o desenvolvimento do software possa existir.
Com isso foi desenvolvida uma ferramenta, ou solução, para desenvolvedores que necessitam controlar a posição do mouse nos seus eixos X e Y, além de que ao movimentá-lo o SO reconhecerá como um hardware e não linhas de código, sendo que o teclado teve o mesmo princípio ao utilizar suas teclas.
Essa ferramenta servirá principalmente para o desenvolvimento de programas que necessitam utilizar a inteligência artificial, pois assim se terá total controle dos periféricos de entrada (teclado e mouse).
Também será descrito quais métodos foram utilizados como, por exemplo, a IDE (Integrated Development Environment – Ambiente Integrado de Desenvolvimento), desenvolvida pela própria Microsoft e a sua extensão WDK (Windows Driver Kit – Kit de Drivers Windows), desenvolvida especialmente para o apoio a desenvolvimento de drivers.
É possível verificar que Okumura (2008, p. 1) nos descreve esses teclados virtuais já existentes como sendo “(...) peças de software que possibilitam a entrada de informações através de um dispositivo de apontamento, como o mouse”, porém o objetivo é a automatização da tarefa e não a substituição de um hardware por outro.
Por este motivo, o objetivo geral deste trabalho é desenvolver um framework para programadores que precisam utilizar os periféricos já mencionados de forma autônoma, podendo também ser considerado como um drive virtual, mais especificamente para um mouse e um teclado, os quais poderão ser utilizados para testes de automatização de atividades ou verificar a segurança de um software que não permite que a manipulação destes dispositivos seja efetuada automaticamente através de softwares.
A implementação destes recursos, sendo teclados e mouses inteligentes, pode trazer benefícios que facilitariam tarefas do dia a dia. A automatização dessas tarefas, que são utilizadas o tempo inteiro, mesmo que sejam na economia de segundos, podem refletir em um ganho de agilidade muito grande após algum tempo de uso.
Além de que o dispositivo virtual serve como base para testes e simulações em aplicativos que utilizam o mouse e o teclado sem a necessidade de compra de um dispositivo físico, fazendo com que seja possível testar aplicações sem alterações no hardware do equipamento e, desta forma, conseguir tanto agilizar processos como economizar dinheiro (TecMundo_Drivevirtual, 2013).
Com este trabalho também poderão ser efetuado o controle do mouse e teclado em softwares que não permitem o este tipo de interação autônoma como, por exemplo, jogos que tentam inibir a utilização de programas que auxiliam jogadores de forma a prejudicar outros jogadores.
Portanto, este trabalho foi dividido em três partes denominadas capítulos 1, 2 e 3, sendo que para entender o capítulo 2, o leitor precisa, obrigatoriamente, estar familiarizado com os conceitos do capítulo 1.
O capítulo 1 aborda os aspectos que englobam o hardware e o software no geral, sendo que este capítulo está descrito de forma coloquial para que o leitor mais inexperiente possa se inteirar do assunto.
No capítulo 2 serão expostos os materiais necessários para o desenvolvimento de um driver, bem como os modelos de implementação disponíveis, sendo eles modo usuário e modo kernel. Além disso, também será descrito o protocolo de comunicação criado para garantir o correto funcionamento do driver.
E, por fim, no capítulo 3 encontram-se as dificuldades no desenvolvimento e testes deste software, sendo exposto como é delicado tratar algumas funções, restrições aos desenvolvedores de drivers, utilização dos protocolos para invocar as requisições, instalação do dispositivo virtual, entre outros assuntos pertinentes ao seu desenvolvimento.
1 ASPECTOS GERAIS DE COMPONENTES DE HARDWARE E SOFTWARE
Neste capítulo serão abordados assuntos pertinentes à parte física e lógica do computador no âmbito geral, expondo os conceitos de hardware, software, drive, driver e drives virtuais, além de que este será o embasamento para o leitor, o que fará com que a sua compreensão deste trabalho seja de melhor proveito.
O hardware do computador é a sua parte física, podendo ser qualquer componente eletrônico de algum tipo de sistema englobando uma infinidade de dispositivos, desde sistemas complexos como um notebook até um celular ou até mesmo um rádio relógio. Tocci e Laskowski (1990, p. 109) descrevem hardware como algo que:
(...) engloba os dispositivos eletrônicos, mecânicos e magnéticos que compõe a parte física do computador. A quantidade de hardware varia bastante, dos pequenos microcomputadores a máquinas de grande porte, mas todos eles têm um ponto em comum: o hardware é inútil sem programas armazenados na memória.
O software são ordens dadas ao hardware, criadas por humanos que e também servem para efetuar uma determinada tarefa internamente podendo ser um cálculo, envio de arquivo, requisição a um servidor ou qualquer outra função utilizada no meio computacional. Tocci e Laskowski (1990, p. 109) definem software como: “O software diz respeito aos programas que comandam todas as atividades do sistema de computação, da inicialização ao encerramento. Todo software pode ser dividido em duas categorias: aplicativos e básicos”.
Sendo assim, existem os softwares aplicativos que são rotinas que executam uma tarefa específica como, por exemplo, jogos, editores de texto, softwares para controles industriais, entre outros. Já os softwares básicos são mais genéricos que os aplicativos, eles dão apoio aos aplicativos. Todos os sistemas operacionais possuem esses softwares básicos dentro do seu núcleo como, por exemplo, os drivers (TOCCI; LASKOWSKI, 1990, p. 109).
A seguir, apresentam-se detalhes sobre o conceito e a utilização desses programas na atualidade, bem como a importância da sua existência e como influenciam diretamente na decisão de investimentos em certas tecnologias.
1.1 Device
O TecMundo (TecMundo_Drive, 2013) define drives como algo relacionado ao hardware propriamente dito, é um conjunto de dispositivos físicos que serve para determinada função como, por exemplo, uma unidade óptica de DVD (Digital Versatile Disc – Disco de Vídeo Digital), o HD (Hard Disk – Disco Rígido), placas off-board, entre outros.
1.2 Driver
A Microsoft (Microsoft_Driver, 2013) afirma que o driver é o software que controla o drive, ou seja, para que a peça física funcione corretamente é preciso instalar o driver correto. Os sistemas operacionais já contêm um pacote de drivers genéricos para que, dessa forma, funcionem as partes básicas de determinado dispositivo.
Um exemplo seria a utilização de dispositivos que tenham como interface o USB (Universal Serial Bus – Barramento de Série Universal), os quais utilizam o protocolo HID (Human Interface Device – Dispositivo de Interface Humana), que nada mais é do que um protocolo padrão para os dispositivos de entrada e saída do computador, que define o número de dados e bits que são possíveis utilizar com determinado hardware (SOUZA; WANG, 2009, p. 25).
Conforme orientação de Souza e Wang (2009, p. 25) “A maioria dos sistemas operacionais reconhecerá dispositivos HID USB padrões, tais como teclados e mouses sem a necessidade de um driver especial”, ou seja, para mouses que contêm o número padrão de teclas (botão direito, esquerdo e scrool) funcionará sem a necessidade de instalação de um driver adicional. Porém, para a utilização de mouses que contêm os botões laterais de avançar e retroceder, ou até alguns modelos que utilizam a tecnologia wireless, existe a necessidade de uma alteração no driver HID padrão do SO, substituindo-o pelo software do fabricante.
1.2.1 Virtual device
O TecMundo (TecMundo_Drivevirtual, 2013) descreve o drive virtual como um software que faz a simulação do dispositivo físico (drive), fazendo com que o SO o
reconheça como sendo uma peça física completa, porém não passa de um programa de computador. O drive virtual tem todas as necessidades do drive real como, por exemplo, o software para controlá-lo, sendo este o driver do drive falso.
Atualmente, existem vários desenvolvedores para alguns tipos de drives virtuais mais buscados como, por exemplo: máquinas virtuais, drive de CD (Compact Disc – Disco Compacto) e DVD (Digital Versatile Disc – Disco de Vídeo Digital), pen-drives e até mesmo a própria memória RAM (Random Access Memory – Memória de Acesso Aleatório) pode ser emulada, porém ainda não existe nenhuma implementação para mouse ou teclado que sirva como um simulador do hardware real. A seguir apresenta-se alguns conceitos e exemplos de virtualização.
1.2.2 Máquina Virtual
A forma mais importante na utilização da virtualização é a simulação de computadores completos dentro do SO. Essa técnica começou a ser utilizada na década de 70 pela Universidade da Califórnia, em San Diego, juntamente com a linguagem UCSD Pascal (FREITAS; NUNES, 2013, p. 40).
Freitas e Nunes (2013, p. 40) definem uma máquina virtual como sendo outra máquina duplicada e isolada da real, ou seja, é um computador simulado que deve ter as mesmas funcionalidades de um equipamento verdadeiro, podendo este ter limitado seu hardware conforme necessidade do usuário.
Para Freitas e Nunes (2013, p. 40) “o usuário que utilizar uma máquina virtual não encontrará diferenças em relação a uma máquina real, com a vantagem de que não há propagação de falhas entre máquinas virtuais e o sistema hospedeiro”. Dessa forma, pode-se perceber que existe uma grande vantagem na utilização dessa técnica, tanto para a segurança de arquivos quanto para testes de softwares ainda em desenvolvimento.
Ao simular um SO tem-se na realidade, um arquivo único de extensão do software que se utiliza, onde contém todas as informações que foram aderidas ao equipamento, como quantidade de memória RAM, quantos núcleos da CPU (Central Processing Unit – Unidade Central de Processamento) utilizará, HD e os arquivos que estão contidos no disco rígido virtual.
1.2.2.1 Exemplos de Máquina Virtual
O VmWare (VmWare, 2013) é um software com o intuito de prover a virtualização de máquinas e consequentemente sistemas operacionais completos onde é possível instalar o Windows dentro do Linux ou vice-versa, podendo até mesmo ter o mesmo SO um dentro do outro.
O fabricante (VmWare_Produto, 2013) garante que a utilização de seu produto para virtualização em desktops é uma das melhores soluções, pois além da simplificação da instalação permite o acesso remoto ao sistema virtual com segurança, podendo este acesso ser por computador, iPad ou até mesmo pelo sistema Android.
A desenvolvedora Microsoft também disponibiliza um virtualizador. Além disso, tem disponível para download o arquivo de configuração de vários sistemas já instalados e configurados prontos para a utilização, precisando apenas fazer o download do arquivo de configuração. Essas imagens são para testes e verificações quanto ao comportamento e estabilidade dos produtos oferecidos pela empresa (Microsoft_Virtualizador, 2013).
1.2.3 Dispositivos Físicos Isolados
Além da virtualização de dispositivos complexos, como um computador completo, também é necessário virtualizar dispositivos menores, evitando assim a aquisição de peças físicas, o que pode gerar custos indesejados. Abaixo apresenta-se conceitos e explicações sobre algumas soluções de virtualização.
1.2.3.1 Drive de CD/DVD
Um bom exemplo é a utilização do software Daemon Tools (DaemonTools, 2013) que virtualiza um dispositivo físico de leitura de CDs e DVDs, com isso não é necessário gravar as imagens de programas armazenadas no disco rígido para utilizá-las através dos CDs, podendo apenas emulá-utilizá-las.
De outra parte, tem-se ainda vários programas que necessitam do DVD dentro da leitora para serem executados, dessa forma, criando o dispositivo falso não existe a necessidade de colocar o DVD toda vez que utilizar tal software.
A Microsoft também possui um software para esta função, mas somente funciona para versões do SO Windows XP até Windows 7. Já nas versões posteriores como, por exemplo, o Windows 8 este tipo de software já vem embutido dentro do SO não necessitando a instalação posterior de algum programa (Microsoft_CD-ROM, 2013).
1.2.3.2 Memória RAM
Para garantir que o SO terá memória suficiente para executar as tarefas normalmente, ele emula uma quantidade de memória física para que se houver o esgotamento da memória RAM verdadeira, seja possível alocar mais espaço em outro dispositivo. Cada desenvolvedor dá um nome diferente a esta área virtualizada, porém todos têm o mesmo fim.
A Microsoft determina que essa área seja chamada de arquivo de paginação, que é um arquivo com um tamanho especificado pelo SO, o qual pode ser alterado pelo próprio usuário do computador, desde que ele tenha direitos administrativos. Este espaço “extra” fica localizado no disco rígido, mais especificamente na raiz da instalação do SO (Microsoft_RAM, 2013).
Assim sendo, para sistemas de distribuição livre como, por exemplo, o Linux, é necessário que se tenha uma partição totalmente voltada para a virtualização, este espaço é denominado Swap que é criado na hora da instalação do SO não podendo ser alterado pelo usuário durante a execução do sistema (HIRATA, 2002, p. 57).
Já com um conhecimento mais abrangente sobre os hardwares e softwares, no próximo capítulo será demostrado sobre as ferramentas utilizadas para o desenvolvimento do presente trabalho, bem como especificações técnicas para a sua utilização.
2 MATERIAIS E MÉTODOS
Neste capítulo tratar-se-á sobre as ferramentas envolvidas na criação do presente trabalho, bem como o desenvolvimento de um protocolo de comunicação para evitar possíveis erros.
2.1 Computador e Sistema Operacional
O SO a ser utilizado para o desenvolvimento e para a implementação será o Windows Seven, pois a grande maioria dos computadores utiliza os sistemas da Microsoft e já existem vários pacotes de correção de BUGs (defeitos) para este SO em específico (Netmarketshare, 2013). Além disso, existe uma portabilidade entre o sistema a ser desenvolvido e os sistemas que serão disponibilizados futuramente pela empresa.
Também será necessária a utilização de dois computadores, nos quais devem ter instalados o SO utilizado, bem como todos os softwares básicos para o seu funcionamento, sendo que um dos equipamentos será para o desenvolvimento do drive virtual e seu driver e o outro servirá para testes de funcionamento e estabilidade do sistema.
2.2 Linguagem utilizada para o desenvolvimento
A Microsoft orienta utilizar apenas a linguagem de programação C para o desenvolvimento de um driver, porém conforme nos afirma a desenvolvedora do SO também pode-se utilizar C++ com algumas restrições. É definido o C como linguagem de desenvolvimento pelo seu suporte nativo ao sistema (Microsoft_C/C++, 2013).
Além disso, a linguagem em questão é um intermediário entre o Assembly e as outras linguagens de alto nível, fazendo com que além de uma ferramenta tão eficiente quanto às outras disponíveis como, por exemplo, Java e Pascal, seja possível obter acessos exclusivos ao hardware. Também é genérica possibilitando o desenvolvimento de programas especiais para a utilização em computadores genéricos, ou seja, independentemente do hardware utilizado, o software desenvolvido nessa linguagem deve funcionar corretamente para o SO desenvolvido (PEREIRA, 2007, p. 16-17).
2.3 Ide – Plataforma
Será utilizado o Visual Studio 2013, o qual possui suporte para a linguagem de programação, além de que o software é desenvolvido pela mesma empresa do SO, fazendo com que dessa forma não ocorram incompatibilidades ou anomalias no desenvolvimento do software. Além disso, a Microsoft define que o desenvolvimento nessa plataforma é essencial para o correto funcionamento do driver (Microsoft_Visual_Studio, 2013).
2.4 Extensão
Para o desenvolvimento de drivers, a Microsoft disponibiliza gratuitamente o WDK, o qual é integrado ao visual Studio, atualmente funcionando nas versões do WDK 8.1 compatível com o Visual Studio 2013. Salienta-se que o desenvolvimento desse tipo de programa não seja efetuado em versões anteriores e nem posteriores do Visual Studio, pois mesmo compilado, o seu funcionamento pode conter erros e causar a instabilidade do sistema (Microsoft_WDK, 2014).
2.5 Modelagem
Para o desenvolvimento do drive virtual necessita-se de um driver, o qual fará todo o trabalho desde “mentir” para o SO até receber as instruções do usuário e executá-las conforme determinado em seu código. Para que isto seja possível serão utilizadas as ferramentas já mencionadas (linguagem de programação, IDE, WDK e SO).
A programação deste driver pode ser feita através de algumas diretivas de acesso denominadas modo kernel e modo usuário. A diferença delas está na utilização de rotinas e na declaração de acesso a partes específicas do SO, as quais estão descritas nos parágrafos seguintes (Microsoft_Kernel_Usuario, 2013).
Programação em modo usuário é quando a aplicação tem acesso apenas a sua área de memória, bem como somente a suas rotinas. A maior vantagem da utilização deste modo é que a programação não é tão delicada e a probabilidade de que irá funcionar nas versões posteriores do SO da Microsoft é quase de 100%, porém
não há garantias de que será possível a sua portabilidade (Microsoft_Portabilidade, 2013).
Já, o modo kernel, tem-se acesso total a qualquer parte da memória física (memória RAM) ou rotinas de bibliotecas de baixo nível fazendo com que a programação se torne mais delicada, pois qualquer alteração na parte errada da memória faz com que se tenha uma instabilidade muito grande no sistema fazendo com que se tenha a “tela azul”, ou seja, acessando a parte errada da memória ou executando uma tarefa não permitida pode-se ter um travamento do sistema e, consequentemente, a perda de dados não salvos na memória ROM (Read Only Memory – Memória Apenas de Leitura).
Desta forma, optou-se pelo desenvolvimento deste estudo baseado no modo kernel, para que possa haver a liberdade de substituição do driver nativo instalado no Windows para o driver desenvolvido neste trabalho.
Outro requisito que precisou ser definido foi qual modelo de hardware será utilizado, sendo que atualmente existem duas possibilidades, ou seja, pode-se definir que o drive virtual utilizará protocolos HID, que são protocolos padrões para teclados com interface USB ou protocolos PS2.
Uma vez que os notebooks possuem suporte nativo para entradas PS2, ou seja, o teclado e o mouse pad do notebook são PS2, por este motivo foi adotado este padrão no desenvolvimento do driver, além disso, este padrão, foi criado em 1987 e possui especificações mais detalhadas sobre o funcionamento do hardware (CAPELLI et al., 2013, p. 20).
É preciso ter cautela no quesito da programação, pois mesmo tendo a definição detalhada do hardware ainda é necessário conhecer internamente o tratamento das informações que existem nas rotinas disponíveis pela Microsoft, pois “os drivers podem corromper a integridade de todo o sistema, eles podem ter erros que não ocorrem sempre, mas em algumas circunstâncias raras” (Codeproject, 2014). Notou-se que existe uma vasta documentação no quesito de desenvolvimento de drivers, porém toda ela complexa, exigindo muita leitura e conceitualização por parte dos desenvolvedores, sendo assim, nenhum material objetivo sobre as funções de interrupções dos drivers foi encontrado junto à fornecedora do WDK 8.1 de forma oficial.
Todavia, os documentos oficiais sobre a utilização dos métodos (disponível em: http://msdn.microsoft.com/pt-br/windows/hardware/ff960953.aspx) foram de
grande ajuda para que fosse possível começar a construção sobre a escrita de drivers desde um simples “olá mundo” até a criação completa de um drive virtual para dispositivos de entrada.
Conforme já foi dito, as explicações oficiais sobre a utilização de métodos necessários para a criação deste trabalho são muito complexas e por muitas vezes desnecessárias. Assim, buscou-se alternativas para a criação do conhecimento necessário para a conclusão do driver em si.
Diante da conclusão de que o site oficial é escasso quando se trata de objetividade e esclarecimentos, em segundo lugar e de forma bem mais acessível, buscou-se entendimento e compreensão na comunidade de desenvolvimento da Microsoft (disponível em: http://msdn.microsoft.com/en-US/windows/desktop/ aa904945.aspx).
Após estudos efetuados nestas fontes de informações, verificou-se a necessidade da criação de um protocolo de comunicação entre a aplicação desenvolvida pelo programador e o drive virtual criado neste trabalho. A seguir são apresentadas as explicações técnicas dos protocolos de comunicações.
2.5.1 Protocolos
Para que a execução do driver ocorra sem anomalias e de forma segura as regras abaixo devem ser seguidas pelo usuário de forma criteriosa tendo como princípio a criação e exclusão de arquivos de comunicação. Desta forma, é preciso criar os arquivos nesta ordem: executar.txt, ordens.txt e, por fim, o arquivo de resposta.txt será criado pelo driver.
Os arquivos do teclado terão um “T” na frente da nomenclatura e os arquivos do mouse terão um “M”, ou seja, os arquivos de configuração do teclado são Texecutar.txt, Tordens.txt e Tresposta.txt e os do mouse são Mexecutar.txt, Mordens.txt e Mresposta.txt.
As exclusões dos arquivos devem ser impreterivelmente nesta sequência: após o arquivo de resposta (resposta.txt) ser gerado deve-se excluir o ordens.txt, logo após o executar.txt e, por fim, o resposta.txt, lembrando que para o teclado adiciona-se T e para o mouadiciona-se M.
Caso a exclusão não seja nesta sequência existe uma possibilidade muito grande de uma reexecução dos parâmetros anteriores ou de um travamento no SO,
ou seja, se o arquivo resposta.txt for excluído antes do ordens.txt pode ocorrer uma “tela azul”.
Para o teclado utilizar-se-á quatro arquivos. São eles: Teclado.config, Texecutar.txt, Tordens.txt e Tresposta.txt, os quais têm parâmetros diferenciados, o arquivo Teclado.config será tratado no capítulo 3.
O arquivo Texecutar.txt é responsável por enviar as solicitações de simulação de escrita para o driver, e deve conter no máximo 104 caracteres, sendo eles descritos da seguinte forma:
O primeiro caractere define a função que o driver deve executar, podendo esta ser para escrever uma lista de caracteres (irá escrever uma frase), escrever apenas um caractere e caractere especial.
Cada função descrita acima será tratada de forma diferente. A seguir explica-se como montar o bloco de instrução para cada situação:
Execução de uma lista de caracteres: como já foi dito o primeiro caractere
define qual é a função, neste caso o primeiro caractere deve ser 0 (zero), o segundo e o terceiro deve ser o número de caracteres que o drive deve executar, caso o número seja menor que dez deve-se adicionar 0 na frente do algarismo numérico.
Um exemplo é a seguinte frase “envio de lista de caracteres”, desta forma, o arquivo Texecutar.txt será escrito da seguinte forma “028envio de lista de caracteres”, um outro exemplo seria esta outra frase “tccrohde” onde o arquivo Texecutar.txt será escrito da seguinte forma “008tccrohde”.
Lembra-se que para uma frase maior ou igual a dez elementos não há necessidade de colocar um 0 na frente da lista, porém para cadeias de caracteres menores é obrigatório que a estrutura receba um 0 na frente da quantidade de elementos.
Outro quesito importante é que para símbolos unidos precisa-se separá-los antes de solicitar a execução para o drive. Por exemplo: “Apresentação”, deve ser escrito da seguinte forma “013Apresentaç~ao”, ou ainda, se o desejo é escrever “é É â  ã Ô deve ser escrito da seguinte forma “017´e ´E ^a ^A ~a ~A”.
Assim, tem-se os três primeiros caracteres que definem a função e a quantidade de elementos e, desta forma, pode-se perceber que se tem somente dois dígitos para quantidade de elementos, podendo enviar no máximo cadeias de 99 caracteres, lembrando que o espaço também é considerado um caractere.
Escreve apenas um caractere: nesta função, assim como na descrita
anteriormente, o primeiro caractere será o que indica a função, neste caso deve ser definido 1 para o primeiro caractere e em seguida qual deles deve ser escrito pelo drive.
Como exemplo pode ser usada a necessidade da inserção do caractere “a”, desta forma, o arquivo Texecutar.txt será escrito da seguinte forma “1a”; para escrever “b” o arquivo será escrito “1b”, para “c” ficaria “1c” e assim sucessivamente.
Escrever caractere especial: caracteres especiais são aqueles que não é
possível determinar através de um símbolo, pois todos os símbolos possíveis já foram utilizados. Pode-se ter vários caracteres especiais como, por exemplo, enter, tab, seta para cima, baixo, direita, esquerda, pgup, pgdown, enfim várias funções especiais.
Para que fosse possível a execução deste tipo de tecla foi criada uma tabela (Tabela 1), definida como “Mapa de código de caracteres especiais”, onde tem-se a descrição da tecla e o código referente à sua execução.
Tabela 1: Mapa de código de caracteres especiais
Tecla Código da instrução
Esc 00 F1 01 F2 02 F3 03 F4 04 F5 05 F6 06 F7 07 F8 08 F9 09 F10 10 F11 11 F12 12 Shift esquerda 13 Shift direita 14 Enter 15 End 16
Back space – apagar 17
Alt 18
Tab 19
NunLK 20
PgUp 22
PgDown 23
Insert 24
Del 25
Windows 26
Seta para cima 27
Seta para baixo 28
Seta para direita 29
Seta para esquerda 30
Ctrl 31
BtDireito Mouse – Aplicativo 32
Alt GR 33
Pause break 34
Print Scrn 35
Break 36
Fonte: Autor.
Desta forma, tem-se o primeiro caractere definido como “2” para que esta função seja invocada, e logo após o código do caractere especial. Por exemplo, para a necessidade de executar um “enter” em alguma aplicação, necessariamente deve-se escrever o Texecutar.txt da deve-seguinte forma “215”, 2 pela função caractere especial e 15 pela definição do enter.
Para executar uma função que seu código seja definido menor que dez é necessário, impreterivelmente, colocar um 0 entre o código da função e a função propriamente dita, ou seja, se quiser chamar a tecla “f1” cujo o código é 01, o arquivo Texecutar.txt deve ser escrito da seguinte forma “201”.
Já o arquivo Tordens.txt é utilizado como variável de execução, sendo assim, depois de escrito o arquivo Texecutar.txt, que contém as ordens de escrita para o driver do teclado, deve-se criar o Tordens.txt, sendo ele escrito dessa forma “1\0”.
Salienta-se ainda que o arquivo Tordens.txt deve ser escrito com um “\0” após o “1”, não sendo confundido com o \0 que define o fim de arquivo. Caso o arquivo escrito com a nomenclatura não atenda a estes requisitos o drive poderá se comportar de forma anormal.
E, por fim, tem-se o arquivo Tresposta.txt que define a resposta do driver em relação à solicitação da execução de alguma das funções descritas acima. Este arquivo receberá “Resposta 0” caso o driver tenha executado corretamente a
solicitação e se houver algum erro na execução do algoritmo este arquivo conterá “Resposta 1”.
Para o mouse utilizar-se-á outros quatro arquivos, sendo eles: Mouse.config, Mexecutar.txt, Mordens.txt e Mresposta.txt, sendo que o arquivo Mouse.config também será abordado no capítulo 3, juntamente com o Teclado.config.
O arquivo Mexecutar.txt define qual função o drive deve executar. Estas funções são definidas de forma similar as do teclado, conforme a explanação a seguir sobre a sua utilização.
Clique e desclique esquerdo: esta função executa um clique com o botão
esquerdo do mouse e já efetua um “desclique”, para utilizá-la o arquivo Mexecutar.txt deve conter o seguinte conteúdo “01”.
Clique e desclique direito: esta função executa um clique com o botão direito
do mouse e já efetua um “desclique”, para utilizá-la o arquivo Mexecutar.txt deve conter o seguinte conteúdo “11”.
Movimento absoluto do mouse: esta função executa um movimento do
mouse para o ponto absoluto na tela, sendo esta a mais complexa das funções do driver, pois os parâmetros devem ser tratados antes da sua simples gravação em um arquivo de texto. As coordenadas tanto do X quanto do Y devem necessariamente serem representadas num valor correspondente a 0 para o canto superior esquerdo e 65536 para o canto inferior direito.
O cálculo para converter as coordenadas reais para as coordenadas virtuais pode ser efetuado de diversas formas. Como este trabalho criou uma classe Java para a execução das solicitações será demonstrado abaixo como esta implementação é feita em Java:
pontoX = Math.round((x * 65536) / xResolucao)+1:
- pontoX: é a variável que irá receber o valor do X convertido para os parâmetros exigentes;
- Math.round: método Java para efetuar arredondamentos;
- x: valor do local do X para onde o mouse deverá se deslocar, levando em consideração a resolução virtual;
- xResolucao: valor da resolução da tela para o X (horizontal).
Este mesmo cálculo, apresentado acima, pode ser utilizado para converter o valor do Y, levando em consideração que as variáveis acima mencionadas foram
usadas para o X, para o Y deve ser utilizado as variáveis do Y. Sendo assim, o arquivo Mexecutar.txt terá obrigatoriamente os seus parâmetros da seguinte maneira:
- Primeiro caractere define-se 2;
- Os próximos cinco caracteres definem o X já convertido, sendo que se o número não ocupar os cinco caracteres deve-se adicionar zeros na frente do valor para que todos os caracteres sejam preenchidos;
- Ao final da declaração do valor de X deve-se declarar os valores de Y já convertido, sendo este também composto por cinco caracteres e, caso não sejam usados todos eles deve-se adicionar zeros na frente do valor real; - Por fim adiciona-se o número nove para garantir a execução.
Desta forma, para mover o mouse para um ponto absoluto onde X recebe o valor de 500 e Y recebe o valor de 300 em uma resolução 1366X768, o arquivo será escrito da seguinte maneira “223989256019”.
Por outro lado para valores menores como, por exemplo, 10 para X e 20 para Y não se pode esquecer de adicionar os zeros na frente do valor absoluto, sendo assim o arquivo será escrito da seguinte maneira “200480017079”.
Movimento relativo do mouse: esta função executa um movimento relativo
ao atual, ou seja, moverá o cursor X pixels na horizontal e Y pixels na vertical em relação à posição atual do mouse. Para que esta definição possa ocorrer deve-se definir o conteúdo do Mexecutar.txt da seguinte maneira:
- Primeiro caractere define-se 3;
- Os próximos cinco caracteres definem o X, sendo que se o número não ocupar os cinco caracteres deve-se adicionar zeros na frente do valor para que todos os caracteres sejam preenchidos;
- Ao final da declaração do valor de X deve-se declarar os valores de Y, sendo este também composto por cinco caracteres e caso não sejam usados todos eles deve-se adicionar zeros na frente do valor real;
- Por fim adiciona-se o número nove para garantir a execução.
Desta forma, tomemos como exemplo o seguinte cenário: deve ser movido o cursor do mouse 33 pixels para direita e 40 pixels para baixo da posição atual do mouse, então o arquivo Texecutar.txt deve ser escrito da seguinte forma “300033000409”.
No entanto se tiver algum dos números negativos deve-se alterar o primeiro algarismo do seu valor determinante de 0 para 1. Dessa forma, se for necessário
mover 10 pixels para a esquerda e 5 para cima o arquivo será escrito dessa forma “310010100059”.
Pressionar botão esquerdo: se necessário apenas efetuar o pressionamento do botão esquerdo pode-se utilizar a função “41” com o fim de arquivo determinado por \0 na escrita do arquivo Texecutar.txt.
Soltar botão esquerdo: deve-se tomar cuidado ao utilizar esta função, pois
ela só poderá ser usada caso a função acima tenha sido previamente invocada. Sendo assim, pode-se utilizá-la para liberar o botão esquerdo, e o Texecutar.txt deve ser escrito da seguinte forma “51” com o \0 como fim de arquivo.
Pressionar botão direito: se necessário apenas efetuar o pressionamento
do botão direito pode-se utilizar a função “61” com o fim de arquivo determinado por \0 na escrita do arquivo Texecutar.txt.
Soltar botão direito: deve-se tomar cuidado ao utilizar esta função, pois ela
só poderá ser usada caso a função acima tenha sido previamente invocada. Sendo assim, pode-se utilizá-la para liberar o botão esquerdo, e o Texecutar.txt deve ser escrito da seguinte forma “71” com o \0 como fim de arquivo.
O Mordens.txt funciona da mesma forma que o Tordens.txt, ou seja, este arquivo será criado quando houver a necessidade de interrupção do sistema após a criação do Mexecutar.txt. E o arquivo Mresposta.txt é o arquivo de resposta do driver do mouse, sendo que se conter “Resposta 0” significa que os comandos foram executados e se conter “Resposta 1” é por que ocorreu algum erro.
A partir deste ponto, considera-se que o leitor possui conhecimento técnico referente aos protocolos de comunicação utilizados no drive virtual. No próximo capítulo será portanto sobre o desenvolvimento do drive e do driver e as suas complicações na hora de sua chamada, além disso, será abordado como deve-se utilizar dos protocolos já mencionados e onde esses arquivos serão gravados.
3 DESENVOLVIMENTO DE UM DRIVE VIRTUAL E SUA UTILIZAÇÃO
Neste capítulo será abordado sobre o desenvolvimento em si deste trabalho. Primeiro sobre a importância da automatização de periféricos computacionais; e, logo após, rapidamente, sobre a sua utilização na inteligência artificial.
Em seguida será tratado sobre o desenvolvimento e os testes efetuados na plataforma, os quais abrangem as configurações dos dispositivos, economia de recursos, forma de instalação e, por fim, os testes efetuados nos softwares de terceiros.
A automatização de periféricos computacionais, através de simuladores, já vem sendo desenvolvida há algum tempo, desde então surgiram softwares capazes de realizarem tarefas pré-programadas como, por exemplo, Mouse Recorder pro e Auto Hotkey (Baixaki_Mouse, 2013; Autohotkey, 2013).
Esses programas são apenas softwares que têm uma rotina determinada, onde é gravado um movimento ou clique e este fica se repetindo pelas vezes determinadas no programa, o problema é que é apenas um software pode ser detectado como tal por programas com proteção contra automatização de tarefas manuais ou ainda não será possível criar algoritmos complexos para sua execução, apenas será possível determinar as teclas e cliques em determinados momentos.
Com a utilização do dispositivo virtual pode-se descartar o movimento determinado e utilizar rotinas de código, juntamente com a inteligência artificial, que determinaria qual caminho que o mouse ou o teclado deverão tomar, fazendo assim a automatização de alguma função manual.
3.1 Inteligência Artificial
A utilização da inteligência artificial para automatizações manuais começou a ser utilizada em 1982 pela empresa Digital Equipament Corporation, a qual lucrou mais de 40 milhões de dólares apenas automatizando seus sistemas internos de computadores (GOLDSCHMIDT, 2010, p. 14).
Com isso, pode-se ter uma noção de quão importante é a automatização de tarefas manuais, mesmo que sejam pequenos movimentos do ponteiro do mouse, bem como teclas digitadas pelo teclado, criando até mesmo atalhos no sistema.
Existem subtermos dentro de inteligência artificial, ou inteligência computacional, dentre eles o aprendizado de máquina, onde é possível executar comandos manualmente e com o tempo o algoritmo vai compreendendo qual tarefa deve executar para cada situação, fazendo com que o computador aprenda a tarefa automaticamente (GOLDSCHMIDT, 2010, p. 36).
3.2 Desenvolvimento e Testes
Todo o trabalho foi baseado em dois modelos disponibilizados pela Microsoft, sendo que um modelo é utilizado para o embasamento, bem como o conhecimento da estrutura interna do driver do teclado e o outro para o desenvolvimento do mouse (Microsoft_Exemplo, 2014).
A partir deste ponto foi possível averiguar as necessidades de comunicação para com o SO de forma bastante técnica, sendo que esta programação é de mais baixo nível do que as linguagens comuns. Um exemplo para comparar o quão complexa é a comunicação entre o driver e o SO pode ser analisada em alguns códigos descritos abaixo.
1. SetCursorPos(X,Y) (Microsoft_Cursor, 2014);
2. FindWindow(String^ lpClassName, String^ lpWindowName) (Microsoft_Kb, 2014);
3. (*(PSERVICE_CALLBACK_ROUTINE)pDevExt->cdUpperConnectData. ClassService)(pDevExt->cdUpperConnectData.ClassDeviceObject, Input DataStart, InputDataEnd, InputDataConsumed) (Microsoft_Mouse, 2014); 4. (*(PSERVICE_CALLBACK_ROUTINE)devExt->UpperConnectData.Class Service)(devExt->UpperConnectData.ClassDeviceObject,InputDataStart, InputDataEnd,InputDataConsumed) (Microsoft_Exemplo, 2014).
Em primeiro lugar tem-se a definição de um movimento simples do mouse na linguagem C++, sendo preciso apenas incluir o cabeçalho WinUser.h que dará acesso a este tipo de chamada, ou seja, para mover o mouse para as coordenadas x = 300 e y = 700 em um software comum apenas é preciso usar a função SetCursorPos (300, 700) em seu bloco de código.
Já em segundo lugar tem-se a manipulação de teclas que são aceitas em strings em um bloco de código C++, lembrando que para C esta função não existe,
precisa usar um import para biblioteca user32 e inserir as strings para determinada janela.
Porém, quando se trata de um nível de programação mais baixo que precisa conversar diretamente com o SO sem a ajuda do kernel, os comandos são muito mais complexos. O terceiro código é um serviço de rotina que é criado por uma interrupção direta no sistema, o que causa um congelamento atual e executa os argumentos passados pela função. Esta função utilizada para o movimento do mouse tem quatro argumentos, sendo eles descritos abaixo:
1. (*(PSERVICE_CALLBACK_ROUTINE)pDevExt->cdUpperConnectData. ClassService)(pDevExt->cdUpperConnectData.ClassDeviceObject): este comando passa como argumento à classe do objeto em si, ou seja, ela envia o seu identificador de hardware que no caso deste é o {4D36E96F-E325-11CE-BFC1-08002BE10318};
2. InputDataStart: é uma estrutura dos atributos que envolvem o mouse, ela é composta por nove variáveis (Microsoft_Mouse_Struct, 2014). Neste argumento, deve ser passado para função o primeiro pacote que vem do hardware para o driver;
3. InputDataEnd: tem a mesma estrutura descrita acima, porém ao invés de passar o primeiro pacote, passará o último pacote lido no buffer de entrada do hardware;
4. InputDataConsumed: é o número de pacotes que devem ser tratados pela função (Microsoft_Mouse, 2014).
Para o teclado tem-se outras estruturas, diferentes das citadas acima, conforme os argumentos descritos abaixo:
1. (*(PSERVICE_CALLBACK_ROUTINE)pDevExt->cdUpperConnectData. ClassService)(pDevExt->cdUpperConnectData.ClassDeviceObject): este comando passa como argumento à classe do objeto em si, ou seja, ela envia o seu identificador de hardware que no caso deste é o {4D36E96B-E325-11CE-BFC1-08002BE10318};
2. InputDataStart: é uma estrutura dos atributos que envolvem o teclado, ela é composta por cinco variáveis (Microsoft_Teclado_Struct, 2014). Neste argumento, deve ser passado para função o primeiro pacote que vem do hardware para o driver;
3. InputDataEnd: tem a mesma estrutura descrita acima, porém ao invés de passar o primeiro pacote, passará o último pacote lido no buffer de entrada do hardware;
4. InputDataConsumed: é o número de pacotes que devem ser tratados pela função (Microsoft_Mouse, 2014).
Devido à complexidade deste tipo de instrução, obviamente que é preciso ter um feedback das instruções enviadas pelo driver, desta forma, ousa-se afirmar que a ferramenta mais importante para a depuração e testes de funcionamento é o DebugView.
Este software que é desenvolvido pela Microsoft, pode ser definido como “um aplicativo que permite que você monitore a saída de depuração em seu sistema local”, ou seja, se não tiver uma quebra de sistema pode-se expor valores de variáveis e/ou mensagens na tela referente à execução do driver (Microsoft_Debug, 2014).
Para exibir qualquer coisa para depuração do driver pode-se facilmente exibi-las utilizando as funções Kdprint ou Dbgprint, dependendo da circunstância. Salienta-se ainda que nem Salienta-sempre poderá Salienta-ser utilizado Kdprint, da mesma forma nem Salienta-sempre poderá ser utilizado Dbgprint, porém se uma função não é aceita a outra funcionará corretamente (Microsoft_Kdprint, 2014; Microsoft_Dbgprint, 2014).
Todavia, se houver uma quebra de sistema, ou seja, se tiver uma “tela azul”, esta ferramenta ajudará somente até a invocação da rotina, ou função que gerou o congelamento do SO e logo em seguida o computador será reiniciado não podendo mais exibir as informações pertinentes à depuração do algoritmo.
Por exemplo, a utilização de uma função que grava algum tipo de arquivo como um arquivo de texto que contenha informações relevantes para o bom funcionamento do sistema, levando em consideração mais especificamente a função RtlStringCbPrintfA.
Se for utilizada de forma a não tratar a sua expressão como um todo, conforme explicado mais adiante, com certeza, irá ocorrer um travamento do sistema e obrigatoriamente a perda de dados não salvos na memória ROM e, possivelmente, uma agressão ao hardware do sistema, podendo até mesmo danificá-lo (Microsoft_Texto, 2014).
Esta função deve ser utilizada conforme é definida na documentação oficial da Microsoft, em um IRQL (Interrupt Request Level – Nível de Solicitação de Interrupção) denominado PASSIVE_LEVEL, porém a execução e o tratamento de
todas as funções dentro do escopo do driver é em DISPATCH_LEVEL, fazendo com que se está chamada seja feita dentro do driver de forma convencional ocorra uma “tela azul” (Microsoft_Texto, 2014).
Entretanto, para poder utilizar esta e outras funções é possível invocar a função KeRaiseIrql que faz a alteração no nível de interrupção que pode ser utilizada pelo driver. Este tipo de solicitação só pode ser efetuado para aumentar o nível e, consequentemente, aumentar o acesso e as responsabilidades do programador (Microsoft_KeRaiseIrql, 2014).
Verificando que o PASSIVE_LEVEL é considerado nível 0, ou seja, quase sem acesso às funções delicadas, porém sem o risco de “mexer onde não deve” e o DISPATCH_LEVEL é nível 2, ou seja, acesso irrestrito a endereços de memória e quase todo tipo de funções, a utilização desta forma se torna mais complexa, não é possível a alteração do DISPATCH_LEVEL para o PASSIVE_LEVEL.
Para gravar algum arquivo de texto trabalhando em nível 2 é necessário que o driver desenvolvido converse diretamente com a controladora do dispositivo de armazenamento, isso faz com que funções do tipo RtlStringCbPrintfA se tornem restritas e a utilização do KeRaiseIrql inútil.
Desta forma, é bom salientar que caso for utilizada a função KeRaiseIrql para diminuição do nível de IRQL, ou seja, se usada esta função para alterar o trabalho do driver de DISPATCH_LEVEL para PASSIVE_LEVEL haverá sem dúvidas uma “tela azul” e, consequentemente, uma agressão ao sistema físico e a perda de dados da memória ROM.
Podem ser criadas threads, que são executadas em paralelo ao driver propriamente dito, mas que tenham acesso às variáveis globais e definir o IRQL destas threads no momento em que são instanciadas.
O escopo do driver nada mais é do que a instanciação de uma thread que tem seu nível de atuação definido como 0, ou seja, o drive virtual será controlado por uma thread do driver real que tem acesso PASSIVE_LEVEL.
Reitera-se que o desenvolvimento do driver baseado em threads é muito mais delicado, pois “o uso de threads não é paralelizado pelo Sistema Operacional e sim pelo programador”, fazendo com que o desenvolvedor do driver precise ter ciência de tudo que está acontecendo e garanta que não haverá conflito entre as threads criadas (ROHDE, 2012, p. 137).
Contudo, não se pode executar a função mais importante do driver nesta thread devido ao fato de que PSERVICE_CALLBACK_ROUTINE não pode ser invocado em PASSIVE_LEVEL, porém pode ser usada a função KeRaiseIrql e aumentar o nível de instrução para o que for necessário e após executar os comandos necessários efetuar o retorno ao nível original da thread através do KeLowerIrql. (Microsoft_KeRaiseIrql, 2014).
Depois de desenvolvidos vários testes de estabilidade, testado as entradas e saídas de comandos manualmente e exaustivamente os drivers desenvolvidos neste trabalho foram submetidos a testes pela ferramenta “verifier”, a qual está disponível na família Microsoft a partir do SO Windows Vista.
Esta ferramenta faz vários testes em drivers em desenvolvimento. Para tal, o código fonte é submetido a testes juntamente com o arquivo já compilado. Ao utilizá-la através da linha de comando pode-se obter respostas às seguintes verificações (Microsoft_Verifier, 2014):
- Verificação de pool especial; - Força a verificação de IRQL; - Simulação de recursos baixo; - Rastreamento de pool;
- Verificação de E/S; - Detecção de bloqueio;
- Verificação de E/S reforçada; - Verificação DMA.
Ao utilizar esta ferramenta foi possível verificar que o driver que emula o drive virtual não contém erro, porém, conforme já dito, existe a possibilidade do driver encontrar um conflito durante a sua utilização e acabar corrompendo o kernel instanciado e, consequentemente, ter-se-á uma quebra de sistema (Codeproject, 2014).
3.2.1 Configurações Técnicas de Comunicação com o Driver
Para que a comunicação com o driver possa ser efetuada existem alguns métodos disponíveis pela Microsoft, os quais serão abordados e explanados a seguir.
A forma mais utilizada para a comunicação do driver com aplicativos “comuns” é a utilização de IOCTLs (Device Input and Output Control), onde a estrutura de variáveis é definida internamente no driver e no aplicativo que utilizará a interrupção a nível de software para o driver (Microsoft_IOCTL, 2014).
Como este tipo de estrutura é voltado para C e C++, é possível ocorrer problemas na utilização desta técnica de interrupção quando utilizada outra linguagem de programação como, por exemplo, Java.
Partindo deste pressuposto, as ordens dadas ao driver devem ser enviadas através de uma outra forma de comunicação, sendo assim, poderiam ser enviadas através da alteração de valores das variáveis diretamente na memória.
Desta forma, cria-se uma área de memória compartilhada através das funções ExAllocatePoolWithTag e IoAllocateMdl em um endereçamento não protegido, podendo este ser alterado a qualquer momento por uma aplicação em modo usuário. (Microsoft_Aloc1, 2014; Microsoft_Aloc2, 2014).
É preciso ter a noção de que toda vez que o computador é reiniciado outro endereço lhe será atribuído, tendo assim a necessidade de passar o endereço de memória para a aplicação toda vez que o sistema é reiniciado. Mesmo que o endereço de memória seja disponibilizado, têm alguns inconvenientes onde algumas linguagens não permitem a alteração diretamente no endereço de memória.
Assim, foi utilizado outro tipo de comunicação sendo esta através da escrita e leitura em arquivos de texto em pastas pré-determinadas com instruções fixas, as quais definem as ordens e recebem uma resposta do driver que indica se a instrução foi executada com sucesso ou não.
Portanto, são necessárias especificações que indiquem como esta comunicação é efetuada, por este motivo foi criado o protocolo de comunicação, o qual já foi abordado no capítulo anterior. Salienta-se, novamente, que caso alguma instrução não esteja de acordo com as especificações técnicas abaixo há uma grande possibilidade de haver uma “tela azul” (Microsoft_Tela_Azul, 2014).
As pastas que contém as configurações do driver estão localizadas em C:\TCCRohde\Config, na qual devem ser gravados os arquivos Teclado.config e Mouse.config, já as instruções dadas devem ser escritas em C:\TCCRohde\, sendo que as respostas referentes às execuções das ordens estarão nesta mesma pasta.
O arquivo Teclado.config faz duas configurações, sendo elas o tempo de dormência e o status que define se o driver deve funcionar ou não. Este arquivo deve
conter exatamente seis caracteres, sendo que os primeiros cinco definem o tempo de dormência em milissegundos e o último a ativação propriamente dita.
As explanações sobre a importância da utilização destes dois parâmetros serão abordadas no item 3.2.2. Tenhamos como exemplo, tem-se a seguinte situação: O programador precisa que a leitura seja efetuada de um em um segundo, desta forma, o arquivo Teclado.config será escrito desta forma “010000”.
Se desejar que o driver execute comandos em intervalos de dezoito segundos e meio, o arquivo será impreterivelmente escrito da seguinte maneira “185000”, porém se o desejo é que o driver não execute mais nenhum comando pode-se desprezar os primeiros cinco algarismos e definir o último algarismo como “1”, ou seja, para desativar a funcionalidade temporariamente o arquivo Teclado.config deve ser escrito da seguinte forma “XXXXX1”, onde o X representa qualquer número.
Já o Mouse.config deve conter quatro configurações, sendo elas o tamanho da largura da tela, o tamanho da altura da tela, o tempo de dormência do driver e se o driver deve permanecer ativo.
A dormência do driver e a sua ativação, as quais são denominadas pelos últimos seis dígitos do arquivo de configuração, serão abordados no item 3.2.2.
Obrigatoriamente o valor da largura e da altura devem conter quatro dígitos, entretanto, se o valor de algum deles for menor que 1000 deve ser escrito antes do valor um zero, já para a dormência o valor é dado em cinco dígitos e caso o valor determinado pelo programador seja menor que 10000, deve-se adicionar os zeros para cada unidade não utilizada e o valor de ativação é dado por um ou zero.
Desta forma, tem-se a resolução da tela X e Y e o tempo de delay de cada leitura. Por exemplo, um computador que possui resolução 1280x720 e o delay inicial de 99 segundos ou 99000 milissegundos, o arquivo Mouse.config será escrito da seguinte forma “12800720990000”.
Se tiver a seguinte resolução 1440x900 e um delay de 15 segundos o arquivo de configuração terá o seguinte conteúdo “14400900150000”. Já para a mesma resolução sem delay o arquivo deve conter “14400900000000”. Porém, para um delay de leitura 5 segundos para uma resolução 800x600 o arquivo deve conter o seguinte conteúdo “08000600050000”.
3.2.2 Economia de Recursos e Aperfeiçoamento do Algoritmo
Neste item são abordados assuntos referentes à dormência (delay) e à ativação que podem ser definidas dentro do Mouse.config e Teclado.config. Este é um recurso importantíssimo para o bom desempenho do computador que utilizará tal driver.
Considerando que o driver é executado com prioridades diferentes das aplicações “comuns” aos desenvolvedores e usuários, existe a necessidade de economizar recursos, tanto de processamento quanto de leitura dos arquivos de ordens e respostas (Microsoft_Prioridades, 2014).
Desta forma, o quantum do processador dado ao driver para a execução do seu algoritmo é muito maior do que para a aplicação a qual o utiliza, pois o driver está sendo executado com prioridade DISPATCH_LEVEL, mesmo que com permissões PASSIVE_LEVEL, enquanto as outras aplicações são executadas com a prioridade PASSIVE_LEVEL.
Assim, não existe lógica em ficar lendo um arquivo no HD de forma constante e testar as variáveis dentro do driver de forma contínua se o programador não precisa utilizá-lo naquele momento. Por este motivo, no arquivo de configuração é determinado qual o tempo de inércia do driver e se ele deve permanecer ativo (Microsoft_Prioridades, 2014).
Neste período de inércia o driver continuará a consumir processamento e IO (Input Output – Entrada e Saída) de disco e recursos do CPU, porém o seu gasto é muito reduzido, pois ele fará uma leitura a cada tempo determinado no arquivo de configuração.
Se o driver virtual não for utilizado naquele momento orienta-se que o deixe desativado, pois mesmo com o tempo de inércia no máximo, ou seja, determinado como tempo de dormência, os seus quase cem segundos ainda assim será consumido processamento e memória RAM.
O caractere que determina se o driver deve permanecer ativo é definido da seguinte maneira “0” para ativado e “1” para desativado. Para que essas configurações sejam atualizadas dentro do driver de forma contínua e sem desperdício, tomou-se alguns princípios como regras, conforme descritas a seguir.
As configurações são carregadas para dentro do driver na sua inicialização e após esta configuração inicial será efetuada outra configuração somente a cada
interação de execução, ou seja, cada vez que o driver receber alguma ordem o seu arquivo de configuração será lido e, consequentemente, haverá a sua atualização interna.
No entanto, se for necessário desativá-lo temporariamente deve-se definir 1 no caractere de configuração, sendo que para o teclado é o sexto caractere e para o mouse é o décimo quarto caractere e, logo após a sua configuração, executar alguma ordem ou reiniciar o computador.
Entretanto, se o driver for desativado somente poderá ser ativado seguindo os seguintes passos:
- Ativação do driver definindo-se 0 no caractere de ativação, sendo que para o teclado é o sexto caractere e para o mouse é o décimo quarto caractere; - Reinicialização do computador no qual ele está sendo utilizado.
Salienta-se, ainda, que quando o computador for iniciado, não importando se é para a sua reativação ou para a execução normal do driver o computador terá obrigatoriamente um comportamento anormal caso não sejam seguidas as seguintes diretivas:
- Aguardar o carregamento do SO por completo, caso houver uma IRQL do teclado ou do mouse antes de ser efetuado o carregamento de algumas DLLs haverá, sem dúvida, uma quebra no sistema;
- Após o carregamento por completo do SO na primeira utilização do teclado e do mouse haverá impreterivelmente um congelamento na usabilidade do mouse e do teclado PS2, ou seja, logo após a inicialização quando forem utilizados o teclado e o mouse a instanciação da thread de cada um e a sua configuração inicial durará exatamente dez segundos;
- Devido ao passo anterior não será possível ordenar execuções para o teclado nem para o mouse nesta inicialização;
- Tendo em vista as configurações do PSERVICE_CALLBACK_ROUTINE não será possível executar as ordens se não for efetuada a instanciação das threads, as quais são criadas na primeira interação, ou seja, para a utilização do mouse precisa-se impreterivelmente efetuar um clique ou mover um pixel, já para o teclado precisa-se impreterivelmente que seja efetuado um clique de alguma tecla para que seja possível a utilização do drive desenvolvido neste trabalho.
3.2.3 Instalação do Dispositivo
Existem duas ferramentas disponibilizadas pela Microsoft, as quais quando utilizadas juntas fazem a instalação do driver para o usuário de forma leiga utilizando o método Wizard. Primeiro temos o DPInst que faz a configuração inicial do driver e, segundo, o IExpress que cria o ambiente Wizard para o usuário (Microsoft_DPInst, 2014; Microsoft_IExpress, 2014).
Porém, há um inconveniente na utilização destas ferramentas, pois elas funcionam apenas para driver assinados digitalmente pela Microsoft, fazendo com que se tornem inúteis na utilização deste trabalho.
Desta forma, este estudo não foi submetido a testes efetuados pela empresa devido ao tempo que levará para ser verificado e, além disso, para que a verificação seja efetuada é necessário o envio de partes do código fonte juntamente com o driver desenvolvido (Microsoft_Assinatura, 2014).
No entanto, é possível ainda efetuar a instalação manual do driver a partir dos seguintes passos:
Entrar nas propriedades do “Computador”;
Clicar na opção “Gerenciador de dispositivos”;
Para o Mouse localizar “Mouse e outros dispositivos apontadores”: - Expandir a árvore;
- Localizar “Mouse compatível com PS2” e clicar com o botão direito;
Para o Teclado localizar “Teclados”: - Expandir a árvore;
- Localizar “Teclado padrão PS/2” e clicar com o botão direito;
A partir daqui é o mesmo procedimento para o mouse e para o teclado: - Selecionar a opção “Atualizar driver”;
- Selecionar “Procurar software de driver no computador”;
- Selecionar “Permitir que eu escolha em uma lista de drivers de dispositivo no computador”;
- Selecionar “Com Disco”; - Selecionar “Procurar”;
- Selecionar o Arquivo com extensão inf do driver e clicar em abrir, OK, Avançar, Sim, Fechar, Sim;
- O computador irá reiniciar.
A depender de qual versão do SO é utilizado, pode-se encontrar problema na instalação do dispositivo. Este fato dar-se-á pela segurança que o Windows impõe para a instalação de drivers não assinados digitalmente, ou seja, em algumas versões do SO não é possível instalar softwares que não foram verificados pela Microsoft (Microsoft_Testsigning, 2014).
Se o SO não aceita o driver e for instalado mesmo assim ocorrerá uma parada do hardware. Para que se possa analisar e compreender melhor esta situação, é apresentada a seguir a Figura 1 na qual se verifica a mensagem dada pela Microsoft quando um driver não assinado é instalado.
Figura 1: Erro ao instalar driver não assinado pela Microsoft
Fonte: autor.
No caso visto na Figura 1 o driver foi instalado em um computador com o Windows Seven Ultimate 64 bits. Nesta versão do SO os drivers não assinados são recusados pelas diretivas do sistema, mas caso se insisti na instalação o sistema acaba aceitando e efetua a instalação.
Porém, ao reinicializar o sistema o dispositivo de hardware não funcionará e no gerenciamento de dispositivos o hardware estará identificado com um triângulo amarelo que indica seu mau funcionamento, isto poderá ser contornado desativando esta verificação da assinatura digital.
