C# is very unsecure indeed



  •  In my school, there are classes that teach the basic of programmings. The first 5 semester of the programming class all teach C# to the student until you get to 6. and 7. semester where you are taught C++ (The school system works a little bit different here than what people are usually accustomed to).

     Today was our first day in learning the basics of C++ and seeing how most if not all had spend quite good time learning C#, he went to explain the basic difference between C# and C++. At this point, one of the "smarter" students pipes out and says that C# is also unsecure compared to C++. When I asked him to clarify what he meant by that, he said the following: "With C# you can use a program to view the original source code for the program but that is not possible with C++."

    Basically, because it's easy to get the source code for C# application, C# is more unsecure than C++.

    If the source code is the only security you have to worry about, I really envy your job.



  • @TheThing said:

    "With C# you can use a program to view the original source code for the program but that is not possible with C++."

    If he's talking about a program that decompiles an assembly to extract the CIL code, and then generates C# code from that, he deserves a beating. Otherwise he needs some time in a sanitarium.



  •  [quote user="Renan "C#" Sousa"]@TheThing said:

    "With C# you can use a program to view the original source code for the program but that is not possible with C++."

    If he's talking about a program that decompiles an assembly to extract the CIL code, and then generates C# code from that, he deserves a beating.[/quote]

     That is exactly what he is talking about.



  • Alright then, show him this: google results for "decompiling C+ programs".



  • [quote user="Renan "C#" Sousa"]Alright then, show him this: google results for "decompiling C+ programs".[/quote] 

    Also Dotfuscator. And the 50 equivalent tools.



  • [quote user="Renan "C#" Sousa"]Alright then, show him this: google results for "decompiling C+ programs".[/quote] 

    @First hit from Google said:

    ... Although if you're on the holy grail to decompiling ... [followed by extensive list of reasons why decompiling C++ is hard]

    I think you've made a point, even if it wasn't the one you wanted to make.

    What I want to say, of course it's possible to decompile C++. Still, without anysource annotations, you'll need a lot more skill to make sense of the results as with CLR languages or e.g. Java. In that sende, I can actually understand the guy in the original story.



  • If the code can be executed by a device, it can be decompiled. I use the Hex-rays Disassembler & Decompiler at work to reverse engineer programs. With some work, the results are amazing. It might not be the original code, but its close enough to know whats going on. 



  • @Mole said:

    If the code can be executed by a device, it can be decompiled. I use the Hex-rays Disassembler & Decompiler at work to reverse engineer programs. With some work, the results are amazing. It might not be the original code, but its close enough to know whats going on. 

    Technically yes, any executable file can be "disassembled".  However, you have to be knowledgeable about  assembly language to understand the output and I'm not aware of a decompiler that will produce fully compilable source code.

     



  • No one has yet brought up that gaining access to the source code has very little to do with security. If your security is based on the secrecy of your algorithms, you already have poor security. Besides, most any thing you can get from decompiling a program that could be used as a security exploit is usually easily identifiable with a static code analysis tool. The biggest security holes in C++ code are buffer overflows and stack overflows. You don't have to understand the code to find these. For those other cases where you want to bypass security routines in a compiled application, just watch the app run in IDA Pro and no-op out the code that does the security evaluation.



  • @El_Heffe said:

    @Mole said:

    If the code can be executed by a device, it can be decompiled. I use the Hex-rays Disassembler & Decompiler at work to reverse engineer programs. With some work, the results are amazing. It might not be the original code, but its close enough to know whats going on. 

    Technically yes, any executable file can be "disassembled".  However, you have to be knowledgeable about  assembly language to understand the output and I'm not aware of a decompiler that will produce fully compilable source code.

    I tried out a C# decompiler on a dotfuscated program recently. The output looked compilable, but I couldn't test since the decompiler was a trial version. The output included all classes, methods and variables, though the names were randomized. The source produced was close to the original source. With no help from me, it had produced a near-perfect decompilation containing all of the program and no added library routines.

    The guy had a (bit of a) point -- CIL is far easier to reverse-engineer than native x86 code. True, it isn't really related to security, but it would still matter to anyone producing a closed-source app...



  •  Depending on the size of the code and your skill level with IDA, the decompiler is probably the closest your going to get - sometimes it does produce completely compilable code, however ugly. You do loose a lot of the structure of the program, so you end up with labels and gotos, but you can still get some compilable code from it. 


  • BINNED

     I haven't tried it but I seriously doubt that a the output of a C++ decompiler is more readable than the disassembly. Might as well use that.



  • Its just the right tool for the job and all that. Sometimes it'll be easier to understand the assembly, and sometimes it'll be easier to understand the C. If a program is massively dependant on templates, inherited classes (or probably even non-inherited classes), overloaded operators, and the like, then the decompiled output is going to look nothing like the original code and you may prefer to read the assembly. However, if your decompiling an algorithm, hitting decompile can give you an instant multi-platform version that may be easier to understand than the assembly and a lot more useful. Since the decompiler is typically done by the time I release the hotkey (it only decompiles the current function), I just normally check quickly and decide which to examine.



  • @joemck said:

    The guy had a (bit of a) point -- CIL is far easier to reverse-engineer than native x86 code. True, it isn't really related to security, but it would still matter to anyone producing a closed-source app...
     

    It would only matter to a paranoid lunatic producing a closed-source app.  Your program's workings are never secret.  There is no technological solution; you must rely on your legal protections, such as copyright law and contract law, which mean you can easily sue anyone you catch reverse-engineering your program or copying parts of it.

    It's important to remember that open source is not about revealing how a program works, and closed source is not about concealing it.  It's all about the rights people have.  Open source users have the right to modify programs and create derivative works.  Closed source authors have the right to exclusive control of their creations.  That's all.



  • @joemck said:

    The guy had a (bit of a) point -- CIL is far easier to reverse-engineer than native x86 code. True, it isn't really related to security, but it would still matter to anyone producing a closed-source app...

    The reverse-engineering ease is still not an inherent issue with C# development.  C++ developers usually feel like their code can't be decompiled and they are sometimes right and sometimes wrong, but they rarely check.  C# developers know their code can be decompiled and go out of their way to obfuscate the code when necessary.  Good quality obfuscators actually do a better job than making unreadable code than the C++ compiler does.  They obfuscate literal strings, combine methods into confusing overloads, and do all sorts of other things to make it not easy to understand the code.

    On the actual security front, C# encourages good security design because the developer is acutely aware that their algorithms are viewable.  A C++ developer that has the "my code can't be reverse-engineered" attitude may take security risks that blow up in their face by not understanding the attack surface.



  • @Jaime said:

    On the actual security front, C# encourages good security design because the developer is acutely aware that their algorithms are viewable.  A C++ developer that has the "my code can't be reverse-engineered" attitude may take security risks that blow up in their face by not understanding the attack surface.

    This may be true to some extent, but I think the open source/closed source mentality is still going to dominate.  Even in Perl development, closed source development people apparently tend to think they can hide things because the code won't be read - despite the fact that there's no compiled binary form, so the source is always available.  (Yep, I've found problems like this and reported them to the vendor along with a patch.  Every time, the vendor was astounded that someone was able to find a problem in their code because it was closed source, as denoted clearly by the comment header at the top of each file.  Note that it was always the same vendor - "closed source" perl code being kinda rare.)



  • @tgape said:

    Every time, the vendor was astounded that someone was able to find a problem in their code because it was closed source, as denoted clearly by the comment header at the top of each file.
    QFWTF


Log in to reply