Pentesting Electron Applications

I recently came across my first Electron application as a target. As is the case I try and take notes as I go and here they are so that I am ready for the next time.

When you are targeting an “app” (various thick client or mobile application targets) I always want to:

  • Decompile it if possible – to enable source code review
  • Modify and recompile if possible – to enable me to add additional debugging to code or circumvent any client side controls.
  • Configure middling of communication channels – to enable testing of the server side API.

That is the general process for this kind of task and the blog post covers how to do all of these for Electron applications.

Extracting .asar Files on Windows

When going to the application’s folder I found that it had a “resources” directory containing a couple of “.asar” files. A quick google uncovered that this is a tar like archive format as per the link below:

This is similar to APKs in the Android app testing realm. To get serious we need to extract these to have a proper look.

First get NodeJs:

After installing this open a new command prompt and type “npm” to check that you have the Node Package Manager working right.

Then install “asar”

npm install --engine-strict asar

As a new user of npm I want to just marvel at the pretty colours for a second:

Oh NPM, you are gorgeous

Also an inbuilt check for vulnerabilities? NPM you are crushing it.. Just crushing it. So how come so many apps have outdated dependencies?

Turns out the above command – while gorgeous – did not stick the “asar” command into the windows path as intended. To do that I subsequently ran this command:

npm install -g asar

Then it was found the command in the path:

Oh asar, I found you, I never knew I needed you 10 minutes ago

I was unclear as to the operation of asar. Specifically, would this extract into the folder in a messy way? In the doubt I created a new folder “app” and copied my target “app.asar” file into that before extracting it:

mkdir app
copy app.asar app
asar e app.asar . 
del app.asar 

Note: that del is important because it stops you packing a massive file back into your modified version later.

I was glad I did copy the target into a folder because extraction did this:

Files Extracted to the Current Directory

Had I done the extraction a directory higher then the target application folder would have been messy.

With access to the source you can go looking for vulnerabilities in the code. I cannot really cover that for you since it will depend on your target.

Modifying the app

If you are half way serious about finding vulnerabilities you will need to modify that source and incorporate your changes when running the target. You need to modify the code and then re-pack the “app.asar” file back.

The best place to start is where the code begins its execution. That is in the “main.js” file within the “createWindow” function as shown:

Showing the createWindow function

I modified this to add a new debugging line as shown:

Added console.log debugging line

The point of this was to tell me that my modified version was running instead of the original. I started a command prompt in the “resources” folder and then executed these commands:

move app.asar app-original.asar
asar pack app app.asar

Note: that move command was about ensuring I have the original “app.asar” on tap if I needed to revert back to it. The pack command would otherwise overwrite the original file.

It turns out that “console.log” writes to stdout which means you can see the output if you run the target application from the command prompt. I prefer to create a .bat file for so that I can view stdout, and stderr easily in a temporary cmd window.

The contents of my bat file were:


The first line ran the target exe, and the second ensured that the cmd window would stay open in the event of the target being closed or crashing (until a key is pressed). I saved this in the folder with “target.exe” and called it “run.bat”. Instead of clicking on the exe I just double clicked on run.bat and got access to all of the debugging output.

Much success the first line of output when I load the application was now:

[*] Injecting in here

You can now see if there are any client side controls you can disable.

Allow Burp Suite to proxy the application

You will want to be able to see the HTTP/HTTPS requests issued by your target application. To do that you need to add an electron command line argument. If we look again at the “createWindow” function you can see two examples already:

This image has an empty alt attribute; its file name is image-9.png
createWindow function showing commandLine.appendSwitch

At line number 58 I added this switch which configured localhost port 8080 as the HTTP and HTTPS proxy:'proxy-server', '');

Again I had to pack the app folder into app.asar as shown in the previous section.

Electron loads chromium and therefore you will need to install burp’s CA certificate as per this URL:

Once you have done that you should see all the juicy HTTP/HTTPS traffic going into burp.

Congratulations you can now go after the server side requests.

I have covered extracting the Electron application to let you see the code, how to modify the code, and how to middle the traffic. That is more than enough to get going with.

Happy hunting

Retiring old vulns

There I was finding a lovely Cross Site Scripting (XSS) vulnerability in a customer site today. Complete beauty in the HTTP 404 response via the folder/script name. So I started to write that up.

I peered at the passive results from Burp Suite and noticed a distinct lack of a vulnerability I was expecting to see:

I looked at the HTTP headers and saw this peering back at me:

