MD5 Hash

[starzboy]

Hello
yesterday i was playing with a dll of mine, which has MD5 algo in it, was detected by avira as virus.(Tr.Gen.Dropper)
I am using cryptohash library by drizz for computing the MD5, when i remove the MD5, then no virus is detected, but with the MD5 it is detected.
Can someone please explain why this happens, i tried the same MD5 in an exe and no virus was detected, why this happens in a dll ?
And is there any other algo for computing the MD5 ?

thnx
starz

[drizz]

Hi,

I don't know what could possibly trigger the AV... Maybe because it was written in asm? Crappy heuristics?
Anyway, you could use MS crypt api http://www.masm32.com/board/index.php?topic=4322.msg32297#msg32297

p.s. Avira is very popular in the AV Software sh*t list subforum.
p.s.2. I don't use AV software and I never will, a good firewall is all that's needed.

[kromag]

Not that I have to but I second that notion! I also use no AV software etc...
All I use are some tweaked cleaners and Comodo FW.

Albeit, if you're looking to distribute this application you'll want to use a known algo
for this so most AVs don't flag it as a potential risk.
---

William

[starzboy]

Hmmm, i tried SHA and i gave the same detection, and the weird thing is that when i removed all the code and i just had the MD5 Algo, nothing got detected !
And when the MD5 is nothere and the rest of the code is there it gets detected ?
I dont understand.

Maybe the MD5 sign and my code sign both must match to trigger the heusterics.
Btw i used VirusTotal for scanning.
And i think MD5 is popular enough....

[kromag]

What else is the application doing?
---

William

[starzboy]

Hi
thanks for the reply, i managed to fix it, basically the dll computes MD5 of a string which it extracts from an ini file located in the same directory.
I deleted a bmp file in the resource section which i wasnt using and the problem got solved.
I tried packing my dll with upx and the problem started again.

Is there any good freeware packer which dosent get detected ?

Anyways, basically the problem is solved, thanks to all.

[BlackVortex]

Try PE Compact.

But don't worry so much about being falsely detected by antivirus products. It's not our job to fix their shit.

[GreenTea]

Hi
thanks for the reply, i managed to fix it, basically the dll computes MD5 of a string which it extracts from an ini file located in the same directory.
I deleted a bmp file in the resource section which i wasnt using and the problem got solved.
I tried packing my dll with upx and the problem started again.

Is there any good freeware packer which dosent get detected ?

Anyways, basically the problem is solved, thanks to all.

Your root problem is a buggy AV program.

I would stop using it.

Like other posters, I don't use one either.

Take care.

[starzboy]

Thanks for the reply.
Actually it wasnt my AV that detected it, i scanned the files over VirusTotal.
And yes you are right, its their problem i shouldnt let it bother me.

Thanks a ton fro you help guys
starz

[donkey]

Hi Starzboy,

Unlike the others I run AV software (f-secure) on my system. Rarely does it give a false positive but it does happen on occasion. I have excluded my projects folder from the scan, after all I have written everything in there myself and I know there are no viruses, this takes care of most of the problems. I have also found that shuffling calls can make a big difference, for example moving GetModuleHandle away from immediately before GetProcAddress or GlobalAlloc sometimes helps. At any rate, good luck...

[KeepingRealBusy]

Speaking of MD5 Hashes. I Implemented an MD5 Hash routine to validate some 256 Megabyte blocks that I was creating. It is taking 2.5 to 3 seconds to create the hash from the memory image, other timings for the memory image are .2 seconds to set all bits (using XMM), and 1.25 seconds to count all bits using BT. I am moving all data into a 64 byte buffer on DWORD bounds (to make the routine generic so it can handle odd byte sizes for input). Should I try to speed this up by skipping the move into the buffer and just access the DWORDS directly from the memory image (read only so no changes to the image, data already on DWORD bounds - in fact on Page bounds via Virtual Alloc)? Is this a reasonable time for a 256 Megabyte hash?

Dave.

[donkey]

A 64 byte buffer is a lot of looping (nearly 4.2 million in your case), I typically use a 1MB buffer but with the Crypt API that works well. I would suggest a much bigger buffer to start with and if you don't get the speed increase you are comfortable with then try mapping the entire file and processing it in one gulp..

[KeepingRealBusy]

Donkey,

Thank you for the reply. The data is all in memory already, I just have to change the code to stop moving the data to the buffer and just utilize the data pointer instead of the buffer pointer, incrementing the data pointer instead of moving another block into the buffer.

Is the timing of ~2.5 seconds about right for 256 Megabytes for MD5 hashing?

Dave.