.NET and "industrial espionage"
-
Hi friends, I am involved in project whose the development of base classes and architecture high level were under my team responsibility. After creating 80% of these classes I am about to involve more developers in the process and I fall in problem that is me leaving a little preoccupied: These basic components won't be maintained by production team and they will only have access to the binaries of these components. The tools that I made some tests for assemblies obfuscation it doesn't allow me to protect such assemblies inside the team. I would like that the team have these assemblies ALREADY protected, what would be the first level of safety against copy of intellectual property. My idea is that even if talented programmer gets to leave of company with the sources that contain the business rules, the CORE it (basic classes, personalized controls, access rules for database and etc) of the thing he won't have access, which, I belive, turns the sources "less attractive" because to create such components of the zero it would take plenty time. Does anybody already use some tool that allows something like that? Does anybody have some idea on this? Greetings, Marcelo Palladino Brazil
-
Hi friends, I am involved in project whose the development of base classes and architecture high level were under my team responsibility. After creating 80% of these classes I am about to involve more developers in the process and I fall in problem that is me leaving a little preoccupied: These basic components won't be maintained by production team and they will only have access to the binaries of these components. The tools that I made some tests for assemblies obfuscation it doesn't allow me to protect such assemblies inside the team. I would like that the team have these assemblies ALREADY protected, what would be the first level of safety against copy of intellectual property. My idea is that even if talented programmer gets to leave of company with the sources that contain the business rules, the CORE it (basic classes, personalized controls, access rules for database and etc) of the thing he won't have access, which, I belive, turns the sources "less attractive" because to create such components of the zero it would take plenty time. Does anybody already use some tool that allows something like that? Does anybody have some idea on this? Greetings, Marcelo Palladino Brazil
Palladino wrote: I would like that the team have these assemblies ALREADY protected, what would be the first level of safety against copy of intellectual property. My idea is that even if talented programmer gets to leave of company with the sources that contain the business rules, the CORE it (basic classes, personalized controls, access rules for database and etc) of the thing he won't have access, which, I belive, turns the sources "less attractive" because to create such components of the zero it would take plenty time. 1. You need to trust your team. 2. You are making the assumption that someone will act unethically at best, and illegally at worst. Another company hiring such a person, at least here in the US, can get in real hot water. There are employee agreements to prevent this, including the jokingly unenforceable "you can't work in a related industry for 5 years after termination" type of BS. 3. Is this something you really feel is necesary to spend time and effort worrying about? Palladino wrote: Does anybody have some idea on this? It wasn't clear as to why you can't give the production team the obfuscated assemblies. How is obfuscation failing you in this instance? Marc Latest AAL Article My blog Join my forum!
-
Palladino wrote: I would like that the team have these assemblies ALREADY protected, what would be the first level of safety against copy of intellectual property. My idea is that even if talented programmer gets to leave of company with the sources that contain the business rules, the CORE it (basic classes, personalized controls, access rules for database and etc) of the thing he won't have access, which, I belive, turns the sources "less attractive" because to create such components of the zero it would take plenty time. 1. You need to trust your team. 2. You are making the assumption that someone will act unethically at best, and illegally at worst. Another company hiring such a person, at least here in the US, can get in real hot water. There are employee agreements to prevent this, including the jokingly unenforceable "you can't work in a related industry for 5 years after termination" type of BS. 3. Is this something you really feel is necesary to spend time and effort worrying about? Palladino wrote: Does anybody have some idea on this? It wasn't clear as to why you can't give the production team the obfuscated assemblies. How is obfuscation failing you in this instance? Marc Latest AAL Article My blog Join my forum!
Hi Marc, Before anything: Thank you for trying to understand me. I am aware that my English is badly, I am trying to get better. Marc Clifton wrote: 3. Is this something you really feel is necesary to spend time and effort worrying about? hum... To read your post made to think me of another point of view. Perhaps it is not, really... I will continue thinking about this. Marc Clifton wrote: It wasn't clear as to why you can't give the production team the obfuscated assemblies. How is obfuscation failing you in this instance? I have like this a class (before obfuscation):
public class MyClass { }
After obfuscation:public class 983276376jssdjh { }
Perhaps I am making something wrong, but this way, the assemblie becomes invalid for programming. The execution goes well, however. Hugs, Marcelo Palladino Brazil -
Hi Marc, Before anything: Thank you for trying to understand me. I am aware that my English is badly, I am trying to get better. Marc Clifton wrote: 3. Is this something you really feel is necesary to spend time and effort worrying about? hum... To read your post made to think me of another point of view. Perhaps it is not, really... I will continue thinking about this. Marc Clifton wrote: It wasn't clear as to why you can't give the production team the obfuscated assemblies. How is obfuscation failing you in this instance? I have like this a class (before obfuscation):
public class MyClass { }
After obfuscation:public class 983276376jssdjh { }
Perhaps I am making something wrong, but this way, the assemblie becomes invalid for programming. The execution goes well, however. Hugs, Marcelo Palladino BrazilPalladino wrote: Perhaps I am making something wrong, but this way, the assemblie becomes invalid for programming. The execution goes well, however. Ah, you so you want the source code obfuscated? It would be a little bit of work to add the automation, but what would happen if you took your obfuscated assembly, read it into Lutz Roeder's .NET Refelctor[^], and ran the "decompiler" function to emit the now obfuscated but still compileable assembly source? But I'm confused about something--why supply the source and obfuscate things like the class name? Wouldn't that break other functions that reference that class? Or do you *want* people to use the obfuscated source? No wait--you want to supply the internal source obfuscated, but there are certain "public" unobfuscated classes and methods that are the interface points? Is that it? Marc Latest AAL Article My blog Join my forum!
-
Palladino wrote: Perhaps I am making something wrong, but this way, the assemblie becomes invalid for programming. The execution goes well, however. Ah, you so you want the source code obfuscated? It would be a little bit of work to add the automation, but what would happen if you took your obfuscated assembly, read it into Lutz Roeder's .NET Refelctor[^], and ran the "decompiler" function to emit the now obfuscated but still compileable assembly source? But I'm confused about something--why supply the source and obfuscate things like the class name? Wouldn't that break other functions that reference that class? Or do you *want* people to use the obfuscated source? No wait--you want to supply the internal source obfuscated, but there are certain "public" unobfuscated classes and methods that are the interface points? Is that it? Marc Latest AAL Article My blog Join my forum!
Hi again Marc, Marc Clifton wrote: No wait--you want to supply the internal source obfuscated, but there are certain "public" unobfuscated classes and methods that are the interface points? Is that it? It is exactly this! What is happening, with the tool that I am using: It is changing the names of the types, instead of changing implementation only. However, when beginning to talk with you I went to test other tools (Salamander, for instance) and I noticed that work in the expected way. It seems that am in the road. Thank you, again! Marcelo Palladino Brazil
-
Palladino wrote: Perhaps I am making something wrong, but this way, the assemblie becomes invalid for programming. The execution goes well, however. Ah, you so you want the source code obfuscated? It would be a little bit of work to add the automation, but what would happen if you took your obfuscated assembly, read it into Lutz Roeder's .NET Refelctor[^], and ran the "decompiler" function to emit the now obfuscated but still compileable assembly source? But I'm confused about something--why supply the source and obfuscate things like the class name? Wouldn't that break other functions that reference that class? Or do you *want* people to use the obfuscated source? No wait--you want to supply the internal source obfuscated, but there are certain "public" unobfuscated classes and methods that are the interface points? Is that it? Marc Latest AAL Article My blog Join my forum!