X-XSS-Protection: 1; mode=block

Burp was correct not to raise that issue because it detects where that very header is insecurely set or non existent.

For the uninitiated the “X-XSS-Protection” header is supposed to tell web browsers to inspect content from the HTTP request which is then present in the immediate response. It had a laudable goal to make reflected XSS a thing of the past, or at least harder to exploit.

Chrome liked it so much it defaulted to having it enabled. Even if the server didn’t bother setting it. This caused much consternation.

Stawp making the world safer Google… Jeez!

I thought ah this is my testing browser (Firefox) I must have overridden the XSS filter.

  • So I try in Chrome.. *pop pop*.
  • So I try in Edge.. *pop pop*.

I think I google “Is X-XSS-Protection still a thing?” and stumble across this nugget:


No. It is not a thing. Has not been a thing for a little while.

The modern approach is to ensure that you use robust Content-Security-Policy settings. The radical approach is to prevent XSS by secure coding practices which will just never ever catch on.

Security tools and scanners including: nikto, burp suite, and nessus all still pull this header out as something to be reported on. Does it have any real relevance if user-agents simply ignore it now?

It may impact older browsers. But generally when you are talking about any web browser that is old. There will be some way to completely control the victim’s computer. Logically you should only concern yourself with where the herd is running at today.

My approach is to take this out the back to put it out of its misery with a few rounds through the head(er). Then I will stuff it and mount it onto my wall next to “Password Field with autocomplete enabled”. Which is itself deprecated based on browsers also choosing to ignore it.

Time rolls on and standards change. Lets have a round of applause for good old “X-XSS-Protection”. It has been a good sport. A brilliant contender but sadly it never truly saw its potential realised because Arsenal kept buying replacement wingers. It never got any game time.

Dodgy Link: Hiding the URL

It is very rare that I do Phishing campaigns (dang it I should ask to do more as they are interesting).  I do have to answer customer questions, and talk about security awareness training often though.

I have heard people saying that “just hover your mouse over a suspicious link and it shows you where it is going!”. Generally this is a good feature of web browsers. However, it is definitely not to be relied on as shown in the video below:

With a tiny bit of JavaScript you can defeat that particular part of someone’s security awareness training. The source code is available below:

<a id="hey" href=""
>Totally Legit</a>

Quite simple:

  1. When the mouse goes over the link the “onmouseover” event handler executes. This changes the URL to “; so that is what the Web Browser shows to the user at the bottom.
  2. If the user actually clicks on the link the “onclick” event is triggered which replaces the URL with whatever we are actually wanting our victim to interact with.

Nothing new. Nothing earth shattering. I needed to document it as I have forgotten how to do this a few times but now it is written down forever. Hope it is useful.

Standing Out: a Workshop for Wannabe Pentesters

I asked Twitter for questions to help me find topics people were interested in. The first response was very simple:

To me this boils down to the question “What can I do to make my CV or application stand out from the hordes of others?”. When I say “hordes” I literally mean it. I personally get approached a lot either via LinkedIn or email from candidates.

To deal with that question I have broken it down into three sections:

  1. Sharpen your CV
  2. Your online Content
  3. Your offline presentation

I will make sub-sections for each of these and if you feel that you have one of these nailed skip over it.

Sharpen your CV

Your CV is the gateway to your soul. Often it may be all that the company you are applying to is going to see. For the first step follow this process:

  1. Keep it exactly two pages long. No more. I have heard of hiring managers throwing anything longer on the pile of rejects before they go home and sleep like a baby. Harsh, but nobody said reality was going to be easy.
  2. Write it yourself. If your university has provided a template then you might find that the company has seen your CV many many times before. Familiarity with the format will not make it stand out. You do not have to go insane design wise but making it a bit unique is a good idea. Your CV is a chance to prove you can write in English and sell yourself. If you can do that, then you may be able to sell a vulnerability report to a customer. Genuinely write it yourself and resist temptation to pay someone to write it for you.
  3. Contact Details. Display clearly your contact details with your mobile number and address etc. I have had a few cases where I couldn’t call back, which doesn’t help. In mine I think I made it the header of the page so it is not eating up the real estate on the page but appears at the top of both pages.
  4. Link to online content. The next section contains how to fix your online content. Make sure that your CV links to that content appropriately. If you identify an organisation that blogs regularly about a thing that you have too then highlight that etc. If your research interests and theirs align you will find a willing buyer.

The general idea here is to make something that is the right length, ensure your key information is there, and that YOU wrote it.

