Archives March 2018

NSIS ReadCustomerData without invalidating SignTool Digital Signature

Introduction

Are you using NSIS (Nullsoft Scriptable Install System) to create Windows Installer executables? Do you send custom versions of your .exe installer file to each user (e.g. embedded user token or username/password)? Would you like to have NSIS build one master installer file and easily embed the user data into the installer without having to rebuild or resign the installer? Then this article is for you!

I will demonstrate how to implement the NSIS ReadCustomerData function to customize your master installer file for each user.

I will share my custom version of the AppendPayload program originally written by Aymeric Barthe and shared in his blog post Changing a Signed Executable Without Altering Windows Digital Signature. I will also demonstrate Linux and macOS (OSX) compilation/usage.

Our users can login to our website to download a custom installer that includes their account details. The Linux program reads the original signed NSIS installer, reads a data file that contains the user data, and writes a new installer file with the embedded customer data. Windows recognizes the original digital signature since we are just adding arbitrary data and did not modify the code.

Background

We provide a Windows application for our users. When I researched moving this particular Windows application to NSIS, I was very interested in the NSIS ReadCustomerData function that read arbitrary data appended to the end of the executable (.exe) file. This would allow us to customize our signed installer file with user data (e.g. user token or username/password) without generating and signing a separate installer for each user.

NSIS ReadCustomerData

The NSIS ReadCustomerData documentation was a little slim, so I will discuss a few nontrivial steps.

  • Decide which “ReadCustomerData” function you will use. Both functions should provide the same results, though the second function seems faster. Save the function to a file named “ReadCustomerData.nsi”.
  • Add the following code near the top of your primary .nsi file to import the function you saved in the previous step.
; Include ReadCustomerData function
!include ReadCustomerData.nsi
  • Add the following code to your main Section to verify that you can (or cannot) read your custom data.
; Read Customer Data (e.g. "username;password")
Push "CUSTDATA:"
Call ReadCustomerData
Pop $1
StrCmp $1 "" 0 +3
MessageBox MB_OK "No data found"
Abort
MessageBox MB_OK "Customer data: [$1]"
  • Create (and sign, if applicable) your NSIS installer executable file.

Now you are ready to append data to the end of your installer! When you run your installer, it will display a message box that says “No data found”. Continue reading to learn how to add a custom payload.

If you have a complex payload with multiple values, I highly recommend that you go back to the NSIS ReadCustomerData function page and use their functions to parse the data.

Embed User Data Method #1 – INVALID DIGITAL SIGNATURE

I initially attempted the following method as discussed in this Stack Overflow article. While NSIS does seem to be able to read the custom user data appended to the end of the .exe file using this method, Windows 10 no longer recognizes the digital signature of the NSIS installer file.

REM DO NOT USE THIS METHOD IF YOU SIGNED YOUR EXECUTABLE!
copy setup.exe user123.exe
echo "USERDATA:username;password" >> user123.exe

To clarify, the Digital Signature tab on the file properties page is no longer present when data is appended to a signed executable in this way. Windows 10 does not throw an error warning that the signature is invalid. Rather, Windows treats the executable as unsigned.

Embed User Data Method #2 – VALID DIGITAL SIGNATURE

I was able to successfully embed custom user data into the signed NSIS installer .exe file by using the method described in Aymeric Barthe‘s blog post Changing a Signed Executable Without Altering Windows Digital Signature.

We compile and sign our installers on Windows, but we would like to customize and distribute the installer from our Linux servers (e.g. generate custom installer on the fly when requested by user). I was able to make a few minor changes to Aymeric’s code so that it would compile and run correctly on Linux and macOS (OSX).

Download my port to Linux/macOS in my “Signed NSIS exe Append Payload” GitHub repository.

How to Stream User Group Meetings to YouTube

Would you like to learn how User Groups in Springfield Missouri are LIVE streaming our meetings to YouTube? You’ve come to the right place! Several similar streaming configurations are being used locally…

Springfield Web Devs (YouTube), Springfield .NET, Springfield Python, Springfield Women in Technology

Myke Bates (The Alchemedia Project, Eagle Speak) pioneered this original setup that is used by multiple groups. Jason Arend designed the original template for Web Devs and adapted the graphics for each group.

