Winbatch Vs. AutoIT Security

[everseeker]

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 August 19, 2009 by everseeker

[NELyon]

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.

[AdmiralAlkex]

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

He probably means the unofficial decompiler.

[monoceres]

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?

[everseeker]

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)

[monoceres]

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.

[everseeker]

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.......

[monoceres]

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.

[Nutster]

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 August 20, 2009 by Nutster
grammar/spelling fixes. Add extra sentence to clarify

[jvanegmond]

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.

[Richard Robertson]

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

[jvanegmond]

Nope, never tried it. Should I try it out with DotFuscator?

[Richard Robertson]

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/

[WolfWorld]

Nope, never tried it. Should I try it out with DotFuscator?

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

Edited August 21, 2009 by athiwatc

[Richard Robertson]

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.

[WolfWorld]

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.

[Richard Robertson]

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.

[WolfWorld]

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 August 24, 2009 by athiwatc

[Richard Robertson]

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?

[everseeker]

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.