Here I'll describe how the component installs on your computer and how to remove it while still been able to use Internet Banking. Since all institutions use the same software I've just picked one, Caixa Econômica Federal, hoping the exact same procedures apply to the others.
Analysis of installation
So, let's put our hands on it. After opening the bank's home page and clicking on the top right button ("Acessar") we arrive at the first screen of Internet Banking (Figure 1), where we enter our username. If it's not been installed yet, we'll be asked now to install the security module ("Módulo de Segurança") (Figure 2). At this stage you might have already noticed how the window title is marred with punctuation characters as we move across pages (more on this later). We then allow the component to install, taking us to the second screen, which presents the virtual keyboard (Figure 3).
The software is now installed. Whenever I install something on my computer I like to know whether anything has been configured to execute on system start-up, because that's what makes your computer slow. And that was what caused my first bad impression about G-Buster Browser Defense. If we launch Autoruns it shows us three new entries in the registry. Figure 4 and Figure 5 contains the non-Microsoft entries before and after installing G-Buster Browser Defense on my computer. The main component is Gbieh Module, or gbiehCef.dll‡, a file under "%WINDIR%\Downloaded Program Files".
What really frightened me the most was to discover that gbiehCef.dll is injected into the Winlogon process: Process Explorer comes to our help (Figure 6). Being loaded by Winlogon means the software survives logoffs, and will be running even when we don't need it, possibly eating valuable CPU cycles. It's even worse: if a computer has many users and only one needs the Internet Banking service every user must pay the price for it.
Just to be sure my ranting isn't totally reasonless, let's take Process Monitor and see how G-Buster performs. If we leave it running for some seconds with no filters set we note that some kind of polling is screamingly taking place. And you should know that polling kills. Every 5 seconds a thread in Winlogon reads a number of registry entries, checking for its values. Figure 7 illustrates the polling of the PendingFileRenameOperations key. Process Explorer brings out the culprit (Figure 8), gbiehCef.dll, when we search it for the thread id shown in Process Monitor.
Observing the polled registry entries is enough to guess what the security component is doing: check any attempt of its removal. That's likely to prevent malicious programs from disabling it. But that leaves the average user with no option to uninstall it. Deleting the auto-run entries has no effect because they will be recreated. Trying to delete or move the file containing the component is impossible. Scheduling the removal to the next reboot is also not possible, as the results of Process Monitor already suggested us. Rebooting into safe mode doesn't help either. We are left with the Recovery Console, which lets us delete the offending file and, an easier way, Process Explorer.
In the same screen we found the polling thread we can kill it (the "Kill" button). Now that nothing is polling the registry anymore we may open Autoruns and delete all related entries (those three whose description reads "Gbieh Module"). We can't delete the file because it's still in use (we don't need to, as you'll see in a while). Now, since we have killed a thread from a System process, we'd better reboot the computer, otherwise we may leave the operating system unstable (the component might have left a lock open inside Winlogon before we killed it).
Upon rebooting we may inspect with Process Explorer and Autoruns and make sure G-Buster is not there anymore. However, the component will attempt to install itself again in the auto-run entries if we hit the Internet Banking site (we are safe if we just open the bank's home page) because the Internet Explorer component is still installed and the browser will not ask our permission to execute it. Now the cool part: if you have a Limited User Account, as I do, you'll be able to use the Internet Banking service without the hassle of installing G-Buster. The site will open and the component will be executed by Internet Explorer, but it will fail to change the start-up entries or inject the library into Winlogon (Figure 9). Fortunately, it doesn't attempt to modify the per-user start-up entries either. Logging on and off is enough to get rid of G-Buster, and we are back with a clean system (gbiehCef.dll will be kept loaded by Explorer until we log off).
If, by accident, you visit the Internet Banking site under an account with administrator privileges, you'll need to repeat the steps to identify the Winlogon thread and the auto-run entries. You'll notice that on the second install an additional Windows service (gbpsv.exe, G-Buster Browser Defense - Service) will be registered: that could be to a bug in the install process. The same steps apply, though.
I understand the purpose of G-Buster Browser Defense. It monitors registry keys (hooking would be a better solution than polling, however) to prevent a specially crafted software to disable it. It scrambles characters on the Internet Baking page title maybe in an attempt to slip away from the eyes of a keylogger looking for a certain page. Perhaps it monitors your Internet usage trying to identity suspects of forgery. It's not clear whether it sends personal information or downloads anything. There's no agreement or consent dialog.
What I don't understand is how that solution is better than an "on demand" scanner. It could scan the system just before the customers enter their information, and not full time. Sure, a trojan can be built to hide itself from an outdated scanner but, as demonstrated here, it's as easy to disable an outdated real-time scanner and bypass any security checks. Changing the title is also pointless if the trojan looks for the window's content.
And there is still another problem: G-Buster Browser Defense is a component used by more than one bank. That makes it a more interesting target of hackers because a single trojan solution can defeat the defenses of many banks. By the way, what looks like a poor design issue: if the component is the same for many sites, why does it need a separate installation for each one? It scans and polls the system twice! Finally, what can bother much more users, even those not worried about performance, is the need for an ActiveX component, locking them into Internet Explorer.
Regarding anti-phishing solutions, I like the one adopted by the Brazilian HSBC bank. You're presented with a box containing 9 lines of 4 characters each. To enter the password you must locate the line which contains the first character of your password and click the arrow next to it. Repeat for the second character and so on. A spying program can't guess which character you thought about when you clicked the arrow. Heck, neither does a person sitting on your side! It's not the perfect solution, since the careful analysis of the clicks of many logins may reveal the password, but I find it a lot less obtrusive than G-Buster and as effective as. No ActiveX, cross-browser and cross-platform.
Note: I should say that I made many assumptions in the analysis here and thus could be totally wrong in some points. I had nothing at hand, though. As stated previously, it's not clear anywhere what the component does nor how it does it.
† The footnote below names some of the other banks.
‡ Gbieh Module has a different filename depending on the bank:
|Banco do Brasil||gbieh.dll|
|Caixa Econômica Federal||gbiehCef.dll|
|Banco Real ABN AMRO||gbiehabn.dll|
|Mercantil do Brasil||gbiehbmb.dll|