Universal Extractor extract the nsi file

Thanks. Only thing I was afraid was strings (which are in disassembly). I'll study threads that Red Wine posted.

Originally posted by pospec
Thanks. Only thing I was afraid was strings (which are in disassembly). I'll study threads that Red Wine posted.

You cannot protect strings! If your installer "knows" (uses) the string, then it must be stored somewhere in the EXE file. Of course you could try to encrypt the string and decrypt it at only at runtime. But even if you mange to keep your key a secret (the key must be stored somewhere in the EXE file too), still the string would be in memory at runtime. So somebody could do a memory dump and obtain your string. Guess why those new "unbreakable" Copy Protection systems like AACS (Blue Ray Disc) have been broken that fast! They didn't crack the protection itself, they simply grabbed the "secret" keys from memory while playing the disc in a legitimate player. This cannot be prevented without special hardware mechanisms (like a TPM), it can only be made more difficult by using techniques of "obfuscation" ...

BTW: Modifying the NSIS source codes and "randomizing" some of it's data structures would be one method of obfuscation. But that is NO real security! It's called "Security through Obscurity", which basically means there is no security at all!

is all the same.

As i told previously, the nsis is not the same, but all the commands as the calls to my internal compressor with passwords, are exposed. And sorry but an opensource tool not mean we must share the scrips because yes and yes.

As i said this is not serious, because include a monkey is able to extract the passwords or all the needed from the extracted nsis script.

Really pathetic

And again: No software in the world will be able to protect your passwords! That's because the installer must be delivered to the user and the passwords must be stored in the installer somehow (otherwise the installer couldn't work). You could try to encrypt your passwords, but then you would have to store the decryption key in the installer as well (besides the problem that the passwords could be grabbed from a memory dumb anyway). So there simply is NO secure way to do that. Obfuscation can make it harder to "extract" your passwords and it might cause some disassemblers to fail. But it's no reliable protection. If somebody wants, he/she can circumvent your password protection easily...

one thing is the security and other so different is allow a script extraction. Sorry but all of you not has reasson on this.

Originally posted by arfgh
one thing is the security and other so different is allow a script extraction. Sorry but all of you not has reasson on this.

Nope, there is no difference between "script extraction" (disassembly) and "security". I have explained that enough now, so I won't explain again. Simply read previous posts in this thread any maybe the referenced threads...

is clear for me.

Is nsis who allow this extraction. And YES is kinda different the security and this script extraction.

Maybe we must check if the winamp setup allow this extraction ?

Last time now: If you want to make a "working" installer - an installer that the user can execute - this installer MUST contain valid program code! Otherwise it couldn't be executed and it would be useless to the user. And if your installer contains valid program code, it can be disassembled! Or in your words: The script can be extracted (although "extracting" is not the proper word). That's a fact you cannot change. Also it's not a NSIS problem. It's a general problem that applies to ALL programs/executables, including ALL installers. Unless you understand this fact, the entire discussion in this thread is useless...

you can argue a lot of times but the fact not go to change.

YES IT IS A PROBLEM CAUSED BY NSIS. Because we dont want to allow the script extraction !

Not to keep feeding the troll here, but I wonder if we could randomize the command values per script build...

As long as both the build side, and the exehead side agree on what the values for each command is, there is no real reason why we can't randomize each command value...
This would make the decompiler at least have to work a lot harder on figuring out what each command is.

Specifically, what if we were to allow "per script build" randomization of "exehead\fileform.h" of the enum of NSIS commands?

Obviously, for debugging of the resulting exe would be a nightmare, but then again, isn't that the point?

Originally posted by arfgh
YES IT IS A PROBLEM CAUSED BY NSIS. Because we dont want to allow the script extraction !

You can call it "extraction" over and over again. But it's still a disassembly. The script is NOT extracted, because it's NOT in the installer file! The disassembler "restores" the script from the binary program code. Look at the file, it's totally different from the original script. Of course it is! Disassembly is a whole different thing than "extraction" and it's NOT a problem of NSIS. Once and for all 🙄

Originally posted by Sheik
As long as both the build side, and the exehead side agree on what the values for each command is, there is no real reason why we can't randomize each command value...
This would make the decompiler at least have to work a lot harder on figuring out what each command is.

Yes, this should be possible. But as said before: this would be "Security through Obscurity". And one of the first things you learn when you get in touch with Security in Software Development is that "Security through Obscurity" is a really bad idea. So you always have to assume that the Attacker has full knowledge about how your protection works. Nevertheless I agree that some obfuscation might help to prevent Scriptkiddies from "extracting" (see the Quotation marks) your installer too easy. But don't make the mistake and think this is a "safe" protection...

Last but not least I think an OpenSource project like NSIS should stand for TRANSPARENCY instead of OBFUSCATION. There already are enough companies that bother the users and developers with their obfuscations attempts...

LoRd_MuldeR

if i use a command as for example...

unuharc.exe e -pblahblah -y+ -t"$INSTDIR\blah" blah.uha

this exact command will be present on the extractes nsi script. This mean secury is 0 ! Because in my dictionary the action it performed the unversal extractor was not a dissasemble !

Then, by this way is NSIS who allow this extraction.
I do now a vey hard request to the nsis team to put security to not allow that, and just to be at least a be serious.

thx

