Certian Obfuscations arent SAFE

meditext#0 20:25 04/10/2024

I'm here to bring over a major problem with the obfuscation process.

We know to make in order to execute the script must use the goddamn hex or binary addresses, and sadly, this makes it possible and vulnerable to anyone else deobfuscate it by doing some arbitrary time-taking decompilation.

I worked on projects that used decompilation, and most of the time, obfuscators (like the Lua obfuscator) let anyone else access the obfuscated string of code that was going to be executed by the executor.

Now I know this isn't supposed to happen because anyone else thinks that "Obfuscators will actually protect your scripts with a high level of protection,"  despite the fact that the fact that its backend deobfuscator VM actually requires Hex.

This process of obfuscating scripts is widely known even for developers back in 2011, which is practically safe for most exploiters not to be "able" to copy the whole script and modify themselves, as the whole server script decompilation in question has been solved at the same period (which led to the removal of the ability to supposedly use bytecode scripts).
Justinb#7819 Replied 17 Days ago21:17 04/10/2024

first, congratz on being the first actual valuable forum post here

Second, what you mean with "the goddamn hex or binary addresses", are you referring to the code virtualization which is nothing new cuz IronBrew2 is a thing?

Or are you referring to the string obfuscation by doing a XOR on the string to hide its content?

Either way, strings will always be revealed in the obfuscated code as they are used at the runtime. Some strings could be hashed depending on its usecase (often used in Windows IAT Imports for malware). I chose to not use any hashing cuz the avrg user is rather stupid anyways.

But yeah, strings ain't safe and can be decrypted/decode rather easily. Still a bit of a pain to automated and okay-ish for noobs
meditext#0 Replied 17 Days ago21:30 04/10/2024

> Second, what you mean with "the goddamn hex or binary addresses", are you referring to the code virtualization which is nothing new cuz IronBrew2 is a thing?

What I mean is basically the string that places the script in it.

> Either way, strings will always be revealed in the obfuscated code as they are used at the runtime. Some strings could be hashed depending on its usecase (often used in Windows IAT Imports for malware). I chose to not use any hashing cuz the avrg user is rather stupid anyways.

Exactly. None of the obfuscated scripts can be "protected" because it can still reveal minor parts of scripts, depending on how processed the obfuscation is.

Also, most of the time, skids don't prefer to do all of it themselves. They want to grab the unencrypted script, modify it, and most of the time, publish it as theirs without the script developer's consent.

>But yeah, strings ain't safe and can be decrypted/decode rather easily. Still a bit of a pain to automated and okay-ish for noobs

Yes, Intentionally. Most of the time, string encrypters also do include a decrypter like Base64, ROT13, and including hex. We know that computers do not speak our languages, but yeah, script obfuscators can be generally unsafe and give skids hints of what the script structure, which is encrypted, works and looks like.

Please
to join shitposting this thread <3