VOPS
in [Visual Objects]
|
From: Gary Stark on 21 Nov 2005 18:21 jmespinosabaviera(a)yahoo.com wrote: > 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 ? Only if you let it. I've already made a reference to obfuscators; I strongly suggest that you research them. -- g. Gary Stark gstark(a)RedbacksWeb.com http://www.RedbacksWeb.com
From: Geoff Schaller on 21 Nov 2005 18:41 Gary, But just to add to what you've said, even without obfuscators, the reverse engineering task is not going to be easy. One thing I did see was that comments go into the output too but if they are suppressed, it might make the task even more difficult. (Or maybe one of the tasks of the obfuscator is to strip these?) Surely there is a point where the cost of reverse engineering exceeds functionality duplication in the first place? I'm not that sure I'm too worried about it. Geoff "Gary Stark" <bogusemail(a)yahoo.com> wrote in message news:3uf366F110kdlU1(a)individual.net: > jmespinosabaviera(a)yahoo.com wrote: > > > 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 ? > > > Only if you let it. > > I've already made a reference to obfuscators; I strongly suggest that > you research them. > > > -- > g. > Gary Stark > gstark(a)RedbacksWeb.com > http://www.RedbacksWeb.com
From: Don Caton on 21 Nov 2005 19:27 "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message news:43825b20$1(a)dnews.tpgi.com.au: > Gary, > > But just to add to what you've said, even without obfuscators, the > reverse engineering task is not going to be easy. One thing I did see > was that comments go into the output too but if they are suppressed, it > might make the task even more difficult. (Or maybe one of the tasks of > the obfuscator is to strip these?) This is incorrect. Nothing from the source code, comments or otherwise, ends up in the output of a .NET assembly. The only information about the source code in an assembly is the file name(s) of the source code, and line/column number information that associates a group of IL instructions with a line/column number range in the source code. This information is used by the runtime in stack dumps and error information, by the debugger and by utilities such as ILDASM. If you disassemble a .NET assembly using ILDASM and it was compiled with debug information AND the source code is present, then you will see the original source code (including comments) in the output of ILDASM. If the source code isn't present, you will only see the raw IL code. As I mentioned in another post, it is possible to store the original source code in a .pdb file but I'm not aware of any .NET compiler that does this. And even if there is, you typically wouldn't distribute the ..pdb file anyhow. -- Don
From: Geoff Schaller on 21 Nov 2005 20:00 Don, Ok, thank you for the correction. I thought I had seen that demonstrated but it must have been with debug on. It is probably then another good reason not to distribute debug versions. Geoff "Don Caton" <dcaton(a)shorelinesoftware.com> wrote in message news:AcOdnbeUPrCc-x_enZ2dnUVZ_tOdnZ2d(a)comcast.com: > "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message > news:43825b20$1(a)dnews.tpgi.com.au: > > > > Gary, > > > > But just to add to what you've said, even without obfuscators, the > > reverse engineering task is not going to be easy. One thing I did see > > was that comments go into the output too but if they are suppressed, it > > might make the task even more difficult. (Or maybe one of the tasks of > > the obfuscator is to strip these?) > > > This is incorrect. Nothing from the source code, comments or otherwise, > ends up in the output of a .NET assembly. > > The only information about the source code in an assembly is the file > name(s) of the source code, and line/column number information that > associates a group of IL instructions with a line/column number range in > the source code. > > This information is used by the runtime in stack dumps and error > information, by the debugger and by utilities such as ILDASM. > > If you disassemble a .NET assembly using ILDASM and it was compiled with > debug information AND the source code is present, then you will see the > original source code (including comments) in the output of ILDASM. If > the source code isn't present, you will only see the raw IL code. > > As I mentioned in another post, it is possible to store the original > source code in a .pdb file but I'm not aware of any .NET compiler that > does this. And even if there is, you typically wouldn't distribute the > .pdb file anyhow. > > -- > Don
From: Don Caton on 21 Nov 2005 20:21
"Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message news:43826d73$1(a)dnews.tpgi.com.au: > Don, > > Ok, thank you for the correction. I thought I had seen that demonstrated > but it must have been with debug on. It is probably then another good > reason not to distribute debug versions. I don't think there's any risk in distributing debug versions. The only real difference between a .NET assembly compiled in debug mode is that JIT compiler optimizations are turned off and line number information is present. The line number information can be helpful in tracking down runtime errors during development and beta testing. If you compile without debug info, stack traces will only contain method names, no line numbers, so it's harder to track down errors. -- Don |