Sign in to follow this  
Followers 0
everseeker

Winbatch Vs. AutoIT Security

28 posts in this topic

#1 ·  Posted (edited)

Autoit vs. Winbatch

Autoit scripts can be decomplied by anyone even if they dont know the password or even if you use the nodecompile flag. The compiler is opensource,so everytime a new version of autoit pops up theres people writing decompilers using the source. If you value your work autoit is not a good choice as anyone can get your script source code in a couple of clicks.

WinBatch, the ability to decompile the code is nonexistent and therefore secure.

Is this true? If not, can you provide me with a counterargument?

Edited by everseeker

Everseeker

Share this post


Link to post
Share on other sites



Is this true? If not, can you provide me with a counterargument?

As far as I know, the compiler most certainly is not open-sourced.

Share this post


Link to post
Share on other sites

Is this true? If not, can you provide me with a counterargument?

If WinBatch compiles to machine code this is partly true. Then the complete source cannot be decompiled, only the assembly version.

If it's not however, then it's possible, if no decompilers currently exists then it's because enough skilled crackers are not interested in it, thus hinting that maybe WinBatch isn't the greatest of creations?


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

If WinBatch compiles to machine code this is partly true.

umm... Is it not true that AutoIT compiles to Machine Code??? (Via the AU3->Exe compile)


Everseeker

Share this post


Link to post
Share on other sites

umm... Is it not true that AutoIT compiles to Machine Code??? (Via the AU3->Exe compile)

No. The source is just embedded together with the autoit interpreter in the exe.


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

No. The source is just embedded together with the autoit interpreter in the exe.

So then it IS fairly trivial to extract the source.

Helllooooo obsfuscator.......


Everseeker

Share this post


Link to post
Share on other sites

So then it IS fairly trivial to extract the source.

Helllooooo obsfuscator.......

The question is - what are you trying to protect? If you're worrying about people aren't going to pay for the program then it doesn't matter (I'm sure you know how much warez is out there). You should protect your program with a license (so you can sue the living shit of anyone fucking with you) instead of trying to protect the interior.


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Because of the nature of an AutoIt V3 executable, an encrypted script needs to be decrypted (that is made readable) before it is run. This requires that a decrypting password is stored in the executable somewhere the interpreter can find it. Although the encryption system is proprietary, there have been several attempts to create AutoIt decrypting programs over the years, some have even worked, well, until we released a new version.

In earlier versions of AutoIt V3, we even had our own decrypter available, but that was discontinued over security concerns. If you do find an old version of exe2aut, it will not be able to decrypt a more recent version of compiled script. This may be what the guy from WinBatch was refering to.

Encryption is like a lock and key; it will keep most people out, but someone with enough skill, time and determination can pick the lock (or just kick down the door) and read your original code. The encryption only slows them down, not stops them entirely. Nothing that is made available to others is truly secure, just reasonably secure.

Edited by Nutster
grammar/spelling fixes. Add extra sentence to clarify

David Nuttall
Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius

AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...

Share this post


Link to post
Share on other sites

C# and VB.NET both compile into CIL, which can be read almost just as easily as C#. This has never been a problem to the thousands of developers using these languages.

Share this post


Link to post
Share on other sites

Hey Manadar, have you ever read well-obfuscated C# code? It's really funny looking. The names and extra classes and things.

Share this post


Link to post
Share on other sites

I've never bothered obfuscating my own code. I just happened to be digging through a few programs. One prime example was this 3d desktop thing called Sphere. I'm pretty sure it was this http://www.spheresite.com/

Share this post


Link to post
Share on other sites

Try {smartassembly} . I used that(not free) it won't even let most decompiler decrypt it all all(gives an error)

For the record, if the decompiler errors, that means that the assembly contains invalid instructions or the decompiler is not well written.

Any assembly can be decompiled to at least the MSIL level. Not all MSIL can be interpreted into a higher language easily.

Share this post


Link to post
Share on other sites

For the record, if the decompiler errors, that means that the assembly contains invalid instructions or the decompiler is not well written.

Any assembly can be decompiled to at least the MSIL level. Not all MSIL can be interpreted into a higher language easily.

It does not make an invalid instructions. It just remove the meta and put a fake one and do a proxy link to the real meta which can be retrieve when run in managed environment.

Share this post


Link to post
Share on other sites

Then that means that the decompiler is not very good if it doesn't follow those links. If the MSIL is valid, the decompiler should work. End of story.

Share this post


Link to post
Share on other sites

#18 ·  Posted (edited)

Then that means that the decompiler is not very good if it doesn't follow those links. If the MSIL is valid, the decompiler should work. End of story.

"decompiler is not very good if it doesn't follow those links" Because the decompiler does not have a runtime.(proxy link <<< look it can only be solve at runtime) End of story >_<

Oh, just to remind you Decompiler and Unpacker are not the same!

Edited by athiwatc

Share this post


Link to post
Share on other sites

If a link exists, it can be followed, regardless of whether a runtime is executing or not. Also, if the decompiler were also written in .Net, wouldn't that runtime be executing?

Share this post


Link to post
Share on other sites

While all of this is interesting, I still do not have a clear rebuttal to the WINBATCH assertion that Autoit is less secure then Winbatch because they do a true compile, while AutoIT just attaches the code to an instance of the AutoIT runtime.... and the source can be easily read by any scriptkiddie on the block

There is a "Workaround"... Run an obsfuscator before generating the EXE... but it's not exactly optimal.


Everseeker

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0