none
How to sign executable using API RRS feed

  • Question

  • I'm looking for any C# example on how to sign an executable from my .Net application using Crypto API (signtool is not an option here).


    Regards, Dmitry
    • Edited by Demchuk Monday, December 19, 2011 11:17 AM
    Monday, December 19, 2011 10:05 AM

Answers

All replies

  • Check below link for Crypto API Sample

    http://msdn.microsoft.com/en-us/library/ms867080.aspx

    Monday, December 19, 2011 7:28 PM
  • This article is about encryption, but I'm looking for code signing.
    Regards, Dmitry
    Monday, December 19, 2011 8:40 PM
  • If signtool is not an option (it was my first until I got to your comment) what are you trying to achieve that you would not get with signtool?
    Tuesday, December 20, 2011 12:45 AM
  • Simplifying, I am trying to achieve similar to what one see when installing SQL from MSDN subscription with pre-pidded license key. "Pre-pidded" = better user experience.

    There is a single file setup (.net bootstrapper + few MSIs) available for download in my web application to authenticated users. At some point before sending it to user browser, web app should modify it with user/account dependent data (like MSDN does for SQL). After this it should be signed on the fly. This signed exe can be saved locally and installed on multiple machines, being linked to the same account.

    Of course, I can run signtool on my "sign server" box, but running command line tool from WCF service looks... not appropriate... as long as I can call the same API that it calls.

     

    Possible solution is to use CAPICOM (http://www.vbforums.com/showthread.php?t=470607), but AFAIK it's obsolete and does not work in x64.

    Crypto API looks like the right one. However, coding my way through Crypto API seems to be a considerable effort. I'm looking for a working example to use as a starting point.


    Regards, Dmitry
    Tuesday, December 20, 2011 6:08 AM
  • Found something useful here: http://stackoverflow.com/questions/6357759/has-anyone-got-any-code-to-call-signersignex-from-c

    It does throw 0x80092006 at final step on me, however it's something to begin with.


    • Marked as answer by Demchuk Tuesday, December 20, 2011 10:00 AM
    • Edited by Demchuk Tuesday, December 20, 2011 11:03 AM
    Tuesday, December 20, 2011 10:00 AM
  • Of course, I can run signtool on my "sign server" box, but running command line tool from WCF service looks... not appropriate... as long as I can call the same API that it calls.

    personally if it gets the job done why waste time on an alternative that takes much longer to implement, needs to be maintained and produces a result no different to what you had before. Perhaps if I was "product-ising" the technique for other people then perhaps I'd consider wrapping it but... I'd rather be concentrating my efforts on tasks that are to do with the product itself and I have no easy solution.
    Tuesday, December 20, 2011 1:40 PM
  • maintenance... 
    Tuesday, December 20, 2011 1:41 PM
  • Of course, I can run signtool on my "sign server" box, but running command line tool from WCF service looks... not appropriate... as long as I can call the same API that it calls.

    personally if it gets the job done why waste time on an alternative that takes much longer to implement, needs to be maintained and produces a result no different to what you had before. Perhaps if I was "product-ising" the technique for other people then perhaps I'd consider wrapping it but... I'd rather be concentrating my efforts on tasks that are to do with the product itself and I have no easy solution.


    It depends. For "quick and dirty" or "good to best" kind of project it's probably wrong to waste time on neat solutions :)

    Both options require maintenance, and I'd rather have my application to call API then run external process unless I'm short in resources (which means bad planning or luck). I do take "alternatives that take longer to implement" (e.g. applicable pattens, unit testing, peer reviews, calling proper APIs), and it pays in a long run with stable and scalable systems running in production.

    Anyway, this one is my current pet project, and I do these "right" end-to-end to the best of my knowledge of "right". Surprisingly, great amount of my experience that I apply at work comes from this kind of projects.


    Regards, Dmitry
    Tuesday, December 20, 2011 3:14 PM