Obfuscator (discontinued)

[Rhyono]

@BrewManNH I don't know what the size ratio typically is for obfuscated code, but I was using Mat's example. 105 bytes to 2826, which results in 26.91 times larger. It looks like you're saying that a non-obfuscated script would be compiled to be far larger than 27x the source (which I know it is), that also seems to imply that obfuscated code isn't much smaller than after compiling. Is obfuscated about the size of compiled or is it just a smaller multiplier?

[BrewManNH]

When I compile a script with obfuscator using default settings, original source is about 1760 lines and 84K in size, the end result file is 1602k in size and 20600 lines long due to all the includes I use.

If I obfuscate it with just /sv and /sf which removes unused functions and variables (similar to what /so does) but still obfuscates all the functions and variables and whatnot the end result is 564K in size and 7240 lines or so.

If I do the same script with just the /striponly parameter it comes out at 536K and around 6240 lines.

So, by looking at the results of this, if you do not use Obfuscator at all, your file is going to be a lot larger than just your source code if you use any of the larger include files. If you run it and just use Obfuscator to strip the unused functions etc., it's about the same size (+/- 30K or so in my case) with or without obfuscation.

Edited December 13, 2012 by BrewManNH

[Jos]

@Jos I'm just one of those people that considers source code that is 27 times larger to be massive. Actually, in general I consider 27x to be quite a bit larger.

This is only for short scripts without Includes due to some overhead Func's being added. You will find that it is different for larger scripts and there are a couple of things to minimise the size by an option to obfuscate minimum to shorten all variable/func names and the Strip function, which removes all unused Func's and Global Variables.

You will find that the script in the EXE is many times smaller than simply compiling it. (Hence my remark )

Jos

Edited December 13, 2012 by Jos

[JohnOne]

Jos, is the encryption for renaming variables, one way encryption?

[Jos]

Jos, is the encryption for renaming variables, one way encryption?

It is a one-way rename process.

[Rhyono]

@Jos I can see why some calls and executes would break it (since it seems a lot of what it does is converting everything to be called or executed), but what causes event/GUI related things to break it?

[Mat]

@Jos I can see why some calls and executes would break it (since it seems a lot of what it does is converting everything to be called or executed), but what causes event/GUI related things to break it?

Anything requiring a string function name is broken. (Edit: apart from in the case where obfuscator can read the string as Jos said above) Edited December 14, 2012 by Mat

[Rhyono]

I'm guessing the following two would break, right?

$startButton = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($startButton,"begin")

GUIRegisterMsg($wm_command,'_return')

Edited December 14, 2012 by Rhyono

[BrewManNH]

Wrong, they'd both work just fine.

You should probably test these things for yourself prior to asking if they'd work. 1 minute of typing up some workable code would have answered the question.

[Rhyono]

@BrewManNH I'd prefer to know why they would work over simply knowing they would. Learning the rules of what works in the obfuscator is a lot easier than guessing at it all of the time. I thought it wouldn't work because Mat said that anything using a string variable name wouldn't work, but flipping back to Jos' example it looks like trying to concatenate or store a string in variable would break it. Is that the only rule? All of those works as long as you don't try to concatenate a string or store a string in a variable?

[Mat]

@BrewManNH I'd prefer to know why they would work over simply knowing they would. Learning the rules of what works in the obfuscator is a lot easier than guessing at it all of the time. I thought it wouldn't work because Mat said that anything using a string variable name wouldn't work, but flipping back to Jos' example it looks like trying to concatenate or store a string in variable would break it. Is that the only rule? All of those works as long as you don't try to concatenate a string or store a string in a variable?

No, string representations of functions will break IF its not a string literal. So your close, but its if you try and do anything to a string, not just concatenating or storing in a variable.

[wraithdu]

Basically, obfuscator cannot know the value of a variable at runtime. So this would break:

#Obfuscator_Parameters=/sf /sv /om /cs=0 /cn=0

$startButton = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($startButton,"begin")

$func = '_return'
GUIRegisterMsg($wm_command,$func)

Func _return()
EndFunc

So when obfuscating, it looks at the registered function $func, has no idea what the value is (remember it is not the interpreter and has no idea about variable values, etc), and removes Func _return() because it seems it is not used.

