Secure anti-leaking

[Azu]

1) Is it possible to secure an autoit script so that people can't decompile it at all (not even into ASM) to steal the source code?

2) And also, is it possible to make it sure only one person will be able to use it, and if they try to give it to someone else, it won't work anymore?

All I can think of for the first one is some kind of advanced encryption or something which I have no idea how to do..

For the second one, I'm thinking of having it so a username and password and IP address that can use it, is chosen beforehand, and a bit of crucial code is removed based on an algorithm of those, and a master server that it will connect to is given the username/password/IP details. Then when the person runs the script, it will try to connect to the master server, which will auto detect the IP, and the user will be prompted to input the username and password, which will be sent to the server, and the server will generate a bit of code using the same algorithm based on the username/password and IP, and will send the code to the client, which will edit itself in memory, adding that bit of crucial code, so that it can run, and something will have to somehow block the user from intercepting the code so that they won't be able to mimic it thus getting around the security. There will also be some kind of unique hash made in the client, which will be sent to the server for validation, so if a different IP sends it to the server, the server will know that the client has been leaked to someone else, and it will add the IP and hash to a block list so that it won't ever be able to connect again.

The problem is, I have no idea how to do any of this..

I'm wandering if it's even possible, and if so if anyone might wanna help me develop this?

I'm guessing I'm not the only one who could benefit from this kind of security.

Edit:

In case I didn't say it clear enough(or at all) I'm thinking the security would consist of two programs/scripts/files.

On one of them, you put in the username/password/IP-address, and select the file, and it works it's magic on it, the file is secure and ready to be distributed.

The second one would be the server itself that the clients would have to connect to.

Edited August 27, 2006 by Azu

[Jos]

whatever you do to your program is hackable..

I haven't heard of any program that isn't cracked whatever protection people put in programs.

You can only make it more difficult for people.

Probably the best protection against decompilation is to remove all references to AutoIt3 in the Program resources. If its not known that's an AutoIt3 program then why attempt to decompile.

[Azu]

whatever you do to your program is hackable..

I haven't heard of any program that isn't cracked whatever protection people put in programs.

You can only make it more difficult for people.

Probably the best protection against decompilation is to remove all references to AutoIt3 in the Program resources. If its not known that's an AutoIt3 program then why attempt to decompile.

What I meant was, having it so it can't be reverse engineered at all, not even decompiled/Free disassembled into ASM and not hex edited. So if anyone tried they would get useless junk that that would be completely useless and wouldn't give them a clue about anything.

[Bert]

What you are asking for is what every security minded programmer dreams of...They can make a program that no one can steal or someone else can use unless permission has been granted.

It will never happen.

Any program can be hacked. Period. You can slow the person down, but you can't stop them. You can do things like add keys that require the user to call you to get them, have the PC call home, and so forth. Everything that has been tried, a hacker has goten past. Good luck, but if you can pull this off, I would love to see how it is done.

[Bert]

What I meant was, having it so it can't be reverse engineered at all, not even decompiled/Free disassembled into ASM and not hex edited. So if anyone tried they would get useless junk that that would be completely useless and wouldn't give them a clue about anything.

Doesn't matter. Any program can be hacked.

[Jos]

What I meant was, having it so it can't be reverse engineered at all, not even decompiled/Free disassembled into ASM and not hex edited. So if anyone tried they would get useless junk that that would be completely useless and wouldn't give them a clue about anything.

If you do what you propose, the Processor wouldn't understand anymore what to do with it ...

Assembler is to lowest you can go and is the instructions the Processor understands.

[Azu]

If you do what you propose, the Processor wouldn't understand anymore what to do with it ...

Assembler is to lowest you can go and is the instructions the Processor understands.

I thought it was the lowest human readable format, and what the processor uses is a bunch of 1s and 0s.. which is the lowest possible format.. and maybe it's possible to make it so it can't even be hex edited or disassembled or decomposed into ASM? So that it would have to be taken all the way down to 1s and 0s if someone wanted to get it? Even then it might still be possible.. but it would probably be a LOT harder, no?

Maybe perfect security really is completely possible.. but maybe it's possible to come very close to it?

Or maybe I'm just rambling on about something I know nothing about..

[Uten]

Or maybe I'm just rambling on about something I know nothing about..

Not to offend you but "there you hit the nail".

A CPU is made by humans. It does exactly as instructed. Nothing is left to chance. And unfortunately some humans are really, really good at reading the same instructions as the CPU. Bill Gates is(was) one of them Peter Northon another and the list goes one and one ....

[Bert]

If you make it so no human can read it, then the computer can't either.

