[logback-user] Substituting class/method names in logback log files with original names when deploying obfuscated code

[TJ Rothwell]

Hi Chris,

Keep the log stacktraces obfuscated. Then create a process that
de-obfuscates the stack traces for YGuard. I'm not familiar with YGuard, so
there could be something like this already.

ProGuard (another obfuscation package) has this with ReTrace.
http://proguard.sourceforge.net/index.html#/manual/retrace/introduction.html


-- TJ

On Mon, Nov 28, 2011 at 10:50 AM, Chris Pratt <thechrispratt at gmail.com>wrote:

> You do realize that if you supply the mapping file to the end user, there
> is really no reason to obfuscale the code in the first place.  They'll have
> everything they need to properly un-obfuscate and decompile it.
>   (*Chris*)
> On Nov 28, 2011 7:32 AM, "Christopher BROWN" <brown at reflexe.fr> wrote:
>
>> Hello,
>>
>> What would be the best way to handle logging with logback when deploying
>> obfuscated code?
>>
>> For example, with YGuard, when the obfuscator runs, it outputs a mapping
>> file of obfuscated code (class names, method names, etc) to unobfuscated
>> code.  When a stacktrace or just any logging trace is output, the
>> class/method names are obviously obfuscated.  As it's possible to deploy
>> this mapping with the code, say embedded in the same ".jar", all the
>> information I would need is available.
>>
>> Without too much re-writing of code (default formatting with logback),
>> what would be the best way to dynamically replace matching class/method
>> names?
>>
>> Thanks,
>> Christopher
>>
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-user
>>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20111128/e51c9266/attachment.html>