AU3 DLL Extension

[IchBistTod]

I have gone through the trouble of making this nice little add on for autoit which I believe most of you will love.

I call it AU3DLL.

Basically it is the ability to call code from a compiled script, out of an encrypted .adll file.

How is this useful?

1)It protects your code

2)If you separate your code into paginated .adll files updating your apps via auto updated is now MUCH faster, and much more efficient.

3)The ability to edit your scripts without recompiling, just build a new .adll in a few seconds.

4)Its just plain cool?

But enough about what I think. What do you think?!

I put a lot of work into this.

I plan to put a lot more to help it evolve.

Right now I will not be releasing any source code, just an example that will run all .adll files in the same dir as it, and the .adll builder. See bottom of post.

It comes with two pre-made .adll files.

Known limitations:

No use of input box.

No Conditional Statements.(Working On this)

No Loops.(Working on this next)

Opinions, bugs, anything,post it.

Download:

AU3DLL.zip

Thanks: Geosoft for a regex tip.

SOURCE CODE:

Due to the fact that if the AU3 DLL Plugin Becomes a Success it could have a HUGE impact on the whole AutoIt community. I have devoted a special forum to it. The forum is accessible per my approval ONLY,to protect the integrity of the project. The forum should be up within 2 hours,andsource code will be relocated there. For access please PM me.

Reasoning for this action.

1)Protection of source code

2)More focus on project(Here on Autoit forums it can get shoved down, and become hard to find, where as in the custom forum, it will be stickied to the top of the forum. This will promote focus on the project and further development, as well as make sure development does not go off topic.)

Furthermore.

All developers for this project WILL be encouraged to continue usage of AutoIt forums, to ask for help when needed, to answer questions abotu the project.

All updated will be posted as this project evolves.

When it has a reached a point, where the code in .adll files can not be cracked by method of viewing the source. We will publicly release the source code on the official AutoIt forums.

Forum for AU3 DLL development has been generously donated by a close friend.

For access please pm me and I will tell you how to access them.

They contain the source code for AU3 DLL Plugin system and ALL development will be continued there.

Edited March 25, 2010 by IchBistTod

[Shafayat]

Call me a fool but I simply don't get it. Why is that useful? How am I supposed to call the adll from my script?

[monoceres]

Hi!

Can you explain the technology behind this? Does all code run in the same address space?

[Fantastic]

I don't understand.

What are msgbox.adll and dll1.adll supposed to do ? Are they linked with example ?

[Alek]

I'm guessing the adll files are stringtobinary (encrypted??) autoitscript which are  called using execute.

The only part of this that I find usfull is that you can update the adll file rather then the entire exe.

other then that, why not just use #include??

[ProgAndy]

This is propably using Execute. So you cannot do more complex things. e.g. it will impossible to create loops, functions or conditional statements, only plain linear code.

[IchBistTod]

I don't understand.

What are msgbox.adll and dll1.adll supposed to do ? Are they linked with example ?

The example runs all.adll files in the same directory as itself.

Hi!

Can you explain the technology behind this? Does all code run in the same address space?

It uses regexp + arrays + execute to support variables within the programming. Further explained below.

Right now yes all code runs in same address space. Assuming all code within autoit does, and i assume so as it is by nature single threaded.

This is propably using Execute. So you cannot do more complex things. e.g. it will impossible to create loops, functions or conditional statements, only plain linear code.

With this yes you are correct. However when I add more features the main idea behind this is to use .adll inside of loops in place of static code.

The same with inside of functions and conditional statements. Conditional statements can be used in linear mode eg. "

if $variable = 2 then _au3dll("next set of actions")

" its just a little more work to do it this way.

