Security Tool HijackThis Goes Open Source
wiredmikey writes "The popular free security tool HijackThis has been open sourced by its owner, Trend Micro. The tool scans systems to find settings that may have been modified by spyware, malware or other programs that have wiggled their way onto a system and caused problems. Downloaded over 10 million times, HijackThis generates reports to help users analyze and fix an infected or problem computer. But the tool is not designed for novices – and doesn't actually determine what's good or bad. That's up to you, but it is a good way to keep an eye on things and possibly locate anomalies that may have been missed by other security products. Trend Micro warns that if you don't know what you're doing, it's probably not a good idea to make any changes to your computer settings and system files. Trend Micro acquired the tool from creator Merijn Bellekom in 2007, and has offered it for free ever since, but now is making the code available to the public. The code, originally written in Visual Basic, is now officially available at Sourceforge here."
'src' directory is empty.
My PHB says that free stuff can't be any good. Surely, we'd be much better off by throwing 7 figures at Symantec. ;)
Since it was "originally written in Visual Basic", I wonder what language does it use now?
It turns out, it still uses Visual Basic. Not sure why was the summary written that way.
Say I find a Windows PC, remove its hard drive for analysis, put it in a USB enclosure, and mount it read-only on a Linux box to make the scan process immune to boot-sector malware. Is there a Free compiler capable of compiling Visual Basic code? As of a year ago, there wasn't. If not, the program is Java trapped.*
* The term's origin is historical; Java itself is no longer Java trapped, but plenty of other languages and APIs are.
Hijacjk This ain't jsut for helpdesk monkeys; we use it constantly in Enterprise software testing. Server works fine, Client works fine, OS checks out, software ain't working. Run HT and find the culprit pretty quickly, and when your customers are telcos and banks doing short-cycle upgrades for occasionally legit reasons, your on-site guys need to find fast answers.
...to see how HJT does what it does (in source). AFAIK, it's one of the better tools for finding things that get missed by most AV packages. Dangerous but comprehensive.
I think the IT world collectively owes Merijn Bellekom some beers. Think about how many of us his tool has helped out over the years!
I would like so much to have an HijackThis that runs after every program installation (and possibly every hour) that warns me each time my configuration has changed, just to know that something fishy has possibly happened.
http://sourceforge.net/projects/hjt/ /me looks under license /me looks at you
Was that hard?
Like Borland Delphi, AND, that said? 64-bit ports are easy too (Delphi XE2).
* The reason I note this, is that this program, like so many others like it, read the registry (for malware traces, doubtless based on a single C/C++ style structure/Pascal-Object Pascal record variable that holds the signatures to look for so they can all be treated as a SINGLE variable whose elements get parsed & compared to a registry entry scanned...), and filesystems.
(No, I haven't SEEN the sourcecode, but I wager that's how it's done for efficiency's sake)...
Nice part is, that you'd end up with a faster program than VB yields as well (double bonus), AND, a 64-bit port's SIMPLE in Delphi (easier than any other language imo, that's not runtime interpreted that is - though you have that option in Delphi XE2 also (.NET)).
My guess is that it's a "Find First-Find Next" read of disks/files/folders AND registry entries for the most part (not a hell of a lot to learn & use really, once you "get the hang of it" in Win32/64)... but, that's just a guess (on how I'd design such a tool @ least).
APK
P.S.=> Porting VB to Delphi's pretty easy, and same with C++ to Delphi (or, vice-a-versa in both cases), so... there you are!
...apk
Is that a 32-bit program does NOT have "full" registry hives access in 64-bit systems... hence, possibly WHY a 64-bit port's a GOOD idea - for now though? As long as malwares do NOT go "64-bit" as well?? 32-bit CAN & WILL "do the job"... for now, that is.
APK
P.S.=> Am I interested in this? No... got plenty of code to work on here myself, but it's worth pointing out for those who MAY indeed, be interested in this... apk
http://news.slashdot.org/comments.pl?sid=2680271&cid=39093835
And, I'd wager I am pretty fairly CLOSE to how it does, what it does...
(I've written enough stuff like it since 1994's all the way through the Win16/32/64 strata's why (in the freeware/shareware and commercial software world)).
APK
P.S.=> I haven't SEEN the sourcecode, but... I'd wager my idea's @ least CLOSE to what it does, & how it goes about it... for those of you that DO look @ it?? Please - Feel FREE to correct me assuming my "guesswork's" wrong/off...apk
I always used to say "These are so useful, MS should buy them and make them official." Well, they did. They are top notch for when you need to do some finer diagnosis on what is going on with a system.
I also pull them out when I have some old software that refuses to run without being an admin. By monitoring file access, registry access, and so on I have always been able to find out what it needs to run deprivileged.
Monitor for size changes (easy) to the registry files here -> C:\Windows\System32\config ... Pretty easy, & would signal that something has altered the registry. OF course, there'd be LOADS of "false positives" because the registry does change (gets read/written to, like mad, & especially harmlessly by apps saving recently used filelists, etc./et al)... this @ least, would "alarm/signal" changes are indeed, occurring, but?? It's NOT very specific and would yield "falsies"... Especially @ System Restart.
Now, barring that "primitive method"?
* You could do the same, & monitor SPECIFIC areas of the registry (or filesystem for that matter in folders/files you choose), by the same method (timers) - wouldn't be too difficult really in concept, especially considering that HiJackThis already monitors many of the areas concerned as far as malware, and all you'd have to do is set those routines into operation off said timer.
APK
P.S.=> It'd still be work, but... You'd be surprised that it's not "turning the sky green & grass blue" doing it, & again:
IF you were to start out with say, this HiJackThis codebase?? It'd be pretty short work imo/estimation because it has routines that already do the job (but, still work, but not "loads more" than the program source already does)... apk
"The RegDeleteKey function cannot be used to access an alternate registry view."
and
"Note The Wow6432Node key is reserved. For compatibility, applications should not use this key directly."
* For a "full-blown" antivirus/antispyware/antimalware program (unlike HiJackThis, which is ONLY a reader/reporter really)? It won't work... not that I know of @ least!
APK
P.S.=> Those are the 'snags' you'd hit when attempting to do a "malware removal" program that does BOTH 32/64 bit...
Simply because part of THAT kind of work? Deletes (of malware registry entries)!
So - hence, why a 64-bit port's a "good idea" & especially into a faster language than VB or runtime interpreted ones like JAVA/.NET... I'd lean to C++ or Delphi on that account (very fast, & faster build times than ASM)...
... apk
http://msdn.microsoft.com/en-us/library/aa384129(v=vs.85).aspx
APK
P.S.=> I am GLAD I brought this point up, and that you cited your "workaround-objection" (in case anyone decides to use HiJackThis' sourcecode now that it's open) - the reason I mention this, is simple: IT GIVES OTHERS A 'FOUNDATION' TO BUILD ON, but, more importantly?
This codebase's a potential foundation for a new antispyware/antivirus/antimalware application and standing on the shoulders of giants here would be, a way.
(1/2 way there @ least, or rather, a 1/3... because HiJackThis is ONLY A READER/REPORTER, and you'd have to have the 'signatures' of the malwares too (do they provide that? I wouldn't *think* so, but who knows!))
Yes... that's the other part that might be "prohibitive" & possibly impossible to acquire fast WITHOUT licensing (and would demand upkeep) as far as detection signatures.
The thing holding one back as I noted for this?
The RegKeyDelete... Thus, it looks as if you'd HAVE to have a 64-bit port really, to work on 64-bit reg view via reflection.
If they aren't already doing this, an open source product should make it a bit easier for the malware writers to test out how well hidden their product is (or how closely it represents the noise experienced during a normal day of computing).
Ask me about repetitive DNA
You could always get a life, realize that operating systems are not the end all of existence, and use a Windows machine to scan the hard drive.
True, but why does mounting a USB hard drive read-only require modifying the registry?
Didn't Microsoft once provide a translation tool useful for porting a Visual Basic application to VB.NET, not unlike what the Python Software Foundation would later provide around the 2.6 days?
it would be rather like expecting The Gimp to implement ext4 read / write functions so that one can launch it under windows and access files on a Linux FS
You're right. A better idea is to implement a network redirector service and point GIMP at its drive letter. Likewise, a port of HJT to Linux might include a way to read registries other than that of the boot volume, possibly relying on a separate service to interpret the NT hive files.
But has anyone else noticed the /src folder is empty?
In tests vs. MSVC++, Delphi literally DOUBLED it in string processing and mathwork too (in Visual Basic Programmer's Journal Sept/Oct 1997 issue "Inside the VB5 Compiler" issue - Delphi swept the floor with both, & took 6/10 tests and in a competing language's publication no less ironically).
* A tool like this one would use stringwork for comparisons of regkey reads vs. type record/structure of "badware" mugshots/signatures - I'd want that "instant speed advantage" in fact... fact is, that's why I noted it, & "leaned towards it" - that, or C++ variants (due more to portability here though).
HOWEVER:
Via the Delphi/C++ Builder XE2 RAD Studio, I can also target even Apple stuff...
Linux's possible too, via Kylix (but it needed 'hacks' to its configuration to run on Linux past 2004 or so - was like Delphi 5 really and produced by Borland also).
Anyhow/anyways - I like it for that. Build fast like VB started the ball rolling with, & then get C++ (or better in math & string work) performance!
I also like & use C++ (via various compilers), & it's good stuff too, & porting's possible (more pain in it than in Delphi though I have found) going 32->64 bit though... but it is widely used, and a high-performance code generator.
APK
P.S.=> AND, for 32 and 64 bit versions, and the same exact codebase too (sometimes you have to do typecast conversions making them bigger/wider though, especially bringing up older Delphi code into it for 64 bit, but that's not THAT hard, lol).
Using it, you build fast GUI interfaces like VB, and yet have the power & speed (more even) of MSVC++ (but faster buildtimes + compiles (Pascal's always been noted for unbelievably fast compile time really afaik & that's been since 1992 using it here)), per that test above I noted for example done in respectable publication, in performance of code (especially math & strings)... apk"
Muhaha... no respect these days.
Looking at the source, specifically modEncrypt.bas,
sEncryptionPhrase = "F*CK YOU SPYWARENUKER AND BPS SPYWARE REMOVER!"
Love it! Freedom of speech.. self expression.. now of course if you worked for someone who could fire you over such remarks. That could be a problem.