Anteaus

@JLogan3o13, I was going to think of some succinct reply, but instead I will do two things:I will quote myself: "Think this has been discussed before" ie I have searched. I will then quote Tankbuster, who sums it up about as well as I could: "If someone gets offended by this, because he knows already 200 posts about it. Do not reply" Though, the $1E06 question is whether an EV cert would be necessary to prevent false positives. I've so far found no definite answer to that. Though, feedback from C/C++ utility writers suggests neither may help that much, they still get false positives. So, forget it.

Think this has been discussed before, but is there any way of signing a compiled script with a certificate? Reason I ask is that some AV products keep on producing 'Generic Trojan' false positives on compiled scripts. I'm told that signing with a certificate from a trusted source might reduce this problem.

I'm trying to use this UDF to add Full permissions for a specific user to a given folder. The folder may have existing local permissions, which must be retained. It also inherits Administrator and System (full) permissions from the root. Which is pretty-much a standard situation. Firstly, I presume that the _SetObjectPermissions() function is unsuitable, since this would seem to always remove any existing local permissions, replacing them with the new one. Can anyone confirm that? If I use the _EditObjectPermissions() function, I hit a peculiar combination of effects in that: If $InHerit is zero, the new permission and all existing Full local permissions are trashed. Specifically, they become rewritten as 'This folder only' permissions. If the $InHerit is flag non-zero, all of the inherited permissions are duplicated as local permissions. So you then have two Administrator permissions, two of SYSTEM, etc. Within this scope: If $Inherit is 1, local permissions are made 'This folder-only' as for zero. If $InHerit is 2, local permissions are made 'This folder and subfolder' permissions.If the $InHerit flag is 3, the new new permission is added correctly and existing local permissions are unaffected. (Which would be fine if it were not for the side-effect)$Recurse has no identifiable effect on the outcome, for the toplevel folder anyway. $ClearDACL=1 with $InHerit=3 has the effect that inherited permissions are then made local, and the inheritance flag set to false. Sample code: Local $pArray[1][3] $pArray[0][0]='TestUser'; (Or 'S-1-5-21-789336058-764733703-1177238915-1006') $pArray[0][1]=1 ; Grant $pArray[0][2]=$GENERIC_ALL ; (Or 0x1F01FF for full generic and specific rights, makes no odds.) $SetOwner="TestUser" $ClearDACL=0 ; $Recurse=1 ; $InHerit = [As detailed above] $rtn=_EditObjectPermissions($oName, $pArray, $SE_FILE_OBJECT, $SetOwner, $ClearDacl, $Recurse, $InHerit) $rtn returns 1. Seems there is definitely something amiss here. Since _EditObjectPermissions() loads the existing DACL into an array containing the new permissions, then submits the result to _Set[Reg/File]ObjectSecurity - The same handlers used by _SetObjectPermissions() which does work correctly - I'd hazard a guess that the permissions are somehow being corrupted in the array merge. Just a guess, though. Most testing done on XP SP3 VM, some on Win7/10. AI version 3.14.2 If anyone has thoughts on this, would be welcome. Update: _SetObjectPermissions() has two parameters reversed in the syntax. (Line 519) I did notice that at the time, and thought it unlikely they would differ. Seems like if you have illegal values due to the reversal, it can cause the computer to do strange things thereafter. Which I think was why the _EditObjectPermissions() call was acting up the way it did. That, and there's a fourth array element which determines the scope of the permission. With that in, you get proper Full permissions. Once those two are fixed, seems to work fine. Unfortunately, no. Full permissions are now set correctly, but there are still issues with inherited permissions being duplicated locally. Seems to happen at random even with no change of test parameters. I'm wondering if there's a memory overflow/over-read involved.

#RequireAdmin In this case the compiled script is called by an Inno Setup installer. Though, I don't think the actual mode of calling is significant so long as it's from a limited account. The reason I need to recompile, BTW, is that the 3.3.8.1 build is suffering antivirus false positives. I found a couple of other threads relating to this or similar issues: '?do=embed' frameborder='0' data-embedContent>> '?do=embed' frameborder='0' data-embedContent>> -though they don't seem to offer any definite answer to this one.

A specific executable compiled with Aut2Exe 3.3.8.1 running under Windows 7.1/64 requests UAC/UAE elevation if it is compiled with the RequireAdmin option. Which is the expected behaviour. However, when the same code is compiled with 3.3.12.0 no UAC prompt occurs, and instead the exe (or possibly the calling program) reports 'CreateProcess failed; code 740' and fails to launch. Just wondering if there are any known differences here. If the issue hasn't been seen before I'll do a few more tests to try and establish under what conditions it occurs.

