Thanks to Christoph Murauer for an excellent guide to installing ClamAV 0.97.3 on Mac OS X!
Check out Christoph's ClamAV 0.97.3 install guide here.
Thanks to all of our ClamAV community contributors on their documentation, if you'd like to contribute some documentation, please feel free to contact me at joel@snort.org.
As always Snort.org makes no warranty or edits to submitted documentation, and we'd like to thank the contributors of the documentation for their time.
Friday, December 9, 2011
Friday, November 4, 2011
About one year ago Alain presented the LLVM-based ClamAV bytecode. We've realised that, besides that initial introduction, we've never shown any real life use case, nor did we ever demonstrate the incredible power and flexibility of the ClamAV bytecode engine. I'll try to fix that today.
I decided to target the Xpaj virus because it's an polymorphic file infector, which means that it is not easily to detected with plain signatures.
Please note that I'm just focusing on the detection of Xpaj via bytecode signatures, not on Xpaj itself which was already thoroughly reviewed and explained.
Pic.1: Clean file
Pic.2: Same file as above, but infected with Xpaj
For the scope of this blog post, it suffices to say that Xpaj is a file infector targeting 32-bit Windows executables and DLLs which employs entry-point obfuscation (EPO) capabilities in order to make the detection harder. In particular, the virus code hijacks a few API calls in the .text section of the file, diverting them to its own routine.
This routine is located within the .text section and consists of a series of small chunks of code connected by jumps. Most of that is “garbage”. The only thing this preliminary block of code does is compute the code address for the next stage and jump to it. The actual viral code, as well as the overwritten blocks, are stored, in encrypted form, inside the data section.
Well... enough technical info already. From now on I'll just focus on the Xpaj detection, or rather, the detection of a rather simplified version of it in order to keep this blog post small and readable. The geeks can find the full source code here.
Let's start with a look at the virus entry point code:
After that we have some optional trash (do nothing) code, and then the virus saves the content of 3 random registers, which will be clobbered later by both the virus code and the trash engine too.
So far we can still get away with a signature that makes use of a wildcard, however we still don't have much: stack allocation and 3 registers saved. That's still not enough.
Next, we've got the trash engine in all its glory, and eventually we reach a function call.
The trash code may or may not jump to another chunk of code. And that effectively kills our ability to use a normal (ndb or ldb) signature.
Not all is lost, though. We can still write a small piece of bytecode signature which follows the code through the trash and checks for specific fingerprints.
In particular we plan to scan the code section for something that looks like the following:
Back outside the call we have a couple of other less interesting fingerprints and eventually the virus will jump to some runtime computed location. There are two ways by which this is achieved:
Ok let's code...
First we look for the 5 static bytes at the virus entry point (EP):
As for the actual opcode matching, here are a few examples. The first thing we are interested in is the 3 pushes. In terms of bytecode we need to check that:
I decided to target the Xpaj virus because it's an polymorphic file infector, which means that it is not easily to detected with plain signatures.
Please note that I'm just focusing on the detection of Xpaj via bytecode signatures, not on Xpaj itself which was already thoroughly reviewed and explained.
Pic.1: Clean file
Pic.2: Same file as above, but infected with Xpaj
For the scope of this blog post, it suffices to say that Xpaj is a file infector targeting 32-bit Windows executables and DLLs which employs entry-point obfuscation (EPO) capabilities in order to make the detection harder. In particular, the virus code hijacks a few API calls in the .text section of the file, diverting them to its own routine.
This routine is located within the .text section and consists of a series of small chunks of code connected by jumps. Most of that is “garbage”. The only thing this preliminary block of code does is compute the code address for the next stage and jump to it. The actual viral code, as well as the overwritten blocks, are stored, in encrypted form, inside the data section.
Well... enough technical info already. From now on I'll just focus on the Xpaj detection, or rather, the detection of a rather simplified version of it in order to keep this blog post small and readable. The geeks can find the full source code here.
Let's start with a look at the virus entry point code:
push ebpWhile these are technically enough bytes to create a signature based on the opcodes, such a signature would be a really bad idea. What we have there, in fact, is just a pretty standard function entry point.
mov ebp, esp
sub esp, XX
After that we have some optional trash (do nothing) code, and then the virus saves the content of 3 random registers, which will be clobbered later by both the virus code and the trash engine too.
So far we can still get away with a signature that makes use of a wildcard, however we still don't have much: stack allocation and 3 registers saved. That's still not enough.
Next, we've got the trash engine in all its glory, and eventually we reach a function call.
The trash code may or may not jump to another chunk of code. And that effectively kills our ability to use a normal (ndb or ldb) signature.
Not all is lost, though. We can still write a small piece of bytecode signature which follows the code through the trash and checks for specific fingerprints.
In particular we plan to scan the code section for something that looks like the following:
mov edi, ediHere we are inside "$DELTA"..
push ebp
mov ebp, esp
sub esp, $STACKSIZE
[optional trash]
push eax (*)
push edx (*)
push edi (*)
(*) note, the registers are chosen randomly among the 32 bit general purpose registers except esp and ebp
[optional trash]
call $DELTA
[optional trash]
mov register, [ebp-stacksize]
[optional trash]
ret
Back outside the call we have a couple of other less interesting fingerprints and eventually the virus will jump to some runtime computed location. There are two ways by which this is achieved:
jmp local_varor
push local_var
ret
Ok let's code...
First we look for the 5 static bytes at the virus entry point (EP):
seek(begin_of_the_code_section, SEEK_SET);Then we set ourselves in a disassembly loop and we check if we got what we expect. Something along the lines of:
cur = file_find_limit("\x55\x89\xe5\x83\xec", 5, end_of_the_code_section);
if(cur < 0) return 0;
while(1) {
struct DIS_fixed d;
int next = DisassembleAt(&d, cur, space_remaining);
if(next == -1) break; /* disasm error */
cur = next; /* cur now points at the next op */
[here we check the op]
}
As for the actual opcode matching, here are a few examples. The first thing we are interested in is the 3 pushes. In terms of bytecode we need to check that:
1. the opcode is OP_PUSH
2. the argument is a register
3. the register is one of (eax, ebx, ecx, edx, esi, edi)
In BC that'd be:
1. the opcode is a call
i.e.: d.x86_opcode == OP_CALL
2. the argument is an immediate relative value
i.e.: d.arg[0].access_type == ACCESS_REL
Then we pick the call target and we "jump" to it, not before saving the return address:
Another interesting example is the trash code parser. There can be 3 types or trash ops:
2. the argument is a register
3. the register is one of (eax, ebx, ecx, edx, esi, edi)
In BC that'd be:
d.x86_opcode == OP_PUSHAltogether:
d.arg[0].access_type == ACCESS_REG
d.arg[0].u.reg == REG_EAX || d.arg[0].u.reg == REG_ECX || d.arg[0].u.reg == REG_EDX || d.arg[0].u.reg == REG_EBX || d.arg[0].u.reg == REG_ESI || d.arg[0].u.reg == REG_EDI
if(d.x86_opcode == OP_PUSH && d.arg[0].access_type == ACCESS_REG && (d.arg[0].u.reg == REG_EAX || d.arg[0].u.reg == REG_ECX || d.arg[0].u.reg == REG_EDX || d.arg[0].u.reg == REG_EBX || d.arg[0].u.reg == REG_ESI || d.arg[0].u.reg == REG_EDI))Then we need to check for the call $DELTA. In other words we check that:
1. the opcode is a call
i.e.: d.x86_opcode == OP_CALL
2. the argument is an immediate relative value
i.e.: d.arg[0].access_type == ACCESS_REL
Then we pick the call target and we "jump" to it, not before saving the return address:
int32_t target_address, return_address;
seek(cur-4, SEEK_SET); /* we position onto the call argument */
read(&target_address, sizeof(target_address)); /* we read the relative jump value */
target_address = le32_to_host(target_address); /* we handle big endian machines */
retaddr = cur; /* we save the address to return to */
target_address = cur + target_address; /* we compute the addres to jump to */
Another interesting example is the trash code parser. There can be 3 types or trash ops:
A. Arithmetic or logic operation on a stack allocated DWORD based on an immediate or register value. Eg:
1. d.x86_opcode is one of (OP_ADD, OP_ADC, OP_AND, OP_MOV, OP_OR, OP_SBB, OP_SUB, OP_XOR), i.e.:
2. the dest argument is a mem region:
3. the access size is a DWORD:
4. the dest argument is in the form [ebx-displacement]:
5. the displacement fits within the local funcion stack:
6. the source argument can be anything (i.e. a register or an immediate value): nothing to check!
Case B is very similar, except the arguments are reversed:
1. The dest argument is a register:
2a. The src arg is either another reg:
2b. Or it is an immediate:
2c. Or it is a stack based DWORD:
Finally, case C... Here we:
1. Check that the op is a jmp:
2. Check that it's got an immediate argument:
3. Then we can "jump" to the next position:
mov [ebp-xx], immedB. Arithmetic or logic operation on a 32bit register based on a stack allocated DWORD or an immediate value. Eg:
add [ebp-xx], register
mov register, [ebp-xx]C. A jump to the next chunk of code.Eg:
sub register, other_register
jmp next_chunkMore in details, for case A we check that:
1. d.x86_opcode is one of (OP_ADD, OP_ADC, OP_AND, OP_MOV, OP_OR, OP_SBB, OP_SUB, OP_XOR), i.e.:
d.x86_opcode == OP_ADD || d.x86_opcode == OP_ADC || d.x86_opcode == OP_AND || d.x86_opcode == OP_MOV || d.x86_opcode == OP_OR || d.x86_opcode == OP_SBB || d.x86_opcode == OP_SUB || d.x86_opcode == OP_XOR
d.arg[0].access_type == ACCESS_MEM
d.arg[0].u.mem.access_size == SIZED
d.arg[0].u.mem.scale_reg == REG_EBP && d.arg[0].u.mem.scale == 1 && d.arg[0].u.mem.add_reg == REG_INVALID
d.arg[0].u.mem.displacement <= -4 && d.arg[0].u.mem.displacement >= -(int32_t)stacksize
6. the source argument can be anything (i.e. a register or an immediate value): nothing to check!
Case B is very similar, except the arguments are reversed:
1. The dest argument is a register:
d.arg[0].access_type == ACCESS_REG
2a. The src arg is either another reg:
d.arg[1].access_type == ACCESS_REG
2b. Or it is an immediate:
d.arg[1].access_type == ACCESS_IMM
2c. Or it is a stack based DWORD:
d.arg[0].access_type == ACCESS_MEM && d.arg[0].u.mem.access_size == SIZED && d.arg[0].u.mem.scale_reg == REG_EBP && d.arg[0].u.mem.scale == 1 && d.arg[0].u.mem.add_reg == REG_INVALID && d.arg[0].u.mem.displacement <= -4 && d.arg[0].u.mem.displacement >= -(int32_t)stacksize
Finally, case C... Here we:
1. Check that the op is a jmp:
d.x86_opcode == OP_JMP
2. Check that it's got an immediate argument:
d.arg[0].access_type == ACCESS_REL
3. Then we can "jump" to the next position:
int32_t rel;
seek(cur-4, SEEK_SET); /* move onto the jmp argument */
read(&rel, sizeof(rel)); /* read it */
rel = le32_to_host(rel); /* make it big endian safe */
cur += rel; /* "jump" to it */
Blog post by Alberto Wu.
Monday, October 17, 2011
Just released is version 0.97.3 of ClamAV. The following changes are noted in the ChangeLog distributed with the package:
You can download the newest version of ClamAV by visiting the ClamAV.net website, or at the following download links:
Mon Oct 10 14:41:48 CEST 2011 (tk)* freshclam/manager.c: fix error when compiling without DNS support (bb#3056)Sat Oct 8 12:19:49 EEST 2011 (edwin)* libclamav/pdf.c: flag and dump PDF objects with /Launch (bb #3514)Sat Oct 8 12:10:13 EEST 2011 (edwin)* libclamav/bytecode.c,bytecode_api.c: fix recursion level crash (bb #3706).Tue Aug 2 17:03:33 CEST 2011 (tk)* docs: clarify behavior of --scan-*/Scan* options (bb#3134)Mon Jul 25 16:09:19 EEST 2011 (edwin)* libclamav/bytecode_vm.c: fix opcode 20 error (bb #3100)Thu Sep 15 14:44:11 CEST 2011 (tk)* freshclam: fix pidfile removal (bb#3499)Sun Aug 21 17:05:24 EEST 2011 (edwin)* libclamav/pdf.c: fix incorrect blocking of some encrypted PDF with empty user passwords. (bb #3364)Wed Aug 3 15:41:28 CEST 2011 (tk)* sigtool/sigtool.c: fix calculation of max signature lengthYou can download the newest version of ClamAV by visiting the ClamAV.net website, or at the following download links:
Tuesday, October 11, 2011
Christoph Murauer, one of the many ClamAV and Snort users in the community has written Snort User guides for Lion which we've linked to before over on the Snort blog.
This time Christoph has written a guide for using ClamXav and ClamAV on OSX Lion 10.7. If you are interested in Antivirus protection for on OSX in any way, I suggest a read of his guide.
Check out the article here.
Thursday, August 25, 2011
Today I have the following on my desk:
The malware usually enters your PC via a drive-by download or the user is tricked into loading the file – for example, if the user wants to see some video on the web and the page tells them that they need an additional plugin. Your Windows security center pops up and tells you that you have no antivirus, no firewall, then the "Antivirus" pops up and starts a scan – it doesn't really scan anything, but shows you a nice animation and claims to detect all kind of malicious software on you disk. If you try to start a program – no matter what, you get the information, that a virus was found and blocked – as a result, you can't run any program – but guess what, help is near and if you purchase the full version of this Antivirus it will help and protect you. Nice of them, isn't it?
In our special case the executable copies itself into the
The removal is quite easy, locate the process in the taskmanager, terminate it, run regedit, terminate the process again (yep, it started again when you started regedit), search the registry for all occurrences of the "three letter" process name. (But make sure that you enter the full path as a search string!) Delete each occurrence and then reboot you machine. After reboot you can also delete the malware executable itself. Done.
Ok, that's really nothing new – but why does it work – as we know a lot of people really click the “Buy now” button and enter their CC information – otherwise such rogue programs wouldn't be so widespread. If you want to see more data on how successful this business is, take a look at the pdf from Alain Zidouemba - it can be found here.
The problem is, that people like you and me – people that work in the computer security field –have no problem to tell the good from the bad, we know all the vendors, we know how to recognize a legit website from a fake, simply because we do this for a living or as a hobby. But what to tell the people that are targeted by such rogue software and that don't have the time, the knowledge and interest in diving into the matter and find out what AV to use and how to tell that it's a real AV and not a fraud? All they want is just “some” AV, or some firewall or whatever.
You can start to tell about various well known vendors, throw with feature lists, ssl certificates, safe browsing and much more and in the end you have someone in front of you, that is bored, confused and / or sleeping.
If you really want to give a short answer, how to make sure that a security product is really a security product and not some fraud – here it is:
The not so short answer – go into a real shop, with real salesman and ask for an antivirus. Whatever you take home with you wont be a rogue antivirus – cause they are only sold on the web but none of them has ever been seen in a computer store, inside a box with a price label on it. Really.
But now, that you read this, – you can also try Immunet Protect – it's not available in stores but works really great – and is combined with ClamAV!
The malware usually enters your PC via a drive-by download or the user is tricked into loading the file – for example, if the user wants to see some video on the web and the page tells them that they need an additional plugin. Your Windows security center pops up and tells you that you have no antivirus, no firewall, then the "Antivirus" pops up and starts a scan – it doesn't really scan anything, but shows you a nice animation and claims to detect all kind of malicious software on you disk. If you try to start a program – no matter what, you get the information, that a virus was found and blocked – as a result, you can't run any program – but guess what, help is near and if you purchase the full version of this Antivirus it will help and protect you. Nice of them, isn't it?
In our special case the executable copies itself into the
%USERPROFILE%\Local Settings\Application Data (for example: C:\Documents and Settings\username\Local Settings\Application Data) with a random, three letter name – like dpx.exe. It also adds some keys to the registry to make sure it will be started upon boot and it also adds a key that makes sure that it will be started as soon as you start a program on you Computer. So much for the self defense.The removal is quite easy, locate the process in the taskmanager, terminate it, run regedit, terminate the process again (yep, it started again when you started regedit), search the registry for all occurrences of the "three letter" process name. (But make sure that you enter the full path as a search string!) Delete each occurrence and then reboot you machine. After reboot you can also delete the malware executable itself. Done.
Ok, that's really nothing new – but why does it work – as we know a lot of people really click the “Buy now” button and enter their CC information – otherwise such rogue programs wouldn't be so widespread. If you want to see more data on how successful this business is, take a look at the pdf from Alain Zidouemba - it can be found here.
The problem is, that people like you and me – people that work in the computer security field –have no problem to tell the good from the bad, we know all the vendors, we know how to recognize a legit website from a fake, simply because we do this for a living or as a hobby. But what to tell the people that are targeted by such rogue software and that don't have the time, the knowledge and interest in diving into the matter and find out what AV to use and how to tell that it's a real AV and not a fraud? All they want is just “some” AV, or some firewall or whatever.
You can start to tell about various well known vendors, throw with feature lists, ssl certificates, safe browsing and much more and in the end you have someone in front of you, that is bored, confused and / or sleeping.
If you really want to give a short answer, how to make sure that a security product is really a security product and not some fraud – here it is:
Buy a box.
The not so short answer – go into a real shop, with real salesman and ask for an antivirus. Whatever you take home with you wont be a rogue antivirus – cause they are only sold on the web but none of them has ever been seen in a computer store, inside a box with a price label on it. Really.
But now, that you read this, – you can also try Immunet Protect – it's not available in stores but works really great – and is combined with ClamAV!
Tuesday, August 9, 2011
An interesting article over on DarkReading highlighting one of the presentations Sourcefire gave at BlackHat 2011 last week in Las Vegas, NV by our Malware group.
http://www.darkreading.com/cloud-security/167901092/security/antivirus/231300516/70-percent-of-infected-consumer-machines-hit-with-multiple-malware-types.html
http://www.darkreading.com/cloud-security/167901092/security/antivirus/231300516/70-percent-of-infected-consumer-machines-hit-with-multiple-malware-types.html
"Overall, one out of every six or seven consumer machines is infected, according to new malware statistics gathered from Sourcefire's software-based ClamAV and cloud-based Immunet customers during the first three weeks of July."Head on over to the above link for the full article.
Monday, July 25, 2011
ClamAV 0.97.2 fixes problems with the bytecode engine, Safebrowsing
detection, hash matcher, and other minor issues. Please see
the ChangeLog file for details.
Download : http://downloads.sourceforge.net/clamav/clamav-0.97.2.tar.gz
PGP sig : http://downloads.sourceforge.net/clamav/clamav-0.97.2.tar.gz.sig
Bugfixes : http://www.clamav.net/release-info/bugs/0.97.2
ChangeLog: http://www.clamav.net/release-info/changelog/0.97.2
*** Announcement ***
The ClamAV project is launching a new service called "Third Party web interface". It will allow selected individuals/organizations to publish ClamAV Virus Databases (CVD) through the ClamAV mirror network.
If you choose to publish your signatures through our Third Party web interface you will benefit from the following:
The service is still in beta, you are welcome to contact Luca Gibelli
if you intend to join the beta program.
We especially welcome those who already distribute their own unofficial signatures to join. A list of databases distributed by the new service will be available at http://www.clamav.net/download/cvd/3rdparty
We will be happy to answer any questions you might have.
detection, hash matcher, and other minor issues. Please see
the ChangeLog file for details.
Download : http://downloads.sourceforge.net/clamav/clamav-0.97.2.tar.gz
PGP sig : http://downloads.sourceforge.net/clamav/clamav-0.97.2.tar.gz.sig
Bugfixes : http://www.clamav.net/release-info/bugs/0.97.2
ChangeLog: http://www.clamav.net/release-info/changelog/0.97.2
*** Announcement ***
The ClamAV project is launching a new service called "Third Party web interface". It will allow selected individuals/organizations to publish ClamAV Virus Databases (CVD) through the ClamAV mirror network.
If you choose to publish your signatures through our Third Party web interface you will benefit from the following:
- before publishing the signatures, we will test them for false positives against our false positive file collection.
- before publishing the signatures, we'll verify that the latest two major versions of ClamAV can load them correctly.
- the signatures will be digitally signed and packaged into a single .cvd compressed file.
- there will be no ".UNOFFICIAL" suffix in the detection names.
- a custom prefix will be added to the detection names, identifying the organization which published the signature.
- updates will be distributed both as full CVD files and cdiff incremental updates. Users will benefit from lower network traffic.
- the .cvd and .cdiff files will be distributed through the ClamAV mirror network.
- the service should result in faster remediation of false positives.
- ClamAV users will be able to download the third party databases using freshclam, by adding a single line to freshclam.conf, what should make signature maintenance significantly easier.
The service is still in beta, you are welcome to contact Luca Gibelli
We especially welcome those who already distribute their own unofficial signatures to join. A list of databases distributed by the new service will be available at http://www.clamav.net/download/cvd/3rdparty
We will be happy to answer any questions you might have.
Monday, July 18, 2011
----------- SCAN SUMMARY -----------
Known viruses: 1000066
Engine version: 0.97.1
Scanned directories: 0
Scanned files: 1
Infected files: 1
Known viruses: 1000066
Engine version: 0.97.1
Scanned directories: 0
Scanned files: 1
Infected files: 1
So much work done by so many people - I thought that's worth a post. :-)
Saturday, June 11, 2011
Recently the ClamAV team here at Sourcefire released version 0.97.1 of the software. You can grab it here. Please see the below pasted changelog for ClamAV since the last version:
Thu Jun 9 08:22:31 CEST 2011 (acab)------------------------------------* libclamav/mew.c: harden boundary check on e8/e9 fixup
Thu May 26 14:17:52 CEST 2011 (acab)------------------------------------* libclamav/matcher-hash.c: in hm_sort don't swap an item with itself (bb#2818)
Thu May 12 13:01:56 CEST 2011 (tk)----------------------------------* freshclam/manager.c: fix return code of Rfc2822DateTime() (bb#2809)
Sat May 7 18:05:23 EEST 2011 (edwin)-------------------------------------* libclamav/pdf.c: better detection for encrypted PDFs (bb #2448)
Fri May 6 16:16:00 EEST 2011 (edwin)------------------------------------* libclamav/c++: add support for building with external LLVM 2.9, and drop external 2.8 support
Thu May 5 01:07:57 CEST 2011 (acab)------------------------------------* clamd: log request ip address for instream scans #bb2592
Wed May 4 14:07:12 EEST 2011 (edwin)-------------------------------------* libclamav/c++/llvm/lib/Target/X86/X86InstrInfo.td: bb #2763don't assert on AVX chips (Intel Core i5 and i7)
Tue May 3 22:52:04 PDT 2011 (tk)---------------------------------* sigtool: properly normalize html files (bb#2764)
Tue May 3 16:14:27 PDT 2011 (tk)---------------------------------* sigtool/sigtool.c: fix formatting of hash dbs (bb#2765)
Wed Apr 27 15:07:22 CEST 2011 (tk)----------------------------------* freshclam: add mirror statistics mechanism
Sat Apr 9 17:20:35 CEST 2011 (acab)------------------------------------* libclamav/pe_icons.c: don't sigbus on sparc (bb#2695)
Sat Apr 9 03:56:17 CEST 2011 (acab)------------------------------------* libclamav/pe.c: reset corrupted status before bytecode hooks (bb#2544)
Thu Mar 17 17:46:09 CET 2011 (tk)---------------------------------* sigtool, freshclam: put .info on top of container to speed up loading
Wed Mar 16 15:53:42 CET 2011 (tk)---------------------------------* sigtool: fix --verify-cdiff
Tue Mar 15 17:56:59 CET 2011 (tk)---------------------------------* sigtool: allow arbitrary names for --build
Wed Mar 9 15:42:50 CET 2011 (tk)---------------------------------* clamdscan: fix file exclusion (bb#2579)
Mon Feb 28 21:46:50 CET 2011 (tk)---------------------------------* clamd: add new option ClamukoExcludeUID (bb#2260)Based on idea from alfred*bokxing.nl
Fri Feb 25 14:49:04 CET 2011 (tk)---------------------------------* libclamav/elf.c: fix incorrect detection of Broken.Executable (bb#2580)
Thu Feb 24 14:52:18 CET 2011 (tk)---------------------------------* shared/output.c: fix empty lines in syslog (bb#2578)
Mon Feb 21 18:19:18 CET 2011 (tk)---------------------------------* clamd: update description of ReadTimeout (bb#2565)
Thu Feb 17 19:13:15 CET 2011 (tk)---------------------------------* clamd: add new config option BytecodeUnsigned (bb#2537); drop"None" from BytecodeSecurity* clamscan: add new switch --bytecode-unsigned and drop --bytecode-trust-all
Tue Feb 15 19:19:31 CET 2011 (tk)---------------------------------* sigtool/sigtool.c: improve handling of bytecode.info (bb#2292)
Thu Apr 14 21:29:36 EEST 2011 (edwin)-------------------------------------* libclamav/others.c: make sure TLS key is initializer (bb #2588).Thanks to Cameron Brown for the detailed analysis of the bug.
Thu Apr 14 13:19:38 EEST 2011 (edwin)-------------------------------------* configure: check for enable_extended_FILE_stdio (bb #2542)
Fri Feb 11 13:16:41 CET 2011 (tk)---------------------------------* sigtool/sigtool.c: handle all signature formats with --(list|find)-sigs (bb#2534)
Tue Feb 8 02:42:11 CET 2011 (acab)-----------------------------------* libclamav/mpoo.c: Make solaris linker happy - Thanks to John Kendall <john*capps.com>
Tuesday, May 10, 2011
Wanted to let the readers of this blog know that the VRT has published a blog post concerning the MacDefender OSX Malware over on its blog.
Please check out the post: MacDefender and its variants here.
Please check out the post: MacDefender and its variants here.
Subscribe to:
Posts
(
Atom
)