Neste artigo irei demonstrar o processo de injeção de código em outro processo rodando no windows.

Requisitos: C++, Win32.

Bom existem várias técnicas de injeção de código em outros processos mas a que eu considero mais “limpa” é a da injeção de código via DLL utilizando a API CreateRemoteThread. Vamos começar criando a nossa DLL:

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    MessageBox(NULL, L"Código Injetado", L"Injeção de Código", MB_OK);
    break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Este código está bem simples, quando a nossa DLL for carregada ela mostrará uma MessageBox. Agora vamos para a lógica do negócio do injetor desta DLL:

1) Abrir o processo com a API OpenProcess especificando o pid do processo a ser injetado.

HANDLE handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, processId);

2) Usar o VirtualAllocEx para alocar um buffer dentro do processo aberto no item 1, assim que estiver alocado utilizar o WriteProcessMemory para colocar o nome da DLL que vai ser injetada no processo.

std::string dllPath = "C:\\MeuProjeto\\Minha.dll";
int bytesWritten = 0;
void* remoteBuffer = VirtualAllocEx(handle, NULL, dllPath.size(), MEM_COMMIT, PAGE_READWRITE);

WriteProcessMemory(handle, remoteBuffer, &dllPath[0], dllPath.size(), &bytesWritten);

3) Carregue a DLL Kernel32 através de um LoadLibrary e pegue o endereço da função LoadLibrary dentro dessa DLL.

HMODULE kernel32 = LoadLibrary("Kernel32.dll");
void* loadLibraryAddress = GetProcAddress(kernel32, "LoadLibraryA");

4) Crie um thread remoto usando a função CreateRemoteThread que inicie na função LoadLibrary através do endereço adquirido no item 3 e que passe como parâmetro o buffer com o nome da DLL que foi previamente alocado.

LPTHREAD_START_ROUTINE threadStart = reinterpret_cast<LP_THREAD_START_ROUTINE>(loadLibraryAddress);
DWORD threadId = 0;
HANDLE remoteThread = CreateRemoteThread(handle,
      NULL,
      0,
      threadStart,
      reinterpret_cast<void*>(remoteBuffer),
      0,
      &threadId);

Para simplificar o processo eu criei uma biblioteca que “automatiza” o processo de injeção de código em outros processos, os fontes juntamente com um exemplo estão aqui, sugiro ler os fontes do source Process.cpp para ter uma idéia prática do processo.

Process process(4952);

if (process.InjectDll("D:\\Projetos\\Examples 2\\Debug\\Examples 2.dll"))
{
  std::cout << "dll injetada com sucesso\n";
}

Então vamos compilar a DLL e alterar o caminho da DLL no arquivo de exemplo para a sua DLL que foi compilada e alterar no construtor do Process o pid do processo a ser infectado. Assim provavelmente acabaremos com uma tela assim:

Creio que muitos tenham visto o meu post sobre como descobrir endereços de memória alocados dinâmicamente, aqui vou mostrar um exemplo prático aplicado ao jogo Warcraft 3 onde alteraremos o valor do gold do player dentro da memória do Warcraft 3.

Conhecimentos Requeridos: Assembly, Debugging.

Debugger Utilizado: Windbg e Ollydbg.

Buscando a memória

Bom, começarei lançando o meu debuger, carregando o war3.exe e criando um jogo no custom game, peguei um mapa qualquer e o iniciei. Inicialmente estou com 500 de gold, o valor que a gente usará de base no debugging.

Agora que o jogo já está carregado disparei um breakpoint no debugger e usarei o comando de procurar pela memória que o Windbg fornece:

s b 0×00000000 L?0xffffffff f4 01

Que faz com que o valor 0xf4 0×01 (500 em decimal) seja procurado do endereço 0×00000000 (início da memória) até L?0xffffffff (fim da memória). É interessante lembrar que os bytes foram invertidos por causa do Endianess. Isso faz com que uma lista de endereços seja retornada sempre que o valor nele for o mesmo que a gente estiver procurando, o que nos retornou uma lista beeem grande. Para resolver isso gastamos um pouco o gold dentro do jogo e efetuamos a busca novamente com o novo valor do gold o que nos deixará com duas listas enormes. O endereço que for igual quando compararmos as duas listas provavelmente é o endereço do gold, para fazer isso criaremos um programa que realize esta comparação (quando eu tiver o meu site eu posto os meus fontes aqui).

