> The Name property must be a fully qualified 'package.TypeName' value, and
> no package was found for 'ab'.
>
> Java.Lang.Object subclasses only need to contain a package if their name
> will be used in AndroidManifest.xml. (Android!!! /me shakes hand in air.)
>

Thats the point - all my UI classes now should be out of obfuscation,
making them easy target for an attacker.

> Is it possible to do some 'normalization' of symbols when generating
> .java - to support this?
>
> I'm not sure. Obfuscators can potentially rename ~everything (class names,
> method names, field names). If your obfuscator were to process
> Mono.Android.dll, it could then rename virtual methods in all subclasses;
> I'm sure


Obfuscating Mono.Android is difficult, moreover if you say it contais
reflections with symbolic names.
But obfuscation application classes is not a big problem. Right these
classes are uncovered for an attacker.


> The problem is the Mono.Android.dll implementation which looks up many
> methods via Reflection, by-name, and if these methods are renamed then all
> bets are off and things will break horribly.
>

It searches only API inherited methods ( overrides ) - but these methods
are not be renamed by obfuscator - so thats fine.


> so normalizing Java type names is something that could be done. Would that
> be effective? I don't know.
>

This is exactly what should be done. Moreover, this can be treated as a
bug. See this absolutely legal C# declaration:

class @if

Transformation into java by GenerateJavaStubs will definitely fail, because
@if is not a java identifier (and formally, it should be 'if', not '@if')

Therefore mapping and normalization in GenerateJavaStubs is needed, to
totally conform both language specs.

 Igor
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid

Reply via email to