(De)obfuscation / IClassTransformer / production environment

[flapee]

Hi,

 

  i'm trying to deploy a mod into production ( in dev all works )

  The mod uses AspectJ (runtime weaving) for bytecode manipulation

  CoreMod pointing to IClassTransformer and positioned behind DeobfuscationTransformer using IFMLLoadingPlugin.SortingIndex(1011)

 

  The Transformer receives bytecode for transformation(weaving),

  but method/field names are just in the form func_NNNNN_A / field_NNNNN_A ( dumped the class at the end of the transformation chain using legacy.debugClassLoadingSave)

 

 

  a) what to do, to get the method names deobfuscated?

  b) what side effects will it have on the rest of code, bearing in mind that:

    1) asm patches are applied before deobfuscation

    2) rest of the MC/forge/mods code will get same deobf treatment

    3) somwhere in forge i saw even reflection helper/fixer for (de)obf - correct me on this, if need be

  c) if full run-time deobf has no side effects, why is it not turned on

 

any help/tips would be appreciated

 

Thanks

p

[Draco18s]

Coremods are heavily discouraged around here.  Sooo....you are unlikely to get any help.

 

That said:

> a) what to do, to get the method names deobfuscated?

> 1) asm patches are applied before deobfuscation

You can't both of these. You're either waiting until after deobf, or you're not.  You can't have both.

[flapee]

Fully understand the discouragement, but Core is the only place for bytecode patching, which i have to use.

 

Actually u can have booth, the transformation chain:

takes obfuscated bytecodes,

gives it to ASM patchers (mods seem to provide two sets of patches, one for deobf and one for obf )

patched bytecode is handed to deobfuscation

and then AspectJ patches the bytecode again ( given full deobf ... )

 

the question is if during deobf, mcp remapping can be used instead of srg

[Draco18s]

Fully understand the discouragement, but Core is the only place for bytecode patching, which i have to use.

 

The question is "why?"

Nearly everything anyone would want to do can be done without ASM, the rest should be submitted as a pull request to Forge.

[flapee]

In most cases I would agree.

 

But unfortunately,  most of the places i need to patch, Forge does not have hooks for.

 

And even if the tables would be turned, me being forge,

considering the request ,

i would decline it, as for most usecases, it would be useless

 

not to mention the patches are intended to be applied on 3rd party mods as well ...

 

Sure one could argue, that 3rd party mods should implement an API,

but seeing the state of modpacking scene ( the slowdown that is added by explicitly implementing interoperability), this approach is much more flexible and expedient and API would be just a fallback option for conflicting situations.

[diesieben07]

Coremods are not supported here. If you want to make one, go ahead, but you will not receive support.

 

If you want support, explain your problem and we will find a solution.

[flapee]

Using patches via coremod, the mod main code works already surprisingly well,

What I need, is help from coremod folks.

Where / how could i get in touch with them?

 

One could argue, to use second set of patches for obf,

but that would equal to throwing most of the AspectJ advantage out of the window

[diesieben07]

What I need, is help from coremod folks.

This help will not be provided here. If you insist on making a coremod, you are on your own.