Soda PDF Reader SSL Pinning Bypass

Bypassing the SSL Pinning implementation used in the software Soda PDF.

In this post I will be talking about a trivial SSL Pinning Bypass I found against LuLu Software Soda PDF Reader and outline the steps I took and how you may follow the same methodology to bypass SSL Pinning against other Desktop and Thick Client applications.

SSL Pinning

SSL Pinning/SSL Certificate Pinning is a method for preventing Man in the Middle attacks against an applications secure network communications. By taking record of a hosts public key the application can verify that it is talking securely to the host, since it verifies the public certificate provided by the host with the one the application already knows about. This pins the certificate and if an attempt is made to intercept this communication by spoofing the host, the application will detect this due to there being a mismatch between the certificate the application knows about and the certificate being provided by the spoofed host.

SLL Pinning is used in a large amount of applications, desktop applications, thick client applications and mobile applications are the most common however it is not limited to just these instances.

You can find out more information about SSL Pinning here.

Why Bypass SLL Pinning?

Often whilst pen testing a mobile application is is important to intercept the communication between the application and server it is using. However, because of the nature of these communications they are often encrypted and pinned to prevent an attacker easily performing MitM attacks. As a pen tester this can make it difficult and you would have to find a way arround these protections. Once bypassed the pen tester has a much more transparent view of the application and can perform a more in depth test.

The techniques used can be mirrored into a different context and in this case I wanted to look at the Soda PDF reader and any issues that might be present in the application. By bypassing the SSL pinning mechanism I would be able to have a more transparent view of the application and also test input to the application that comes from a server response and therefore may lack the same sanitization as user supplied input. It may also be possible to extend the applications free trial by spoofing the server responses and tricking the application into thinking that the 7 Day Free Trial is still going ahead even though the time has expired.

The possibilities are endless.

Firing up the application

The first stage was to simply fire up the application and gain an idea of the program functionality. Running Soda PDF I was greeted with a user registration form allowing you to either log into the application or register an account. This immediately highlights that the application may be speaking to a backend for authentication purposes.

Sodapdf Authentication

Once registered and logged in I could access the application.

Sodapdf after Authentication

At this point it would be possible to explore the different functionality of the application and test for particular vulnerabiltites when the user can supply input through a number of different methods. Initialy, however, having seen that the application may be speaking to a backend I wanted to see if it was possible to view, intercept and modify the communication between the desktop application and the backend.

Proc Mon

The next stage in my proccess was to explore what the application was doing behind the scenes. This involves seeing what proccesses, executables and services that are running, the permisions they have and if anything interesting sticks out. In order to do this I would first have to create some filters so that the only information I got in Procmon was that of the application itself and associated binaries.

Using task manager I was able to discover two running executables and three services. The executables and running privileges can be seen bellow.

Table of executables

Despite being very limited this information provides some interesting insight, specifically that the activation service (presumably monitoring the time left on the free trial) is running as system. This is interesting because if there happens to be a weakness in the executable there may be scope for elavation of privileges (EOP).

However, now I knew the executables that were running I could add these as filters to Procmon and therefore only see actions that were associated with these two executables.

Procmon Filters

Upon restarting the application and looking at the events in Procmon, as you can imagine, thousands of events were created.

Procmon Events

Since I was wanting to veiw the network traffic I first stripped the Procmon results to only show network traffic.

Procmon Network Events

This revealed that the application was definitely talking to a backend and the network traffic was encrypted (HTTPS). Closer inspection shows that the requests from both the activation service and the soda executable were being made to the IP address

This IP address is actually a Cloudflare IP address therefore indicating that whatever domain the application is connecting too sits behind cloudflare. This also makes it difficult to run a reverse DNS against the IP to determine the domain/domains the application is connecting too.


A solution to find the domains the application was connecting too was actually relatively simple. At some point the application must be doing a DNS lookup if it was making a HTTPS request. Luckily it appeared that this application was also not using the system cache therefore was making these DNS requests everytime the application would run.

To find out the domains I simply used the following filter in Wiresark which would make obvious what TCP connections were being made to the cloudflare IP and the preliminary DNS request made.

(ip.dst == && tcp) || dns

Some of the output can be seen bellow.

Wireshark Capture

Here it is obvious that the desktop app is communicating using TLS however from the wireshark capture we are now able to identify three domains that the application is try to connect to.


It is important we know the domains the app is connecting to so that we can perform invisible proxying of the application.

Invisible Proxying

At this point we can try and intercept the traffic.

