Firefox 3 is comming....

Midas.dll and COM+ applications deployment issues

It is a known fact that Midas.dll needs to be registered before installing/registering a COM+ ActiveX Library under COM+, when deploying an ActiveX library written with Delphi, right?
Well... something interesting that I discovered this week: DON'T register a Midas.dll version 10.x (from BDS 2006 installation). Use a lower version - I'm using my D6 dll.
If you use version 10.x it will be registered without any errors, but when you try to install the ActiveX Library, boooom!!! You will get a "Error loading type library" error, as Midas.dll was not registered at all.
After ActiveX Library installation/registration, Midas.dll can be even deleted (If you are linking with MidasLib.dcu), as usual.

ASP.NET Compilation Error

Another common error I've found installing ASP.NET web services in IIS:

"Compilation Error - The compiler failed with error code 128"

This error has a simple solution: Just go to your .NET subfolder, for instance,

%SystemRoot%\system32\Microsoft.NET\Framework\

and type

aspnet_regiis -i

This will re-install and configure ASP.NET for IIS.

Arcana Intraweb Elite Suite is now Open Source!

Good news for Intraweb developers! Arcana has released its Intraweb Elite Suite to Open Source (MIT license). This is an excellent component pack for every Intraweb project!
Download here: http://code.google.com/p/iwelite/

Object Serialization in Delphi - Part II

This is a unit based on JVCL’s JvgXMLSerializer (from old Globus library). It has some basic classes used for object serialization:

unit XMLSerializer;

interface

uses
  SysUtils, Classes, JvgXMLSerializer;

type
  TXMLSerializer = class(TJvgXMLSerializer)
 private
    { Private declarations }
  protected
    { Protected declarations }
  public
    { Public declarations }
    procedure Serialize(Component: TObject; var s: string); overload;
   procedure DeSerialize(Component: TObject; s: string); overload;
 published
    { Published declarations }
  end;

 TSerializable = class(TPersistent)
 public
    { Public declarations }
    function Serialize: string;
   procedure DeSerialize(s: string);
 end;

implementation

{ TXMLSerializer }

procedure TXMLSerializer.DeSerialize(Component: TObject; s: string);
var
  Stream: TStringStream;
begin
  Stream := TStringStream.Create(s);
 try
    DeSerialize(Component, Stream);
 finally
    Stream.Free;
 end;
end;

procedure TXMLSerializer.Serialize(Component: TObject; var s: string);
var
  Stream: TStringStream;
begin
  Stream := TStringStream.Create('');
 try
    Serialize(Component, Stream);
   s := Stream.DataString;
 finally
    Stream.Free;
 end;
end;

{ TSerializable }

procedure TSerializable.DeSerialize(s: string);
var
  Serializer: TXMLSerializer;
begin
  Serializer := TXMLSerializer.Create(nil);
 try
    Serializer.DeSerialize(Self, s);
 finally
    Serializer.Free;
 end;
end;

function TSerializable.Serialize: string;
var
  Serializer: TXMLSerializer;
begin
  Serializer := TXMLSerializer.Create(nil);
 try
    Serializer.Serialize(Self, Result);
 finally
    Serializer.Free;
 end;
end;

end.

The classes declared are:

TXMLSerializer: my direct descendant of TJvgXMLSerializer. It implements two new methods:
- Serialize: serialize an instance directly to a string, without the necessity of creating a TStream;
- DeSerialize: receive a string as a parameter containing the XML and deserialize the instance.

TSerializable: a TPersistent descendant that implements the Serialize and DeSerialize methods too.
They both work to serialize and deserialize itself.
All my "serializable" classes are direct descendants of TSerializable.

I've modified the original JVCL unit TvgXMLSerializer (using latest version 3.33) to make it compatible with VCL.NET (using BDS 2006).
Using that unit I can create serializable classes that can be shared - and used - among Win32 and .NET modules. Not only creating single sorced projects, but I can pass a XML to a ASP.NET WebService from my Win32 consumer client, in an easy and convinient way.
More about it later. ;-)

G-Buster Browser Defense. O que os bancos instalam em seu PC sem você saber.

ATENÇÃO: Este procedimento não é válido para as versões mais recentes do G-Buster. Um novo post explica como bater esta praga novamente! Estou adorando brincar de gato & rato com a GAS Tecnologia! ;-)
A mais nova versão da praga pode ser removida mais fácil que antes, com o novo procedimento descrito neste link.

