Quest app.asar

Anyone who has developed the Electron client knows that under the build node of package.json, if "asar": true is set, the program files will be synthesized into an app.asar file when the software is packaged. After the software is installed, it can be found in the resources subdirectory of the installation directory.

// package.json
  "build": {
    ...
    "asar": true,
    ...
  }

app.asar appears to be a zip file (like .zip or .7z), somewhat mysterious. In fact, it is just a packaging format, which just stitches together files without any compression . Because a package contains multiple files, each file needs to be indexed. After adding these index information, the size of the .asar file actually exceeds the sum of the files. It's a little accident!

The format of .asar is not secret and it can be easily restored. Next, let’s walk through it with me (you can also go to https://github.com/electron/asar  for more details), in two steps:

1. Install the asar plugin globally:

npm install -g asar

2. Execute the extract command on the specified app.asar file , the format is:

asar extract "<源路径>\app.asar" “<目标路径>”

Take Figma, a common tool for UX designers, as an example (visit the website www.figma.com , register/login, click the user avatar in the upper right corner of the page, select "Get desktop app" in the drop-down menu, download and install it), execute the following command :

asar extract "<你电脑上的安装路径>\Figma\app-108.1.0\resources\app.asar" D:\Test1

We can unpack Figma's app.asar and release it to D:\Test1. Go to D:\Test1 to have a look again, what a surprise—a bunch of .js source files! And without any confusion, interested students can study their source code to their heart's content! Further verification: the app.asar file size is 1.55MB, and the size of all files under D:\Test1 is 3.55MB, what's going on? Didn't it mean that .asar doesn't do compression? That's right! Go back to the Figma installation directory, you will see an app.asar.unpacked directory, the files inside are exactly 2MB. When executing the asar extract command, it will actually copy the files in the app.asar.unpacked directory to D:\Test1. (Small episode: I stepped on a pit during the drill: because the installation path of app.asar is too deep, I first copied it to the D drive, but when I executed the asar extract command, an error was reported, saying that the app.asar could not be found. asar.unpacked directory, oh...I get it!)

Next, let's explore other Electron client software by the way. For example, in Microsoft Teams, after unpacking app.asar, we open its main program entry file main.bundle.js and see the following:

!function(e,t){for(var n in t)e[n]=t[n]}(exports,function(e){var t={};function n(i){if(t[i])return t[i].exports;var o=t[i]={i:i,l:!1,exports:{}};

The source code is obviously obfuscated and not friendly to humans, just give it up. Looking at GitHub Desktop again, the interesting thing is that there is no app.asar in its installation directory, and then open main.js, and found that the code is obfuscated similarly to Teams. Let’s look at a software called Lofelt Studio. After unpacking its app.asar, open main.js to see that the code is also obfuscated. Then open package.json to find that it is developed based on the React framework and compiled through webpack. The packaged .js file naturally has this effect. If you still have more ideas, https://www.electronjs.org/apps  There are more Electron Apps, maybe you can find treasures!

This article is coming to an end, I guess, you may still have a question in your mind: .asar neither encrypts nor compresses, so what is the value of it? That's right! Packaging with asar is not necessary, like GitHub Desktop does. And using asar to package, there are also some advantages to online transmission, for example: if some resource paths our program depends on are very deep, and there is a limit to the length of the resource path on Windows, if the path is too long, the loading will fail, use asar Packing can bypass this problem; in addition, loading a total .asar file when the program is running, compared with loading a bunch of scattered small files, can avoid frequent disk addressing, and there will be some gains in performance—I think , makes sense~