Detection

[gotter]

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?

[Saltine]

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?

They must have detected it via the files unique hash (MD5 or SHA1)

[gotter]

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?

[iRustleYourJimmies]

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.

[Jason]

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.

Why do you think tools like BlackCipher and craps work? They simply add some junk to the .dll so you don't even need to recompile. The file's hash is different.

[aeronyx]

Why do you think tools like BlackCipher and craps work? They simply add some junk to the .dll so you don't even need to recompile. The file's hash is different.

The tools don't work anymore.

:c

'ciphering' your hack is now irrelevant, nexon still detects the hack somehow.

[gotter]

but strangely when simply recompiling it works... but when you "Cipher" your hacks they are still detected... so seriously im wondering whats going on

[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

[arun823]

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

That and just so you know, not that many people know this, but it's that time of year again where hooks get detected. **Hint Hint** to everybody

[Jason]

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

[Bombsaway707]

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

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 ----------

That and just so you know, not that many people know this, but it's that time of year again where hooks get detected. **Hint Hint** to everybody

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.

[Jason]

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.

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:

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!!!!!");

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:

BYTE *bFile = ReadFileData(optional_header->BaseOfCode, optional_header->SizeOfCode);
//do hash check on the portion of the file

That way, dumping useless shit on the end won't affect their precious hash values, as it's just ignored.

[arun823]

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.

That is not entirely true, detected hooks cause the game to crash after about a minute or so.

[Bombsaway707]

That is not entirely true, detected hooks cause the game to crash after about a minute or so.

Yes, but the main issue isnt a detected hook. Otherwise recompiling wouldnt fix the issue

[HellSpider]

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.