There is this executable that is packed however neither peid nor protection_id nor RDG tell me what it is, as they dont know.
How do i go about finding the packer?
Or what if its' custom made?
It could easily have been derived from another packer in such a way as to destroy the signature by which the packer is recognized by those tools. Someone with experience looking at packed binaries might be able to detect obvious signs that it originated from a specific tool, but if all three tools fail to detect it, there's a good chances that it's custom made. A sign that it's custom made would be if the unpacking code is fairly simple and doesn't go through more than a few KB of code before executing the payload. Also look for signs that it doesn't look like it could pack generic program binaries.
Related
I am trying to reduce and make as difficult as possible the ability to access my source code after being compiled by NSIS. I have read that the only way to reduce the chance of unzipping is to modify the order of the opcodes in the Source\fileform.h from the source code and then Compile the new version.
This is a bit over my head. I was wondering if anyone has done this before and willing to post one they have done. (Or create one for me?)
Main reason for this is I have info that I encrypt using blow-fish within NSIS and do not want the chance oFf someone finding out what the encryption keys are. (Used for licencing the software) I understand noting is fool proof, but just want it as difficult as possible.
I know its asking a lot, but could really this.
Thanks!
I don't believe there are any publicly available modified builds like that. And if there were and it got popular, the decompilers would just add support for it.
I have a complete step-by-step guide to building NSIS here.
If you know C/C++, Delphi or C# you could build your own private NSIS plug-in that handles the encryption details.
No matter what you do, somebody who knows how to use a debugger can easily set a breakpoint on the blow-fish plug-in and view your key. The only way around that is a custom plug-in or an external application that handles the cryptography internally...
I created expect script for customer and i fear to customize it like he want without returning to me so I tried to encrypt it but i didn't find a way for it
Then I tried to convert it to excutable but some commands was recognized by active tcl like "send" command even it is working perfectly on red hat
So is there a way to protect my script to be reading?
Thanks
It's usually enough to just package the code in a form that the user can't directly look inside. Even the smallest of speed-bump stops them.
You can use sdx qwrap to parcel your script up into a starkit. Those are reasonably resistant to random user poking, while being still technically open (the sdx tool is freely available, after all). You can convert the .kit file it creates into an executable by merging it with a packaged runtime.
In short, it's basically like this (with some complexity glossed over):
tclkit sdx.kit qwrap myapp.tcl
tclkit sdx.kit unwrap myapp.kit
# Copy additional assets into myapp.vfs if you need to
tclkit sdx.kit wrap myapp.exe -runtime C:\path\to\tclkit.exe
More discussion is here, the tclkit runtimes are here, and sdx itself can be obtained in .kit-packaged form here. Note that the runtime you use to run sdx does not need to be the same that you package; you can deploy code for other platforms than the one you are running from. This is a packaging phase action, not a compilation or linking.
Against more sophisticated users (i.e., not Joe Ordinary User) you'll want the Tcl Compiler out of the ActiveState TclDevKit. It's a code-obscurer formally (it doesn't actually improve the performance of anything) and the TDK isn't particularly well supported any more, but it's the main current solution for commercial protection of Tcl code. I'm on a small team working on a true compiler that will effectively offer much stronger protection, but that's not yet released (and really isn't ready yet).
One way is to store the essential code running in your server as back-end. Just give the user a fron-end application to do the requests. This way essential processes are on your control, and user cannot access that code.
Theos lists it supports
Third party frameworks can be placed inside $THEOS/lib, and utilised with instance_EXTRA_FRAMEWORKS. (kirb)
But I am not sure how to make it work or trouble shooting, can someone explain what's this for, and how to use it? If I already build a binary, and the binary needs some frameworks, how to do it?
I tried to follow the samples like putting frameworks under $THEOS/lib and add the flag, but when it runs, for example I am adding AWSCore.framework and AWSS3.framework, it reports library not loaded, image not found
I need to understand how the framework is added into my binary, and what's the run path etc. and how to debug where goes off. Thank you. Does the binary already contains the framework, or I should copy it to somewhere?
I have a stack which was originally built in Hypercard then migrated to Metacard. Obviously, it has expanded greatly over that time. Some core features broke when I tried to migrate to Runrev which is why I've waited till now to finally do that. I'm keeping it as a stack rather than an exe so I can save changes to it. I've built a standalone player to launch it and that is working. I've included the revmessagebox.rev stack in the Standalone Stack settings. This does add it but, incorrectly. I can put messages to it from my stack but, it won't run commands and it's missing all it's icons. I'm also included the revimagelibrary.rev and revtools.rev stacks in the hopes of fixing this but, no dice. I was also hoping that including revimagelibrary.rev would get my old Metacard icons to display but, no dice. I appreciate any help I can get on this.
Rich
I don't think you can. The message box is part of the IDE and requires the development environment to run. When you build a standalone your scripts etc are compiled and an interpreter for commands is no longer present.
To replicate it in a standalone you could use a simple window with a field to accept text and would require you passing the text entered to a "Do" command. The other functions present with the message box (accessed via the icons you mentioned) are also development tools and don't make much sense in a standalone.
The message box is not only integrated into the IDE, the engine also has hooks that directly support it. I'm not sure those hooks are included with the engine that is built into a standalone, so even if you adapt the existing message box for your standalone it still may not work correctly.
The solution, as others have said, is to build your own stack that functions as a pseudo-message box. It is easy to display messages in your own stack, and pretty easy to execute simple commands using the "do" command. It is somewhat more difficult to execute complex or multi-line commands. But I agree with Dunbarx that I'd assess the need for such a thing if you are planning this standalone for distribution. It's a non-standard interface element.
What James said. But note that though the msg box is indeed integral to the IDE, it is still just a stack, and that stack can be replicated to whatever extent you need.
That said, the msg box is usually used as a development tool, to test short scripts (usually one-liners), to get or set property values quickly, as a simple calculator, that sort of stuff. If you need that sort of functionality, you should probably integrate it more comprehensively into the structure of your project.
Craig Newman
i have been programing in vc++ for sometime and i want to make some free software for people to use but i really don't want people to have a unprotected copy of my work. i just use what ever vc++ 2008 has when i build in right now so i don't know if it is encrypted or now. i don't need something that is top of the line i was just hopeing for something free and it would encrypt my project before i gave it out.
You need to start by thinking about what you want people to be able to do with your code, and what you want people not to be able to do. If all you want is that people can run your code, but can't change it (without significant difficulty) and can't see how you're doing what you're doing, then you can simply compile the program with your compiler, and send them the executable code. This is the way in which much commercial, paid-for software is distributed: as an example, if you buy a copy of Microsoft Word, you get an executable program which you can install on your machine and run, but you don't get the source code from which it was built. This means that you can't make changes to Word if you want to fix a problem or change the way in which it works.
If what you want it more complicated than this, please tell us what you want various people to be able to do and not do, and we'll try to help.
Well, "free software" can mean one of two things- free as in beer or free as in freedom. It sounds like you're looking for the first of the two.
I'd say don't bother with encrypting it. If you're distributing a compiled program, there's really no way to prevent someone from reverse engineering it if they wanted to... which is unlikely if your program is free anyway. Same goes if you're distributing the source. Encrypt it all you like, but all it takes is one person with a decrypted copy to redistribute it.
no one is going to use any 3rd party library if it can't be maintainable/debugable(because you don't want to provide source code)
its like installing unknown program on your computer... you never know that's gonna happen
if you really want to release it, then you might split it and release it in parts?
or maybe someone is already doing something like you.. check github for example
i don't really get what you want, maybe you just want to encrypt your project files?
if you want to encrypt it with free software why don't just compress and put password, for example you can use 7-zip, the encryption is AES-256 bit which is really good, no one can break it, except maybe NSA.