LNK Parsing: You’re doing it wrong (II)

As we saw in the first article, Windows gives priority to data in the ITEMIDLIST to resolve LNKs whenever there's both an ITEMIDLIST and a LinkInfo structure, so let's focus on the actual format of the ITEMIDLIST.

An ITEMIDLIST is nothing more than a list of ITEMID/SHITEMID (IID) which are contiguous. It is terminated by an empty IID which is defined as a 0-size IID. On-disk it's seen as

typedef struct _ITEMIDLIST
	USHORT size;
	BYTE data[ size ];
} ITEMIDLIST; contains all the contiguous IIDs. For LNK files the IIDs are in order as they have to form a path so that IID #0 will be the first element, IID #1 the 2nd, etc.

Let's say you have the path "C:\TEMP\file.tmp"

C: would be in an IID
TEMP would be in the next IID
file.tmp would be the last IID

Every IID conforms to the following definition:


LNK Parsing: You’re doing it wrong (I)

Recent developments on the malware arena (MS10-046) have raised awareness of LNK files. Due to the nature of the LNKs used by this specific malware I tried to challenge a few members of the forensic community to make them question themselves about what's publicly known of LNKs but it seems I failed miserably.

Instead, I've decided to post what I researched nearly 2 years ago. This is what I found...