Veremos que apesar de tudo nenhum endereço se igualou, o que nos diz que o gold é guardado de maneira diferente dentro da memória do jogo… droga, mais trabalho pra gente. Ainda nos resta procurar pelo valor ASCII do gold que é pintado na tela que pode nos dar uma dica de como achar o endereço do gold original. Peguemos o nosso Windbg e repetiremos o processo de criação de um jogo. Agora realizaremos uma busca (da mesma forma que fizemos anteriormente) pela memória com o valor de 35 30 30 que corresponde ao valor de 500 em ASCII:

s a 0×00000000 L?0xffffffff 35 30 30

Repetiremos o processo de gastar o gold e procurar pelo novo valor e comparar os resultados. Humm, dessa vez conseguimos dois endereços válidos, vamos analisá-los mais de perto setando um breakpoint em cada um deles quando o processador tentar escrever neles.

ba w4 0x[endereco]

Sendo [endereco] o endereço que o comparador retornou, faça isso em ambos endereços. Esse comando tem a seguinte sintaxe: ba [w/r][tamanho] [endereco]. Ele faz com que cada vez que o [endereco] com [tamanho] bytes seja [escrito/lido] um breakpoint seja disparado. Então agora cada vez que gastamos/ganhamos gold um breakpoint é disparado pela aplicação, agora está começando a ficar legal.

Reversing

Já que eu não gosto do disassembly do Windbg percebemos que a string que guarda o gold começa com “mo”, então vamos carregar o nosso Ollydbg com o processo war3.exe, criar um custom game e procurar por mo500 na memória, o que vai nos retornar os mesmos dois endereços anteriores, então vamos setar hardware breakpoints em ambos e gastar um pouco de gold, o que vai disparar um breakpoint e nos dar o seguinte código:


6F6628A2 MOV BYTE PTR DS:[EAX],CL
6F6628A4 PUSH EBX
6F6628A5 PUSH EDI
6F6628A6 MOV EDI,DWORD PTR SS:[EBP+8]


Percebemos que o registrador EAX está com apontando para um dos nossos endereços, e vemos que o valor de EBP+8 é o novo valor do gold que deve ser atualizado, EBP geralmente é usado para especificar parâmetros, então esta variável deve estar vindo de uma função acima no stack, vamos segui-la:


6F151766 CALL Game.6F088E10
6F15176B MOV ECX,EAX
6F15176D MOV EAX,6666666
6F151772 IMUL ECX
6F151774 SAR EDX,2
6F151777 MOV EAX,EDX
6F151779 SHR EAX,1F
6F15177C ADD EDX,EAX
6F15177E JMP SHORT Game.6F151782
6F151780 XOR EDX,EDX
6F151782 PUSH EDX
6F151783 PUSH Game.6F804EC0 ; ASCII “%u”
6F151788 LEA ECX,DWORD PTR SS:[EBP-40]
6F15178B PUSH 40
6F15178D PUSH ECX
6F15178E CALL <JMP.&Storm.#578>
6F151793 MOV ECX,DWORD PTR DS:[EDI+124]
6F151799 ADD ESP,10
6F15179C LEA EDX,DWORD PTR SS:[EBP-40]
6F15179F PUSH EDX
6F1517A0 CALL Game.6F662890

A variável que está sendo passada como parâmetro é a EDX, logo antes da chamada à função que estavamos anteriormente temos um:

6F15179C LEA EDX,DWORD PTR SS:[EBP-40]

Que faz com que EDX aponte para o endereço DWORD PTR SS:[EBP-40], provavelmente uma variável local com tamanho fixo de 0×40, que está sendo populado quando a função <JMP.&Storm.#578> é chamada, então observemos os seus parâmetros: regitrador EDX, variável local com valor “%u”, uma variável local e seu respectivo tamanho. Está com cara de uma função de conversão de valor decimal para caractere. Sabemos então que EDX está com o valor decimal do gold.

A instrução que origina o valor de EDX antes de serem efetuados aqueles calculos (que são necessário para converter o valor “escondido” no decimal) é:


6F151766 CALL Game.6F088E10
6F15176B MOV ECX,EAX