For the the sake of this blog post I was pressuming the application, specifically the activation service that the research was focusing on is a non-proxy-aware app therefore in order to proxy the application I am going to be using Burp Suites invisible proxy.

Invisible proxying is a simple concept made extremely easy when using Burp Suite. By adding the domains that get resolved by the application to the systems hosts file we can set them to resolve to a proxy running on the local system. This proxy can then forward/mirror any requests to the intended target and intercept the response. Therefore allowing a non-proxy-aware client to have its network traffic proxied. The below diagram explains this proccess in 4 easy steps.

Invisible Proxy

Setting up the proxy settings in Burp is very straight forward.

  1. Navigate to Proxy -> Options -> Proxy Listeners -> Add
  2. Here we want to bind to port 443 since we are intercepting encrypted traffic.
  3. Be sure to listen on the loopback only
  4. Navigate to Request handling
  5. Add the IP address to forward the request onto, in this case
  6. Select the option Support invisble proxying
  7. Click OK

Burp Suite Invisible Proxy Settings

It really is that simple to set up an invisble proxy for non-proxy-aware applications. The same technique can be used for proxying non-proxy-aware mobile applications and also Thick clients. Further information about Burp Suites invisible proxy can be found Here.

Therefore I added the subdomains collected earlier to my hosts file and configured Burp correctly.

Hosts file

Initial Testing

Now the proxy is set up it was time to test if it was simply a case of intercepting the encrypted communications as the application was not checking the certifcate provided. If it didn’t have a strict policy then it may be possible to intercept the encrypted communications without needing any extra steps.

Now running the application if the interception is succesful we would either see the requests in Burps history tab or we would recieve an error.

Burp Certificate Errors

Unfortunately, in this test we recieved certficate errors in Burp revealing that the client was in fact pinning its certifcate. This was followed by an error in the application itself showing that it was not able to connect to its backend.

Sodapdf Error

At this point some applications may be using the local machines certifcate store. Therefore opening MMC.msc I added the Burp certificate to the certifcate store and ran the application again. Unfortunately this time it also gave a similar error indicating that the application was responsible for pinning all of its own certificates and was not trusting those on the local system.

Bypassing the SSL Pinning

At this point it was time to revist Procmon and see if there was anything interesting that may be of assistance and offer a method for bypassing the certificate pinning.

Fortunately I had previously seen a file that I thought might be extremely useful. Certificate Bundle File

Both the soda.exe and activation-services.exe were making multiple reads to the file C:\Program Files\Soda PDF Desktop 12\curl-ca-bundle.crt.

This file was a bundle of certificate authorities root certifcates. I thought that potentially the application was using this to verify the authenticity of certifcates and encryption being used in its network communications. Not only did the contents of the file suggest this but the name of the file beggining with curl-* indicated that the application may have been using curl to make the requests and using this to verify the certifcate chain created when making a request to *

A snippet of the bundle file can be seen below.

## Bundle of CA Root Certificates
## Certificate data from Mozilla as of: Wed Jan 23 04:12:09 2019 GMT
[... SNIP ...]
## Conversion done with version 1.27.
## SHA256: 18372117493b5b7ec006c31d966143fc95a9464a2b5f8d5188e23c5557b2292d

GlobalSign Root CA
[... SNIP ...]

Therefore in order to bypass the SSL Pinning implementation all I needed to do was add the Burp CA certificate into this file and I would be able to trick the application into trusting the certificate chain.

Converting the .der file produced by visiting http://burp in your browser (configured pointing at the Burp proxy) I was able to simply copy and paste the certificate onto the end of the file curl-ca-bundle.crt.

Burp Root CA

Testing the Bypass

Finally, now the Burp CA certificate is added to the certificate bundle that the application is using to verify the certificate chain I should be able to intercept its communications.

Running the application and checking the Burp history I was able to view the commuication between the desktop application and its backend.


I could now intercept, modify and manipulate the requests made by the application proving I had successfully bypassed the SSL Pinning implementation.

More Success

Responsible Disclosure

I had no issues disclosing this issue and the proccess was quick and responsive, however, after multiple times asking for permision to post this blog post and being told that someone would get back to me I have heard nothing and since the 90 day disclosure period is passed I see no reason not to share this educational content.


  • First Contact - 03/02/2021
  • Responsible Disclosure of Vulnerability details - 07/02/2021
  • Vulnerability Fixed - 16/02/2021
  • Public Disclosure - 23/05/2021


If you have any questions feel free to get in contact with me!

Thanks for reading.

Author: @su__charlie