You may be able to make a computer language in klingon, which 99% of the computer world doesn't understand. That would go a long way in stopping them. However, for every person who knew the language, the odds of being hacked increase.

[Azu]

Okay.. what about the second part? If it was a lot of code that was missing from a lot of the script, then there wouldn't be anything there to decompiler except the part that connects to the server, and the rest seemingly broken bits and pieces.. wouldn't that alone make it harder?

[Uten]

So how would you run the code on your machien when most of it is on the server?

Obviously you could go the client server path but that is a diffrent consept.

If your conserned about this I sugest the following.

• Create your program add customer specific parts in the code, obfusicate it with EnCodeIt and compile it to a a3x.
• For each "customer" you have encrypt your program with some encryption tool/UDF and a unique customer phasprase.
• Create a launcher program asking for the phasphrase and using fileinstall to install and decrypt your program.
• Run the decrypted program with

  Run(@AutoItExe & " /AutoIt3ExecuteScript " & $pathname)

• As soon as possible delete the decrypted file

Now if your source code end up in the wild you know you can blame one of your entrusted clients

[Azu]

So how would you run the code on your machien when most of it is on the server?

The code that's removed would be determined by some kind of algorithm based on the username, password, and IP address.

The part of the code that connects to the server wouldn't be touched.

When you run it, it would ask for the username and pass, and send the username and pass your IP to the server, and the server would use the same algorithm to remake the removed code, and sent it to the client, and the client would receive the code and would embed the code into itself in memory, changing itself in memory, not putting the code into an actual file that someone could crack.

Obviously you could go the client server path but that is a diffrent consept.

If your conserned about this I sugest the following.

• Create your program add customer specific parts in the code, obfusicate it with EnCodeIt and compile it to a a3x.
• For each "customer" you have encrypt your program with some encryption tool/UDF and a unique customer phasprase.
• Create a launcher program asking for the phasphrase and using fileinstall to install and decrypt your program.
• Run the decrypted program with

  Run(@AutoItExe & " /AutoIt3ExecuteScript " & $pathname)

• As soon as possible delete the decrypted file

Now if your source code end up in the wild you know you can blame one of your entrusted clients

That definitely sounds like it could increase security a lot, but I'm looking for something a bit stronger then that..

The client could just be leaked and the password with it and then voila everyone can use it and I would have no way to stop it.

I'm not planning on using this for "customers", but rather so I can let a few people use it without having to worry about it being leaked and cracked and everyone and their grandmas being able to use it.

Edited August 28, 2006 by Azu

[dcop]

I'm not planning on using this for "customers", but rather so I can let a few people use it without having to worry about it being leaked and cracked and everyone and their grandmas being able to use it.

I think the most realistic of all this thread was take out all reference to AutoIt. Even that's only a 'slow them down' result. The most used OS on the globe has been hacked to pieces and that with ongoing code being written every month via updates to prevent this and it's a continuous battle. Adobe 7.0 Pro wasn't even released before it cracked, and that app is HUGE! Keep doing what your doing and at best it might be good enough to those that have your pgm in hand, but if it's in the hands of someone(s), somewhere that has an intrest and skill it wont be a problem to them.

[Uten]

@Azu, Why don't you just use C or ASM?

The simplicity of AutoIt has a price! It's a scripted language. It will run in a script engine.

This topic has a new thread like every week!

I'm out

[Azu]

@dcop

That would make it harder for people to decompile straight into easy to read autoit source, but it can still be recompiled/disassembled into ASM and hex edit.. and besides all that, it doesn't prevent them from simply putting the file on rapidshare and leaking it all over..

@Uten

I know that the program that would do this would probably have to be written in C or ASM to do something like this, but I am requesting it for use on AutoIt scripts. Kind of like the .exe that compiles/decompiles AutoIt scripts might not be an AutoIt script itself, but it's USED on AutoIt scripts.

Sorry if there was any misunderstanding..

[dandymcgee]

EDIT: Post Removed

Edited August 28, 2006 by dandymcgee

[Bert]

write it in a programable language based on Klingon! Look here===> http://en.wikipedia.org/wiki/Var%27aq

Thats enough to drive most people crazy when trying to crack it!

[Azu]

I don't think there is really any way to make it so the code itself can't be turned to source and messed with, the impression I'm getting is that there is no way to prevent it from being changed into readable ASM without totally breaking it.

My idea is to break it.

A program where you put in a username and password and the IP that will use it, and the IP of the server, and then select the autoit script (it would work with any kind of file really), and it will mess up part of the code, using an algorithm of the username/password/IP

