joakim

No, the question has nothing to do about the script source code. It is open and with a wide open license, for example MIT. The question is about the distribution of compiled scripts (the exe), and whether my interpretation of the referenced license for SOFTWARE PRODUCT is correct in that such distribution will NOT require that license attached.

So there is some code shared with license set to for example MIT. Now, when sharing a compiled script, is that supposed to have this one attached; https://www.autoitscript.com/autoit3/docs/license.htm ? I see the definition of SOFTWARE PRODUCT there, of which I've made an opinion on in the favour of "not needed". Just wanted to be absolutely sure.

Great. Thanks.

Is there a working link for this dll?

I doubt that I'll do more with that tool, so what I would suggest is to try running tool from the local system account, or as trustedinstaller. It's a quick workaround that usually gives you access to any registry key.

Great idea and code! Very nice. But there's still a way to fool the compiled binary. Remove the CHKS resource, modify the binary to fit your needs, and then re-run the program. In the end it will compare itself against the checksum generated on the hacked executable.

No, not from me.

Looks cool. Will be away for a few days, but will look further into it when back.

So I think I understand a bit more it now However, still I am not sure if MCI/mciSendString is supposed to support a memory pointer as lpszDevice (instead of filename as in sound.au3). Curently I get error code 263: "The specified device is not open or is not recognized by MCI." And still I am not sure exactly how mciSendString in the end resolves audio length with lpszCommand=status and lpszOpenFlags=length. Do you know Melba23?

That's really nice! I did not notice it before now. One question, since I may not have understood all the code yet: Is it possible to use this code and calculate mp3 sound length for a resource or some memory chunk (without temporarily writing it to disk as .mp3)? My quick assumption is no, since it is based on reading file properties. Or yes if temporarily writing the data to disk as .mp3 is an option..

Guess both functions will do as they both support SND_MEMORY. Apparently some calculation is needed in order to get at time length; http://www.datavoyage.com/mpgscript/mpeghdr.htm http://www.multiweb.cz/twoinches/mp3inside.htm Each frame has a constant time length. But in order to get at number of frames, you must parse the entire file. Frames can vary in size with vbr. And to complicate further, there may exist metadata containers, like id3..

We also implemented FSCTL_SET_REPARSE_POINT when making the NTFS file extractor, if you want an example for that;http://mft2csv.googlecode.com/files/NTFS_File_Extractor_v4.0.0.2.zip

While testing it, I thought I'd found a bug in it, but realized it was just unexpected Windows behaviour.. Trying: echo text > c:\file.ext:something.txt I was wondering why your tool displayed 0d 0a at the end. Turns out echoing into an ADS from cmd will do that, although it strictly speaking should not be part of the content. Or I have misunderstood something.. Doing the same thing with the type command (piping content from standard $DATA attribute of a file into an ADS, will not lead to the strange prefix. Anyways, your tool works fine

If I remember this ok, it can be before signature (stub + script is signed). after signature (stub is signed). within signature (stub is signed, and script is within the scope of signature as defined in data directory and signatures header). Not so sure if it's a security flaw with regards to autoit, as no one would sign the stub before appending the script anyway. And even if you could append a script after or within the signature, the stub will still execute the correct script (assuming you signed the stub + script). But still, it's fun to mess with

One of the strange things I remember from when poking with this, was that by modifying the signature in certain ways would make explorer crash/freeze when attempting to validate it. If I'm not wrong I had to also adjust the authenticode signature header slightly to adapt to new size (in addition to pe checksum, data directory entries, and the signature itself along with alignment issues as you already pointed out). The funny thing about all this in the autoit world is that a signed executable with overlay added (encoded script), lets call it program A. You could turn that executable into a different program without messing up the signature. You could even put the script overlay within the signature overlay! Try this by signing the AutoItSC* and then hiding the encoded script within the signature On a side note, I could mention because actually I did not notice until now, that on Windows 7 x64 I can not even run the executables that I've signed with the certificate I made back then when doing that "DigitalSignatureTweaker" tool. So the OS refuses to run those executables, while it will not complain about unsigned ones.. Hmm, maybe it is my test certificate that has been blacklisted somehow..(don't know). But if not, it certainly does not make sense to have higher restriction for self signed than unsigned executables, which seems like strange logic to me. So maybe the trick can still be verified on Windows 7 x64, as a long as different test certificate is used. Anyway, this was a bit off topic. Edit: And for those with nothing else to do, and for the fun of it, could try to make signed executables with hidden signed executables with hidden signed executables, until you are fed up with nesting it. Do it on Microsoft signed executables (exe,dll,sys) instead of self signed ones.