Springfield Amazon Web Services (YouTube)

Jason Klein (Logic Forte) adapted Myke’s setup above to broadcast SGF AWS meetings.


Initial Setup

I will describe my experience setting up OSB for use with live streaming of the SGF AWS meetings. This should be similar to Myke’s experience. My MacBook Pro (Quad i7 2.2Ghz) uses about 9% CPU while streaming with the following settings.

  1. Connect your devices (webcam, microphone, and HDMI capture) to your computer. Install device drivers if necessary.
  2. Create a YouTube Channel
    1. Tip: Be sure to create your channel under a “Brand” account so you can assign multiple people access to manage and stream to the channel. You create a “Brand” account while logged into your existing Google account. A “Brand” account does NOT have a separate username/password.
    2. Configure Live Streaming and setup your Live Streaming keys
    3. Tip: If you are streaming 720p, you can usually enable the low delay option in YouTube live stream buffer settings. This allows remote viewers to see audio/video of the presentation and submit questions in near real time (e.g. 15-30 second delay). If you are streaming 1080p or 4k, you need to make sure you have fast and consistent upstream bandwidth to support this option. The standard buffer setting seems to delay audio/video around 40-60 seconds.
  3. Install and Configure OSB
    1. General Configuration
      1. Automatically Record When Streaming (YES)
      2. Keep Recording when Streaming Stops (NO)
    2. Configure Streaming
      1. Type: Streaming Services
      2. Service: YouTube / YouTube Gaming
      3. Server: Primary YouTube Ingest Server
      4. Stream Key: (configure in YouTube)
    3. Configure Output
      1. Mode: Simple
      2. Video Bitrate: 2500
      3. Encoder: Software x264
      4. Audo Bitrate: 160
      5. Recording Quality: Same as Stream — Recommended on laptops and other low power computers. You can choose higher option if your computer has enough CPU to handle it.
      6. Recording Format: FLV
    4. Video Output
      1. Base Canvas Resolution: 1920×1080
      2. Output Scaled Resolution: 1280×720
      3. Downscale Filter: Bicubic
      4. Common FPS Values: 30
  4. Setup Scenes in OSB — You switch to different scenes during your meeting to control how inputs are used/streamed. Contact Jason Arend or Jason Klein for current templates.
    1. Opening Scene — Usually a backdrop with User Group logo, NO audio, NO video
      1. Color Source: Solid Background Color
      2. Image: User Group Logo
      3. Text: User Group Name, Meeting Title, Meeting Date, Other Info
    2. Large Webcam with Small Capture — Great for beginning/end of presentation. Resize the HDMI Capture so that it appears in the lower righthand corner of the screen.
      1. Audio: Blue Snowball
      2. Video Capture Device: Logitech Webcam
      3. Video Capture Device: Elgato or Magwell HDMI
      4. Color Source: Solid Background Color
      5. Image: User Group Logo
      6. Text: User Group Name, Meeting Title, Meeting Date, Other Info
    3. Large Capture with Small Webcam — Great for majority of presentation. Resize the Webcam so that it appears in the lower righthand corner of the screen.
      1. Audio: Blue Snowball
      2. Video Capture Device: Logitech Webcam
      3. Video Capture Device: Elgato or Magwell HDMI
      4. Color Source: Solid Background Color
      5. Image: User Group Logo
      6. Text: User Group Name, Meeting Title, Meeting Date, Other Info
    4. Closing Scene
      1. Color Source: Solid Background Color
      2. Image: User Group Logo
      3. Text: User Group Name, Meeting Title, Meeting Date, Other Info