Aqui observamos que no fim das contas o valor de EDX vem do retorno da função ((registrador EAX) chamada no bloco acima, então vamos entrar nessa função e ver de onde que o registrador EAX tira o seu valor:

Gotcha!

6F088E78 MOV EAX,DWORD PTR DS:[EDX+78]
6F088E7B POP ESI
6F088E7C POP EBX
6F088E7D RETN


Logo no fim dessa função podemos ver o endereço de onde o valor de EAX está vindo, então finalmente, ai está o maldito endereço do gold. Mas porque nós não tinhamos achado ele no início? Porque o valor está com um zero a mais (gold 500, valor 5000) ai os bytes que a gente procurou são inúteis. Agora para brincar escreva no endereço EDX+78 o quanto de gold você quer ter :).

Agora este endereço entra no problema da memória alocada dinâmicamente que expliquei em outro post (cada vez que o processo war3.exe for reiniciado esse endereço será outro), deixarei a criação do “trainer” (programa externo que modifica a memória de outro processo) de tema de casa, só vou dar uma dica: Win32 ReadProcessMemory/WriteProcessMemory. Não se iluda, o calculo da memória “fixa” vai ser bem mais complicado do que o que eu descrevi no post pois envolve vários ponteiros e estruturas, mas todos têm condições de fazê-lo.

Até o próximo post, aceito sugestões :).

Na criação de trainers para jogos é comum nos depararmos com alguns valores sendo alocados dinâmicamente, isto pode gerar alguns empecilhos que podem ser ultrapassados, aqui vou dizer como.

Conhecimentos necessários: Assembly e Debugging.

Debugger utilizado: OllyDbg.

Memória dinâmica

Memória dinâmica é a memória alocada no heap de um programa, que foi alocada pelo sistema operacional. Ela pode ser um empecilho pois, para programar os trainers nós necessitamos de um endereço fixo para ser lido e/ou escrito (os pontos em um jogo por exemplo). Em um programa escrito em C++ podemos alocar a memória dinâmicamente com a seguinte construção:

int* dynamic = new int;

Descobrindo o endereço fixo da memória dinâmica

Quando usamos um new int[4] o sistema operacional “vasculha” por um lugar na memória que esteja disponível e retorna o endereço dessa memória, que no caso do nosso exemplo acima este endereço fica armazenado no ponteiro com o nome dynamic. No caso o ponteiro para essa memória alocada é que tem endereço fixo, então descobrindo o endereço do ponteiro nós podemos ler o valor do mesmo e descobrir o endereço da memória dinâmica.

Exemplo

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

class Jogo
{
public:
    volatile char m_dummy;
	volatile int* m_pontos;

	Jogo()
	{
        m_dummy   = 'a';
		m_pontos  = new int;
		*m_pontos = 57;
	}
	~Jogo()
	{
		delete m_pontos;
	}
};

Jogo jogo;

int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, char* cmdParam, int cmdShow)
{
	char points[10];

	wsprintf(points, "%d", *(jogo.m_pontos));

	::MessageBox(0, points, "Meu jogo", MB_ICONEXCLAMATION | MB_OK);
    ::MessageBox(0, points, "Meu jogo", MB_ICONEXCLAMATION | MB_OK);
}

Após compilar este programa vamos carrega-lo com o OllyDbg e botar um breakpoint na chamada da função wsprintf, e executar o programa o que vai nos deparar com o seguinte código:

LEA EAX,DWORD PTR DS:[373370]
MOV ECX,DWORD PTR DS:[EAX+4]
MOV EDX,DWORD PTR DS:[ECX]
PUSH ESI
PUSH EDX
LEA EAX,DWORD PTR SS:[ESP+C]
PUSH OFFSET Examples.??_C@_02DPKJAMEF@?$>
CALL DWORD PTR DS:[<&USER32.wsprintfA>]

Esse é o código que lê a variável m_points e passsa o seu valor para a função wsprint. Logo na primeira linha podemos ver:

LEA EAX,DWORD PTR DS:[373370]

Que faz com que EAX aponte para a variável global jogo.

MOV ECX,DWORD PTR DS:[EAX+4]
MOV EDX,DWORD PTR DS:[ECX]

A primeira linha lê o ponteiro que está em EAX+4 e o copia para ECX, e a segunda pega o valor que o ponteiro ECX está apontando e salva o seu valor em EDX, simplificando, ECX fica com o endereço de m_pontos e EDX com o seu valor.

Para ler o m_pontos neste programa só seria necessário ler a memória no endereço 0×373374 (que é fixo), pegar o valor lido (que será o endereço da varável m_pontos, que foi escolhido dinâmicamente) e ler no seu endereço.