Este é o nome do vírus que os bancos instalam em seu computador sem você saber. Vírus sim, mesmo que benigno. Tem as mesmas características técnicas de um vírus qualquer que um hacker coloca no seu PC: invisível, furtivo, instalado sem seu conhecimento, impossível de ser removido por um leigo, rouba sua CPU fazendo coisas que você nem tem idéia.

Quem faz isto atualmente: Banco Real, Banco do Brasil, Caixa Econômica Federal, Unibanco. O desenvolvedor da praga é a GAS Tecnologia.

O mais nefasto dos efeitos deste "vírus" pode ser visto direto no seu TaskManager. Se você acessa um destes bancos via internet, poderá ver o serviço Gbpsv.exe na lista de processos em execução. Este serviço pode também ser visto acessando-se o controlador de serviços em Painel de Controle/Ferramentas Administrativas. O mais interessante é que nem o administrador local da máquina é capaz de parar, remover, pausar ou alterar as configurações deste serviço - o que na minha opinião é um abuso por parte dos bancos. Possivelmente em outro país isto seria considerado ilegal.

Pesquisei muito na internet para descobrir o que era e o que fazia o tal G-Buster, e a melhor fonte de informação está aqui.

O estranho é que tenho instaladas as versões do Banco Real e do Banco Mercantil do Brasil, mas somente a versão do Banco Real instala o serviço Gbpsv.exe. A versão do Banco Mercantil do Brasil é somente a DLL do controle ActiveX, mas não o serviço de monitoração.

Então, vamos separar o joio do trigo: A DLL que contém o controle ActiveX não é indesejável, uma vez que só é carregada sob demanda quando se acessa o Internet Banking do respectivo banco. Assim funciona por exemplo com o Banco Mercantil do Brasil que só usa a DLL gbiehbmb.dll.
A praga em si é o serviço Gbpsv.exe que roda para todos os usuários da máquina, 24 horas por dia, fazendo polling na registry, conforme demonstrou o Romulo Ceccon em seu blog.

Tentei removê-lo usando a técnica descrita no site acima, mas não tive sucesso. Então adicionei alguns passos e consegui resolver.

Identificando os módulos executáveis
Testei com o Internet Banking do Banco Real, e os módulos podem ser encontrados em:

C:\Arquivos de programas\GbPlugin\

Cada banco tem sua versão da DLL, a do Banco Real é: gbiehabn.dll, da Caixa é gbiehcef.dll, do BMB é gbiehbmb.dll e analogamente para outros bancos.
Existe ainda o serviço GbpSv.exe, na mesma pasta. Este é o serviço que está rodando 24x7 em seu computador, consumindo ciclos de sua CPU - sem você ter sido informado - e que será removido!

Ferramentas necessárias para remoção da praga:

1) SysInternals Process Explorer disponível aqui, ou para download direto aqui.

2) SysInternals Autoruns disponível aqui, ou para download direto aqui.

3) Login como administrador local da máquina. Sem estas credenciais, nada feito.

Desinstalando o servico Gbpsv.exe

A forma normal de remover um serviço é através do controlador de serviços no painel de controle. Infelizmente o abuso chegou ao ponto de impedir a parada ou desinstalação do serviço por este método.
O interessante é que antes testei a ferramenta de exclusão de serviços do aplicativo HijackThis que geralmente resolve este tipo de problema e não tive sucesso. Recebo a mensagem que o serviço não existe. Bem, isto porquê a praga muda as permissões na registry de sua própria entrada em:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\GbpSv
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\GbpSv
OBSERVAÇÃO: Podem haver variações nos nomes da chave ControlSet001, ControlSet002, ControlSet003. Em todas elas deve-se verificar a existência da subchave GbpSv.

Então, vamos do início:

1) Abra o Regedit, para que possamos mudar as permissões nas chaves mostradas acima. Para abrir o Regedit vá em Iniciar -> Executar e digite Regedit e clique em OK, conforme a figura:



2) Vamos então procurar as chaves:

Expanda sucessivamente as chaves HKEY_LOCAL_MACHINE, depois SYSTEM, ControlSet001 e finalmente Services.



3) Mudando as permissões nas chaves:

