|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Prevent others from using my class librariesI have a solution with a Windows Application project and two Class
Library Projects. I'd like to have the ability to "protect" my Class Libraries from someone copying them and using them in their project. What would be the procude to ensure that the Class Libraries can only be loaded by my Windows Application? ..NET 2.0 Thanks so much! Jason Newell For those interested, I've found that using InternalsVisibleTo Attribute
in my AssemblyInfo.cs did the trick. Jason Newell Jason Newell wrote: Show quoteHide quote > I have a solution with a Windows Application project and two Class > Library Projects. I'd like to have the ability to "protect" my Class > Libraries from someone copying them and using them in their project. > What would be the procude to ensure that the Class Libraries can only be > loaded by my Windows Application? > > .NET 2.0 > > Thanks so much! > > Jason Newell That class is intended to allow another assembly to treat your internal
members as public, but doesn't do anything to protect your public members. Additionally, this doesn't help much with reflection and reverse compilation and such. There are things you can try to do to protect your code, but they won't really stop anyone who is determined to use your code. If they have your binary, you are pretty limited in what you can do to deter someone. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Jason Newell" <nospam@nospam.com> wrote in message news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... > For those interested, I've found that using InternalsVisibleTo Attribute > in my AssemblyInfo.cs did the trick. > > Jason Newell > > > Jason Newell wrote: >> I have a solution with a Windows Application project and two Class >> Library Projects. I'd like to have the ability to "protect" my Class >> Libraries from someone copying them and using them in their project. What >> would be the procude to ensure that the Class Libraries can only be >> loaded by my Windows Application? >> >> .NET 2.0 >> >> Thanks so much! >> >> Jason Newell Could it be possible to use SecurityAction.InheritanceDemand for the class in
order to prevent others application to instanciate it ? Show quoteHide quote "Joe Kaplan (MVP - ADSI)" wrote: > That class is intended to allow another assembly to treat your internal > members as public, but doesn't do anything to protect your public members. > Additionally, this doesn't help much with reflection and reverse compilation > and such. > > There are things you can try to do to protect your code, but they won't > really stop anyone who is determined to use your code. If they have your > binary, you are pretty limited in what you can do to deter someone. > > Joe K. > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services Programming" > http://www.directoryprogramming.net > -- > "Jason Newell" <nospam@nospam.com> wrote in message > news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... > > For those interested, I've found that using InternalsVisibleTo Attribute > > in my AssemblyInfo.cs did the trick. > > > > Jason Newell > > > > > > Jason Newell wrote: > >> I have a solution with a Windows Application project and two Class > >> Library Projects. I'd like to have the ability to "protect" my Class > >> Libraries from someone copying them and using them in their project. What > >> would be the procude to ensure that the Class Libraries can only be > >> loaded by my Windows Application? > >> > >> .NET 2.0 > >> > >> Thanks so much! > >> > >> Jason Newell > > > Not really. They can resign your code with their key or remove it or turn
off CAS completely. Nothing will really stop them if they have the dll. objfuscation can help protect your IP. -- Show quoteHide quoteWilliam Stacey [MVP] "serge calderara" <sergecalder***@discussions.microsoft.com> wrote in message news:C869007B-04EA-410A-AECC-3FF0497B1B87@microsoft.com... | Could it be possible to use SecurityAction.InheritanceDemand for the class in | order to prevent others application to instanciate it ? | | "Joe Kaplan (MVP - ADSI)" wrote: | | > That class is intended to allow another assembly to treat your internal | > members as public, but doesn't do anything to protect your public members. | > Additionally, this doesn't help much with reflection and reverse compilation | > and such. | > | > There are things you can try to do to protect your code, but they won't | > really stop anyone who is determined to use your code. If they have your | > binary, you are pretty limited in what you can do to deter someone. | > | > Joe K. | > | > -- | > Joe Kaplan-MS MVP Directory Services Programming | > Co-author of "The .NET Developer's Guide to Directory Services Programming" | > http://www.directoryprogramming.net | > -- | > "Jason Newell" <nospam@nospam.com> wrote in message | > news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... | > > For those interested, I've found that using InternalsVisibleTo Attribute | > > in my AssemblyInfo.cs did the trick. | > > | > > Jason Newell | > > | > > | > > Jason Newell wrote: | > >> I have a solution with a Windows Application project and two Class | > >> Library Projects. I'd like to have the ability to "protect" my Class | > >> Libraries from someone copying them and using them in their project. What | > >> would be the procude to ensure that the Class Libraries can only be | > >> loaded by my Windows Application? | > >> | > >> .NET 2.0 | > >> | > >> Thanks so much! | > >> | > >> Jason Newell | > | > | > Identity permission (e.g. used in Inheritance or LinkDemands) are only enforced
in partial trust (at least in 2.0 - this was different in 1.1 - the various ways to bypass these checkes in full trust lead to the removal of that feature). So yes - you can use them - but only if your app (or to be more specific - the caller of your class lib) is running in partial trust. Is that the case? No. Because the question of the OP was how to protect his component when he does not have any control over the target environment. Again the answer is No - you cannot protect your lib. Obfuscation with a number of access checks may make it harder...but you can only raise the bar. If you need full control over your lib - don't hand it to someone. dominick Show quoteHide quote > Could it be possible to use SecurityAction.InheritanceDemand for the > class in order to prevent others application to instanciate it ? > > "Joe Kaplan (MVP - ADSI)" wrote: > >> That class is intended to allow another assembly to treat your >> internal members as public, but doesn't do anything to protect your >> public members. Additionally, this doesn't help much with reflection >> and reverse compilation and such. >> >> There are things you can try to do to protect your code, but they >> won't really stop anyone who is determined to use your code. If they >> have your binary, you are pretty limited in what you can do to deter >> someone. >> >> Joe K. >> >> -- >> Joe Kaplan-MS MVP Directory Services Programming >> Co-author of "The .NET Developer's Guide to Directory Services >> Programming" >> http://www.directoryprogramming.net >> -- >> "Jason Newell" <nospam@nospam.com> wrote in message >> news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... >>> For those interested, I've found that using InternalsVisibleTo >>> Attribute in my AssemblyInfo.cs did the trick. >>> >>> Jason Newell >>> >>> Jason Newell wrote: >>> >>>> I have a solution with a Windows Application project and two Class >>>> Library Projects. I'd like to have the ability to "protect" my >>>> Class Libraries from someone copying them and using them in their >>>> project. What would be the procude to ensure that the Class >>>> Libraries can only be loaded by my Windows Application? >>>> >>>> .NET 2.0 >>>> >>>> Thanks so much! >>>> >>>> Jason Newell >>>> What about having a licence key for use your library ?
Show quoteHide quote "Dominick Baier" wrote: > Identity permission (e.g. used in Inheritance or LinkDemands) are only enforced > in partial trust (at least in 2.0 - this was different in 1.1 - the various > ways to bypass these checkes in full trust lead to the removal of that feature). > > So yes - you can use them - but only if your app (or to be more specific > - the caller of your class lib) is running in partial trust. Is that the > case? > > No. Because the question of the OP was how to protect his component when > he does not have any control over the target environment. > > Again the answer is No - you cannot protect your lib. > > Obfuscation with a number of access checks may make it harder...but you can > only raise the bar. > > If you need full control over your lib - don't hand it to someone. > > dominick > > > Could it be possible to use SecurityAction.InheritanceDemand for the > > class in order to prevent others application to instanciate it ? > > > > "Joe Kaplan (MVP - ADSI)" wrote: > > > >> That class is intended to allow another assembly to treat your > >> internal members as public, but doesn't do anything to protect your > >> public members. Additionally, this doesn't help much with reflection > >> and reverse compilation and such. > >> > >> There are things you can try to do to protect your code, but they > >> won't really stop anyone who is determined to use your code. If they > >> have your binary, you are pretty limited in what you can do to deter > >> someone. > >> > >> Joe K. > >> > >> -- > >> Joe Kaplan-MS MVP Directory Services Programming > >> Co-author of "The .NET Developer's Guide to Directory Services > >> Programming" > >> http://www.directoryprogramming.net > >> -- > >> "Jason Newell" <nospam@nospam.com> wrote in message > >> news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... > >>> For those interested, I've found that using InternalsVisibleTo > >>> Attribute in my AssemblyInfo.cs did the trick. > >>> > >>> Jason Newell > >>> > >>> Jason Newell wrote: > >>> > >>>> I have a solution with a Windows Application project and two Class > >>>> Library Projects. I'd like to have the ability to "protect" my > >>>> Class Libraries from someone copying them and using them in their > >>>> project. What would be the procude to ensure that the Class > >>>> Libraries can only be loaded by my Windows Application? > >>>> > >>>> .NET 2.0 > >>>> > >>>> Thanks so much! > >>>> > >>>> Jason Newell > >>>> > > > serge,
just think about it - all the code is on the clients machine. this guy is admin. he can do everything he wants. He can use reflector. He can turn of CAS. Hey, he can even patch the clr to disable all checks. You are right, there are a lot of techniques to make this harder, strong naming, CAS, licence keys etc...it is just that i wouldn't spend too much time and effort on them. Look at big companies in the IT or games industry - have they achieved bulletproof licencing schemes - and they surely spent more money on investigation than you ever can. just my 2c dominick Show quoteHide quote > What about having a licence key for use your library ? > > "Dominick Baier" wrote: > >> Identity permission (e.g. used in Inheritance or LinkDemands) are >> only enforced in partial trust (at least in 2.0 - this was different >> in 1.1 - the various ways to bypass these checkes in full trust lead >> to the removal of that feature). >> >> So yes - you can use them - but only if your app (or to be more >> specific - the caller of your class lib) is running in partial trust. >> Is that the case? >> >> No. Because the question of the OP was how to protect his component >> when he does not have any control over the target environment. >> >> Again the answer is No - you cannot protect your lib. >> >> Obfuscation with a number of access checks may make it harder...but >> you can only raise the bar. >> >> If you need full control over your lib - don't hand it to someone. >> >> dominick >> >>> Could it be possible to use SecurityAction.InheritanceDemand for the >>> class in order to prevent others application to instanciate it ? >>> >>> "Joe Kaplan (MVP - ADSI)" wrote: >>> >>>> That class is intended to allow another assembly to treat your >>>> internal members as public, but doesn't do anything to protect your >>>> public members. Additionally, this doesn't help much with >>>> reflection and reverse compilation and such. >>>> >>>> There are things you can try to do to protect your code, but they >>>> won't really stop anyone who is determined to use your code. If >>>> they have your binary, you are pretty limited in what you can do to >>>> deter someone. >>>> >>>> Joe K. >>>> >>>> -- >>>> Joe Kaplan-MS MVP Directory Services Programming >>>> Co-author of "The .NET Developer's Guide to Directory Services >>>> Programming" >>>> http://www.directoryprogramming.net >>>> -- >>>> "Jason Newell" <nospam@nospam.com> wrote in message >>>> news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... >>>>> For those interested, I've found that using InternalsVisibleTo >>>>> Attribute in my AssemblyInfo.cs did the trick. >>>>> >>>>> Jason Newell >>>>> >>>>> Jason Newell wrote: >>>>> >>>>>> I have a solution with a Windows Application project and two >>>>>> Class Library Projects. I'd like to have the ability to >>>>>> "protect" my Class Libraries from someone copying them and using >>>>>> them in their project. What would be the procude to ensure that >>>>>> the Class Libraries can only be loaded by my Windows Application? >>>>>> >>>>>> .NET 2.0 >>>>>> >>>>>> Thanks so much! >>>>>> >>>>>> Jason Newell >>>>>> Dominik,
I full agree with you. In real life when you notinced that it takes too much time to impleemnt a thing most of the time it is left behind and forget about it. But security today is on the top of the scen and I think that if you deploy a safe approach for that they will be agreed on spending more time and money on implementing as safe as you can a secure environrment. So if a compny deplpoy some pplication and tehy do not wnat anyone to use they own library and think you will have to provide effort and solution to reach that goal. Sure you can never be sure but at least you can give some pain to people who might try. Just my own opinion too Show quoteHide quote "Dominick Baier" wrote: > serge, > > just think about it - all the code is on the clients machine. this guy is > admin. he can do everything he wants. > > He can use reflector. He can turn of CAS. Hey, he can even patch the clr > to disable all checks. > > You are right, there are a lot of techniques to make this harder, strong > naming, CAS, licence keys etc...it is just that i wouldn't spend too much > time and effort on them. > > Look at big companies in the IT or games industry - have they achieved bulletproof > licencing schemes - and they surely spent more money on investigation than > you ever can. > > just my 2c > dominick > > > > > What about having a licence key for use your library ? > > > > "Dominick Baier" wrote: > > > >> Identity permission (e.g. used in Inheritance or LinkDemands) are > >> only enforced in partial trust (at least in 2.0 - this was different > >> in 1.1 - the various ways to bypass these checkes in full trust lead > >> to the removal of that feature). > >> > >> So yes - you can use them - but only if your app (or to be more > >> specific - the caller of your class lib) is running in partial trust. > >> Is that the case? > >> > >> No. Because the question of the OP was how to protect his component > >> when he does not have any control over the target environment. > >> > >> Again the answer is No - you cannot protect your lib. > >> > >> Obfuscation with a number of access checks may make it harder...but > >> you can only raise the bar. > >> > >> If you need full control over your lib - don't hand it to someone. > >> > >> dominick > >> > >>> Could it be possible to use SecurityAction.InheritanceDemand for the > >>> class in order to prevent others application to instanciate it ? > >>> > >>> "Joe Kaplan (MVP - ADSI)" wrote: > >>> > >>>> That class is intended to allow another assembly to treat your > >>>> internal members as public, but doesn't do anything to protect your > >>>> public members. Additionally, this doesn't help much with > >>>> reflection and reverse compilation and such. > >>>> > >>>> There are things you can try to do to protect your code, but they > >>>> won't really stop anyone who is determined to use your code. If > >>>> they have your binary, you are pretty limited in what you can do to > >>>> deter someone. > >>>> > >>>> Joe K. > >>>> > >>>> -- > >>>> Joe Kaplan-MS MVP Directory Services Programming > >>>> Co-author of "The .NET Developer's Guide to Directory Services > >>>> Programming" > >>>> http://www.directoryprogramming.net > >>>> -- > >>>> "Jason Newell" <nospam@nospam.com> wrote in message > >>>> news:eu$7RpErGHA.4004@TK2MSFTNGP02.phx.gbl... > >>>>> For those interested, I've found that using InternalsVisibleTo > >>>>> Attribute in my AssemblyInfo.cs did the trick. > >>>>> > >>>>> Jason Newell > >>>>> > >>>>> Jason Newell wrote: > >>>>> > >>>>>> I have a solution with a Windows Application project and two > >>>>>> Class Library Projects. I'd like to have the ability to > >>>>>> "protect" my Class Libraries from someone copying them and using > >>>>>> them in their project. What would be the procude to ensure that > >>>>>> the Class Libraries can only be loaded by my Windows Application? > >>>>>> > >>>>>> .NET 2.0 > >>>>>> > >>>>>> Thanks so much! > >>>>>> > >>>>>> Jason Newell > >>>>>> > > > Thanks for everyones input. I didn't mention it earlier but I am well
versed in the pitfalls of protecting .NET code. I've maybe even done a wee bit of reverse engineering in my day. Hey, we probably all have. My main point is that I just didn't want Joe programmer to simply make a copy of my .dll, reference it and create \ use my objects. Making my Class Libraries members internal was a viable option for me in this scenerio when combined with the InternalsVisibleTo attribute. I wrote a test program that was not designated as a friend assembly and I was unable to see any members via Object Browser nor was I able to create any objects from the Class Libraries. Here is my setup for those interested. Foo <-- Windows Application Foo.Controls <-- Class Library [assembly: InternalsVisibleTo("Foo, PublicKey=xxxx")] Foo.Framework <-- Class Library [assembly: InternalsVisibleTo("Foo, PublicKey=xxx")] [assembly: InternalsVisibleTo("Foo.Controls, PublicKey=xxx")] Jason Newell Jason Newell wrote: Show quoteHide quote > For those interested, I've found that using InternalsVisibleTo Attribute > in my AssemblyInfo.cs did the trick. > > Jason Newell > > > Jason Newell wrote: > >> I have a solution with a Windows Application project and two Class >> Library Projects. I'd like to have the ability to "protect" my Class >> Libraries from someone copying them and using them in their project. >> What would be the procude to ensure that the Class Libraries can only >> be loaded by my Windows Application? >> >> .NET 2.0 >> >> Thanks so much! >> >> Jason Newell Ok, as long as you don't see this is as a real security feature, you are
probably fine. This will prevent casual usage by someone who doesn't try to hard or doesn't know what they are doing. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Jason Newell" <nospam@nospam.com> wrote in message news:emdGquMrGHA.4820@TK2MSFTNGP04.phx.gbl... > Thanks for everyones input. I didn't mention it earlier but I am well > versed in the pitfalls of protecting .NET code. I've maybe even done a > wee bit of reverse engineering in my day. Hey, we probably all have. > > My main point is that I just didn't want Joe programmer to simply make a > copy of my .dll, reference it and create \ use my objects. Making my > Class Libraries members internal was a viable option for me in this > scenerio when combined with the InternalsVisibleTo attribute. I wrote a > test program that was not designated as a friend assembly and I was unable > to see any members via Object Browser nor was I able to create any objects > from the Class Libraries. > > Here is my setup for those interested. > > Foo <-- Windows Application > > Foo.Controls <-- Class Library > [assembly: InternalsVisibleTo("Foo, PublicKey=xxxx")] > > Foo.Framework <-- Class Library > [assembly: InternalsVisibleTo("Foo, PublicKey=xxx")] > [assembly: InternalsVisibleTo("Foo.Controls, PublicKey=xxx")] > > > Jason Newell > > > > Jason Newell wrote: >> For those interested, I've found that using InternalsVisibleTo Attribute >> in my AssemblyInfo.cs did the trick. >> >> Jason Newell >> >> >> Jason Newell wrote: >> >>> I have a solution with a Windows Application project and two Class >>> Library Projects. I'd like to have the ability to "protect" my Class >>> Libraries from someone copying them and using them in their project. >>> What would be the procude to ensure that the Class Libraries can only be >>> loaded by my Windows Application? >>> >>> .NET 2.0 >>> >>> Thanks so much! >>> >>> Jason Newell A few more questions for you Joe, if you have time.
In addition to what I've aleady done, I obviously plan on obfuscation. I have some custom routines that I have developed on my own and would really like to protect. They involve parsing CAD data that is stored in compound files. I'm proficient in C++ so I'm wondering if I would be better off putting that logic in a C++ .dll and pinvoke it from .NET. I suppose people could still figure out how I'm calling the C++ .dll but it would be much more difficult for them to know "how" the C++ does it's magic. If that sounds like a good idea, I'm wonder how I could also prevent anyone but me from calling the C++ exported functions. Any ideas or is that even possible? Thanks so much. Jason Newell Joe Kaplan (MVP - ADSI) wrote: Show quoteHide quote > Ok, as long as you don't see this is as a real security feature, you are > probably fine. This will prevent casual usage by someone who doesn't try to > hard or doesn't know what they are doing. > > Joe K. > I'm not aware of any easy way to do that in native code, but I'm not really
a native code developer, so I'm not a good person to ask. Another thing you might consider if you like writing C++ is writing in managed C++, with some of your core logic implemented in native code so it would all be combined together in one binary. You might be able to get the best of both using an approach like that. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Jason Newell" <nospam@nospam.com> wrote in message news:O%23Y$f%23QrGHA.516@TK2MSFTNGP05.phx.gbl... >A few more questions for you Joe, if you have time. > > In addition to what I've aleady done, I obviously plan on obfuscation. > > I have some custom routines that I have developed on my own and would > really like to protect. They involve parsing CAD data that is stored in > compound files. I'm proficient in C++ so I'm wondering if I would be > better off putting that logic in a C++ .dll and pinvoke it from .NET. I > suppose people could still figure out how I'm calling the C++ .dll but it > would be much more difficult for them to know "how" the C++ does it's > magic. If that sounds like a good idea, I'm wonder how I could also > prevent anyone but me from calling the C++ exported functions. Any ideas > or is that even possible? > > Thanks so much. > > Jason Newell > > > Joe Kaplan (MVP - ADSI) wrote: >> Ok, as long as you don't see this is as a real security feature, you are >> probably fine. This will prevent casual usage by someone who doesn't try >> to hard or doesn't know what they are doing. >> >> Joe K. >> Hi Joe,
DCC http://www.itee.uq.edu.au/~cristina/dcc.html, which is 12 years old now, is a C decompiler that was developed by Cristina Cifuentes for her PhD thesis. After Cristina's thesis, there were at least couple of attempts of commerical decompilers. I remember that some of them were producing decent results, however (AFAIK) none of them managed to became succesfull due to insuficient interest to commerical versions of decompilers. And now there is an open source boomerang project http://boomerang.sourceforge.net/ that already have quite good results when decompiling real life programs even so it is in its alpha (0.3) release. So far about decompilation of binary code ;-). -Valery. http://www.harper.no/valery Joe Kaplan (MVP - ADSI) wrote: Show quoteHide quote > I'm not aware of any easy way to do that in native code, but I'm not really > a native code developer, so I'm not a good person to ask. > > Another thing you might consider if you like writing C++ is writing in > managed C++, with some of your core logic implemented in native code so it > would all be combined together in one binary. You might be able to get the > best of both using an approach like that. > > Joe K. > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services Programming" > http://www.directoryprogramming.net > -- > "Jason Newell" <nospam@nospam.com> wrote in message > news:O%23Y$f%23QrGHA.516@TK2MSFTNGP05.phx.gbl... > >A few more questions for you Joe, if you have time. > > > > In addition to what I've aleady done, I obviously plan on obfuscation. > > > > I have some custom routines that I have developed on my own and would > > really like to protect. They involve parsing CAD data that is stored in > > compound files. I'm proficient in C++ so I'm wondering if I would be > > better off putting that logic in a C++ .dll and pinvoke it from .NET. I > > suppose people could still figure out how I'm calling the C++ .dll but it > > would be much more difficult for them to know "how" the C++ does it's > > magic. If that sounds like a good idea, I'm wonder how I could also > > prevent anyone but me from calling the C++ exported functions. Any ideas > > or is that even possible? > > > > Thanks so much. > > > > Jason Newell > > > > > > Joe Kaplan (MVP - ADSI) wrote: > >> Ok, as long as you don't see this is as a real security feature, you are > >> probably fine. This will prevent casual usage by someone who doesn't try > >> to hard or doesn't know what they are doing. > >> > >> Joe K. > >> And of course, almost I forgot IDA Pro
http://www.datarescue.com/idabase/ida.htm - #1 tool of reverse engineers and hardcore hackers ;-) -Valery. http://www.harper.no/valery Valery Pryamikov wrote: Show quoteHide quote > Hi Joe, > DCC http://www.itee.uq.edu.au/~cristina/dcc.html, which is 12 years old > now, is a C decompiler that was developed by Cristina Cifuentes for > her PhD thesis. > After Cristina's thesis, there were at least couple of attempts of > commerical decompilers. I remember that some of them were producing > decent results, however (AFAIK) none of them managed to became > succesfull due to insuficient interest to commerical versions of > decompilers. > And now there is an open source boomerang project > http://boomerang.sourceforge.net/ that already have quite good results > when decompiling real life programs even so it is in its alpha (0.3) > release. > > So far about decompilation of binary code ;-). > > -Valery. > http://www.harper.no/valery > > > Joe Kaplan (MVP - ADSI) wrote: > > I'm not aware of any easy way to do that in native code, but I'm not really > > a native code developer, so I'm not a good person to ask. > > > > Another thing you might consider if you like writing C++ is writing in > > managed C++, with some of your core logic implemented in native code so it > > would all be combined together in one binary. You might be able to get the > > best of both using an approach like that. > > > > Joe K. > > > > -- > > Joe Kaplan-MS MVP Directory Services Programming > > Co-author of "The .NET Developer's Guide to Directory Services Programming" > > http://www.directoryprogramming.net > > -- > > "Jason Newell" <nospam@nospam.com> wrote in message > > news:O%23Y$f%23QrGHA.516@TK2MSFTNGP05.phx.gbl... > > >A few more questions for you Joe, if you have time. > > > > > > In addition to what I've aleady done, I obviously plan on obfuscation. > > > > > > I have some custom routines that I have developed on my own and would > > > really like to protect. They involve parsing CAD data that is stored in > > > compound files. I'm proficient in C++ so I'm wondering if I would be > > > better off putting that logic in a C++ .dll and pinvoke it from .NET. I > > > suppose people could still figure out how I'm calling the C++ .dll but it > > > would be much more difficult for them to know "how" the C++ does it's > > > magic. If that sounds like a good idea, I'm wonder how I could also > > > prevent anyone but me from calling the C++ exported functions. Any ideas > > > or is that even possible? > > > > > > Thanks so much. > > > > > > Jason Newell > > > > > > > > > Joe Kaplan (MVP - ADSI) wrote: > > >> Ok, as long as you don't see this is as a real security feature, you are > > >> probably fine. This will prevent casual usage by someone who doesn't try > > >> to hard or doesn't know what they are doing. > > >> > > >> Joe K. > > >> Thanks for follow ups on the native code side, Valery. I was hoping you'd
provide more info here. I think our overall point was that if the users have a copy of his binaries, he is fairly limited in terms of what he can do to protect it from a dedicated hacker. The only point I was trying to make with the native code is that it makes it a little easier to keep the honest people honest. :) It is fantasy to pretend that it provides real security. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Valery Pryamikov" <val***@harper.no> wrote in message news:1153555778.549613.34920@b28g2000cwb.googlegroups.com... > And of course, almost I forgot IDA Pro > http://www.datarescue.com/idabase/ida.htm > - #1 tool of reverse engineers and hardcore hackers ;-) > > -Valery. > http://www.harper.no/valery > > Valery Pryamikov wrote: >> Hi Joe, >> DCC http://www.itee.uq.edu.au/~cristina/dcc.html, which is 12 years old >> now, is a C decompiler that was developed by Cristina Cifuentes for >> her PhD thesis. >> After Cristina's thesis, there were at least couple of attempts of >> commerical decompilers. I remember that some of them were producing >> decent results, however (AFAIK) none of them managed to became >> succesfull due to insuficient interest to commerical versions of >> decompilers. >> And now there is an open source boomerang project >> http://boomerang.sourceforge.net/ that already have quite good results >> when decompiling real life programs even so it is in its alpha (0.3) >> release. >> >> So far about decompilation of binary code ;-). >> >> -Valery. >> http://www.harper.no/valery >> >> >> Joe Kaplan (MVP - ADSI) wrote: >> > I'm not aware of any easy way to do that in native code, but I'm not >> > really >> > a native code developer, so I'm not a good person to ask. >> > >> > Another thing you might consider if you like writing C++ is writing in >> > managed C++, with some of your core logic implemented in native code so >> > it >> > would all be combined together in one binary. You might be able to get >> > the >> > best of both using an approach like that. >> > >> > Joe K. >> > >> > -- >> > Joe Kaplan-MS MVP Directory Services Programming >> > Co-author of "The .NET Developer's Guide to Directory Services >> > Programming" >> > http://www.directoryprogramming.net >> > -- >> > "Jason Newell" <nospam@nospam.com> wrote in message >> > news:O%23Y$f%23QrGHA.516@TK2MSFTNGP05.phx.gbl... >> > >A few more questions for you Joe, if you have time. >> > > >> > > In addition to what I've aleady done, I obviously plan on >> > > obfuscation. >> > > >> > > I have some custom routines that I have developed on my own and would >> > > really like to protect. They involve parsing CAD data that is stored >> > > in >> > > compound files. I'm proficient in C++ so I'm wondering if I would be >> > > better off putting that logic in a C++ .dll and pinvoke it from .NET. >> > > I >> > > suppose people could still figure out how I'm calling the C++ .dll >> > > but it >> > > would be much more difficult for them to know "how" the C++ does it's >> > > magic. If that sounds like a good idea, I'm wonder how I could also >> > > prevent anyone but me from calling the C++ exported functions. Any >> > > ideas >> > > or is that even possible? >> > > >> > > Thanks so much. >> > > >> > > Jason Newell >> > > >> > > >> > > Joe Kaplan (MVP - ADSI) wrote: >> > >> Ok, as long as you don't see this is as a real security feature, you >> > >> are >> > >> probably fine. This will prevent casual usage by someone who >> > >> doesn't try >> > >> to hard or doesn't know what they are doing. >> > >> >> > >> Joe K. >> > >> > Hi Joe,
Yes, there are classes of functions that could never be obfuscated, as for example it is hopeless to obfuscate encryption keys and similar. However there are also classes of functions that could be protected quite effectively. And if we take in account functions that are combined of other function, there are very effective methods of protecting them. When talking about software protection - we have to use different notion of security than with cryptography. With cryptography we are ensuring that break of encryption algorithm is unfeasible, i.e. attempt to break it should take billions of millions of years even if we take all computers (including mobile phones) and start breaking a single key. With software protection it is absolutely unrealistic and unnecessary. The point of software protection should be to ensure that breaking software should be at least as difficult as independent development of functional equivalent. If we take such definition for software protection - then it becomes easy to explain why protection of encryption key is impossible - independent recovery of encryption key by looking at input and output is provably unfeasible! Therefore, regardless how much effort attacker will use for breaking the program it will be less than trying to break encryption key. But if we look at any usual programs, any program that is somehow useful (and isn't related to decryption of data with unknown key) could be developed from scratch by independent effort and often such independent development would also take less resources than original development because some design decisions are becomes obvious. If we only consider programs that are sufficiently complex, I believe that is possible to protect them in such way that breaking them will be as difficult and expensive as independent development of functional equivalent. Here you can read about new and quite promising technique: http://www.harper.no/valery/content/binary/ctt.pdf and you can also check the source code of demo program accompanying the article here: http://www.harper.no/valery/CallTreeTransformation/ -Valery. http://www.harper.no/valery Joe Kaplan (MVP - ADSI) wrote: Show quoteHide quote > Thanks for follow ups on the native code side, Valery. I was hoping you'd > provide more info here. I think our overall point was that if the users > have a copy of his binaries, he is fairly limited in terms of what he can do > to protect it from a dedicated hacker. > > The only point I was trying to make with the native code is that it makes it > a little easier to keep the honest people honest. :) It is fantasy to > pretend that it provides real security. > > Joe K. > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services Programming" > http://www.directoryprogramming.net > -- > "Valery Pryamikov" <val***@harper.no> wrote in message > news:1153555778.549613.34920@b28g2000cwb.googlegroups.com... > > And of course, almost I forgot IDA Pro > > http://www.datarescue.com/idabase/ida.htm > > - #1 tool of reverse engineers and hardcore hackers ;-) > > > > -Valery. > > http://www.harper.no/valery > > > > Valery Pryamikov wrote: > >> Hi Joe, > >> DCC http://www.itee.uq.edu.au/~cristina/dcc.html, which is 12 years old > >> now, is a C decompiler that was developed by Cristina Cifuentes for > >> her PhD thesis. > >> After Cristina's thesis, there were at least couple of attempts of > >> commerical decompilers. I remember that some of them were producing > >> decent results, however (AFAIK) none of them managed to became > >> succesfull due to insuficient interest to commerical versions of > >> decompilers. > >> And now there is an open source boomerang project > >> http://boomerang.sourceforge.net/ that already have quite good results > >> when decompiling real life programs even so it is in its alpha (0.3) > >> release. > >> > >> So far about decompilation of binary code ;-). > >> > >> -Valery. > >> http://www.harper.no/valery > >> > >> > >> Joe Kaplan (MVP - ADSI) wrote: > >> > I'm not aware of any easy way to do that in native code, but I'm not > >> > really > >> > a native code developer, so I'm not a good person to ask. > >> > > >> > Another thing you might consider if you like writing C++ is writing in > >> > managed C++, with some of your core logic implemented in native code so > >> > it > >> > would all be combined together in one binary. You might be able to get > >> > the > >> > best of both using an approach like that. > >> > > >> > Joe K. > >> > > >> > -- > >> > Joe Kaplan-MS MVP Directory Services Programming > >> > Co-author of "The .NET Developer's Guide to Directory Services > >> > Programming" > >> > http://www.directoryprogramming.net > >> > -- > >> > "Jason Newell" <nospam@nospam.com> wrote in message > >> > news:O%23Y$f%23QrGHA.516@TK2MSFTNGP05.phx.gbl... > >> > >A few more questions for you Joe, if you have time. > >> > > > >> > > In addition to what I've aleady done, I obviously plan on > >> > > obfuscation. > >> > > > >> > > I have some custom routines that I have developed on my own and would > >> > > really like to protect. They involve parsing CAD data that is stored > >> > > in > >> > > compound files. I'm proficient in C++ so I'm wondering if I would be > >> > > better off putting that logic in a C++ .dll and pinvoke it from .NET. > >> > > I > >> > > suppose people could still figure out how I'm calling the C++ .dll > >> > > but it > >> > > would be much more difficult for them to know "how" the C++ does it's > >> > > magic. If that sounds like a good idea, I'm wonder how I could also > >> > > prevent anyone but me from calling the C++ exported functions. Any > >> > > ideas > >> > > or is that even possible? > >> > > > >> > > Thanks so much. > >> > > > >> > > Jason Newell > >> > > > >> > > > >> > > Joe Kaplan (MVP - ADSI) wrote: > >> > >> Ok, as long as you don't see this is as a real security feature, you > >> > >> are > >> > >> probably fine. This will prevent casual usage by someone who > >> > >> doesn't try > >> > >> to hard or doesn't know what they are doing. > >> > >> > >> > >> Joe K. > >> > >> > > I see what your saying Joe, but in a sense, it is a fools task. You end up
"protecting" for the 99% who don't care, and you can't do anything to protect against the 1% that you really want to protect it from in the first place. Moreover, they are the ones that will "share" how smart they are on the Internet with the other 99%. So in the end, I fear it turns into a waste of time and money that could better be used creating a better product. -- Show quoteHide quoteWilliam Stacey [MVP] "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:%23KbKo4ZrGHA.5004@TK2MSFTNGP05.phx.gbl... | Thanks for follow ups on the native code side, Valery. I was hoping you'd | provide more info here. I think our overall point was that if the users | have a copy of his binaries, he is fairly limited in terms of what he can do | to protect it from a dedicated hacker. | | The only point I was trying to make with the native code is that it makes it | a little easier to keep the honest people honest. :) It is fantasy to | pretend that it provides real security. | | Joe K.
Decryptionfailed to bring original text back....
Help encrypt conn string - no ASP, no server, can't protect keys, can't use Windows Authentication Simple Keyed hash question What's wrong with my encryption function? Newbie Question - Thanks in Advance... Non Administrator creating shares on a DC random passwords Getting the Access Permissions for a specific SID on a File / folder Security problems Native RC4 code |
|||||||||||||||||||||||