Define "auJasperatically" from AutoIt help file

[Crash]

Hi AutoIt community!

I have a quick question. According to AutoIt help file on Variables,

If you declare a variable inside a function it is in local scope and can only be used within that same function. Variables created inside functions are auJasperatically destroyed when the function ends.

So what the meaning of "auJasperatically destroyed"? Is it completely destroyed or might be destroyed?

 

I am writing a security software and it is important to not let any password lingers in the memory. In a function, I have saved the password typed by user in a local var. I am not sure if I need to reset this variable before the function ends. (Or is there any better security practices?)

 

Thanks very much!

[BrewManNH]

That's obviously a typo.

Local variables cease to exist as far as the script is concerned, not sure if the memory gets cleared out though. If you want to make sure it's cleared just set the variable to something nonsensical, or an empty string.

Word of advice though, if you're writing security software, don't do it in AutoIt, AutoIt is not guaranteed to be secure.

[iamtheky]

yup, just the choice of aperiodic vs sporadic.  and through the magic of google I am going to guess you are seeing a forum scrambled version of an out of context use of this typo prefixed by an 'a' in a box.

Substitute 's' from String2 for 'o' in String1.
_operatically → asperatically

http://fuzzy-string.com/Compare/Transform.aspx?r=operatically&q=asthmatically&t=5

 

and contrary to the author's impressions, you will get neither opera nor asperations (nor will the link teach you anything about asthma).

 

Edited December 23, 2015 by iamtheky

[jdelaney]

Make sure you define all variables with Local...If there happens to be a global variable with the same name, and you don't specifically define the function's variable as local, it will overwrite the global:

Local $ThisWillBeOverWritten = "NOT from the function"
ConsoleWrite($ThisWillBeOverWritten & @CRLF)
WillNOTOverWriteGlobal()
ConsoleWrite($ThisWillBeOverWritten & @CRLF)
WillOverWriteGlobal()
ConsoleWrite($ThisWillBeOverWritten & @CRLF)

Func WillNOTOverWriteGlobal()
    Local $ThisWillBeOverWritten = "FROM the function...won't exist outside of function"
EndFunc

Func WillOverWriteGlobal()
    $ThisWillBeOverWritten = "FROM the function"
EndFunc

 

output:

NOT from the function
NOT from the function
FROM the function

[trancexx]

Hi AutoIt community!

I have a quick question. According to AutoIt help file on Variables,

So what the meaning of "auJasperatically destroyed"? Is it completely destroyed or might be destroyed?

 

It has no meaning. Someone was playing with that page and changed "Tom" to "Jasper" - not only within the example code shown there.

The word is "automatically".

[Crash]

That's obviously a typo.

Local variables cease to exist as far as the script is concerned, not sure if the memory gets cleared out though. If you want to make sure it's cleared just set the variable to something nonsensical, or an empty string.

Word of advice though, if you're writing security software, don't do it in AutoIt, AutoIt is not guaranteed to be secure.

Thanks. I understand a variable local to a function is scoped within it, and that means the variable is not accessible outside of the function. I am as unsure as you are whether if the memory gets cleared out. Although I might not be able to access it, the password may remain around as scrap data in some part of memory! D:

Thanks for the advice! I'm not training in programming and that is quite startling. Is it because AutoIt is too high-level? Too many stuff in between that may compromise security?

 

yup, just the choice of aperiodic vs sporadic.  and through the magic of google I am going to guess you are seeing a forum scrambled version of an out of context use of this typo prefixed by an 'a' in a box.

http://fuzzy-string.com/Compare/Transform.aspx?r=operatically&q=asthmatically&t=5

 

and contrary to the author's impressions, you will get neither opera nor asperations (nor will the link teach you anything about asthma).

 

Thanks for your reply. You lost me completely XD I'm as fuzzy as the theory suggests. haha.

 

Make sure you define all variables with Local...If there happens to be a global variable with the same name, and you don't specifically define the function's variable as local, it will overwrite the global:

