I'm able to sign .NET assemblies with SHA1 and SHA256 at the same time using signtool.exe (this link helped me greatly), but I would like to use SignFile task in MSBuild. As far as I understand, SignFile task uses signtool.exe, but when I see the reference of SignFile in MSDN, there are much less options than signtool.exe and I am not able to sign an assembly with both SHA1 and SHA256 so far.
Obviously I could just use Exec task to execute signtool.exe and be done with it, but I still would like to explore the option of using SignFile as the call would look much cleaner.
Please let me know if you have any information on this.
TIA
Related
I am using some third party libraries(source codes) in my project and I want to list all the versions of the libraries in a file using a script. For that I got two ideas:
First is to search for version file(.h file in source code) and use the grep command to retrieve the library version
Second is to use wmic in command prompt or get-childitem in PowerShell to get product information from library file or executable file that is created.
Can anyone suggest which is better in terms of time or security. Or can you suggest any better ideas than this. Thanks in advance.
I've been trying to sign an MSI file in a post build event with the following code
signtool sign /t http://timestamp.verisign.com/scripts/timestamp.dll /f "E:\Products\Tools\DigitalId\Certificate.pfx" /p 1501ocbc /d "Server" "E:\Products\Setup\Server_Setup\ServerSetup\bin\Release\en-US\ServerSetup.msi"
This will sign OK with the Visual Studio command prompt and similar code works for C++ projects. However, when building the setup and signing the code with post build events, I get a code error, 9009. After much debugging I have come to the conclusion that WiX is using the ordinary command prompt. How do I get cmd.exe in WiX to open with Visual Studio tools?
Or is there another way to sign my packages?
You could define the event like this:
"%programw6432%\microsoft sdks\windows\v7.1\bin\signtool.exe" sign /t etc..
Note: you need to adapt the path to your install (program files, Windows SDK version, etc.), or you could also define your own environment variable.
It looks like there is a built-in way of signing MSI files which seems to work correctly with SignTool: Insignia.
Register the certificate and use the /sha1 hashkey - just to be sure the certificate is good (check browser-internetoptions/content/certificate)
SignTool path - make it explicit as Simon Mourier suggested or put signtool.exe in an accesible path
Choosing postbuild operation - you should sign the MSI file after you've completed all operations upon the MSI file. Any action upon the MSI (INSERT/UPDATE Property) will undo the signing.
I'm looking for a free open source tool-set that will compile various "classic" scripting languages, e.g. Korn Shell, ksh, csh, bash etc. as an executable -- and if the script calls other programs or executables, for them to be included in the single executable.
Reasons:
To obfuscate the code for delivery to a customer so as not to reveal our Intellectual Property - for delivery onto a customer's own machine/systems for which I have no control over what permissions I can set regarding access, so the program file has to be binary whereby the workings cannot be easily seen by viewing in a text editor or hexdump viewer.
To make a single, simply deployed program for the customer without/or a minimal amount of any external dependencies.
I would prefer something simple without the need for package manager since:
I can't rely on the customer's knowledge to carry out (un) packaging instructions and
I can't rely on the policies governing their machines regarding installing packages (and indeed from third parties).
The simplest preferred approach is to be able to compile to proper machine code a single executable that will run out of the box without any dependencies.
The solution that fully meets my needs would be SHC - a free tool, or CCsh a commercial tool. Both compile shell scripts to C, which then can be compiled using a C compiler.
Links about SHC:
https://github.com/neurobin/shc
http://www.datsi.fi.upm.es/~frosal/
http://www.downloadplex.com/Linux/System-Utilities/Shell-Tools/Download-shc_70414.html
Links about CCsh:
http://www.comeaucomputing.com/faqs/ccshlit.html
You could use this: http://megastep.org/makeself/
This generates a shell script that auto-extracts a bundled tar.gz archive into the temporary directory, and then can run an arbitrary command upon extraction.
Using this tool, you can provide only one shell script to the client.
This script will then extract your ofbsh obfuscated scripts and binaries into /tmp, and run them transparently.
You can obfuscate shell scripts with something like ofbsh. You won't easily bundle other programs into a single executable for unix, though. Normally the approach for installation would be to buld a package for your platform's package manager (e.g. rpm, deb, pkg) or to provide a tarball to unravel in the appropriate directory.
If you need an executable file that unpacks the contents you might be able to use a shell archive. Take a look at the docs for shar(1) and see if that will get what you want
If you really need a scripting capability to glue multiple C programs together, take a look at the Tcl language. It has an API that is designed to trivially wrap C programs that expect to see argv[] style parameters. You can even embed the chunks of C code into a custom Tcl interpreter and glue it together with various Tcl scripts.
If you really need to make it opaque, you could encrypt the tcl scripts and wrap the whole thing in something that unencrypts the tcl scripts to a buffer and then runs the Tcl interpreter on them. Tcl can accept scripts from a file or a char* buffer, so the unencrypted scripts never have to hit the file system.
shc
I have modified the original source and upgraded to a new version with some feature addition and bug fixes.
It's here.
Example Usage:
shc -f script.sh -o binary_name
script.sh will be compiled to a binary named binary_name
Note that, you still need the required shell to be installed in your system to run this executable.
arx is a great bundler, and you may be able to integrate a obfuscator in its workflow.
Options that are available to you:
Write a logic in your code that, when the code is run for the first time on a box, it'll check to see if all the required packages exist. And if they do not, the code will automatically go get the packages itself and will install them...without asking to the user to do anything. The only question the user needs to be asked is "Is it ok to proceed with the install of the aforementioned packages? (Y/N)". Anything outside of that is too much.
Once the above code is complete (yes, i'm aware it may not be all that simple for you to code this, or may be it is, i don't know your coding capabilities), copy and paste your completed code to a site like kinglazy.com and an actual executable file will be generated for you.
There are quite a few benefits of this particular option:
Yes, you will be able to run the encrypted version of your script without exposing any proprietary information.
No one can try to "view" your script, because if they do, they'll see nothing but indecipherable, encrypted jargon which wont make sense to them.
No one can attempt to modify your script because if they do, the script will immediately become inoperable.
No one can run a debugger on your script to see how it works. If they do, the script will abort.
Also, no one can create copies of your script on the same server. If they do, it will abort and won't work. It'll only allow users to create symlinks to the original location of wherever you want the script to be.
I may be missing some things in what you asked for, but i believe the above satisfies a good portion of what you wanted.
Not sure if this works on other scripts but it certainly does for shell scripts.
You can also use the free online version of CCsh to compile a shell script into a binary:
http://www.comeaucomputing.com/tryccsh/
I want to make a stand-alone exe with cygwin. I have two options:
Staticly link cygwin1.dll
If I can statically link cygwin1.dll, then I can get a stand-alone exe.
Merge cygwin1.dll with myprog.exe
If I can merge cygwin1.dll with my program, the I can get a stand-alone exe.
Do not suggest that I use IlMerge. This will not work because I didn't compile my program with .NET.
Are any of these options possible? If not, is there anything that is possible with this dilemma? Thanx!
Try passing -mno-cygwin as a compiler and linker flag. If your program's requirements are simple enough this will avoid depending on Cygwin libraries and create a standalone EXE.
I can see two possibilities that you might consider reasonable. One would be to build a stub executable with a different compiler (e.g., MinGW -- whatever, just so it doesn't need cygwin) to unpack the main executable and cygwin.dll into a temporary directory, and then spawn that executable. To distribute only a single executable, you'd want to add the main executable and cygwin.dll to the "stub" as binary resources. It's a bit ugly, but pretty straightforward.
The alternative would be to grab the source to cygwin, and build it as a static library. At least in theory, this should be cleaner -- but it's also undoubtedly more work. Getting it to build as purely static code instead of a DLL will almost certainly take some work, though it's hard to even guess how much. Just browsing a bit, it's seems pretty unlikely that it's going to be a quick job of a couple hours, or anything like that (unless there's something there that I missed that already supports building it statically, of course).
More precise answer of Jerry.
Procedure described below should be confronted with your rights and license law! I know it can work but rights to distribute the result (or even perform the procedure) may be (and I'm really feel that are) bounded by Cygwin license. That is because your application will still refer to Cygwin (even though it is useless - but is still in your app)
Assume hello.exe is the name of your great application compiled under Cygwin in great project directory C:\xxx\yyy\zzz\
In the cygwin console go to C:\xxx\yyy\zzz and type
objdump -p hello.exe | grep "DLL Name"
You obtain all DLLs your application uses. Then copy C:\xxx\yyy\zzz to all DLLs listed and specific for cygwin.
Note that your application may invoke other applications (using exec function for example) --- find libraries aplications use and copy this libraries as well as this applications themselves -- to C:\xxx\yyy\zzz.
Maybe you will have to recompile your project with option of kind -L C:\xxx\yyy\zzz or so. Watch all other paths in your sources.
Thus your application becomes independent of Cygwin installation and you can present its functionality to/ share it with ---- other Windows users without Cygwin. But - once more I point and ask you - be aware of proper license and law of Cygwin creators and observe them!
My application is currently using SSCrypto.framework to decrypt a string encrypted with Blowfish. SSCrypto utilizes OpenSSL which is a new problem for me. Using the 10.6 base SDK while targeting 10.5 doesn't seem to work. The issue is explained in this Apple Mailing List thread: http://lists.apple.com/archives/Cocoa-dev/2009/Aug/msg01737.html
I have to use Blowfish or all copies currently in the field would stop working once they were updated (they rely on a previously stored Blowfish encrypted string which they have to be able to decrypt and verify).
OpenSSL has a very permissive license, so just link it into your app as a static library. You should then still be able to use the SSCrypto framework, or you can just call the OpenSSL libcrypto routines directly.
Step 1: Build openssl from source: Download OpenSSL
Step 2: Add a header search path to Xcode, pointing to the OpenSSL include directory for the source tree you built
Step 3: Link against libcrypto.a. Note: to prevent XCode from linking against the system's dynamic copy of libcryto, do NOT add libcrypto.a to your XCode project. If you do, that will add a -lcrypto to the linker command, and the linker will resolve that by looking for a dynamic library first (which it will find in /usr/lib - exactly what you don't want)
Instead, put the full path to the library in "Other Linker Flags"
Step 4: Build.
Blowfish is simple and common enough that you may be able to easily embed your own copy of the algorithm.