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

[Christopher BROWN]

Hi TJ,

Had thought about this too.  However, the most reliable way of doing this
is to bundle the mapping with the code, as we can deliver lots of different
versions, including hotfixes, so doing offsite de-obfuscation will be
unreliable as we'll have a hell of a time ensuring that we match the right
stacktraces to the right mapping versions.

As I said, this is about checking out the feasibility and best approach to
performing the mapping.  I'm well aware that this is not in any way an
absolute way to protect code, just makes it a little harder for average
curious people to stick their noses in.

So I'm aware of the limits and some alternatives, but I'd still be
interesting in evaluating how this particular approach could be implemented.

--
Christopher



On 28 November 2011 17:56, TJ Rothwell <tj.rothwell at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/9f661860/attachment.html>