[JavaProfit]

Hi. I have no intentions of writing any malicious software with what I am asking, but I'll ask anyways.

I've heard that some decompilers are flawed in the way that you can change goto to goto w or something and hide blocks of code. Are there any other, more practical ways of hiding code from decompilers?

I'm thinking this would be a good way to obfuscate code without having to obfuscate with ProGaurd or similar.

Basically I want the knowledge of how to hide static or instance initializers from most decompilers.

Thanks to all who can assist!

edit: forgot to include the research that I've conducted on my own. It seems that changing goto -> goto_w can work. I was looking at the jsr operator, and possibly the jsr_w operator may work (but I have not tested it). Maybe jump to a subroutine (jsr operator) and then goto_w to some hidden code?

[nOrr]

Using a bug in 3rd party software as an argument for security is the silliest idea I've heard in a long time. There's a reason good obfuscators are expensive. ;)

[Bibl]

jsr is a lot slower i believe compared to a normal jump
the _w opcodes are just wide so you can support bigger ranges, eg. ldc_w:bigger constants, jsr_w:jump offset can be bigger
different decompilers will do different things but ive been writing a pure class editor
https://github.com/TheBiblMan/CFIDE
so the instructions will always be there, it just depends on the specific decompiler and how it will work/break under certain situations

[JavaProfit]

Using a bug in 3rd party software as an argument for security is the silliest idea I've heard in a long time. There's a reason good obfuscators are expensive. ;)

This is targeted towards services that have staff who examine uploaded JARs with public deobfuscators. As in, no the goal is not to obfuscate the code but instead hide some initializes in order to get past these examinations. And run stuff that otherwise would not get approved.

[DаrkStorm]

This was posted on the Admincraft subreddit.

[Psifour]

Yes, it is old news that certain decompilers struggle with that just like some can't handle static arrays being initialized in abnormal orders. The problem is going to be that targeting a specific bug in a specific decompiler is asking to get caught when they suddenly just run a simple file-size check between the output of a few different decompilers.

As for what DarkStorm linked to I am still amazed that they weren't also just running bytecode scans for malicious code.

[Bibl]

Yes, it is old news that certain decompilers struggle with that just like some can't handle static arrays being initialized in abnormal orders. The problem is going to be that targeting a specific bug in a specific decompiler is asking to get caught when they suddenly just run a simple file-size check between the output of a few different decompilers.

As for what DarkStorm linked to I am still amazed that they weren't also just running bytecode scans for malicious code.

impossible to do so u never know whats comin from an external stream so u can never guarantee if its safe

[Psifour]

bibl, did you not get enough sleep or did your ability to think just suffer a catastrophic malfunction? I know you typically stick to trolling, but this is either a masterpiece or a cry for help.

They are only verifying the integrity of the downloads that are submitted to them. As such they have the version to be published already stored locally. From there it is a simple matter to make a script that handles decompilation, file-size comparison, scanning for calls to known restricted functions/methods, and flags anything that uses seldom used op codes. Anything that can't pass a basic check like that would then require manual verification or the original developer to fix his unorthodox code to better comply with standards.

[Bibl]

bibl, did you not get enough sleep or did your ability to think just suffer a catastrophic malfunction? I know you typically stick to trolling, but this is either a masterpiece or a cry for help.

They are only verifying the integrity of the downloads that are submitted to them. As such they have the version to be published already stored locally. From there it is a simple matter to make a script that handles decompilation, file-size comparison, scanning for calls to known restricted functions/methods, and flags anything that uses seldom used op codes. Anything that can't pass a basic check like that would then require manual verification or the original developer to fix his unorthodox code to better comply with standards.

its an masterpseacew

[whitewoolyhat]

Since the CPU runs machine code, which can also be derived from assembly code, couldn't you use a program such as OllyDBG and bypass the obfuscators? Correct me if I am wrong or if this is just plain silly.

xD

[JavaProfit]

This was posted on the Admincraft subreddit.

May or may not be what I was referring to in my post. Didn't want to link it.

[blootooby]

OllyDbg is a native debugger. Even if it had the ability to debug Java bytecode, obfuscated bytecode would still be obfuscated.

Just an FYI, Ida Pro works for Java bytecode. Not that it's really the best tool for it, but it does do a good job.

[clrlslwi]

OllyDbg is a native debugger. Even if it had the ability to debug Java bytecode, obfuscated bytecode would still be obfuscated.

Doesn't mean you can't use it with the JVM 🤫

Spoiler (Click to View)
Not that anybody should try that; it'd be fucking retarded

[JavaProfit]

Since the CPU runs machine code, which can also be derived from assembly code, couldn't you use a program such as OllyDBG and bypass the obfuscators? Correct me if I am wrong or if this is just plain silly.

xD

You generally wouldn't use OllyDBG on bytecode...At least that's my stance. You can use it, but javap would give you more detailed information than a disassembly.