$0 = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($0,"begin")
$1 = '_return'
GUIRegisterMsg($2,$1)

Versus your example, obfuscator knows that GUIRegisterMsg takes a function name as its second parameter, and since it is a literal string it can find it, alter its name, whatever.

You can manually make my example work by using the #Obfuscator_Ignore_Funcs directive.

#Obfuscator_Parameters=/sf /sv /om /cs=0 /cn=0
#Obfuscator_Ignore_Funcs=_return

$startButton = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($startButton,"begin")

$func = '_return'
GUIRegisterMsg($wm_command,$func)

Func _return()
EndFunc

#Obfuscator_Ignore_Funcs=_return
$0 = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($0,"begin")
$1 = '_return'
GUIRegisterMsg($2,$1)
Func _return()
EndFunc

[wraithdu]

Further, since I think this might be your next question, what happens if _return() is called somewhere else and not removed entirely?

#Obfuscator_Parameters=/sf /sv /om /cs=0 /cn=0

$startButton = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($startButton,"begin")

$func = '_return'
GUIRegisterMsg($wm_command,$func)

_return()

Func _return()
EndFunc

It gets renamed and breaks anyway.

$0 = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($0,"begin")
$1 = '_return'
GUIRegisterMsg($2,$1)
_3()
Func _3()
EndFunc

Of course the Ignore_Funcs situation is handled as well, and is the safest way out. _return() retains its original name everywhere.

#Obfuscator_Ignore_Funcs=_return
$0 = GUICtrlCreateButton("Start", 81, 160, 75, 25)
GUICtrlSetOnEvent($0,"begin")
$1 = '_return'
GUIRegisterMsg($2,$1)
_return()
Func _return()
EndFunc

Edited December 14, 2012 by wraithdu

[Rhyono]

Thanks Mat and wraithdu, that explains it quite thoroughly.

[EQuSu]

Hi

I'm trying to decompile an .exe autoit file using exe2aut.exe

I get na obfuscated script which is fine since i'm not really interested in editing it, but when i try to run the .au3 script that i got, it gives me an error asking for a .tbl file.

I don't get that .tbl file after the exe2aut.exe decompile, so how can i extract it from the autoit .exe? Or is there some other way?

Thanks

[JohnOne]

What is the original file?

[Melba23]

EQuSu,

Welcome to the AutoIt forum.

Unfortunately you appear to have missed the Forum rules on your way in. Please read them now (there is also a link at bottom right of each page) - particularly the bit about not discussing decompilation - and then you will understand why you will get no help. And if you ever mention decompiling a script again you will be permanently removed from the forum.

M23

[doppelGanger]

@Thread Starter

thank you for your wonderful program and you did the best thing to secure our source code...

however, i tried to compare and use exe2aut(decompiler application) with the 64bit and 32bit

64bit:

@Obfuscator

-fully obfuscated

@exe2aut

-fully unreadable for human

32bit:

@Obfuscator

-fully obfuscated

@exe2aut

-readable some text, and other personal strings shows up

my problem is that, i cant release a 32bit application to my users it is because maybe others know how to use autoit and they can decompile it...

can you suggest an alternative way to obfuscate the source code like the 64bit does.

thank you...

Edited February 6, 2013 by doppelGanger

[Jos]

@Thread Starter

thank you for your wonderful program and you did the best thing to secure our source code...

You are welcome.. BUT where have your read it make the sourcecode secure? Believe I made it pretty clear it doesn't make it secure at all!

however, i tried to compare and use exe2aut(decompiler application) with the 64bit and 32bit

There is NO supported exe2aut and any other illegal stuff has been pretty much beaten to dead and isn't up for discussion in our forums any more.

Please read our forum rules.

Edited February 6, 2013 by Jos

[doppelGanger]

You are welcome.. BUT where have your read it make the sourcecode secure? Believe I made it pretty clear it doesn't make it secure at all!

There is NO supported exe2aut and any other illegal stuff has been pretty much beaten to dead and isn't up for discussion in our forums any more.

Please read our forum rules.

sorry about those things i've said, but sir can't we discuss about the security about 32bit that I had post?