Detection

Originally Posted by Bombsaway707

Please explain to me how pumping changes the SHA1 of the file? If you compare the SHA1 of a file before and after being pumped theyre exactly the same. So no, pumping doesnt work on the SHA1. IF you were to use other encryption methods then perhaps you could actually change the SHA1. Nexon doesn't hash different parts of the file. I know this because when you recompile a hack it becomes undetected. You dont even have to change a single piece of the file. If it were hashing out parts of the file then the file would consistently not work because the same parts would be getting hashed and detected right away yes? When you pump the file the SHA1 doesn't change, the pumping only changes the MD5. I have it on good authority that nexon previously detected MD5, they no longer use that. The purpose of the file pumping was to change the MD5 of the file, thats the only thing it actually changes. I was using SHA1 as an example, however trying to explain that to the people who dont actually understand this doesnt work. And if its so easy to encrypt the dll externally without packing it with 200 dollar software please do share.

Dim filesize As Double = Val(NumericUpDown1.Value)
filesize = filesize * 1024
Dim filetopump = IO.File.OpenWrite(TextBox2.Text)
Dim size = filetopump.Seek(0, IO.SeekOrigin.[End])
While size < filesize
filetopump.WriteByte(0)
size += 1
End While
filetopump.Close()

Because that shit no longer works

---------- Post added at 02:16 PM ---------- Previous post was at 02:16 PM ----------

Its not the hooks, because when people recompile the hacks work for about 5 hours before becoming detected again. If the hooks were being detected they wouldnt work from the start.

I'm sorry, but if anything changes in the file, the full file's hash will completely change. Jason's right, they must be applying a technique such as ignoring all data after the end of the .code section. Recompiling only fixes the issue because, as HellSpider stated, the hash would change due to the time stamp in the PE headers.

Originally Posted by Saltine

I'm sorry, but if anything changes in the file, the full file's hash will completely change. Jason's right, they must be applying a technique such as ignoring all data after the end of the .code section. Recompiling only fixes the issue because, as HellSpider stated, the hash would change due to the time stamp in the PE headers.

Compare the SHA1 of a file before and after its been pumped, it doesnt change. Regardless, yes as far as i know jason was right.

Originally Posted by Bombsaway707

Just so everyone knows.. its the SHA1 thats being detected. For the SHA1 to change actual code modification has to be made to the file. Recompiled, changed a string etc. Pumping bullshit doesnt work on SHA1

who told you that information? Although I 100% agree pumping random bytes to EOF is not the correct way to do it. What you need to do is pump random byte into the the resource section of image, or if enough space allows it pump random bytes into the end of the code section of image,, also to make it complete you would modify the crc value in the image header. Ohh back to my point SHA1 MD5 ect.. is all similar by hashing a given amount of bytes, what makes you think SHA1 is just for some reason automatically knows not to include EOF bytes?

http://www.codeprojec*****m/Articles/...ksum-Algorithm

Originally Posted by Departure

who told you that information? Although I 100% agree pumping random bytes to EOF is not the correct way to do it. What you need to do is pump random byte into the the resource section of image, or if enough space allows it pump random bytes into the end of the code section of image,, also to make it complete you would modify the crc value in the image header. Ohh back to my point SHA1 MD5 ect.. is all similar by hashing a given amount of bytes, what makes you think SHA1 is just for some reason automatically knows not to include EOF bytes?

An Analysis of the Windows PE Checksum Algorithm - CodeProject

All of that "pumping" is rubbish. You can't just pump random bytes into the resource section, some programs actually USE their resources, and overwriting them with rubbish data can cause instability. You *can* overwrite the padding of each section (each section is page aligned, so you can compute the difference between VirtualSize and SizeOfRawData and overwrite the difference), but there a multitude of safe places in an executable image that you can overwrite.

Originally Posted by Jason

No one said to overwrite resources, I said pump... meaning to add new resources into the resource section of the image.. and yes I 100% agree with the page alignment hence the reason why I stated "if" enough space(aka padding) allows you to write random byte to the end of the code section(or any other section for that matter). to add new resources is a simple process using windows API UpdateResource UpdateResource function

A small example in Delphi would be something like....

Code:

ResourceHandle := BeginUpdateResourceW(PWideChar(WideString(SaveDialog1.Filename)) , False); //File name
UpdateResourceW(ResourceHandle,PWideChar(RT_RCDATA),(PWideChar(WideString('DATA'))),0,@szData[1],Length(szData));
EndUpdateResourceW(ResourceHandle, False);

szData is just a string generated randomly, SaveDialog1.Filename is the file you want to add resources to... simple 3 lines of code to add resources

Detection

Post a Reply

Similar Threads

Tags for this Thread