so... i didnt edit the source or anything since i released... i simply recompiled it and it aint detected anymore but its exactly the same... WTF?
is it normal?
wouldnt they need to update hackshield for that?
also every hacks does that... if the person who released it recompile it then they can simply recompile again and it SHOULD not be detected anymore also if i make a loader that would write the file using binary and i was wondering would the md5 change? since its the exact same file theorically ... so idk ... if i make a loader would it remain undetected?
Last edited by gotter; 08-15-2012 at 01:20 PM.
All they would have to do to detect your dll's MD5 or SHA1 is add it to a txt file on their database or something. And each time you load hackshield, it would load that txt file into memory. Then scan for it.
You can win the rat race,Originally Posted by Jeremy S. Anderson
But you're still nothing but a fucking RAT.
++Latest Projects++
[Open Source] Injection Library
Simple PE Cipher
FilthyHooker - Simple Hooking Class
CLR Injector - Inject .NET dlls with ease
Simple Injection - An in-depth look
MPGH's .NET SDK
eJect - Simple Injector
Basic PE Explorer (BETA)
but strangely when simply recompiling it works... but when you "Cipher" your hacks they are still detected... so seriously im wondering whats going on
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
What do you mean "Doesn't work on SHA1", that's just plain wrong? SHA1 in and of itself is just like every other encryption algorithm. It doesn't do anything special, or different from what would happen if Nexon used MD5, SHA256, SHA512 or any other encryption algorithm. However, if they've changed their hashing logic (i.e WHAT they're hashing) then that would be what's causing it to fail, since all the public "ciphers" just dump shit on the end of the file, which is very easy to exclude.
They may be just hashing the code base, or the sections, or any other constantly identifiable portion of the file. Still, very easy to mix up the .dll externally and still remain undetected without having to recompile...if you know what you're doing that is
Last edited by Jason; 08-16-2012 at 05:24 AM.
You can win the rat race,Originally Posted by Jeremy S. Anderson
But you're still nothing but a fucking RAT.
++Latest Projects++
[Open Source] Injection Library
Simple PE Cipher
FilthyHooker - Simple Hooking Class
CLR Injector - Inject .NET dlls with ease
Simple Injection - An in-depth look
MPGH's .NET SDK
eJect - Simple Injector
Basic PE Explorer (BETA)
Departure (08-26-2012)
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.
Last edited by Bombsaway707; 08-16-2012 at 12:29 PM.
Derps :3. By your reasoning, SHA1 is a broken encryption algorithm.
I'm not saying that file-pumping doesn't work any more, I believe that it doesn't. I'm just saying that it is NOT because of the encryption algorithm they are using (SHA1/MD5...whatever), its because Nexon have gotten smarter than:
Instead of just reading blindly whatever is on disk, they're likely to be parsing some of the internal infrastructure of the .dll file (which is well documented), and hashing only a portion of the file. Something like:Code:BYTE *bFile = ReadAllOfTheFileOnDisk("path/to/library.dll"); std::string sha1 = ComputeMagicalSHA1Hash(bFile); if (our_list_of_baddy_hacks.contains(sha1)) ALERT("YOU HAX BAD MEN!!!!!");
That way, dumping useless shit on the end won't affect their precious hash values, as it's just ignored.Code:BYTE *bFile = ReadFileData(optional_header->BaseOfCode, optional_header->SizeOfCode); //do hash check on the portion of the file
You can win the rat race,Originally Posted by Jeremy S. Anderson
But you're still nothing but a fucking RAT.
++Latest Projects++
[Open Source] Injection Library
Simple PE Cipher
FilthyHooker - Simple Hooking Class
CLR Injector - Inject .NET dlls with ease
Simple Injection - An in-depth look
MPGH's .NET SDK
eJect - Simple Injector
Basic PE Explorer (BETA)
The header timestamp is different each time you recompile your application. If the implementation of their hashing algorithm doesn't ignore hashing the PE header the hash value is gonna be different each time. MSVC stub might have some time dependant data too, which obviously is different each time your recompile the application.
It doesn't matter if they use MD5 or SHA1 as the algorithm is basically the same, just a different hash size and digest chunk size, which affect only performance and hash security.