The difference is that encryption makes a script unreadable. Embedding a shell-script in a C-program would probably result in a executable file containing the script still readable.

You could code some form of encryption into the C-program as wel, but I guess that's exactly what the 'SHC' people have done.

My rot13 is not be taken very serious. Though it does make the code unreadable at the first glance, a good novice user can figure it out. As easy/difficult with the compiled C-program.

So, stick with 'SHC'. Easier than writing your own.

No, not really.
All identifiers (variable and function names) are gone. With a disassembler you can can the source in assembly. With a lot of patience one could figure out how what it does, and reconstruct the program is C. Maybe there exist utilities to help with this, but I don't know of any.

kushalkoolwal - asking about the difference between "encryption" and "binary format" is a good one, and the answer has some important points.

Basically, "binary encoding" makes the program unreadable to a human, but decipherable to the machine.

"Encryption", on the other hand, renders the program undecipherable to *both* the human *and* the machine, without the proper key and decryption function.

The important points are these:

a) "binary encoding" doesn't necessarily make it *unreadable* to the human - merely somewhat inconvenient to decipher

b) In that respect, it is absolutely equivalent to rot13 (a simple data encoding scheme) and "obfuscation" (a souce code encoding scheme).

c) Encoding data so that it can be handled more conveniently (for example, uuencode to transmit binary data over 7-bit ASCII transports) is perfectly legitimate.

d) Confusing simple encoding schemes with true encryption is tantamount to "Security through Obscurity" (i.e. obfuscating the data and hoping nobody will go to the trouble of deciphering it).

Which is basically no security whatsoever.

Again, it sounds like what you need more than some encryption or obfuscation scheme is a good, written "Right to Use" policy, and some good user education.

Honest .. PSM

wow!!! That was interesting to know. Thanks so much

If you want, you can send me you encryped script and I'll tell you if I can crack it or not. I'm not a novice user, so I wont accidentally screw up my system. You should send me the script unencyped too so I can compare what I get from trying to crack the encryped script with the real script.

Don't forget to include your internet IP address and root password - that way we can all "help".

yea, and we'll probably need a credit card number.

1. Well algorithms use mathematical computations to your file
"plain.txt" to generate an encrypted file "cipher.txt". And these algorithms are generally programmed in some language. And on the encrypted file you run the algorithm again to get back the plain text. Ofcourse you use a password key ... depending on the algorithm.

2. The binaries you get from a C file are actually machine code which the computer understands to execute and accomplish the tasks of your program which you possibly wrote in a High Level Language. Also getting the C file back from a binary is hard. Unlike Java where you can use a decompiler on a java class file to get back the java code.


Hope this helps you understand the difference.

Thanks

You could have your script encrypted in a C program that feeds it to /bin/bash via a pipe. Bash is supposed to read it from stdin.

thank you guys. I really appreciate for all your help.

I have one more question to ask:

Does it make difference wrt to system performance if I run a normal shell script or run it through a C binary commands (by embedding those commands in shell script in the C file)?


thanks

If you parse the commands yourself with no help from the shell, it'd help in case /bin/bash is replaced with /bin/cat to obtain the source of your program.

But in any way it could be obtained by hijacking (be it replacing all programs executed or library redirection). The best way would be to emulate most of the functionality with the C library

Binaries are typically faster than shell scripts but if your binary is having to call a shell script then it won't be faster. Long ago I'd tested a product from Cactus software that appeared to do what shc says it does. On testing I found that the resulting binary was no faster (or slower) than the original shell script.

To make a binary faster you have to use the C libraries that do equivalent functions to shell commands rather than doing "system shellcommand" calls. The former makes it all machine language whereas the latter makes an external call to another item so has to fork off to that.

kushalkoolwal, with proper encryption, getting at the clear text is designed to be prohibitively CPU intensive. The effort will depend on the length of the key. As always, that's "to the best knowledge of free science" -- it's always possible that some country's secret service knows a much faster algorithm to crack a popular encryption, but we'll never know.

But that's not your situation -- you are giving the cypher and THE KEY to the people from whom you're trying to keep your script. So it doesn't matter that much if it is a sophisticated encryption or rot13.

Compiling a C program may obscure things a little (even though it's not intentionally designed for that). If "install.c" calls system for each line of your original script, and you compile it into "install", then simply running "strings install" has a good chance of printing the whole script, maybe preceded by 10 to 20 unrelated symbols.

Thanks for the information. That clears whole bunch things of me.

Also you mentioned something about "use the C libraries that do equivalent functions to shell commands" . Where I can see the library C commands for my regular shell script commands like cp, fdisk, mv,tar, etc.

Thanks

if they are ignorant users they probably wouldn't dare play with it.
why not simply make it non-writeable?
You can make it a root-owned file in their directory.


hiding things is the microsoft way, not ours.