Depois de alguns meses sem postar, felizmente anuncio a minha volta junto com uma novidade: Gotcha 0.1a foi lançado.

Modificações:

* Arquitetura Cliente/Servidor para aplicações cliente e fontes de input.

Mas o que tem de tão bom assim nessa arquitetura nova?

- Ela permite abstrair as fontes de input de modo que se uma aplicação foi construída em cima do Gotcha e de repente o usuário escolher usar a webcam como input ao invés de um wiimote essa alteração será refletida automaticamente na aplicação sem mesmo precisar reiniciar ela.

- Pode-se usar um computador como fonte de input (ligar um sensor nele) e distribuir essa informação para vários outros computadores que não têm o sensor.

- Na arquitetura antiga, se muitas aplicações usassem o wiimote como fonte iriamos perceber uma perda de performance considerável, algo que a nova arquitetura evita.

- Integração com outras linguagens fica muito mais fácil, pois qualquer linguagem que tenha acesso ao protocolo TCP pode se comunicar com o Gotcha.

O link para download do source está aqui.

GotchaDrivers: contêm todas as fontes de input que o gotcha suporta (atualmente o wiimote e uma fonte de exemplo), deve ser iniciado após o servidor.

GotchaMouseClient: Esse é o client que permite controlar o mouse, deve ser iniciado por ultimo.

GotchaServer: Esse é o servidor do Gotcha, deve ser iniciado antes do cliente e do driver.

Compilando

O Gotcha possui as seguintes dependências:

Boost 1.35.0.
Wiiyourself.

Em breve disponibilizarei um Wiki com informações mais completas sobre o Gotcha.

Muitas pessoas tem me reclamado quanto aos créditos do meu sistema, afinal, nunca uma idéia é feita completamente do zero, então meus créditos:

1) Ao roteirista do Minority Report pela incrível idéia de utilizar o computador usando as mãos.

2) Ao website http://www.wiili.org/ (que aliás, merece grande parte dos créditos) por ter quebrado o protocolo do wiimote e disponibilizar links de bibliotecas de acesso ao mesmo. Eles também revelaram que realmente era possível fazer tracking de pontos IR a partir do wiimote sem problemas.

3) À biblioteca WiiYourself (http://www.wiili.org/) que possibilitou o acesso aos dados do wiimote.

4) Ao Jean Karpisnki pela idéia de criar o Multipointer.

Espero que esse post tenha sido esclarecedor para muita gente.

Há tempos eu estava sendo cobrado de um vídeo do sistema já que os da imprensa não dava para ver direito. Apesar de eu estar sem meus aparelhos (longe de casa) eu consegui fazer um vídeo do sistema. Aliás, já definimos o nome: Gotcha. Gostaram? hehe. Me desculpem se fiquei devendo os detalhes técnicos, assim que eu tiver mais tempo eu posto eles.

Comparações:

Quanto às comparações técnicas relativas ao software do Johnny Lee eu já criei um post sobre isso e agora tenho o vídeo para provar que o meu sistema é diferente do dele, nós tivemos a idéia sem ver o vídeo dele e conseguimos um resultado diferente do dele. Me desculpem pela falta de som, é que como já falei estou sem meus aparelhos.

Vídeo:

Futuro:

Qual o futuro do Gotcha? Primeiramente, vou desenvolver uma versão para o Linux, pretendo também tirar a dependência do wiimote e fazer uns últimos ajustes no sistema. Também pretendo fazer uma versão para usuários tetraplégicos e entre eles o meu sonho, criar um sistema para que o meu tio possa utilizar o computador, ele praticamente não possui nenhum movimento mas prometo que em breve verão ele utilizar um computador. Quanto à licença, planejo adotar uma que seja compatível com a filosofia open-source, aguardem.

Muitas pessoas estão perguntando sobre a diferença do meu sistema ao do Johnny Lee apresentado no vídeo: http://br.youtube.com/watch?v=0awjPUkBXOU

Vejam o vídeo, é muito legal só que é importante esclarecer aqui:

O nosso projeto não é um plágio. Ai está o porque:

