\n<\/strong><\/p>\n
- \n
- 918e0ecb43d17e23<\/strong> used by Notepad (32-bit)<\/li>\n
- 9b9cdc69c1c24e2b<\/strong> used by Notepad (64-bit)<\/li>\n
- 1bc392b8e104a00e <\/strong>used by Remote Desktop<\/li>\n<\/ul>\n
and so on and so forth. The data from Forensics Wiki has been harvested from many sources and it’s a very useful reference for further research.<\/p>\n
The algorithm to create a hash-like value is actually ‘sort of known’. There are posts out there suggesting that the AppID is a nothing but a CRC64 sum taken from the application path. For example, in this post<\/a>, an Anonymous poster provided a Hexrays Decompiler’s code snapshot taken from shell32.dll showing how the AppID is generated. When I came across this particular comment I decided to verify it. I applied CRC64 sum to an example path and compared it with an expected known file name, and since you are reading this post you are probably guessing that it failed miserably \ud83d\ude42<\/p>\n
Okay, so since it failed and since the algorithm didn’t t seem to be explored in-depth yet I thought I will give it a go. It turned out to be quite simple, but there were a few challenges on the way that may be interesting to know about so I describe it below. I also ended up writing a perl script that I called AppID calculator (appid_calc.pl). It allows you to calculate an AppID based on provided string – more about it below as well. You can find a download link to the script at the bottom of this post.<\/p>\n
Challenges<\/h2>\n
Using the code snippet I referred to earlier as a guidance, I quickly found the code responsible for generating AppIDs, put the appropriate breakpoints in a debugger, and.. immediately understood why the CRC64 (path) didn’t work for me earlier \ud83d\ude42<\/p>\n
The CRC64 algorithm has been indeed applied to a path, but there are a few quirks:<\/p>\n
- \n
- The path is first converted to Unicode<\/li>\n
- If the path is located in one of locations that are recognized and treated by system in a special way, the path is normalized first<\/li>\n
- The CRC64(Path) algorithm applies only to AppIDs automatically generated by the system; At any point of time any application can change its AppID either using the SetCurrentProcessExplicitAppUserModelID<\/em> API, or can even apply window-specific AppID using \u00a0IPropertyStore::SetValue<\/em> to change the PKEY_AppUserModel_ID<\/em> property of\u00a0 the particular window<\/a><\/li>\n
- On top of that, the CRC64 uses a non-standard polynomial<\/li>\n<\/ul>\n
First, let’s talk about the CRC64. There are many CRC algorithms out there. In fact, the difference is not only between the length in bits (CRC16, CRC32, CRC64), but also in the configuration of a particular implementation. There are obviously many standard configurations (Wikipedia described quite a few<\/a>), but the one used in AppID generation is not on the standard list. I know, because the very first thing I tried was to use all standard configurations, but all of them failed :-).<\/p>\n
The actual code used by the system relies on a precalculated lookup table, but googling around for the numbers from the table only brought 2-3 hits. In such case, the usual way of solving the issue is to rip the code from the source and reimplement it e.g. in perl.\u00a0 This could be done easily. The 2-3 hits I mentioned earlier refer to a code that was created as a result of reverse engineering of thumbcache.dll\u00a0 file – turns out that the very exact CRC64 configuration\/implementation has been used in that DLL.<\/p>\n
Exploring the properties of CRC I eventually managed to deduce the CRC configuration and the actual polynomial used to generate the lookup table.<\/p>\n
The polynomial used by the AppID algorithm is 0x92C64265D32139A4<\/strong><\/span>.<\/p>\n
Once I found out I went to google again and this time I also got 2-3 hits only. First two were on the Thumb Cache-related code I already mentioned. The last one was the Microsoft page describing the use of this particular polynomial in a ADSStreamHeader<\/a> structure:<\/p>\n
Crc (8 bytes): <\/strong>A bit-reversed CRC-64 hash of the FCIADS stream from the TimeStamp<\/strong> field to the end of the structure that can be used to validate the integrity of the FCIADS stream. The cyclic redundancy check (CRC) polynomial is x**64 + x**61 + x**58 + x**56 + x**55 + x**52 + x**51 + x**50 + x**47 + x**42 + x**39 + x**38 + x**35 + x**33 + x**32 + x**31 + x**29 + x**26 + x**25 + x**22 + x**17 + x**14 + x**13 + x**9 + x**8 + x**6 + x**3 + 1, with the leading 1 implied. The normal representation is 0x92C64265D32139A4<\/span>.<\/p>\n
That was a good sign and I could now start implementing the appid calculator w\/o ripping the lookup tables.<\/p>\n
The second issue to solve was the normalization.\u00a0 The paths are normalized using KNOWNFOLDERIDs<\/a>, so it’s a simple search and replace before applying the CRC.<\/p>\n
One aspect of normalization I need to mention is… ambiguity. Depending on the OS (32 vs. 64 bit) different KNOWNFOLDERIDs are applied during the normalization path and it’s quite confusing. I suggest reading the Microsoft page I linked to above for further details.<\/p>\n
Last, but not least. – quite a lot applications use SetCurrentProcessExplicitAppUserModelID<\/em> API to change their AppID after they are executed. For example, the following applications do it (AppID – application name):<\/p>\n
- \n
- Microsoft.Silverlight.Offline<\/strong> – Silverlight<\/li>\n
- Microsoft.InternetExplorer.Default<\/strong> – Internet Explorer<\/li>\n
- VMware.Workstation.vmplayer<\/strong> – VMWare Player<\/li>\n
- Microsoft.Windows.MediaPlayer32<\/strong> – Windows Media Player (32-bit)<\/li>\n
- Microsoft.Windows.MediaPlayer64<\/strong> – Windows Media Player (64-bit)<\/li>\n<\/ul>\n
For this reason, attempting to find e.g. AppID of c:\\program files\\Internet Explorer\\iexplore.exe<\/em> doesn’t really make sense as all IE windows are grouped under Microsoft.InternetExplorer.Default<\/strong> AppID.<\/p>\n
Examples<\/h2>\n
AppIDs of InternetExplorer and Sticky Notes<\/h4>\n
![\"appid_1\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_1.png\")
<\/a><\/p>\nThese can be confirmed by looking at Forensic Wiki:<\/p>\n
- \n
- Microsoft.InternetExplorer.Default<\/strong> – 28C8B86DEAB549A1<\/strong><\/li>\n<\/ul>\n
![\"appid_2\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_2.png\")
<\/a><\/p>\n- \n
- Microsoft.Windows.StickyNotes<\/strong> – 337ED59AF273C758<\/strong><\/li>\n<\/ul>\n
![\"appid_3\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_3.png\")
<\/a><\/p>\n\u00a0Notepad<\/h4>\n
![\"appid_4\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_4.png\")
<\/a><\/p>\nYou may notice that in this example there are 2 different AppIDs shown. This is because of the ambiguity I mentioned earlier; applications running on 64-bit systems can be executed in more than one configuration and since there is WOW64 folder redirection happening AppID needs to be calculated in a context.<\/p>\n
The Notepad path looks the same to both 32- and 64-bit application (because of WOW64 folder redirection):<\/p>\n
- \n
- c:\\windows\\system32\\notepad.exe<\/li>\n<\/ul>\n
but the AppID depends on a type of Notepad .exe file:<\/p>\n
- \n
- if it is 32-bit, the AppID is 918E0ECB43D17E23 <\/strong><\/li>\n
- if 64-bit, the AppID is 9B9CDC69C1C24E2B<\/strong>.<\/li>\n<\/ul>\n
This can be also confirmed via Forensic Wiki:<\/p>\n
![\"appid_6\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_6.png\")
<\/a><\/p>\nInternet Explorer – via path<\/h4>\n
It gets even more complicated with Program Files folder as it has two versions – with and without (X86) and 32-\/64- bit applications both ‘see’ Program Files the same way. As an example we could try to generate a hash for Internet Explorer in various configurations by running appid calculator and providing to it a path to c:\\Program Files\\Internet Explorer\\iexplore.exe<\/em>. As mentioned earlier IE uses an AppID that it sets up during the launch, so you should never see AppIDs shown on the screenshot below, but it is a simple example to show various configurations of Program Files<\/em> folder using a well-known path.<\/p>\n
![\"appid_5\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2013\/04\/appid_5.png\")
<\/a><\/p>\nAgain, I strongly suggest reading the Microsoft Article about KNOWNFOLDERIDs<\/a>, The appid calculator provides a link to it as well if the path is known to be ambiguous (system32, program files, program files\\common).<\/p>\n
Download<\/h2>\n
You can find the script here<\/a>. This is a first version, coded in a hurry so it may contain bugs. If you find any issues, please let me know. Thanks!<\/p>\n
To run:<\/p>\n
perl appid_calc.pl<\/pre>\n
If no argument is passed to it, it will calculate a few sample AppIDs – the examples illustrate various ways one can provide the path to the script:<\/p>\n
- \n
- c:\\windows\\notepad.exe<\/li>\n
- c:\\windows\\system32\\notepad.exe<\/li>\n
- c:\\windows\\syswow64\\notepad.exe<\/li>\n
- {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\\notepad.exe<\/li>\n
- c:\\program files\\Internet Explorer\\iexplore.exe<\/li>\n
- MICROSOFT.INTERNETEXPLORER.DEFAULT<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
JumpList files are an interesting forensic artifact and as such they have been thoroughly explored by many researchers over last 2-3 years. There is really a lot of material out there and there are also many tools that parse JumpList … Continue reading
- if 64-bit, the AppID is 9B9CDC69C1C24E2B<\/strong>.<\/li>\n<\/ul>\n
- if it is 32-bit, the AppID is 918E0ECB43D17E23 <\/strong><\/li>\n
- c:\\windows\\system32\\notepad.exe<\/li>\n<\/ul>\n
- Microsoft.Windows.StickyNotes<\/strong> – 337ED59AF273C758<\/strong><\/li>\n<\/ul>\n
- Microsoft.InternetExplorer.Default<\/strong> – Internet Explorer<\/li>\n
- On top of that, the CRC64 uses a non-standard polynomial<\/li>\n<\/ul>\n
- 9b9cdc69c1c24e2b<\/strong> used by Notepad (64-bit)<\/li>\n