Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
is my software safe ?
- Thread starter Eek
- Start date
xascendent
Programmer
as far as I know cracking a exe to get that type of information is not possible because it is converted to machine code.. a Hex editor can do funky stuff to your programs exe but thats about it.. just don't make your program with Java or all will be lost.
petermeachem
Programmer
Yes of course it would be possible to work out the code. You wont get the variable names, of course, but everything else could be found out.
I'm just not sure whether a decompiler is available, or whether one would have to be written. Whether or not the sum of money involved would be too much, I don't know, but of course it could be done.
It would be a lot simpler and cheaper just to walk in and steal your computer of course.
Bit of a worry, the security thing isn't it!
I'm just not sure whether a decompiler is available, or whether one would have to be written. Whether or not the sum of money involved would be too much, I don't know, but of course it could be done.
It would be a lot simpler and cheaper just to walk in and steal your computer of course.
Bit of a worry, the security thing isn't it!
JohnYingling
Programmer
Machine Code is not intelligble, just darned tedious to take apart. You hide a million $ in there and I'll take the time to root it out by hardware, software and eyeWare.
There were decompilers for VB3 and VB4 beacuse they were compiled to an intermediate code.
Even more possible for VB.NET as of now. All product code will be in MSIL (MS Intermediate Language) assembly to be JIT (Just In Time) compiled on the users machine. There is talk of obfuscators but who knows.
There were decompilers for VB3 and VB4 beacuse they were compiled to an intermediate code.
Even more possible for VB.NET as of now. All product code will be in MSIL (MS Intermediate Language) assembly to be JIT (Just In Time) compiled on the users machine. There is talk of obfuscators but who knows.
xascendent
Programmer
why is MS using a Intermediate Language isn't that what Java is?
I have heard of some VB decompilers out there . . . some work to a VERY limited degree, most don't work at all. But, as was previously mentioned, all of your logic is present in the machine language code which can be directly read by someone with enough time and a high enough skill level (personally, I would rather chew on broken glass that read the machine code genereated for a VB app) . . .
The point of all this? The point is this . . . if someone REALLY wants the information in your code, AND they have the time and the skill level, they are going to get it. The chances of this happening however are pretty slim.
Remember . . . the only thing that locks do is to keep honest people honest. If someone really wants your stuff, they're going to get it. - Jeff Marler B-)
The point of all this? The point is this . . . if someone REALLY wants the information in your code, AND they have the time and the skill level, they are going to get it. The chances of this happening however are pretty slim.
Remember . . . the only thing that locks do is to keep honest people honest. If someone really wants your stuff, they're going to get it. - Jeff Marler B-)
petermeachem
Programmer
yes, I was just pointing out that everything has a price. Your company may have a figure they can put on the formulae, and another company will have a figure on how much they would pay to get it.
I once watched a programme on the telly by a security guy. He said that all security systems are relatively easy to get round. He said the best way to get infomation out of a company was to give a secretary or someone in that sort of position a bag containing £25000 if they ran the documents you wanted through a photo-copier and popped them in an envelope in the out tray. Virtually no risk of getting caught, and he reckoned most people would do it. Why should they be loyal to a firm that would sack them if it wanted to?
I once watched a programme on the telly by a security guy. He said that all security systems are relatively easy to get round. He said the best way to get infomation out of a company was to give a secretary or someone in that sort of position a bag containing £25000 if they ran the documents you wanted through a photo-copier and popped them in an envelope in the out tray. Virtually no risk of getting caught, and he reckoned most people would do it. Why should they be loyal to a firm that would sack them if it wanted to?
Well go figure... I like BOTH VB & assembler 
Anyway...
A determined hacker is going to be able to get at your formulas. There are tricks to slow them down but no way to stop them. You don't even have to be an expert. The only question is: Is the time going to be worth it?
If the formulae are that important & revolutionary then you may want to consider another business model ;-)
Anyway...A determined hacker is going to be able to get at your formulas. There are tricks to slow them down but no way to stop them. You don't even have to be an expert. The only question is: Is the time going to be worth it?
If the formulae are that important & revolutionary then you may want to consider another business model ;-)
rafe,
Don't get me wrong . . . I like assembly as well. But I firmly believe that it has its place (and GUI design is not one of them). I taught myself how to program as a kid by learning assembly on the 6809 (back in the 8 bit days . . . and to think, I once used a 1MHz 8 bit system with 64K of Ram compared to my 1 GHz with 512M). But every time I try to read the assembly produced by VB (and I have tried this) I always end up with a headache. OK . . . enough on the side note . . . back to the original question! - Jeff Marler B-)
Don't get me wrong . . . I like assembly as well. But I firmly believe that it has its place (and GUI design is not one of them). I taught myself how to program as a kid by learning assembly on the 6809 (back in the 8 bit days . . . and to think, I once used a 1MHz 8 bit system with 64K of Ram compared to my 1 GHz with 512M). But every time I try to read the assembly produced by VB (and I have tried this) I always end up with a headache. OK . . . enough on the side note . . . back to the original question! - Jeff Marler B-)
Eek,
Rafe made a very good point. Perhaps if your formulae are that important and confidential, then another architecture may be in order. I don't know what you are designing, but perhaps a web application with all of the Business logic (i.e. for formulae existing in compiled DLLs on an MTS box BEHIND then firewall where only authorized people would have access to them would be in order. Just a thought . . . - Jeff Marler B-)
Rafe made a very good point. Perhaps if your formulae are that important and confidential, then another architecture may be in order. I don't know what you are designing, but perhaps a web application with all of the Business logic (i.e. for formulae existing in compiled DLLs on an MTS box BEHIND then firewall where only authorized people would have access to them would be in order. Just a thought . . . - Jeff Marler B-)
xascendent
Programmer
this is not on the subject.. but where can I find samples for MTS programming with VB? I need to make a client server model.. and I was thinking about doing the same thing you just said.
xascendent,
It depends on what you want to do. Do you only want a client-server application, or are you looking at a true n-teired application. Also, will this be for a web app, and internal VB app, or both? But you're right, this is not the subject. Why don't you start a new thread and state specifically what you are looking for and we can go from there.
- Jeff Marler B-)
It depends on what you want to do. Do you only want a client-server application, or are you looking at a true n-teired application. Also, will this be for a web app, and internal VB app, or both? But you're right, this is not the subject. Why don't you start a new thread and state specifically what you are looking for and we can go from there.
- Jeff Marler B-)
Eek, Rafe is mostly correct. Security is moot if somebody is willing to spend the time, effort or money to unravel your secrets. Unfortunately, some secrets stand out like a sore thumb and don't require much time or effort.
I have to admit that I like to snoop, from time to time. I take shortcuts that tell me a bit (often, quite enough) about software packages without violating EULAs by "disassembling", "decompiling" or "reverse engineering". Several associates have been amused while watching me press the Page Down key in a binary file editor while scanning an EXE or DLL. They watch millions of hieroglyphs flash by in a blur and then gasp when I stop, press Page Up and start taking notes.
"How could you possibly understand that?!?"
"I couldn't. I was looking for the API declarations."
At least I'm honest. Formulas wouldn't be so easy to unravel but they could be cracked in a matter of hours (minutes for some pros) if they are associated with text.
If you are worried about somebody taking the next step, i.e., setting break points and tracing the JMPs, I suggest that you look into application compression/encryption. I believe PKware has a stable 32-bit version of PKlite. There are probably quite a few others.
This technology makes it extremely difficult to disassemble or view the contents of an executable. The National Security Agency could crack it fairly easily with their Super LOL Computers but that technology isn't available to most commercial ventures.
Good luck. Have fun. Take it easy. Your competitors will find it much more cost efficient to develop the technology independently, rather than stealing it from you.
Alt255@Vorpalcom.Intranets.com
I have to admit that I like to snoop, from time to time. I take shortcuts that tell me a bit (often, quite enough) about software packages without violating EULAs by "disassembling", "decompiling" or "reverse engineering". Several associates have been amused while watching me press the Page Down key in a binary file editor while scanning an EXE or DLL. They watch millions of hieroglyphs flash by in a blur and then gasp when I stop, press Page Up and start taking notes.
"How could you possibly understand that?!?"
"I couldn't. I was looking for the API declarations."
At least I'm honest. Formulas wouldn't be so easy to unravel but they could be cracked in a matter of hours (minutes for some pros) if they are associated with text.
If you are worried about somebody taking the next step, i.e., setting break points and tracing the JMPs, I suggest that you look into application compression/encryption. I believe PKware has a stable 32-bit version of PKlite. There are probably quite a few others.
This technology makes it extremely difficult to disassemble or view the contents of an executable. The National Security Agency could crack it fairly easily with their Super LOL Computers but that technology isn't available to most commercial ventures.
Good luck. Have fun. Take it easy. Your competitors will find it much more cost efficient to develop the technology independently, rather than stealing it from you.
Alt255@Vorpalcom.Intranets.com
Curious? What about runtime debuggers? You've gotta decompress to run. Of course I may be way off target here.
Altho I COMPLETELY agree with the time vs. money equation on this. Slow them down enuf so that it's cheaper to roll they're own. I should tell you that I've seen some 13-year-olds at work & they're not "experts" but they are motivated. They DO get at alot of stuff. Then again, what tends to intrest most teenagers are "X-Files" type secrets not business $$ & cents... but not all the time.
For me, I usually take the read the o/s calls approach too... when I'm not studing (open-source) for learning purposes. I'm making no claims to god-like expertese ;-)
Jeff elaborated quite well upon my suggestion. If you can't slow them enuf to make up for the $$ lost then it may be the way to go... provided it works for the business. Again, it's not perfect but it is MUCH better. Read: much more time (=$$) to get at your stuff.
Altho I COMPLETELY agree with the time vs. money equation on this. Slow them down enuf so that it's cheaper to roll they're own. I should tell you that I've seen some 13-year-olds at work & they're not "experts" but they are motivated. They DO get at alot of stuff. Then again, what tends to intrest most teenagers are "X-Files" type secrets not business $$ & cents... but not all the time.
For me, I usually take the read the o/s calls approach too... when I'm not studing (open-source) for learning purposes. I'm making no claims to god-like expertese ;-)
Jeff elaborated quite well upon my suggestion. If you can't slow them enuf to make up for the $$ lost then it may be the way to go... provided it works for the business. Again, it's not perfect but it is MUCH better. Read: much more time (=$$) to get at your stuff.
I don't think it would be easy to run a debugger on compressed Win32 executables. Take a look at this link and see what you think:
I could be wrong... I certainly don't possess the skills to attempt it.
Alt255@Vorpalcom.Intranets.com
I could be wrong... I certainly don't possess the skills to attempt it.
Alt255@Vorpalcom.Intranets.com
- Status