I wish you good luck with your request to fix a "problem", which you apparently do not understand and which is impossible to fix (because it's not a problem, but a fact)

😁

Originally posted by arfgh
LoRd_MuldeR

if i use a command as for example...

unuharc.exe e -pblahblah -y+ -t"$INSTDIR\blah" blah.uha

this exact command will be present on the extractes nsi script. This mean secury is 0 ! Because in my dictionary the action it performed the unversal extractor was not a dissasemble !

Then, by this way is NSIS who allow this extraction.
I do now a vey hard request to the nsis team to put security to not allow that, and just to be at least a be serious.

thx

We could see that with any installer. Just watch the Installer "exec" off any processes. The command line to your "unuharc.exe" you see will be the exact same as you would see in NSIS.

For anyone who's interesting about the forum rules:

Post Pumping
- If a post is suspected to serve no other purpose than to increase the post count of the poster, then the moderators may, at their discretion, issue a PM to the member in question enquiring about the nature of the post. Posts/Threads that are blatantly post pumping will be removed/locked without recourse to the poster.

Sheik

yes, we can see the strings using a dissasembler. But this is not the fact. The fact is the universal instalelr is not a dissasembler.

Originally posted by arfgh
Sheik

yes, we can see the strings using a dissasembler. But this is not the fact. The fact is the universal instalelr is not a dissasembler.

Yes, it is a DISASSEMBLER. In some way 😉

Of course the primary purpose of Universal Extractor is extracting files from archives. Yes. But it uses 7-Zip to extract the files from a NSIS installer. 7-Zip also is NOT a disassembler. Yes. Nevertheless it is obviously using DISASSEMBLER techniques to create that "[NSIS].nsi" file. That file cannot be "extracted" from the installer (like all the other files), because there is no such file in the installer! It's not there! However the script file can be "restored" from the installer code easily, because the installer code MUST be in the installer (otherwise the installer couldn't run). The process of restoring textual "Assembler Code" from binary "Machine Code" is called DISASSEMBLING. And that's exactly what's happening here. If you like to hear that or not. It's so obvious that there is no doubt. Just look at "[NSIS].nsi". It's NOT your original script, it's a DISASSEMBLY of your installer code.


@Red Wine: This post is not to pump my post count. I don't care about post count. I just want to explain that issue. thanks...

i dont cares too about post count.

ok LoRd_MuldeR, then what is our solution to prevent that ?
Can we do somethig about ?

thx

Originally posted by LoRd_MuldeR
@Red Wine: This post is not to pump my post count. I don't care about post count. I just want to explain that issue. thanks...

Sure, but all of you guys just repeating the same things over and over again. There's nothing new just an endless repeat. This is at least tedious, what else could I say? The subject has been already discussed as I said ages ago when this annoying thread started.

Red Wine

the things are not fully discussed.
Because the last i must to say is about an old version of nsis where the nsi script is not extracted by the universal extractor. I think it was the 2.03 version.

Originally posted by arfgh
Red Wine

the things are not fully discussed.
Because the last i must to say is about an old version of nsis where the nsi script is not extracted by the universal extractor. I think it was the 2.03 version.

Well, you think wrong or you haven't read at all the discussion. Could you tell one single news regarding to the subject which has been added through this endless annoying conversation?
Anyways, I wouldn't follow further the annoyance, as I said DOES NOT offer anything more than setting the focus on it.

the discussion is to try to fix this bad fact on the ACTUAL nsis, as suggest or request. But you dont want we talk more about this ? Just tell it clear if is that.

Originally posted by arfgh
the discussion is to try to fix this bad fact on the ACTUAL nsis, as suggest or request. But you dont want we talk more about this ? Just tell it clear if is that.

You are wrong. This discussion will not lead to a "fix", as there is nothing to fix. I won't argue over this, because all has been said in this thread. So please re-read my previous posts as well as Sheik's posts and try to understand. Further discussion is useless until you understand the crux. Thank you!

BTW: If 7-Zip doesn't disassemble NSIS v2.03 installers, this does not mean v2.03 is any safer! It just means the disassembler isn't compatible to v2.03 yet. Maybe the developer created the disassembler with up-to-date NSIS and didn't care about "outdated" versions. Nevertheless it will be easy to adjust the existing disassembler for older versions, if anybody wants that. So nope, using the older NSIS version won't give you more protection. No version ever will or ever did...

you tell not give more protection but the fact is the fact, On this version teh nsi script cant be extracted.

Originally posted by arfgh
the discussion is to try to fix this bad fact on the ACTUAL nsis, as suggest or request. But you dont want we talk more about this ? Just tell it clear if is that.

PLEASE! Don't be silly, after all the forum isn't a playground 😉
Simply, just as simple as it gets, after 50+ posts, show me ONE single thing that this discussion adds, fixes, or whatever it does.

I didn't understand the fuzz about this issue when 7-zip 4.40 was released and I don't understand it now.

Storing passwords as plain text in NSIS code has never been safe and never will be. Simply because you can get the strings from the memory at the run time (see the attachment). And no obfuscation can prevent this.

Originally posted by {_trueparuex^}
I didn't understand the fuzz about this issue when 7-zip 4.40 was released and I don't understand it now.

Storing passwords as plain text in NSIS code has never been safe and never will be. Simply because you can get the strings from the memory at the run time (see the attachment). And no obfuscation can prevent this.

That's what I try to explain since this discussion has started 😁

Originally posted by LoRd_MuldeR
You cannot protect strings!

I am NOT stupid and I KNOW why are all strings in "disassembled" script. Thank you very much.

A solution for your problem would be to generate the password from a user entry, or get the passwords for your secret files via the internet.

So the passwords are not stored in the installer.
This would be quite secure (depending on security of the internet connection, trustworthy of the enduser and so on) because in the Installer is nowhere a direct string

or you store the passwords in a text file (ini format or similar) which is send along but encrpyted (again with a userentry to decrypt it)


But this would be only workarounds of the problem.
I'm not an NSIS-profi but it is a tool for installing software, not for cryptograhpic purposes :-)

of course if we use the "DcryptDll" the key is also exposed, true ? I mean when extract the files with universal installer.