But in the end it makes your script more easily updateable, people can not de-compile your .adll files as they can your autoit script(protecting your source code and important pieces of code.

I'm guessing the adll files are stringtobinary (encrypted??) autoitscript which are called using execute.

The only part of this that I find usfull is that you can update the adll file rather then the entire exe.

other then that, why not just use #include??

The .adll files are encrypted then stingtobinary.

Right now I am working on implementing a modified encryption algorithm I developed.

Partially correct,but as stated above its all a little more complex than that.

And one major advantage is protection of your work. Eg. for authentication systems, passwords, etc. Please read my previous reply for more info on "how".

BTW I LOVE DOMO =D

Edited March 23, 2010 by IchBistTod

[IchBistTod]

If you wish to test its functionality, use the au3dll creator i included, then place the created .adll file int he same directory as the example.exe, then execute example.exe

I also plan to add the ability to use loops with some more complex coding.

Edited March 23, 2010 by IchBistTod

[IchBistTod]

Now are there any actual opinions, bugs,or discussion about the actual USE of this technology?

I see there are what? 47 downloads and this is all we have discussed?

[wraithdu]

A novel idea. But where is your decryption code located? THAT is what needs to be protected. Otherwise your efforts are for naught.

Also your encrypter must be protected as well. A simple autoit app could be decompiled. Once your encryption scheme is known, decrypting it would be trivial.

Edited March 23, 2010 by wraithdu

[IchBistTod]

A novel idea. But where is your decryption code located? THAT is what needs to be protected. Otherwise your efforts are for naught.

Also your encrypter must be protected as well. A simple autoit app could be decompiled. Once your encryption scheme is known, decrypting it would be trivial.

Decrypted code is stored only in memory.

And Indeed it (algorithm) must, although even if the autoit app was decompiled my algorithms would be difficult to break because of how it works.

None the less, I am soon considering making a .dll to encrypt and decrypt the data and return the decrypted text. But about this I am still not sure because someone could call the dll from another language.

I seen something on here about embedding DLL code in binary form in a way in which is different from how it would be written in the HDD, this would at least stop most people from being able to assemble the dll out of the au3 that does encryption.

Am up for suggestion on a better way to encrypt the code.

Still the main purpose is allowing dynamic coding, this protection is a "secondary" feature.

Edited March 23, 2010 by IchBistTod

[wraithdu]

I meant the code that actually does the decrypting, not the decrypted .adll files. Anyway, you got the idea. Those bits of code are what must be protected for your security to stand up. A procompiled DLL would be safer.

The embedded DLLs are basically the binary data of the real DLL. If it is extracted it is trivial to produce the real working DLL. The method that Ward uses in some UDFs with CallWindowProc is a bit different. I'm not exactly sure how that code is produced. It is still the same compiled DLL code, but it does not have all the PE header stuff, just pure function code. While harder, a working DLL could still be produced from that code in some way.

[IchBistTod]

I meant the code that actually does the decrypting, not the decrypted .adll files. Anyway, you got the idea. Those bits of code are what must be protected for your security to stand up. A procompiled DLL would be safer.

The embedded DLLs are basically the binary data of the real DLL. If it is extracted it is trivial to produce the real working DLL. The method that Ward uses in some UDFs with CallWindowProc is a bit different. I'm not exactly sure how that code is produced. It is still the same compiled DLL code, but it does not have all the PE header stuff, just pure function code. While harder, a working DLL could still be produced from that code in some way.

Yes you are right that producing a dll out of the code would be POSSIBLE, but very difficult, as it would require additional headers, direct modification o the binary code.

You must understand the people who decompile these codes are not experts, and most not even close. They use 3rd party decompilers.

So now for protection I am going to need to find some C++ help, mainly making sure from within the dll, that it is being ran from memory, in a exe, and refusing to work as a .dll file.

This would prevent even experts who could extract the code and make a dll out of it, from being able to use it.

Something that would be the best idea would be to get a modified AU3 exe from the developers that integrates a certain method of protection... but the chances of that happening are about 0.000001%

So we will have to make due.

[wraithdu]

You have to be sure what embedding method you are using. If you use the more popular MemoryDll... functions, the all it requires to reproduce the DLL is FileWrite(Binary(...)). If you use the CallWindowProc method, then it is more difficult. However I don't know how to properly produce that code. You'd have to ask Ward how he's done it in the past.

[IchBistTod]

I plan to use the CallWindowProc method =]

Of course. Its a no brainer to choose that... imho.

[IchBistTod]

56 downloads now and nothing about its functionality,no reports of it working not working, bugs, compliments, flaming... nothing?!

[Shafayat]

I thought flaming was not allowed.

I think the reason of lack comments is simply that the source is not available. You see, I'm probably not going to use an encryption method of which I do not have the least bit of idea how it is done or how strong it is.

Besides, no loops = less ability = less interest = less comments.

Your project has some originality. If you ever finish that and also make it opensource then I'll be more than happy to use it.

Best Regards

Shafayat

[IchBistTod]

I thought flaming was not allowed.

I think the reason of lack comments is simply that the source is not available. You see, I'm probably not going to use an encryption method of which I do not have the least bit of idea how it is done or how strong it is.

Besides, no loops = less ability = less interest = less comments.

Your project has some originality. If you ever finish that and also make it opensource then I'll be more than happy to use it.

Best Regards

Shafayat

You seem to be missing the main point of this "plugin".

Its to 1) allow dynamic changing of linear code(and soon loops and all code) in COMPILED executables so as to easily allow for adding plugins to exes, or easily updating code used in exes rather than updating whole executables to update a routine or add a plugin.

2)Protect your code from 3rd party decompilers.

My project is completely original nothing like it exists on these forums.

Simply the fact in itself that is can allow a compiled executable to have code that dynamically changes COMPLETELY by replacing a few kb file, and the ability to dynamically call these files with the execute() function should be a huge plus.

But I assure you I am working on making conditional statements work, then loops.

I am considering making the project open source so I do not have to take on the burden alone.

[JRowe]

I'd say it is very interesting. I've never had a problem with compiling, but the idea of a plugin framework appeals to me very much. You could even embed the .adll as a binary resource, keeping things clean and tidy for the user.

Open source would be cool. I'd enjoy poking around the innards of this thing, seeing how it worked. Thanks for the contribution.

[WeMartiansAreFriendly]

Plugins would be very nice. But wouldn't be easier just to use the command line "/AutoIt3ExecuteScript" ?