[clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

Hi all,
has anybody seen this Malware Analysis Report (AR18-221A)
MAR-10135536-17 – North Korean Trojan: KEYMARBLE
https://www.us-cert.gov/ncas/analysis-reports/AR18-221A
?

I created a file "keymarble-dummy", whose hex dump looks like so:

00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a dumm|
00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y keymarble file|
00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b | created for mak|
00000030 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00 |ing ***@...|
00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
00000050 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 |7245305cd418b8df|
00000060 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 |78652d1c03e9da0c|
00000070 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 |fc910d6d38ee4191|
00000080 64 34 30 0a 00 |d40..|

It matches the Yara rule in AR18-221A (see also below).
However, according to virustotal, my dummy file is clean:
https://www.virustotal.com/#/file/662ddd0a2af6c4ecf7234ef5541e559cfc7d6cedc0f475c3a2f64ced3869e366/detection

But AR18-221A mentions a number of AV products which would report it's a Win32 Trojan.

Hence, they all must use more sophisticated techniques than that simple Yara rule?
IOW: the rule matches more files than it should? (It wouldn't be the first time US-CERT proposes Yara rules which would produce FPs if enabled.)

Otherwise, is the rule wrong? When re-wrapped and commented, it looks like so:

rule rsa_modulus
{
meta:
Author="NCCIC trusted 3rd party"
Incident="10135536"
Date = "2018/04/19"
category = "hidden_cobra"
family = "n/a"
description = "n/a"

strings:
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"

condition:
// MZ signature and PE signature at offset stored in MZ header at 0x3C and $n
(uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them
}


Any recommendation about using that rule?

TIA
Ale
--
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http:

[Al Varnell]

I'm not sure how widely Yara is being used in current A-V scanning, but I would have to guess it's not fully implemented by many. I am aware that the current ClamAV scanner does not handle all the latest features and there are only UNOFFICIAL rule available, so the scanner on VirusTotal would not be expected to detect your dummy since it only uses official signatures.

There may also be an issue with the file type. ClamAV first does a check for file type before applying signature matches, so it would probably be looking for a PE file which your dummy does not appear to be. Other scanners probably do something similar.

Sorry, but my Yara knowledge is too limited to offer more.

Sent from my iPad

-Al-
ClamXAV User

Post by Alessandro Vesely
Hi all,
has anybody seen this Malware Analysis Report (AR18-221A)
MAR-10135536-17 – North Korean Trojan: KEYMARBLE
https://www.us-cert.gov/ncas/analysis-reports/AR18-221A
?
00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a dumm|
00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y keymarble file|
00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b | created for mak|
00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
00000050 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 |7245305cd418b8df|
00000060 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 |78652d1c03e9da0c|
00000070 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 |fc910d6d38ee4191|
00000080 64 34 30 0a 00 |d40..|
It matches the Yara rule in AR18-221A (see also below).
https://www.virustotal.com/#/file/662ddd0a2af6c4ecf7234ef5541e559cfc7d6cedc0f475c3a2f64ced3869e366/detection
But AR18-221A mentions a number of AV products which would report it's a Win32 Trojan.
Hence, they all must use more sophisticated techniques than that simple Yara rule?
IOW: the rule matches more files than it should? (It wouldn't be the first time US-CERT proposes Yara rules which would produce FPs if enabled.)
rule rsa_modulus
{
Author="NCCIC trusted 3rd party"
Incident="10135536"
Date = "2018/04/19"
category = "hidden_cobra"
family = "n/a"
description = "n/a"
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"
// MZ signature and PE signature at offset stored in MZ header at 0x3C and $n
(uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them
}
Any recommendation about using that rule?
TIA
Ale

_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrt

[Alessandro Vesely]

Well, in this case ClamAV supports YARA enough to get:

~/tmp$ clamscan -d keymarble.yara keymarble-dummy
keymarble-dummy: YARA.rsa_modulus.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.100.0
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.006 sec (0 m 0 s)


The question is whether one should copy keymarble.yara to /var/lib/clamav/, on a production server where ClamAV is used to scan email. It is useless if ClamAV catches keymarble already. It is also useless/harmful if $n is a bogus string.

More basic question: Is ClamAV staff monitoring US-CERT's alerts, and updating ClamAV database on good rules?

I'd also appreciate generic opinions about US-CERT. I'm not a careful analyst, so maybe I'm wrong, but it seems to me they are getting weaker and weaker, since about 2013, when they changed alert message format (introducing html and dropping pgp). For example, last year's TA17-293A[*] would have blocked any file containing the string "icon.png"...

Best
Ale
--
[*] https://www.us-cert.gov/ncas/alerts/TA17-293A

Post by Al Varnell
I'm not sure how widely Yara is being used in current A-V scanning, but I would have to guess it's not fully implemented by many. I am aware that the current ClamAV scanner does not handle all the latest features and there are only UNOFFICIAL rule available, so the scanner on VirusTotal would not be expected to detect your dummy since it only uses official signatures.
There may also be an issue with the file type. ClamAV first does a check for file type before applying signature matches, so it would probably be looking for a PE file which your dummy does not appear to be. Other scanners probably do something similar.
Sorry, but my Yara knowledge is too limited to offer more.
Sent from my iPad
-Al-
ClamXAV User

Post by Alessandro Vesely
Hi all,
has anybody seen this Malware Analysis Report (AR18-221A)
MAR-10135536-17 – North Korean Trojan: KEYMARBLE
https://www.us-cert.gov/ncas/analysis-reports/AR18-221A
?
00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a dumm|
00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y keymarble file|
00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b | created for mak|
00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
00000050 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 |7245305cd418b8df|
00000060 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 |78652d1c03e9da0c|
00000070 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 |fc910d6d38ee4191|
00000080 64 34 30 0a 00 |d40..|
It matches the Yara rule in AR18-221A (see also below).
https://www.virustotal.com/#/file/662ddd0a2af6c4ecf7234ef5541e559cfc7d6cedc0f475c3a2f64ced3869e366/detection
But AR18-221A mentions a number of AV products which would report it's a Win32 Trojan.
Hence, they all must use more sophisticated techniques than that simple Yara rule?
IOW: the rule matches more files than it should? (It wouldn't be the first time US-CERT proposes Yara rules which would produce FPs if enabled.)
rule rsa_modulus
{
Author="NCCIC trusted 3rd party"
Incident="10135536"
Date = "2018/04/19"
category = "hidden_cobra"
family = "n/a"
description = "n/a"
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"
// MZ signature and PE signature at offset stored in MZ header at 0x3C and $n
(uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them
}
Any recommendation about using that rule?
TIA
Ale

_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www

[Al Varnell]

Here's the VirusTotal page on this file
<https://www.virustotal.com/#/file/e23900b00ffd67cd8dfa3283d9ced691566df6d63d1d46c95b22569b49011f09/detection <https://www.virustotal.com/#/file/e23900b00ffd67cd8dfa3283d9ced691566df6d63d1d46c95b22569b49011f09/detection>>
and it does show that ClamAV detects it as Win.Trojan.Agent-6641267-0 which was just added yesterday by daily - 24829 and is a MD5 hash:
[daily.hsb] 704d491c155aad996f16377a35732cb4:126976:Win.Trojan.Agent-6641267-0:73

so yes, ClamAV should catch it already.

-Al-

Post by Alessandro Vesely
~/tmp$ clamscan -d keymarble.yara keymarble-dummy
keymarble-dummy: YARA.rsa_modulus.UNOFFICIAL FOUND
----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.100.0
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.006 sec (0 m 0 s)
The question is whether one should copy keymarble.yara to /var/lib/clamav/, on a production server where ClamAV is used to scan email. It is useless if ClamAV catches keymarble already. It is also useless/harmful if $n is a bogus string.
More basic question: Is ClamAV staff monitoring US-CERT's alerts, and updating ClamAV database on good rules?
I'd also appreciate generic opinions about US-CERT. I'm not a careful analyst, so maybe I'm wrong, but it seems to me they are getting weaker and weaker, since about 2013, when they changed alert message format (introducing html and dropping pgp). For example, last year's TA17-293A[*] would have blocked any file containing the string "icon.png"...
Best
Ale

[Alessandro Vesely]

Post by Al Varnell
Here's the VirusTotal page on this file
<https://www.virustotal.com/#/file/e23900b00ffd67cd8dfa3283d9ced691566df6d63d1d46c95b22569b49011f09/detection>
and it does show that ClamAV detects it as Win.Trojan.Agent-6641267-0
which was just added yesterday

Thanks a lot! That solves my doubt. Yet, I'd be curious to know if NCCIC's Yara rule would detect it, because of:

strings:
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"

(Recall that hex strings in Yara require curly braces, for example:
$h = {bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d400}
)


Best
Ale
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clam

[Al Varnell]

I don't quite understand why you think it might not detect it.

Text strings are not required to have an even number of digits. The hex equivalent to that string would be: {62 63 39 62 37 35 61 33 31 31 37 37 35 38 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 64 34 30}. As long as the string appears in a file, it should match.

I'd have to have the actual sample file in order to say anything more about it.

-Al-

Post by Alessandro Vesely
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"
$h = {bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d400}

[Alessandro Vesely]

I don't quite understand why you think it might not detect it. 
Text strings are not required to have an even number of digits. The hex
equivalent to that string would be: {62 63 39 [...] 34 30}. As
long as the string appears in a file, it should match.

That's right.

I thought it is unlikely to find a 65 bytes binary sequence, so it looked wrong to me. Perhaps, that's a wrong conjecture, since a malware writer may want to hard code crypto data in the executable. The sequence doesn't seem to be code.

I'd have to have the actual sample file in order to say anything more about it.

I don't attach it, as it may appear to be a (broken) executable. Using an xxd[*] dump (instead of hd) solves the problem since xxd is reversible and idempotent:

~/tmp$ diff -s <(xxd -g 1 keymarble-dummy) <(xxd -g 1 keymarble-dummy|xxd -r|xxd -g 1)
Files /dev/fd/63 and /dev/fd/62 are identical

So you can copy the following to a file and revert to binary:

~/tmp$ xxd -g 1 keymarble-dummy
00000000: 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d MZthis is a dumm
00000010: 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 y keymarble file
00000020: 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b created for mak
00000030: 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00 ing ***@...
00000040: 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 PEbc9b75a3117758
00000050: 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 7245305cd418b8df
00000060: 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 78652d1c03e9da0c
00000070: 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 fc910d6d38ee4191
00000080: 64 34 30 0a 00

Best
Ale
--
[*] https://github.com/jnweiger/xxd
(But it's probably already installed on your box.)
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clam

[Al Varnell]

Sorry, I wasn't clear. I meant the malware sample, not your dummy.

-Al-

Post by Alessandro Vesely

Post by Al Varnell
I don't quite understand why you think it might not detect it.
Text strings are not required to have an even number of digits. The hex
equivalent to that string would be: {62 63 39 [...] 34 30}. As
long as the string appears in a file, it should match.

That's right.
I thought it is unlikely to find a 65 bytes binary sequence, so it looked wrong to me. Perhaps, that's a wrong conjecture, since a malware writer may want to hard code crypto data in the executable. The sequence doesn't seem to be code.

Post by Al Varnell
I'd have to have the actual sample file in order to say anything more about it.

~/tmp$ diff -s <(xxd -g 1 keymarble-dummy) <(xxd -g 1 keymarble-dummy|xxd -r|xxd -g 1)
Files /dev/fd/63 and /dev/fd/62 are identical
~/tmp$ xxd -g 1 keymarble-dummy
00000000: 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d MZthis is a dumm
00000010: 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 y keymarble file
00000020: 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b created for mak
00000040: 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 PEbc9b75a3117758
00000050: 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 7245305cd418b8df
00000060: 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 78652d1c03e9da0c
00000070: 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 fc910d6d38ee4191
00000080: 64 34 30 0a 00
Best
Ale

[Alessandro Vesely]

Post by Al Varnell
Sorry, I wasn't clear. I meant the malware sample, not your dummy.

To retrieve a sample from VirusTotal, one must work for a _company_ subscribed
to their premium services...

Best
Ale
--
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

[Al Varnell]

Yes, I'm fully aware of that. There have been exceptions made for certain individuals engaged in malware research, but I was turned down and told to use the ClamAV account, but they weren't willing to share unless I went through a tedious vetting process.

-Al-

Post by Alessandro Vesely

Post by Al Varnell
Sorry, I wasn't clear. I meant the malware sample, not your dummy.

To retrieve a sample from VirusTotal, one must work for a _company_ subscribed
to their premium services...
Best
Ale

[G.W. Haywood]

Hi there,

On Sat, 11 Aug 2018, Alessandro Vesely wrote:

Re: Keymarble Yara rule?

Post by Alessandro Vesely
00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a dumm|
00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y keymarble file|
00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b | created for mak|
00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
...
(uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them

The second offset looks wrong to me.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

[Alessandro Vesely]

Post by G.W. Haywood
Hi there,
Re: Keymarble Yara rule?

00000000  4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
00000010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
00000020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
00000040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
...
       (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
any of them

The second offset looks wrong to me.

Why? uint32(0x3c) is 0x00000040...
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net

[Arnaud Jacques]

Post by Alessandro Vesely

Post by G.W. Haywood
Hi there,
Re: Keymarble Yara rule?

00000000  4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
00000010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
00000020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
00000040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38 |PEbc9b75a3117758|
...
       (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
any of them

The second offset looks wrong to me.

Why? uint32(0x3c) is 0x00000040...

Because, each line is 16 bytes long (0x10).

So "00000040" is in hexadecimal, not decimal.
--
Cordialement / Best regards,

Arnaud Jacques
Gérant de SecuriteInfo.com

Téléphone : +33-(0)3.44.39.76.46
E-mail : ***@securiteinfo.com
Site web : https://www.securiteinfo.com
Facebook : https://www.facebook.com/pages/SecuriteInfocom/132872523492286
Twitter : @SecuriteInfoCom

Securiteinfo.com
La Sécurité Informatique - La Sécurité des Informations.
266, rue de Villers
60123 Bonneuil en Valois
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.cla

[Groach]

Post by Arnaud Jacques

Post by Alessandro Vesely

Post by G.W. Haywood
Hi there,
Re: Keymarble Yara rule?

Post by Alessandro Vesely
00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a dumm|
00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y
keymarble file|
00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b |
created for mak|
00000030 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00 |ing
00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38
|PEbc9b75a3117758|
...
(uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them

The second offset looks wrong to me.

Why? uint32(0x3c) is 0x00000040...

Because, each line is 16 bytes long (0x10).
So "00000040" is in hexadecimal, not decimal.

[Alessandro Vesely]

Post by Arnaud Jacques

Post by G.W. Haywood
Hi there,
Re: Keymarble Yara rule?

00000000  4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
00000010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
00000020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
00000040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  |PEbc9b75a3117758|
...
        (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
any of them

The second offset looks wrong to me.

Why?  uint32(0x3c) is 0x00000040...

Because, each line is 16 bytes long (0x10).
So "00000040" is in hexadecimal, not decimal.

Hm... yes, addresses in the first column are hex too. "PE" is there.
_______________________________________________
clamav-users mailing list
clamav-***@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.h