If you use PE Viewers, Editors, Dumpers for forensic purposes, you are most likely using them to extract a compilation timestamp from a binary – to determine when a specific file was compiled.

There is a little ‘gotcha’ here.

Some of these tools show the timestamps as UTC, some localize them to your timezone. This is far from ideal. Without being sure, you may be writing down incorrect information in your report.

We can fix it.

If you don’t know the algorithm your tool of choice is using to display the time you can quickly test it.

How?

As per the PE documentation, the Compilation timestamp is:

Date and time stamp value. The value is represented in the number of seconds that have elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock. The time stamp can be printed by using the C runtime (CRT) time function.’

So, there is no better way to test your fav. programs other than using atest executable with a timestamp set to 0, and observe the results (make sure you change your timezone to a different one from UTC!).

If the result is 1970-01-01 00:00:00 then your tool is using UTC. If it is different, then it’s a local time, and perhaps in some cases, it may be wrong (better test with two different tools). As such, you may even see compilation year 1969!

Quick test shows that:

• Die, IDA, Efd, PE Studio – use local time

and

• PE Bear, PPEE, VirusTotal – use UTC

After I published this post, Brian provided additional comment (thx!):

I would also take note of daylight saving time. Offset of UTC changes from your local time zone.

And here is the test .exe I used, in case you need it.

If you ever came across portable executables that include references to enigmatic modules called:

• krnln.fne
• krnln.fnr
• eAPI.fne
• RegEx.fnr

and many other libraries with a .fne, or .fnr file extensions, or perhaps found some of these files during a forensic exam, then this post is for you.

These executables are generated by so-called Easy Programming Language (EPL), a RAD, Visual Basic-like programming language and software development environment available from this Chinese company, and also available from this website. It’s not super popular, but it definitely has a following in China as programs are still being written in it. Including malware.

If you are in a hurry, you can download and play with the actual RAD v 4.01 from here or here.

When you install it, you will quickly notice that it populates c:\Program Files\EPL\lib folder with all these familiar libraries:

btdownload.fne, cncnv.fne, com.run, cominf.run, downlib.fne, dp1.fne, eAPI.fne, eCalc.fne, EChartBar.fne, eCompress.fne, EDataStructure.fne, eDB.fne, edroptarget.fne, eExcel2000.fne, eGrid.fne, eImgConverter.fne, EInterProcess.fne, eMMedia.fne, eNetIntercept.fne, ePPT2000.fne, ERawSock.fne, ESpeechEngine.fne, ESPI11.dll, ESSLayer.fne, EThread.fne, ewizard.fne, eWord2000.fne, EXMLParser.fne, Exmlrpc.fne, ExtMenu.fne, HtmlView.fne, iext.fne, iext.fnr, iext2.fne, iext3.fne, internet.fne, isapi.fne, Javalib.fne, krnln.fne, krnln.fnr, mp3.run, mysql.fne, ocx.run, odbcdb.run, OPenGL.fne, PhoneCortrol.fne, pop3.fne, portio.fne, RegEx.fne, script.fne, shell.fne, sock.fne, spec.fne, twain.fne, Warning.txt, WNet.fne, xplib.fne

Since the user interface is in English, we can easily load one of the samples provided with the framework e.g. Funny Ball Game:

We can then compile the game and run it:

Now that we compiled and ran the executable, we can look at the file itself.

While the framework requires you to register before you can build the standalone programs, it still provides a way to compile & test them. For the test purposes it provides a small stub executable that launches programs, and does so from a Temporary directory. The commercial version allows to package it all into one standalone .exe. It’s the ‘packaged’ version of .exe we will typically come across ‘in the wild’.

Looking at the stub .exe:

we can notice the following strings of interest:

• krnln.fne
• GetNewSock
• Software\FlySky\E\Install
• Not found the kernel library or the kernel library is invalid!
• Failed to allocate memory!
• / MADE BY E COMPILER – WUTAO

Looking at the PE file properties, we can see that the stub is pretty old:

• TimeDateStamp: 0x3925136B (GMT: Fri May 19 10:11:55 2000)

I am not sure if this timestamp is good enough for any identification as I don’t have enough samples. Plus, this is a stub used for testing. Still, it could be used to run actual E programs (you can find some on github and elsewhere).

The easiest way to identify the program compiled with EPL is to look at its sections:

The .ecode section name is very characteristic, and I have added it to my PE Section list; you may also come across .edata section; this, together with a list of strings, and modules listed earlier (and probably a few more than can be found online – one can create new ones) should be enough to ID the files (e.g. via Yara).

Since the file format is quite obscure, and programs’ dynamic analysis not well researched, many AV and sandbox vendors list some of the artifacts created by the EPL framework as malicious, just because it’s there, for instance this Registry key entry:

• HKCU\Software\FlySky\E\Install\Path

It actually points to a location where the clean libraries are; on a system where the development environment is installed it points to:

• C:\Program Files\EPL\lib\

In cases where the .exe is standalone, when the program is executed the libraries are automatically unpacked to a temporary folder e.g.:

• %Temp%\E_4
• %Temp%\E_N4

The registry entry will be then pointed to that directory. This is obviously a possible persistence mechanism, but its value is pretty low for today’s standard…

During the development phase programs are stored in files with a .e file extension. Some programmers distribute them in this form as well (again, that’s what you can find on github and elsewhere!).

Looking at a sample .e file and its top few bytes we can see a magic string ‘CNWTEPRG’:

References to a MainForm string, and top bytes (BM) of a of a bitmap (.bmp) file are clearly visible. The graphic files can be carved out easily from a .e file. Plus, we can always load the file into the actual developer environment to see what the source code it holds.

For the sample game I have shown earlier, we can double click the form and end up in a code window shown below:

Looking for existing tools that can understand the internal file format of PE files generated by the EPL (especially the packaged ones), I came across a very old Chinese tool called E-Code Explorer. You can download it from here (Web Archive copy over Google Translate :)). Since the E-Code Explorer interface is in Chinese, it’s a bit tricky to operate (screenshot below is from here):

Looking for a good candidate .exe file that could be open with this tool I checked the actual development environment. Not surprisingly, it’s also (at least partially!) written in EPL! After poking around I found out that c:\Program Files\EPL\setup\mksetup.exe can be loaded without any issues:

The program reads the internal structures of the .exe, recognizes its e-code signature, and version. It also lists a lot of information in a way similar to other tools do so for other frameworks, e.g. lists e-code modules the program relies on:

and calculates offsets for internal sections:

This, and a traditional tree-like browser (shown below) may come handy during malware analysis:

Also, when I looked at this file format a few years ago I recall seeing actual description of the internal structures of the standalone .exes, but can’t find it at the moment.

I guess this file format is more a curiosity than anything else, but yet another PE file type to be aware of. What’s more, I am aware of tools written in EPL actually being found during forensic investigations so you may actually come across the .fne, .fnr files during your exams…