From: TSDing on 21 Nov 2005 07:16 That is why I prefer to develop VO32. It will still run on a machine that has .NET on it. Only problem is Grafx is not doing much to improve the product. Ever since Grafx took over, have you notice any improvement on the Image Editor, Install Maker and Report Writter ? in fact they have gone worse. Regards Ding <jmespinosabaviera(a)yahoo.com> wrote in message news:1132571553.607291.242860(a)g14g2000cwa.googlegroups.com... > Thanks to all who are responding. > > This seems to bring other (bad) consequences: If MSIL cab be brought > back to the original code, then a hacker can obtain the source code and > steal your software, I mean make some changes and the hacker can sell > it as his own software, or just manipulate the routine checking for a > dongle in the usb port, thus allowing piracy. From what I know I do not > run this risk with my VO application. > > Is this MSIL code which is distributed to the customers, allowing free > access to the source code ? >
From: Ginny Caughey on 21 Nov 2005 07:37 If you actually use that tool against some MSIL you will see what it does. If debug symbols are available to the Reflector, the translation is surprisingly good. But without the .pdb file, the code isn't as useful to someone else. There are obfuscators on the market that you can purchase that will make the reflected version even less useful. -- Ginny <jmespinosabaviera(a)yahoo.com> wrote in message news:1132571553.607291.242860(a)g14g2000cwa.googlegroups.com... > Thanks to all who are responding. > > This seems to bring other (bad) consequences: If MSIL cab be brought > back to the original code, then a hacker can obtain the source code and > steal your software, I mean make some changes and the hacker can sell > it as his own software, or just manipulate the routine checking for a > dongle in the usb port, thus allowing piracy. From what I know I do not > run this risk with my VO application. > > Is this MSIL code which is distributed to the customers, allowing free > access to the source code ? >
From: jmespinosabaviera on 21 Nov 2005 07:49 Thanks again. What is the .pdb file ? Is it something I will have (as a result of vulcan compilation) and hackers won't have because it's not necessary to deliver to the customer for him to use the software ?
From: Don Caton on 21 Nov 2005 08:00 "jmespinosabaviera(a)yahoo.com" <jmespinosabaviera(a)yahoo.com> wrote in message news:1132571553.607291.242860(a)g14g2000cwa.googlegroups.com: > Thanks to all who are responding. > > This seems to bring other (bad) consequences: If MSIL cab be brought > back to the original code, then a hacker can obtain the source code and > steal your software, I mean make some changes and the hacker can sell > it as his own software, or just manipulate the routine checking for a > dongle in the usb port, thus allowing piracy. From what I know I do not > run this risk with my VO application. IL can _not_ be brought back to the original code. It can be brought back to an approximation, just like any other decompiler can, even for a native code application. It may or may not be recompilable, depending on how good the decompiler is. IL code can always be decompiled to raw IL code to ILDASM and reassembled using ILASM, but you can do the same with native code using a decompiler and an assembler. The metadata in a .NET app makes the process somewhat easier, but there are obfuscators out there that can scramble the metadata in such as way as to render it much harder for humans to understand, while still allowing the CLR to use it. Keep in mind that given enough effort, anything can be reverse engineered. In the case of code checking for a dongle, you might want to keep that code as native and simply have the .NET application call the native routine. In general though, this whole thing really doesn't seem to be an issue. It certainly doesn't seem to be impeding the migration from native to managed applications. This is one of those things that I think people tend to blow out of proportion. -- Don
From: Ginny Caughey on 21 Nov 2005 07:58
Yes that's right. When you create a .NET executable in debug mode, the pdb file is automatically generated. When you release a product to a customer, you'll build it in release mode, and you won't send them the pdb file. I haven't checked, but the release mode might be less useful to reflect against than the debug build anway. -- Ginny <jmespinosabaviera(a)yahoo.com> wrote in message news:1132577394.247798.237960(a)g14g2000cwa.googlegroups.com... > Thanks again. What is the .pdb file ? Is it something I will have (as a > result of vulcan compilation) and hackers won't have because it's not > necessary to deliver to the customer for him to use the software ? > |