Fix LNK Parsing Error in Specific Cases in string_data.py #39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
I came across several LNK files that are not parsed correctly by your library, as well as by many other parsers. The issue lies in the
StringData
class.The class assumes that the 2 bytes (
str_length
) preceding each string accurately reflect the number of characters. However, it turns out thatstr_length
can contain large values (e.g.,0xFFFF
), while Windows internally enforces a 260-character limit (520 bytes in Unicode) on certain strings within the LNK format.This behavior applies to the strings
name
,relative_path
, andworking_dir
, which correspond to the flagsHasName
,HasRelativePath
, andHasWorkingDir
.I've attached files that demonstrate the issue (you can check all of them by right-clicking):
original.lnk
– a regular file without any parsing problemsname_long_ok.lnk
– same file, but with a name string exactly 260 characters long. Note that Windows treats the last character as null, even if it's a valid letter (as in this file).name_broken.lnk
– here the name string is 261 characters long and breaks the followingrelative_path
stringrelative_path_long_ok.lnk
– similar case forrelative_path
relative_path_long_broken.lnk
– 261 bytes inrelative_path
corrupt the next string workdirworkdir_long_ok.lnk
andworkdir_long_broken.lnk
– similar issue, thearguments
string gets corruptedThe arguments string, associated with the
HasArguments
flag, does not appear to have this 260-character limitation (which makes sense).Files are here: test.zip