http://sf.net/projects/softwarepolicy Basically, allows you to control which disk locations executables can be launched from. No changes to core functionality in this version, but better compatibility wtith Windows 7 and 8 when UAC/UAE is enabled.

I would vote most strongly against that kind of nonsense creeping in. I can't count the number times I've cursed php's use of == , === and !== operators for creating an obscure and hugely timewasting bug in an otherwise-ordinary string comparison.

If you run the shortcut-creating script from the network share containing the target executable, then @scriptdir will give you its location. You can then append the executable name to get $Location1/3 automatically. @DesktopDir or @DesktopCommonDir macros give you the desktop location on the local computer for $Location2. With these you should be able to write a script that can be launched at LAN logon and automatically creates the shortcut, no questions asked. BTW, if the need to do this arises because computers have varying and unpredictable drive mappings, then you really ought to think in terms of disallowing manual mapping of shares in Explorer via group policy, and use a server-side logon script to establish the mappings. With a unified environment you can reuse the same .lnk file for all desktops, no need to create it programmatically.

What matters is not what happens with a local file, but whether the security relaxation can be exploited by an external website. Can you be certain that is not the case?

"I have created a script which runs with elevated rights (works fine) and calls from network location" One of the least wise decisions MS made, IMHO, when developing XP>on was to make network connections userized. Thus, you can no longer call network resources from an elevated session, unless that session re-establishes its LAN logon. The usual workaround is to store a LAN account and password locally so that the admin user can be automatically logged-on to the LAN. The problem is that this creates a security issue, since it is relatively easy to steal the saved password from Protected Storage. Other workarounds are to store the password in an AutoIt script, or use an alterntaive to UAC.

http://sourceforge.net/projects/blat/ Might be more suitable for this kind of task than Outlook. Takes a bit of figuring-out the right commandline parameters but once it's set up it's independent of any other email program, and can easily be scripted. We use this to send backup reports. If you want to send a picture such that it will display IN the email itself, use the embed option.

You might like to take a look at http://sf.net/projects/softwarepolicy This is basically a replacement for UAC, and works on the principle that: The user is a proper administrator LAN connections are never lost due to permissions changes All programs can be run with full rights except those specified as 'high risk' eg browsers Restrictions are set on the disk locations programs can be run from Two major advantages are overcoming the loss of LAN connections caused by UAC, which is extremely problematic for business users, and that it is not so easy to spoof the user into robotically clicking 'Yes' to a malicious elevation prompt. For software installation work, the protection can be turned off for a specified interval of time during which you won't be bothered again by prompts. You can even reboot without the status changing. At the end of the time limit the protection automatically turns itself back on, in case you forgot. Obviously not so appropriate if you are distributing your script, but for inhouse use it's a very good solution to keeping security tight without the problems raised by UAC.

I don't have a specific answer, but as a word of warning Microsoft are all too keen on doing this kind of thing where IE is given special priveleges to access the local filesystem. The issue is that it's hard to tell if there might be ways of exploiting it from external websites. I'd look for a safer method of implementing whatever it is you're doing.

This is quite hard to do since most browsers won't allow other programs to see text in the webpage being viewed, for security reasons. A workaround I've used in the past is to use Javascript to set the page title to the text I want to extract, since Autoit can see this property in virtually all browsers.

Aleph, your code looks OK except that your method of preventing repeats within the same minute might be unreliable. The right way to do this is to create am $armed flag for each event, and initalise it to false. In your main loop: IF the current time is equal to or later than the event time THEN ....IF $armed is true THEN .......fire the event .......reset $armed to false ....ENDIF ELSE ....set $armed to true ENDIF SLEEP a few seconds and repeat There is one special case, and that is an event scheduled for exactly midnight, which you may need to make allowance for. (There can be no time value less than 00:00) Though, not important if event is always at 18:00. This is basically how a mechanical timeswitch works - the peg on the dial compresses a spring as the set time approaches. At the set time the peg is disengaged, releasing the spring which trips the contacts smartly from one state to the other. Once the set time is past, the action cannot repeat until re-arming occurs. Also, you may find it easier to convert your times into 'hhmm' format and do a direct numeric comparison, rather than checking hour and minutes separately. HTH.