As duas entradas têm permissões somente para as contas LOCAL e SYSTEM. Nem o Administrador possui permissões nesta chave. Mas não é possível conceder ao grupo de administradores a permissão diretamente. Primeiro temos que tornar o administrador o proprietário da chave. Siga os seguintes passos:
- Selecione a chave GbpSv e depois clique com o botão direito sobre ela (ao selecionar geralmente há mensagem de falta de permissão, ignore estas mensagens).
- Selecione no submenu a opção "Permissões". Poderá ser exibida uma mensagem como a que está abaixo. Ignore-a tb.



- Clique em Avançado e na nova janela que irá se abrir selecione a aba "Proprietário", conforme a figura abaixo:



Apesar do tema estar com cara da MacOS, é um legítimo Windows XP ;-)

Uma vez que a sua conta agora é o proprietário da chave, você poderá alterar as permissões. O que eu fiz: Neguei acesso a conta LOCAL e SYSTEM, a concedi acesso total a conta do administrador. Assim eu posso deletar os valores sem que a praga escreva os valores novamente (isto acontecerá se a conta SYSTEM continuar com permissão de acesso nesta chave). Eu mantive a chave GbpSv, somente excluí os valores e subchaves. Mantendo a chave com permissão negada à conta SYSTEM me garante que o GbpSv não irá escrever nada lá novamente.

Terminando a execução dos processos

Siga então os passos sugeridos pelo Romulo Ceccon: Abra o Process Explorer para que possamos terminar a DLL. A diferença é que além da DLL estar sob o processo WinLogon.exe, encontrei-a também sob o processo Explorer.exe. A melhor forma que encontrei foi procurar todas as ocorrências usando a opção FIND do Process Explorer, procurando pelo nome da DLL. Encontrei duas ocorrências e terminei ambas as threads. Terminei também o serviço GbpSv.exe, visível na lista de processos.
Agora que as pragas não estão em execução, temos que remover as entradas de autoexecução na Registry usando o Autoruns.

Desabilitando a inicialização automática

Execute o Autoruns e na aba EVERYTHING, percorra toda a lista e remova todas as entradas referentes a DLL e ao serviço GbpSv.exe. TODAS as entradas devem ser removidas. Na dúvida, tudo que tiver Gbieh como parte da descrição refere-se à praga e pode ser excluído.

Após remover todas as entradas efetue um boot no sistema. Quando o Windows iniciar, o serviço GbpSv.exe não deverá constar mais na lista de processos em execução no TaskManager. E nem a DLL gbiehabn.dll (ou gbiehcef.dll, etc.) deverá constar no Process Explorer.
Isto significa que, finalmente, poderemos excluir o arquivo GbpSv.exe!
Basta ir na pasta C:\Arquivos de programas\GbPlugin\ e teclar um majestoso DELETE e ver o arquivo ir pro lugar de onde não deveria ter saído.

Irei reinstalar a praga no meu sistema e monitorá-la um pouco mais para aumentar meu entendimento. Mais sobre isto depois.

Usando Temas do Windows em programas Delphi 5 e 6

Recentemente me deparei com um problema bem incômodo ao usar temas através do Theme Manager de Mike Lischke.
O maior problema foram os TBitBtn's que não eram desenhados de acordo com o tema do Windows pelo Theme Service. Procurei várias soluções e não encontrei nada, nem no FAQ da soft-gems. Depois de mais alguma pesquisa, finalmente descobri!
A causa e a solução do problema são relativamente simples:
O problema só ocorria em forms que continham TBitBtn e cujo Owner não era o objeto Application. Uso frequentemente diálogos chamando uma função de classe que cuida de sua criação e destruição da seguinte forma:

class function TMyDialog.Execute: boolean;
var
  Dlg: TMyDialog;
begin
  Dlg := TMyDialog.Create(nil);
  try
    Result := Dlg.ShowModal = mrOk;
  finally
    Dlg.Free;
  end;
end;

Usado desta forma os TBitBtn's neste diálogo não serão desenhados de acordo com o tema do Windows. O melhor a fazer é substituir o código por:

class function TMyDialog.Execute: boolean;
var
  Dlg: TMyDialog;
begin
  Dlg := TMyDialog.Create(Application);
  try
    Result := Dlg.ShowModal = mrOk;
  finally
    Dlg.Free;
  end;
end;

Neste caso o TBitBtn é desenhado corretamente!