Find the answer to your Linux question:
Page 2 of 2 FirstFirst 1 2
Results 11 to 19 of 19
Hello again. Further to my last post. Have the checker establish a run/don't run marker in shared memory. The target software wont run without it. Regardless, the target should always ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Linux Newbie
    Join Date
    Nov 2009
    Posts
    214

    Hello again.

    Further to my last post. Have the checker establish a run/don't run marker in shared memory. The target software wont run without it. Regardless, the target should always check to see if it's ok to run.

    Cheers again - VP

  2. #12
    Just Joined!
    Join Date
    Sep 2011
    Posts
    3

    Thanks :)

    Thanks for all the tips guys - have given me some fresh ideas!

    What I'm doing is pretty simple really and would be easily reproduced.

    I'm just using some python, php and bash scripts along side a SQL database to do some file operations for some unique situations.


    The more I complicate things, the easier it'll be for things to go wrong.

    I think I'll just create a simple script that checks some of the above at startup and then close up the case and lock down the BIOS.

    At the end of the day, anyone wanting to reproduce this would do so anyway.


    Guess it's also incentive to work on support and customer service yeah

  3. #13
    Linux Newbie
    Join Date
    Nov 2009
    Posts
    214
    Brandoo,

    Happy to help. Just one last thought though... Rather than a script which can be read and altered fairly easily, use a compiled program. That way, you can hide how you do your checks and stuff.

    All the best - VP

  4. #14
    Just Joined!
    Join Date
    Jul 2006
    Location
    localhost
    Posts
    31
    Quote Originally Posted by voidpointer69 View Post
    Brandoo,

    Happy to help. Just one last thought though... Rather than a script which can be read and altered fairly easily, use a compiled program. That way, you can hide how you do your checks and stuff.

    All the best - VP
    Sorry but that would be security by obscurity. If somebody really wanted to know they'd decompile the code.

    I'd use a script because of the built-in error checks which you would otherwise have to worry about.

  5. #15
    Linux Newbie
    Join Date
    Nov 2009
    Posts
    214
    Dj...

    Even encryption is "security by obscurity"...

    Read the OP. "At the end of the day, anyone wanting to reproduce this would do so anyway."...

    ... and it might be down to a judgement of how much effort would be required to do so versus just ripping his stuff off.

    In my experience, a compiled program raises the bar in terms of such effort and is often enough to deter the theft. If you are going to put that much effort into the thing, do as the OP says and roll your own.

    Care to explain what you mean by "I'd use a script because of the built-in error checks which you would otherwise have to worry about."? Your scripts don't do error checkings or???

    Cheers - VP

  6. #16
    Just Joined!
    Join Date
    Jul 2006
    Location
    localhost
    Posts
    31
    Quote Originally Posted by voidpointer69 View Post
    Dj...

    Even encryption is "security by obscurity"...
    No, it most certainly is not.
    Code is easy to reverse because the readable code means the same as the compiled code, only translated to a language the computer can execute.

    Encryption requires a key for decryption and without a lot of guesswork it is mathematically impossible to reverse the encryption.

    Quote Originally Posted by voidpointer69 View Post
    Read the OP. "At the end of the day, anyone wanting to reproduce this would do so anyway."...

    ... and it might be down to a judgement of how much effort would be required to do so versus just ripping his stuff off.

    In my experience, a compiled program raises the bar in terms of such effort and is often enough to deter the theft. If you are going to put that much effort into the thing, do as the OP says and roll your own.
    Sure, compiled code might raise the bar, but is it really worth the effort of writing the code to slow down determined people by a few hours?

    Quote Originally Posted by voidpointer69 View Post
    Care to explain what you mean by "I'd use a script because of the built-in error checks which you would otherwise have to worry about."? Your scripts don't do error checkings or???

    Cheers - VP
    Scripting engines tend to have a lot of error checking built-in because of the very nature of scripts.

    In C you define your own string sizes, it's up to you to prevent buffer overflows, keep track of library changes, etc.

    In Python you define variable names and assign it any arbiratry value, be it trings, integers, floats, etc. Libraries are consistent over all environments and are well tested over many years by a lot of people.

  7. #17
    Linux Newbie
    Join Date
    Nov 2009
    Posts
    214
    OK, I'll bite one last time

    Obscurity, by its very nature, implies a lack of knowledge. The more obscure a thing is, the fewer people know about it.

    The obscurity elements of encryption lie in the strength of the algorithm used and the key if one is required. Whilst most algorithms are in plain sight, keys are not. That is, the keys are obscured from view.

    If I try to obscure my tests from you using an encryption system like, for example PGP, the barrier I erect is very strong. I would never bet my life against you being able to bypass it though since you may very well possess the necessary cracking environment to do so for a competitive cost in terms of both time and money. I am also mindful that 30 years ago DES in hardware was state of the art and that just because I may not be able to do it, that restriction may not apply to others.

    If I put my tests in a plain text file, a script of any flavour. The barrier to you is trivial. Use your favourite text editor and it's game over in the blink of eye. Any value in this barrier is based solely on your knowledge of the language I use. My assumption would be that if you are reading it, you either have sufficient knowledge or you are well on the way to obtaining it.

    If I encrypt my tests in a compiled binary file. My barrier is far, far stronger than plain text albeit arguably weaker than what I would get from using a full-blown encryption system since your cracking environment requires a lot less resource to decode this kind of data than other encryptions but much more than a single text editor. It will also take longer than the blink of your eye.

    My barrier is weakened by the fact that you know that the data is machine-code for the target platform which can be represented fairly easily by assembler mnemonics. From there, you might be able to reverse-compile it into some form of source code. Just takes more effort, knowledge and time.

    As for your final comments... Well, I tend to abide by the maxim of "horses for courses". Scripting engines are built on top of other code that has many millions more man-years worth of testing than any script interpreter.

    We all stand on the shoulders of giants. Thank you Stallman, Torvalds, Cox et al.

    Having said that, I think that if you want to fly a plane to Paris, my advice is to learn how to do it before firing the damn thing up.

    Cheers - VP

  8. #18
    Administrator jayd512's Avatar
    Join Date
    Feb 2008
    Location
    Kentucky
    Posts
    5,023
    I'm gonna remove the HDD and let all of you run from an SD card. Or a USB drive.
    And my hardware is gonna be in a closet, behind a heavy door. A big heavy oak door.
    With a big honkin' padlock.
    You wanna rent time with my hardware, I can make you an appointment to do so.
    I know that if I encrypt anything, you could find cracking software on the Internet...

    And with an SD card or a USB drive...........
    That hardware is mine.

    Encryption requires a key for decryption and without a lot of guesswork it is mathematically impossible to reverse the encryption.
    Quite simply... wanna bet?
    Jay

    New users, read this first.
    New Member FAQ
    Registered Linux User #463940
    I do not respond to private messages asking for Linux help. Please keep it on the public boards.

  9. #19
    Just Joined!
    Join Date
    Jul 2006
    Location
    localhost
    Posts
    31
    Quote Originally Posted by voidpointer69 View Post
    OK, I'll bite one last time

    Obscurity, by its very nature, implies a lack of knowledge. The more obscure a thing is, the fewer people know about it.

    The obscurity elements of encryption lie in the strength of the algorithm used and the key if one is required. Whilst most algorithms are in plain sight, keys are not. That is, the keys are obscured from view.
    As you explain it, the "obscurity" part of encryption is the private key, and that's a very skewed way of looking at encryption.

    You need to understand that in a proper encryption implementation the encrypted file does not contain all of the required information to read the file in an unencrypted format, meaning it's impossible to get back to the original data without the correct private key.

    Quote Originally Posted by voidpointer69 View Post
    If I try to obscure my tests from you using an encryption system like, for example PGP, the barrier I erect is very strong. I would never bet my life against you being able to bypass it though since you may very well possess the necessary cracking environment to do so for a competitive cost in terms of both time and money. I am also mindful that 30 years ago DES in hardware was state of the art and that just because I may not be able to do it, that restriction may not apply to others.
    With a powerful key guessing (also known as cracking) facility you could guess the correct key, but then you're using data from outside the file which means it isn't security by obscurity.

    That being said, DES isn't the strongest encryption available. Use RSA and many bits to slow down the key guessing.

    Quote Originally Posted by voidpointer69 View Post
    If I put my tests in a plain text file, a script of any flavour. The barrier to you is trivial. Use your favourite text editor and it's game over in the blink of eye. Any value in this barrier is based solely on your knowledge of the language I use. My assumption would be that if you are reading it, you either have sufficient knowledge or you are well on the way to obtaining it.

    If I encrypt my tests in a compiled binary file. My barrier is far, far stronger than plain text albeit arguably weaker than what I would get from using a full-blown encryption system since your cracking environment requires a lot less resource to decode this kind of data than other encryptions but much more than a single text editor. It will also take longer than the blink of your eye.
    No, compilation does not involve encryption! These are two incredibly different things!
    Here's an analogy:

    If I were to translate an English text into Swedish (assuming of course that every word has a 1:1 translation), you could easily have it translated back into English and have the exact original test back.

    Compiling works the same way; C code is translated into assembler (this step is usually hidden, but it's there if you want to see it) and then translated into native x86 executable code.

    You could easily go back from the native x86 executable code to the exact original assembler code and, for all the computer cares, about the same C code (which isn't a 1:1 translation since, if I recall correctly, variable names and such gets lost when compiling, however the symbol names will remain). The last step involves a bit of guesswork to make it match the assembler code while simplifying the C code.


    If I were to instead take every character in the English text and increase every character by one (making a -> b, z -> a, etc), you would have a very simple symmetrically encrypted text where the key is to increase every character by one for encryption and doing the reverse for decryption.

    You could easily guess the key based on common words and letters, for example "I" would have become "J" and a single uppercase "J" won't appear in plain English, though "I" does appear fairly frequently in English so then you could figure out I've just taken every character and moved it one step further along the alphabet when I encrypted the text.

    You have now guessed the key from just looking at it and mathematically concluding that "J" must equal "I" in the original text since it commonly appears alone.

    You could also have a computer try taking a random amount of steps for the whole text to increase the speed of finding my key in case I had chosen to take 5 or 22 steps for each character. This approach is called to brute-force the key and is very computationally expensive since you try every possible combination.

    Since it either way requires guesswork or data outside the encrypted file which you don't have, it's still not security by obscurity. It won't work without either the key or guesswork.


    In an asymmetric cryptography system you have both a private and a public key, where the public is used to encrypt (anyone with the public key could use it for decryption) and the private to decrypt. These two keys are different, where as in symmetric cryptography they're either equal or inverse, depending on how the system is designed.

    Another difference is that asymmetric encryption is lossy even with the public key, meaning you loose some piece of information while it's encrypting.

    The task of the private key is to enter enough data back into the system to enable decryption. Thus the private key is necessary for decryption and cannot be easily calculated. In modern asymmetric cryptography systems the private key is designed to be mathematically impossible to calculate, using a combination of primes and roots of arbitrary numbers.


    A Google result for "how asymmetric encryption works" will tell you more.

    Quote Originally Posted by voidpointer69 View Post
    My barrier is weakened by the fact that you know that the data is machine-code for the target platform which can be represented fairly easily by assembler mnemonics. From there, you might be able to reverse-compile it into some form of source code. Just takes more effort, knowledge and time.
    After understanding the difference between encryption and compilation you'd realize the time and effort required after compilation is minimal while it's the opposite for encryption.

    I think you should search Google for "asymmetric cryptography", it's a lot of interesting reading and it will explain why it's so secure.

    Quote Originally Posted by jayd512 View Post
    Quite simply... wanna bet?
    On the underlying principles of all asymmetric cryptography systems?
    It'd quite literally be like betting on (sqrt(x))=x anyway...

Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •