Universal Extractor extract the nsi file
Recently i saw that the Universal Extractor is able to extract the files from the installer compiled by makensis.
The files and the nsi script source !!!
How can we prevent that and protect our works ?
thx
Archive: Universal Extractor extract the nsi file
Universal Extractor extract the nsi file
Recently i saw that the Universal Extractor is able to extract the files from the installer compiled by makensis.
The files and the nsi script source !!!
How can we prevent that and protect our works ?
thx
The only way, that I know, that can extract the scripts is if the developer include the script. About the files, well...I think you can use external apps like armadillo to protect it, but I don't know. NSIS is a self-extractor, maybe changing the compressor?
but the thing i cant understand is that exposes the nsi file source we created to make the installer. This is not good :(
The files into the installer are protected because i use other comrpessor.
But how can we protect the nsi source to not be extracted ?
Must exist some way.
I think you are mistaken about the nsi source.
Like Joel said, unless you are packaging the nsi source file into your Installer, there is no way they can see
your nsi source file.
That nsi source file is compiled into a whole different command structure, and unless the person built an decompiler for NSIS, they wouldn't be able to make heads or tails out of whats there.
7z had a decompiler, its output is not pretty tho
I just tried it, indeed UE decompiles the script using 7zip. My script came out with several "Invalid" lines, so it looks like it's not good enough to make it recompilable. As long as you don't do any secret stuff in plaintext nsis code, there isn't much of a risk in this.
Though I do agree that it would be really nice if NSIS installers could be made more solid. Would it be possible, say, to make the compression algorithms randomize their behaviour?
Ah, that makes sense, and definitely is interesting.
I suppose if you had any real "secret sauce" you wanted hidden, you could make a plugin to do it.
Obviously the "hacker" could get your plugin .dll, and attempt to decompile that as well, but at some point, if you are that worried about things, you probably should consider moving to an Installer that isn't free, and has encryption at its cornerstone.
Universal Extractor is most likely using 7-zip v4.40 beta which can "extract" the script too.
PaR
maybe is not the same nsi that the one i created, but !!!
imagine you have lines on your nsi source where some passwords are used to extract or things like that. The passwords are revealed !!
But can someone explain me how the hell the nsi is recovered by teh extraction ? Someone told on this topic about we are packing the nsi source with the installer. I not made that, at least as far as i know.
please help !
If I'm not wrong, it's been already discussed, you may add a kind of security level on your installer by implementing a decryption/encryption method, e.g.
http://nsis.sourceforge.net/DcryptDll_plug-in
Or, if you don't want to go the DcryptDll route, create a plugin that contains your passwords.
Of course, you should use some sort of random thing in there, since anyone could run "strings" against said dll, and get the password strings.
sorry but i see this problem as so serious.
In my dictionary the use of a free tool not mean i could want to show or allow to extract the whole of my work.
This is not serious. Now i suggest and request some countermeasure about this problem on future nsis releases. And i dont think i am the only onw who probably could request this, or yes ?
Free or not free tool, there's nothing really uncrackable, if you believe so go ask M$, sony, etc etc etc.
Anyway, this is a long conversation which has been done in the near past, you may want to search the forum about.
ths not change the fact this is not serious.
The passwords i use with my compressor are exposed extracting the files. Then what i an do related to that ? nothing :(
as i said, this is not serious :(
As I said earlier, you may cover your code with encryption which is especially offered within nsis. Moreover you may write your own plugin to suit your needs or even better modify the source code the way you like it. What else you expect from an open source free program? I'm wondering what is serious and what's not indeed.
the encription make the files cant be compressed :P
Re: Universal Extractor extract the nsi file
Originally posted by arfghNSIS is an OpenSource project. It lives from people contributing to the community, sharing their scripts. What in the world is so bad about people "extracting" your installer? If someone has got your installer, he/she will get the files anyway by running the installer. Also: One the one hand you want use NSIS for free, on the other hand you want to keep your script in private. I call that egoistic...
Recently i saw that the Universal Extractor is able to extract the files from the installer compiled by makensis.
The files and the nsi script source !!!
How can we prevent that and protect our works ?
thx
Originally posted by arfghI bet you haven't even test it though.
the encription make the files cant be compressed :P
Encrypting the files *before* encoding will hurt the compression indeed. That is because compressing files always means entropy coding. After the files have been encrypted, they will "look" and behave like random data (unless you decrypt them with a proper key). I believe this will prevent efficient entropy coding (compression). So if you really want to encrypt the files, you should compress them first and then do the encryption. This of course will prevent solid compression, except you encrypt your files as one solid block of data...
Hi
I to checked this tool and it generetes your NSIS script!
Its not a problem for my application
but I'm intressted on why it is able to genereate the sourcecode of the nsis script!
Is this tool able to do an "uncompile"?
or is the script somehow stored inside the installer?
Somebody knows details?
The endless circle...
Either you haven't read the whole thread, or...
I just gave this "Universal Extractor" a try. Indeed it uses 7-Zip to extract the NSIS installer. And indeed it gets some files out of the installer. However some folder names are incorrect, like "$[31]". Furthermore they obviously use a disassembler to create that "[NSIS].nsi" file. If you look at this file you will notice that this is NOT your original script. It's a very poor disassembly! Of course almost everything is lost, like function names, variable names and all the macros. So the resulting script is totally useless. And where have all the strings gone? The disassembly event won't compile! Instead of looking at this disassembly you could simply run the installer and look at a memory dump. The information you get are the same...
Original installer code:
http://pastebin.org/47545
Disassembly created by 7-Zip:
http://pastebin.org/47543
:igor:
How did they get the NSIS code?
It's been discussed, what else should I say?
This thread contains nothing new, a simple forum search is enough instead.
Originally posted by pospecDon't you read my post? :confused:
How did they get the NSIS code?
RedWine: I have searched the forum. Unfortunately, I can't find a right search phrase to get other discussion on this topic. As you know, English is not my native language.
LoRd_MuldeR: I have red your post two times and it reads about SOME disassembly, but HOW did they made it? (I don't understand this things well.)
Sorry for disturbing.
English is not my native language either ;)
http://forums.winamp.com/showthread....hreadid=245098
http://forums.winamp.com/showthread....hreadid=245397
I know that it isn't. Thanks. I didn't searched for 7-zip :(
Originally posted by pospecHow did they make it? I guess they implemented it! If you can compile a program, then you can disassemble it as well. Simply translate every binary instruction back to the corresponding textual representation. Since NSIS is OpenSource this shouldn't be too hard to implement. Of course some information cannot be restored, like variable/function names and macros. That's because those information simply are NOT present in the compiled binary. Also all comments and all the code formatting is lost for obvious reasons. That's why the disassembly is more or less useless. You end up with a load of code that looks like a mess. And in this case it even won't compile...
LoRd_MuldeR: I have red your post two times and it reads about SOME disassembly, but HOW did they made it? (I don't understand this things well.)
Thanks. Only thing I was afraid was strings (which are in disassembly). I'll study threads that Red Wine posted.
Originally posted by pospecYou 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" ...
Thanks. Only thing I was afraid was strings (which are in disassembly). I'll study threads that Red Wine posted.
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 arfghNope, 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...
one thing is the security and other so different is allow a script extraction. Sorry but all of you not has reasson on this.
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?
Archive: Universal Extractor extract the nsi file
Originally posted by arfghYou 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 :rolleyes:
YES IT IS A PROBLEM CAUSED BY NSIS. Because we dont want to allow the script extraction !
Originally posted by SheikYes, 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...
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.
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)
:D
Originally posted by arfghWe 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.
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
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 arfghYes, it is a DISASSEMBLER. In some way ;)
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.
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_MuldeRSure, 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: This post is not to pump my post count. I don't care about post count. I just want to explain that issue. thanks...
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 arfghWell, 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?
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.
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 arfghYou 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!
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 tell not give more protection but the fact is the fact, On this version teh nsi script cant be extracted.
Originally posted by arfghPLEASE! Don't be silly, after all the forum isn't a playground ;)
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.
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^}That's what I try to explain since this discussion has started :D
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 LoRd_MuldeRI am NOT stupid and I KNOW why are all strings in "disassembled" script. Thank you very much.
You cannot protect strings!
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.
No because you have to supply the key via an userinput and not hardcoded in the script...
if you put the key in the script you have lost, there is no way to "secure" it there. (only obscuring is possible)
and how can we work with that "obscuring" in nsis ?
Originally posted by arfghBe creative! Don't save you password as a simple plain string! Cut your password into several strings, add random characters to those strings and so on. Do everything that might confuse a person who is looking at the disassembly of your installer. At runtime you can calculate the correct password from the strings you have stored in your installer. And don't keep the result in memory any longer than you need it. But be aware that this will keep nobody away from reconstructing your password. It only makes things a tiny bit less trivial...
and how can we work with that "obscuring" in nsis ?
StrCpy $0 "M"
StrCpy $1 "O"
StrCpy $2 "W"
StrCpy $3 "R"
StrCpy $4 "S"
StrCpy $5 "Y"
StrCpy $6 "S"
StrCpy $7 "A"
StrCpy $8 "D"
StrCpy $9 "P"
MessageBox MB_OK "Super secret password: $0$5$9$7$6$4$2$1$3$8"
StrCpy $0 " "
StrCpy $1 " "
StrCpy $2 " "
StrCpy $3 " "
StrCpy $4 " "
StrCpy $5 " "
StrCpy $6 " "
StrCpy $7 " "
StrCpy $8 " "
StrCpy $9 " "
final conclusion. All this fact ruins the so good that the nsis is. At least for me !
Then why not leave NSIS behind, stop bothering the people they try to help you and use some Installer that provides better protection (in your imagination). And better hope the 7-Zip developers won't implement "support" for other Installers :p