* O cara gastou no mínimo uns 60 reais para fazer a matriz de leds dele, uma técnica diferente da minha, na qual gastei no máximo 10 reais.
* O papel reflexivo não é tão efetivo e sofre muita interferência de outras fontes infravermelhas no ambiente.
* Ele não criou ponteiros múltiplos acima do sistema operacional, ele sequer criou algum ponteiro, ele somente indicou onde estavam as fontes infravermelhas.
* Os pontos infravermelho dele não se distinguem um do outro, no nosso caso nós sabemos qual led corresponde a qual dedo.
* Ele não criou um sistema de cliques. Ele interpreta como se qualquer ponto infravermelho fosse um clique (um clique no seu programa, não no sistema operacional). Então ou ele move livremente sua mão sem cliques ou ele fica sempre clicando sem mover suas mãos.
* A pessoa tem que estar entre um intervalo de distância, na qual se ela fica perto, muitos pontos infravermelhos aparecem. Diferente do meu, que a pessoa pode ficar o quão perto ela quiser. Se o projeto do Johnny Lee fosse em um notebook como eu fiz, milhares de pontos infravermelhos surgiriam, e a pessoa não poderia ficar a uma distância agradável do computador, tendo que ficar muito longe.

Ele simplesmente não interagiu com o sistema operacional e nem com outros programas externos somente o seu software interpretou os dados.

Justamente o que inviável o projeto do Johnny Lee torna o meu viável que é o fato da pessoa poder estar perto do computador.

Pelo que podem ver na minha apresentação eu joguei Warcraft 3 com o meu sistema algo que seria impossível com o sistema do Johnny Lee. Não desmereço o seu trabalho, que aliás, é muito bom, só que temos grandes diferenças que são importantes de serem ressaltadas. As diferenças técnicas dos dois projetos devem ser levadas em consideração, teste-os, e teça uma opinião sem se basear em artigos que não são de caráter técnico. Em breve postarei um vídeo no Youtube para ressaltar as diferenças.

Sinto muito se desviarei um pouco o foco técnico que o meu blog tem para divulgar o meu recente feito hehe.

Creio que todos que leiam este blog ja tenham ouvido falar da Campus Party, um evento que sempre acontecia na Espanha e foi, esse ano, realizado aqui no Brasil, que reúne um monte de nerd durante uma semana. E eu fui :), na realidade, estou aqui neste exato momento. Quando fiquei sabendo da CP, eu pensei: “Bá, tenho que fazer alguma coisa legal para apresentar lá”. Neste momento eu estava visitando alguns sites e me deparei com um sobre a definição do protocolo do controle remoto do Nintendo Wii, o Wiimote, fiquei bem interessado e resolvi fazer um software que interagisse com o acelerômetro dele, e fiz, e levei pra CP.

Chegando lá, conheci um amigo do meu irmão, o Jean Karpinski, que já tinha uma palestra agendada sobre como usar o Wiimote no PC, basicamente ele tinha feito o mesmo que eu :P. Dai eu estava melhorando um pouco o meu software e tive a idéia de fazer algo estilo o Minority Report (aquele filme que tem uma cena na qual o personagem interage com o computador usando as mãos), ai falei para o Jean essa idéia, ele adorou, e perguntou: “Cara, acha que consegue fazer para sexta?”. “O Jean não me conhece”, pensei hehehe. Brincadeiras à parte, ai eu peguei, sentei e fiquei desenvolvendo, enquanto o Jean já ia agitando com a galera do modding, com os organizadores da CP que disseram que se eu conseguisse fazer eles me davam um espaço na programação de palestras.

Sexta, lá pelas 5:35 horas da manhã eu consegui com que o primeiro protótipo funcionasse, ai chamei o Jean, que chamou o assessor de imprensa da Campus Party que acabou dando uma ajuda com a parte da imprensa, foi uma manhã legal, ficamos até às 6:40 horas falando sobre o projeto.

Sábado, o dia da apresentação, eu já acordei com um frio na barriga, estava difícil esconder o nervosismo, não consegui comer nada o dia inteiro. Chegou a hora da palestra, eu não me contia de tanto nervosismo depois de ter passado o dia inteiro fazendo uns ajustes, quando eu comecei a falar quase tranquei hahaha. Para quem não estava na palestra, basicamente eu controlo o ponteiro do mouse utilizando as mãos, porém não só um ponteiro, eu criei um sistema que permite ter quantos ponteiros quiser na tela, bem loco hehe. Mas depois da palestra meus amigos disseram que nem deu pra notar que eu estava nervoso, tirando o fato de que eu estava tremendo muito na hora, o ponteiro do mouse não parava, já que era controlado pela minha mão hehe.

Bá mas parece que o pessoal gostou, eu vou postar mais sobre o projeto que eu pretendo continuar, assim que for se definindo o futuro dele eu atualizo vocês.

Agora tenho que ir dormir, e prometo a vocês que em breve escrevei muitos posts, tenho bastante assuntos interessantes, é só achar tempo para escrever.

Bom, pedi à Rael Cunha a autorização para “tunar” o seu código do corretor ortográfico em Java para tentar aproximá-lo o máximo possível da performance do corretor em C++.

Vamos começar com o código presente em seu website:

import java.io.*;
import java.util.*;
import java.util.regex.*;
class Spelling {
     private final HashMap<String, Integer> nWords = new HashMap<String, Integer>();
     public Spelling(String file) throws IOException {
          BufferedReader in = new BufferedReader(new FileReader(file));
       	  String temp = null;
 	  Pattern p = Pattern.compile("\\w+");
 	  while((temp = in.readLine()) != null) {
 	       Matcher m = p.matcher(temp.toLowerCase());
 	       while(m.find()) nWords.put((temp = m.group()), nWords.containsKey(temp) ? nWords.get(temp) + 1 : 1);
 	  }
 	  in.close();
     }
     private final ArrayList<String> edits(String word) {
          ArrayList<String> result = new ArrayList<String>();
 	  for(int i=0; i < word.length(); ++i) result.add(word.substring(0, i) + word.substring(i+1));
 	  for(int i=0; i < word.length()-1; ++i) result.add(word.substring(0, i) + word.substring(i+1, i+2) + word.substring(i, i+1) + word.substring(i+2));
 	  for(int i=0; i < word.length(); ++i) for(char c='a'; c <= 'z'; ++c) result.add(word.substring(0, i) + String.valueOf(c) + word.substring(i+1));
 	  for(int i=0; i <= word.length(); ++i) for(char c='a'; c <= 'z'; ++c) result.add(word.substring(0, i) + String.valueOf(c) + word.substring(i));
 	  return result;
     }
     public final String correct(String word) {
          if(nWords.containsKey(word)) return word;
          ArrayList<String> list = edits(word);
          HashMap<Integer, String> candidates = new HashMap<Integer, String>();
 	  for(String s : list) if(nWords.containsKey(s)) candidates.put(nWords.get(s),s);
 	  if(candidates.size() > 0) return candidates.get(Collections.max(candidates.keySet()));
 	  candidates.clear();
 	  for(String s : list) for(String w : edits(s)) if(nWords.containsKey(w)) candidates.put(nWords.get(w),w);
 	  return candidates.size() > 0 ? candidates.get(Collections.max(candidates.keySet())) : word;
     }
     public static void main(String args[]) throws IOException {
          if(args.length > 0) System.out.println((new Spelling("big.txt")).correct(args[0]));
     }
}

Após um benchmark pude observar que a parte que consome o maior tempo de execução é a inicialização do corretor, então é esse o nosso principal alvo de otimização. Mas o que vamos otimizar exatamente? Neste mesmo benchmark pude ver que as rotinas que consomem maior tempo de execução são:

* java.util.regex.Matcher.find()
* java.lang.String.toLowerCase()

Então vamos nos concentrar nessas rotinas. Já que nosso objetivo não é otimizar as bibliotecas java.* temos de achar alternativas mais rápidas do que as que estamos usando, então vamo começar pela substituição da biblioteca java.util.regex.

Substituições: - Expressões Regulares:

As expressões regulares internamente realizam muitas computações, o que é desnecessário para a nossa causa já que temos de procurar por algo simples (palavras) dentro de uma string. O que faremos então? Vamos utilizar um loop clássico para determinar as palavras.

Primeiro, escaneamos a string para achar qualquer caractere que seja igual a alguma letra que desejamos, no nosso caso todos os caracteres alfabéticos “[a-z]“. Quando o acharmos, estaremos no início de uma palavra. Agora para achar o seu final procuramos por qualquer caractere que não seja alfabético, porém já que são muitos esses caracteres, isso resultaria em muita computação, teríamos que comparar cada caractere com todos os caracteres indesejados e ver se ele é um deles. A melhor saída é “filtrar” previamente os caracteres indesejados e estabelecer um separador entre eles.

- Rotina toLowerCase():