Now I do not know how many of you are as hilarious as me? But I also end every CV I write with something outlandish under my interests as a reward to the reader getting that far.

I remember sauntering up to the MD of Pentest Ltd just as he got to the end of my CV when I was heading to meet him. He was still chuckling as I shook his hand. #nailedit. You might not get to an in person interview like that as the first step until you are rocking out as a senior like I was at that point in my career.

Pro-Tip: If you bump into me in person you can ask about my various CV jokes over the years but I won’t go into it here. Otherwise you will probably all just try and emulate those exact things.

Your online Content

There are so many places that you can put things online for your “work” self. A personal blog (like mine here!), LinkedIn, Twitter, GitHub etc. This can all be evidence of your activities that are relevant to penetration testing or IT in general.

Here are somethings I look for which I presume is what other hiring managers want:

  1. Actively exploring technology. If your blog is all about gadgets you have bought and stuff that was done just to play or learn with it. Then you may have the right mindset.
  2. Attending events. If your Twitter feed is a bunch of photos of you rolling around various Cyber Security events then we think you are definitely keen and trying to network in person.
  3. Speaking at events. If you are speaking at things like your local Defcon, OWASP or whatever then you are even more involved. Spreading knowledge to others is very much the mindset. Being able to talk to a room is also a tick in a box for consultancy skills. But speaking to rooms is not for everyone so it is not a REQUIRED skill.
  4. Coding ability. I am of the opinion that coding helps to make a great tester. Relatively recently I started posting stuff on So now I look for people who do the same. You do not have to invent something that has hitherto not existed in the world. Someone who has sat making their own port scanner will have learned a lot. You do not need to shoot for unique. Implementing your own version of a thing is also a valuable exercise.

Try and separate your work and personal self in your online presence. Keep the photos of food to Facebook and Instagram or whatever mostly (I will break this myself deal with it!). Then keep your online career “self” focused and to the point. That means categories on your blog or using a different blog entirely for other things.

What am I looking for here? Well… The appearance you are active. By reading some technical blog posts I can see more about how you write. Remember a pentester has to document findings to customers. So I want to know that you can write. Via GitHub I can see what tools you have made or what problems you have solved. Knowing someone has familiarity with programming is a good idea.

A final word on your online presence. Put a clear picture of your face. I won’t win any beauty contests. But I put my face on things so that when people meet me in person they can recognise me. Yes there are hackers who will post Chinese characters, or ninja’s or whatever to make themselves anonymous. That is very cool and “op seccy” of you. But take a moment to realise you are applying for a career in the white-box and not the black-box. If you want to go break the law for a living I don’t know where you apply but start at the docks at midnight maybe?

By not putting a photograph, what you may be losing a chance for consistency. I have just completed a recruitment tour and have spoken to around 700 or so people in a month. Sometimes I have met people at multiple events. The faces are now vaguely familiar but try to keep that many names in your head? When someone follows me on Twitter after an event it is easier to try and clash whatever hilarious handle they have to the person if I can recognise them.

Pro-Tip: a clear picture of your face only really. Try not to be “the one in the middle of three folks” or something like that 🙂

If you are represented by a string of binary in green on black in real-life then I promise to try and remember you.

Your offline presentation

By this I mean when you appear in front of a company say at an event. This time you are showing your face and you may have only short time to talk. In that case come prepared. Some people have been handing me business cards in return for mine. That means I can then go and put their name in a spreadsheet for the event and look to see if they actually apply later. So that is a nice touch which I am now recommending.

I didn’t believe in business cards when I was told in 2004 how to get a job by my university. I was like calm down caveman, I’ll just wow them with my personality. Now I have considered what the other side of that coin looks like I say a business card may genuinely help! I have a stack of them now from Securi-tay 2017 ready to get added to a list.

Also you are more likely to remember the companies representative than they are of you. IF you have met them before, re-iterate your name, and where that was when shaking hands. This should tick some boxes in their mind and get you straight onto the “my aren’t they keen” list!

We are fortunate to operate in a hacker style industry. Nobody expects you to wear a suit to these events. So you get a chance to wear some kind of awesome t-shirt or hoodie which may spark a conversation. Your goal at IRL meetings is to literally try and stick in someone’s head for a bit.

Some people do this by trying to ask difficult questions of their prey. Mileage may vary on that one. I love a challenge, but maybe someone else won’t. It is a potential route to making yourself stand out.

There you have it folks. My thoughts on how to “stand out” when applying for a penetration testing career.