Streaming During Meeting

  1. Anytime prior to meeting:
    1. Update text in any scenes that display Meeting Title, Meeting Date, or other meeting specifics.
  2. After setup at meeting, but before you start your live stream:
    1. Confirm Webcam and HDMI captures are appearing correctly. Click on each stream and verify webcam or HDMI capture video is present. If OSB shows a black/blank area for either device, double-click on the source and make sure the correct USB device is chosen from dropdown menu. This is a common issue if you plug a USB device into a different port and the OS configures the device as a new device (e.g. Logitech Webcam #2)
    2. Perform a live streaming sound check. Start on your opening scene, begin broadcast, and talk while switching to your other scenes and finally switch to closing scene. Watch/listen to your very short (10-15 second) test stream on YouTube and make sure there is NO audio during opening/closing scenes. Make sure audio level is reasonable during your presentation scenes. If audio sounds strange or has an echo, make sure you are not capturing audio from Blue Snowball microphone AND internal laptop microphone at the same time. If no audio, double click on the source and make sure correct USB device is selected in the dropdown list. Delete sound check recording.
  3. Several minutes before meeting begins:
    1. Select your Opening Scene (e.g. background w/ logo, meeting details, start time, no audio)
    2. Start Streaming
    3. Go to YouTube and confirm:
      1. Stream appears in correct channel
      2. Stream is public
      3. Stream details are correct (e.g. title, description)
    4. Copy YouTube live stream URL and announce live stream with URL on Slack, Meetup, Facebook, etc.
  4. During meeting:
    1. If you only use one scene, change to that scene. No other interaction required during meeting.
    2. If you use multiple scenes, have someone who can switch between scenes as appropriate during meeting (e.g. large video of webcam w/ small video of presentation, large video of presentation, small video of webcam). They can use up/down arrow keys to switch between two scenes or they can use mouse/trackpad to click on different scenes.
  5. Immediately after meeting:
    1. Change to Closing Scene (e.g. background w/ logo, meeting details, speaker contact info, where to find more details, no audio)
    2. Wait 30 seconds or so
    3. Click Stop Streaming (and Stop Recording)
  6. Anytime after meeting:
    1. Go to YouTube and edit recording
      1. Review meeting details. Add meeting outline to description if available.
      2. Trim opening scene and closing scene so that only a few second appear before/after actual presentation.
      3. Save changes.
      4. (This final step can be done anytime after meeting. Sooner is better than later though.)

Background

Our local User Groups have been working to find an inexpensive way to live stream meetings for several years. We have experimented with a variety of video configurations (Mevo, Mevo Plus, Periscope on iPad, Facebook Live on iPad, etc) coupled with a variety of audio configurations (built-in, venue sound systems w/ XLR adapters, iRig microphones, etc). We considered several different screen capture software packages that we could use to capture each presentation.

Myke found the Elgato Capture device and OSB combination allowed them to capture any presentation in real time. Be aware that the Elgato is listed as macOS compatible, but is NOT compatible with OSB on macOS, so you MUST use OSB on Windows with this device. I went with the Magwell device (for $200 more) instead of buying a Windows laptop. Both capture devices are completely passthrough and transparent to the presenter’s computer. When they connect their HDMI cable to the capture device, their computer believes it is connecting directly to the projector. Myke and I had great luck using both the Elgato and Magwell devices to capture HDMI from various laptops and forward the HDMI signal to various projectors.

Code Signing errors when Dual Signing SHA-1 and SHA-256 for Legacy Systems including Windows XP SP3

PROBLEM: Unable to validate Digital Signature on Windows XP SP3

I recently encountered the following errors when attempting to validate the Digital Signatures for our application on Windows XP SP3:

Digital Code Signature (Right-click application > Properties > Digital Signatures > Details)

Digital Signature Information
The certificate is not valid for the requested usage.

Certificate Information
This certificate does not appear to be valid for the selected purpose.

Receiving these same errors? If your code signing certificate was issued in the past 24 hours, you might just need to wait a day before Windows XP SP3 can validate the signature. See solution #2 at the end of this article for details.

I was attempting to use the following widely-accepted signtool.exe commands to perform Dual Code Signing (SHA-1 and SHA-2/SHA-256 file digest algorithms) of an Executable for use with current systems (e.g. Windows 7, Windows 8, Windows 10) as well as legacy systems (Windows XP SP3, Windows Vista).

Note: As of 03/2018, every one of these OS should accept a “User Mode” executable (e.g. application or service) that is signed with an SHA-1 file digest algorithm. We would like to dual sign to “future proof” our executables since we anticipate that some of these OS will eventually require an SHA-256 file digest algorithm.

signtool.exe sign /f comodo256.pfx /p password /t http://timestamp.comodoca.com /v app.exe
signtool.exe sign /f comodo256.pfx /p password /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /as /v app.exe

We are using our new Comodo SHA-256 code signing certificate with the COMODO SHA-1 Time Stamping server and the COMODO SHA-256 Time Stamping server.

The first command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-1 file digest and a timestamp counter-signature with an RSA SHA-1 file digest. *

The second command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-256 file digest and a timestamp counter-signature with an RSA SHA-256 file digest.

* Contrary to code signing documentation on several certificate authority websites, we have found that XP SP3 *CAN* validate a digital signature when signed with an RSA SHA-256 code signing certificate, as long as the actual signature uses an RSA SHA-1 file digest algorithm.

TROUBLESHOOTING NOTES

I attempted several variations of the signtool.exe commands above. I also attempted using the ZIP bundle of “signtool.exe” version 8.1 distributed by K-Software as well as the “kSign” software created by K-Software to dual sign several executables. I continued to receive the exact same errors, which led me to believe there may be a problem with my certificate, or it was no longer possible to dual sign for XP SP3.

While researching these two digital signature validation errors on Windows XP SP3, I could find no mention of the errors I encountered above related to code signing on legacy systems. In addition, the discussion surrounding SHA-1 vs SHA-256 and the Microsoft announcement to no longer support code signing with SHA-1 made it difficult to determine if it was still possible to dual sign executables with support for legacy systems that require SHA-1.

Through trial and error, I realized that Microsoft no longer allows digital signatures based on RSA SHA-1 digital certificates, but every OS from Windows XP SP3 to Windows 10 continue to support “User Mode” executable (e.g. application or service) that are signed with an RSA SHA-1 file digest algorithm. This Windows Code Signing Hash Algorithm Support article from GlobalSign has a nice chart that supports these findings. The distinction here is that the digital certificate is used to sign all of your applications, whereas the file digest algorithm is the format of the file hash output that is embedded in the executable. I suppose it may be worthwhile for someone to forge a certificate (that could sign many applications), but it would not be as likely or worthwhile for someone to forge an individual signature.

SOLUTION #1: Dual Sign with “osslsigncode” on Linux/OSX instead of “signtool.exe” on Windows

Thanks to a response from @Keeely in the thread signtool failing to dual sign SHA2 and SHA1 with timestamps, I was able to use our Comodo SHA-256 code signing certificate to dual sign an application that validates correctly on Windows XP SP3. I adapted his SHA1-only solution to successfully dual sign with SHA-1 and SHA-2/SHA-256.

Digital Code Signature (Right-click application > Properties > Digital Signatures > Details)

This digital signature is OK
This certificate is intended for the following purpose(s):
Ensures software came from software publisher
Protects software from alteration after publication

Digital Timestamp Counter-Signature

This digital signature is OK
This certificate is intended for the following purpose(s):
Allows data to be signed with the current time

I had to install osslsigncode, which is designed for Linux and also available on OSX. A fork also appears to be available for Windows.

osslsigncode sign -pkcs12 comodo256.pfx -pass password -h sha1 -t http://timestamp.comodoca.com -in unsigned.exe -out intermediate.exe
osslsigncode sign -pkcs12 comodo256.pfx -pass password -nest -h sha256 -ts http://timestamp.comodoca.com/?td=sha256 -in intermediate.exe -out signed.exe

The first command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-1 file digest and a timestamp counter-signature with an RSA SHA-1 file digest into a new file named “intermediate.exe”, which you would delete afterwards.

The second command uses our RSA SHA-256 code signing certificate to embed a digital signature with an RSA SHA-256 file digest and a timestamp counter-signature with an RSA SHA-256 file digest into a new file named “signed.exe”, which you would distribute to your end users.

SOLUTION #2 – Dual Sign with native Windows tools?

Wait several days?

The certificate was issued on a Friday morning. I was attempting to sign executables with our new certificate that same day. When I revisited this issue on Monday, I realized that XP SP3 was suddenly able to validate the previous signatures that were applied with the “signtool.exe” commands listed above.