Local $ThisWillBeOverWritten = "NOT from the function"
ConsoleWrite($ThisWillBeOverWritten & @CRLF)
WillNOTOverWriteGlobal()
ConsoleWrite($ThisWillBeOverWritten & @CRLF)
WillOverWriteGlobal()
ConsoleWrite($ThisWillBeOverWritten & @CRLF)

Func WillNOTOverWriteGlobal()
    Local $ThisWillBeOverWritten = "FROM the function...won't exist outside of function"
EndFunc

Func WillOverWriteGlobal()
    $ThisWillBeOverWritten = "FROM the function"
EndFunc

 

output:

NOT from the function
NOT from the function
FROM the function

Thank you for the reminder; I have forgotten about this. To others, you can declare a local variable with the same name as a global variable and they'll be treated differently. If you don't write 'Local' within your function, the compiler will think that you're referring to the global variable and overwrites its value instead.

 

It has no meaning. Someone was playing with that page and changed "Tom" to "Jasper" - not only within the example code shown there.

The word is "automatically".

Ah THANKS! I think this is the answer I'm satisfied with XD So atrocious, much evil!

Edited December 23, 2015 by Crash

[water]

Seems to be a bug that was introduced after 3.3.12.0.

[mikell]

"auJasperatically" is a pretty cute bug though 

[Jos]

It was already corrected back in October.

[iamtheky]

I was super pleased with my google supported fictitious explanation, I would have liked to see more piling on.  The easy explanation is...easy.

[jchd]

Aside from the now fixed Supercalifragilisticexpialidocious typo, you're right that AutoIt makes no formal guarantee that the local values are effectively wiped out when going out of scope. Sure enough trancexx could vouch for what AutoIt did some time ago but that doesn't mean the behavior is carved in stone. This is merely an implementation detail subject to change at any time. I suspect it currently doesn't bother to zeroise variables memory going out of scope, but don't take my word on this.

Another distinct point is that we have no guarantee either that the old value of a variable is actually overriden after a re-assignment. I would even be surprised if it was, but again I don't have enough insight into current (and future) internal code to assert anything formally.

Obviously no program is safe against reverse engineering or being single-stepped under some advanced tool, so it's impossible to protect any internal secret. But you must be persuaded that a scripting language like AutoIt isn't the best choice to make the life of a determined attacker really hard.

[Crash]

 Thanks everyone for the reply. I appreciate your time.

 

Aside from the now fixed Supercalifragilisticexpialidocious typo, you're right that AutoIt makes no formal guarantee that the local values are effectively wiped out when going out of scope. Sure enough trancexx could vouch for what AutoIt did some time ago but that doesn't mean the behavior is carved in stone. This is merely an implementation detail subject to change at any time. I suspect it currently doesn't bother to zeroise variables memory going out of scope, but don't take my word on this.

Another distinct point is that we have no guarantee either that the old value of a variable is actually overriden after a re-assignment. I would even be surprised if it was, but again I don't have enough insight into current (and future) internal code to assert anything formally.

Obviously no program is safe against reverse engineering or being single-stepped under some advanced tool, so it's impossible to protect any internal secret. But you must be persuaded that a scripting language like AutoIt isn't the best choice to make the life of a determined attacker really hard.

Thanks for the confirmation of doubt. I guess it's because AutoIt is closed-source that no one is able to confirm how it works under the hood, huh. I can now see why C is still such a popular language today although it is pretty much ancient relic. It's very low level and gives you a lot of control. (I denied learning C and had learnt AutoIt instead; secretly hoping C would die. Almost 10 years later, C is still around and strong.)

[jchd]

Note that even with C you don't have direct control over how dynamically allocated variables and storage get destroyed. This is pretty low-level stuff and also depends on the development platform. Not saying it can't be done, just that this isn't as easy as is may sound. C++ destructors give you a much better control, for instance.