Then it will add something to the start of the code that when ran, will try to connect to the server. It will also send the IP embedded in itself to the server. If the IP it's sending doesn't match the IP of the machine it's running on, the server will auto ban that IP of that machine.

If it gets past this check, a dialogue box will come up asking for the username and password, which will be sent to the server.

The server will then look at the username/password/IP and, using the same algorithm that was used before, except it will create some code based on it instead of destroy, and then send that code back to the client, and the client will take the code and merge it into it's own process in memory, without changing the executable file.

If the incorrect username and/or password is sent, then the data it gets from the server won't match the hole in it's own data, and it will just just crash itself and the user will have to try again, since it doesn't change the actual file, no damage will be done.

The server file won't really need configured, since there is no need for it to check usernames and password, since putting in a wrong one is self defeating anyways, and it won't need a list of allowed IPs, since it will just read the IP sent to it, so it will be maintenance free, and the list of banned IPs, it will generate by itself and store them in an INI, and deny connections from any of the banned IPs.

I don't know how to make either of these but I really do think that it's possible and maybe someone might wanna take up this project? It could be useful for a lot of people? It wouldn't be "perfect", nothing is, but it would be very good, wouldn't it?

Is there any reasons something like this wouldn't work good or wouldn't be possible to make? I have really high hopes for this! The only downsides I can see is it will only work if you're online, but anyone who can download has an internet connection so not really much of a problem right? The only vulnerabilities I can see in it are packet sniffing and memory dumping. This can't be totally prevented, but it wouldn't be to hard to just have it auto close common ones, such as WPE Pro, right? That way it would be even harder to crack. Still not perfect, but pretty good, right?

[dcop]

I don't think there is really any way to make it so the code itself can't be turned to source and messed with, the impression I'm getting is that there is no way to prevent it from being changed into readable ASM without totally breaking it.

My idea is to break it.

A program where you put in a username and password and the IP that will use it, and the IP of the server, and then select the autoit script (it would work with any kind of file really), and it will mess up part of the code, using an algorithm of the username/password/IP

Then it will add something to the start of the code that when ran, will try to connect to the server. It will also send the IP embedded in itself to the server. If the IP it's sending doesn't match the IP of the machine it's running on, the server will auto ban that IP of that machine.

If it gets past this check, a dialogue box will come up asking for the username and password, which will be sent to the server.

The server will then look at the username/password/IP and, using the same algorithm that was used before, except it will create some code based on it instead of destroy, and then send that code back to the client, and the client will take the code and merge it into it's own process in memory, without changing the executable file.

If the incorrect username and/or password is sent, then the data it gets from the server won't match the hole in it's own data, and it will just just crash itself and the user will have to try again, since it doesn't change the actual file, no damage will be done.

The server file won't really need configured, since there is no need for it to check usernames and password, since putting in a wrong one is self defeating anyways, and it won't need a list of allowed IPs, since it will just read the IP sent to it, so it will be maintenance free, and the list of banned IPs, it will generate by itself and store them in an INI, and deny connections from any of the banned IPs.

I don't know how to make either of these but I really do think that it's possible and maybe someone might wanna take up this project? It could be useful for a lot of people? It wouldn't be "perfect", nothing is, but it would be very good, wouldn't it?

Is there any reasons something like this wouldn't work good or wouldn't be possible to make? I have really high hopes for this! The only downsides I can see is it will only work if you're online, but anyone who can download has an internet connection so not really much of a problem right? The only vulnerabilities I can see in it are packet sniffing and memory dumping. This can't be totally prevented, but it wouldn't be to hard to just have it auto close common ones, such as WPE Pro, right? That way it would be even harder to crack. Still not perfect, but pretty good, right?

You're determined and I'm sure you'll accomplish at least parts of where you're going with this. Ho do you mask soomething like the following that seems to be in the compiles. With this they'll know it's AutoIt and can mod your code any way they like.

<assemblyIdentity

type="win32"

processorArchitecture="*"

version="6.0.0.0"

name="mash"

/>

<description>AutoIt 3</description>

<dependency>

<dependentAssembly>

<assemblyIdentity

type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

language="*"

processorArchitecture="*"

publicKeyToken="6595b64144ccf1df"

/>

</dependentAssembly>

</dependency>

</assembly>

[dandymcgee]

@Azu I'm really sorry about that last post, It's been edited. I didn't mean to be so rude I don't know what I was thinking. I was just wondering how old you are, because you have some really great ideas. Like I said, I am very sorry for my last post. Keep up the good work, I'll be visiting this topic often to read what you have come up with next Again, I am sorry for my actions.