Obfuscating question

  • Thread starter Thread starter Dotnetjunky
  • Start date Start date
D

Dotnetjunky

Hi,

I notice that some obfuscators in the market can transform out codes into
something like this ?

public void $ (int $, int $)
{
}

I'm wondering how can this be possible ?
How can they have two identical parameters for the method ?
 
Dotnetjunky said:
I notice that some obfuscators in the market can transform out codes into
something like this ?

public void $ (int $, int $)
{
}

I'm wondering how can this be possible ?
How can they have two identical parameters for the method ?
Click to expand...

I suspect that the parameter names are basically ignored by the runtime
- they're really for compile-time messages etc. I can't find the
relevant bit in the spec to check it though.
 
The rule about overload method and variable names in IL are a lot more
relaxed than high level language like C# and VB.NET. IL can use much more
complex overloading.

I don't think your example is correct in relation to the two parameters -
they'd have to be at least different types to reuse the $ variable name.

The ECMA spec defining what is and isn't legal in IL is Partition III - you
can download it from http://msdn.microsoft.com/net/ecma.

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org
 
Nick Wienholt said:
The rule about overload method and variable names in IL are a lot more
relaxed than high level language like C# and VB.NET. IL can use much more
complex overloading.

I don't think your example is correct in relation to the two parameters -
they'd have to be at least different types to reuse the $ variable name.

The ECMA spec defining what is and isn't legal in IL is Partition III - you
can download it from http://msdn.microsoft.com/net/ecma.
Click to expand...

Surely that defines what's legal for "source" IL though, rather than
what's legal in the PE file itself - there may be certain files which
are valid in themselves as far as the CLR is concerned but which cannot
be produced from any legal IL. Whether or not that is the case here is
a different matter, of course.
 
Our obfuscator[1] can rename most everything (except typedefs and some
exceptions) into the same name. You loose verifiability (PEVerify has a
field day with an assembly like that), but, it makes a
decompile/disassembler MUCH harder to use. It's nice to see a class where
every method, field and argument have the same unreadable name.

What's legal/warning/error in the ECMA specs doesn't always translate into a
problem for the CLR. If you check out our small descriptions on the site,
we do a lot more things that "violate" the runtime "rules", but run just
fine. Even a simple "Hello World" program can look like it got hit by a
train ;)

-mike
MVP

[1] www.InvisiSource.com
 
Our Spices.Obfuscator net makes method parameters unnamed, that more
better, also you can use Nondisplayable naming mode for generate
obfuscated members names with nondisplayable characters. these name not
displayed in the mostly known assembly browsers and prevent obfuscated
assembly from using with al.exe (assembly linker), but these assemblies -
veriviable assemblies.
 
Back
Top