In article <dgf5n2$1epo$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <dgf21b$1b80$1@digitaldaemon.com>, James Dunne says...
>>
>>Georg Wrede wrote:
>>>> By the way.  Did you know that compiled .NET programs actually contain
>>>> the full
>>>> source code as well?  I assume this is to allow portions to be
>>>> compiled while
>>>> the application is running, but I was amazed that the code isn't even
>>>> obfuscated.  You have to buy a third party tool to do this if you want to
>>>> protect your IP when shipping .NET applications.
>>> 
>>> 
>>> Geez!
>>> 
>>> I suggested this for D code that would be used instead of scripts, for quite a long time ago. Didn't catch on too well.
>>> 
>>> It has its merits in many situations, but not when you are selling software. And of course, you have to _buy_ something to fix it. As always.
>>
>>For .Net?  Visual Studio .Net comes with Dotfuscator, which obfuscates the symbol table so that the .Net code cannot be reverse engineered into any *meaningful* representation.
>
>I didn't know about that.  I'll admit I only know about this because a .NET person in the office told me about it.  Perhaps he was unaware of this tool.
>
>>In fact, I don't believe the distributed binaries actually contain the "full source code" of the program, as you state.  It's just that the .Net code is compiled into MSIL, which, like Java, is easily reverse engineered.  It doesn't help that the binaries also contain all of the symbolic information from the original code, i.e. local variable names are preserved.
>
>Exactly.  The aforementioned person had a decompiler he'd gotten online somewhere and I was amazed to see that it spat out our source code exactly as it was written.  I expected it would a bit more like decompiled C++ code.  I've wondered whether a JIT build of .NET applications (instead of the .NET assembly format) would contain so much information, but I never bothered to test it.
>
>
>Sean
>
>

The decompiled output is usually meaningless, depending on the feature set used and language which generated the MSIL bytecode.  For instance, C# operator overloading will look like nothing more than class method calls of special names (depending on the decompiler - some might reverse engineer this correctly).  I can't imagine such a thing would be useful for C# 2.0, with generics, as well. But then again, that depends entirely on the implementation.

However, for the majority of your straight-forward logic/assignment/function call instructions, the resulting decompiled output should hit fairly closely to home.

Such a problem exists for mostly any bytecode-compiled language.  Perhaps it is due to the simplicity of the virtual machine used - stack-based machines are much easier to decompile than register-based machines are, or perhaps it is due to the wealth of debugging/reflection information provided within the binary itself.

Perhaps that .NET person in your office was aware of the tool, but wrote it off since it does not entirely solve the problem.

Regards,
James Dunne

In article <dggdrc$2gjp$1@digitaldaemon.com>, James Dunne says...
>
>Perhaps that .NET person in your office was aware of the tool, but wrote it off since it does not entirely solve the problem.

Probably.  Source code security is a huge deal to him and he was pushing to get the best obfuscator around.  For what it's worth, this was a VB assembly, so the fairly simple language design is probably why the output was so meaningful (copy-paste exact in this case).


Sean

I agree.  As a blind reader, it is easier for me to read top-posting, though
body-posting is doable if I scroll by paragraph.
"James Dunne" <james.jdunne@gmail.com> wrote in message
news:dgek0t$s46$1@digitaldaemon.com...
> Sean Kelly wrote:
>> In article <dgd52g$2ff3$1@digitaldaemon.com>, James Dunne says...
>>
>>>Why do some people get all up in arms about top-posting?
>>
>>
>> This is  Alf P. Steinbach's signature file (from the c++ newsgroups):
>>
>> ---
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing on usenet and in e-mail?
>
> Yes, I've seen many like that, and it just doesn't hold.  Most posts are not one-liners.  Such an example is of the most extreme case where everyone uses top-posting.  It shouldn't bother you anyway if you've been following the conversation.  Just find the new post and read on. It's easier to find it at the top than to start at the bottom and scroll up.

Interesting.  That never occurred to me.  I suppose there's something to be said for top-posting after all :)

Sean

In article <dgkvn0$e10$1@digitaldaemon.com>, Ameer Armaly says...
>
>I agree.  As a blind reader, it is easier for me to read top-posting, though
>body-posting is doable if I scroll by paragraph.
>"James Dunne" <james.jdunne@gmail.com> wrote in message
>news:dgek0t$s46$1@digitaldaemon.com...
>> Sean Kelly wrote:
>>> In article <dgd52g$2ff3$1@digitaldaemon.com>, James Dunne says...
>>>
>>>>Why do some people get all up in arms about top-posting?
>>>
>>>
>>> This is  Alf P. Steinbach's signature file (from the c++ newsgroups):
>>>
>>> ---
>>> A: Because it messes up the order in which people normally read text.
>>> Q: Why is top-posting such a bad thing?
>>> A: Top-posting.
>>> Q: What is the most annoying thing on usenet and in e-mail?
>>
>> Yes, I've seen many like that, and it just doesn't hold.  Most posts are not one-liners.  Such an example is of the most extreme case where everyone uses top-posting.  It shouldn't bother you anyway if you've been following the conversation.  Just find the new post and read on. It's easier to find it at the top than to start at the bottom and scroll up.
>
>