Sinceramente, alguém ja viu o código deste método? É de meter medo hehe. E já que estamos percorrendo a cadeia de caracteres inteira mesmo, podemos fazer um toLowerCase em caracteres individuais, assim podemos evitar múltiplas passagens na cadeia de caracteres.

Após otimizado o código ficou assim:

public Spelling(String file) throws IOException {
     BufferedReader in = new BufferedReader(new FileReader(file));
     String temp = null;
     while ((temp = in.readLine()) != null) {
          //converter a string para um array de char
          char[] letters  = temp.toCharArray();
          int end   = letters.length;
          int begin = 0;
          //converter caracteres upper case em lower case e transformar em delimitador todos caracteres indesejados<br />
          for (int i = 0; i < end;i++) {
               char letter = letters[i];
               if      ('a' <= letter && letter <= 'z' ) letters[i] = letter;
               else if ('A' <= letter && letter <= 'Z' ) letters[i] = Character.toLowerCase(letter);
               else letters[i] = '-';
          }
          //atualizar a string com os novos caracteres
          temp = new String(letters);
          for (int index = 0;index < end;index++) {
               //procurar pelo inicio da palavra
               while (letters[index] == '-' && index < (end-1)) index++;
               begin = index;
               //procurar pelo fim da palavra
               while (letters[index] != '-' && index < (end-1)) index++;
               String word = temp.substring(begin, index);
               nWords.put(word, nWords.containsKey(word) ? nWords.get(word) + 1 : 1);
          }
     }
     in.close();
}

Observem que no código a maioria do processamento foi feito com uma cadeia de caracteres já que além de ser mais rápido o acesso a caracteres individuais, um objeto String em Java é imútavel, ou seja, cada alteração que fizermos nele um novo objeto String é criado, o que não ocorre na cadeia de caracteres. Essa otimização resultou em um acréscimo considerável na performance do corretor passando o tempo de execução de 0.983s para 0.734s, ocorrendo uma melhoria de 25,3%. Certo, após essas melhorias eu ainda não estava satisfeito com o acréscimo de 25,3% de performance, então peguei o meu profiler e vi que agora os métodos do HashMap são os que ocupam maior tempo de execução, que estão presentes no construtor apenas nesta linha:

nWords.put(word, nWords.containsKey(word) ? nWords.get(word) + 1 : 1);

Pelo o que podemos constatar o próprio HashMap::get já pode fazer o serviço de constatar se uma key existe ou não então vamos usá-lo:

public Spelling(String file) throws IOException {
     BufferedReader in = new BufferedReader(new FileReader(file));
     String temp = null;
     while ((temp = in.readLine()) != null) {
          //converter a string para um array de char
          char[] letters  = temp.toCharArray();
          int end   = letters.length;
          int begin = 0;
          //converter caracteres upper case em lower case e transformar em delimitador todos caracteres indesejados<br />
          for (int i = 0; i < end;i++) {
               char letter = letters[i];
                if      ('a' <= letter && letter <= 'z' ) letters[i] = letter;
                else if ('A' <= letter && letter <= 'Z' ) letters[i] = Character.toLowerCase(letter);
                else letters[i] = '-';
           }
           //atualizar a string com os novos caracteres
           temp = new String(letters);
           for (int index = 0;index < end;index++) {
                //procurar pelo inicio da palavra
                while (letters[index] == '-' && index < (end-1)) index++;
                begin = index;
                //procurar pelo fim da palavra
                while (letters[index] != '-' && index < (end-1)) index++;
               String  word  = temp.substring(begin, index);
               Integer value = nWords.get(word);
               if (value == null) value = 0;
               nWords.put(word, value + 1);
          }
     }
     in.close();
}

Após a utilização do código citado acima, podemos constatar uma melhoria de 52,87% na performance do corretor ortográfico, algo já bem consideravel.Espero que tenham gostado (comentários são bem vindos, nem que seja só um oi para eu saber que não estou jogado às traças hehe).

Opa pessoal, ultimamente andei pesquisando sobre o novo padrão do C++, o C++0x e fiquei bem feliz com as suas propostas, recomendo a leitura do artigo sobre C++0x no Wikipedia. E algumas de suas novas funções já podem ser encontradas no G++. Sinceramente, fiquei muito empolgado com as propostas, sendo que algumas eu já esperava à muito tempo, este novo padrão fará essa linguagem poderosa ficar ainda mais poderosa. Aproveitem :).