Incorrect VDF parsing when value ends with escaped backslash

[mtkennerly]

Describe the bug

Consider this snippet of the VDF output for app_info_print 210770:

			"0"
			{
				"executable"		"Binaries\\Win32\\SanctumGame-Win32-Shipping.exe"
				"description"		"Launch Game"
				"workingdir"		"Binaries\\Win32\\"
				"config"
				{
					"oslist"		"windows"
				}
			}

Note that the workingdir value ends with \\.

Here's how it looks in the output of getProductInfo([210770], []):

            "0": {
              "executable": "Binaries\\\\Win32\\\\SanctumGame-Win32-Shipping.exe",
              "description": "Launch Game",
              "workingdir": "Binaries\\\\Win32\\\\\"\n\t\t\t\t",
              "config\"": {
                "oslist": "windows"
              }
            }

Issues:

• The workingdir value has a line break and tabs
• The config key is renamed to config"

If a value ending with \\ is the last value in a section, then the following sections are nested incorrectly. Here's an example from app 223220, where launch.0.workingdir ends with the backslash:

		"launch"
		{
			"0"
			{
				"executable"		"launcher\\GSLauncher.exe"
				"description"		"Start with Launcher"
				"workingdir"		"Launcher\\"
			}
			"1"
			{
				"executable"		"GSGameExe.exe"
				"type"		"default"
				"config"
				{
					"oslist"		"windows"
					"betakey"		"kubi"
				}
			}
		}
		"usemms"		"1"

launch.1 moves inside of launch.0 (and is named launch.1"), and usemms moves inside of launch:

          "launch": {
            "0": {
              "executable": "launcher\\\\GSLauncher.exe",
              "description": "Start with Launcher",
              "workingdir": "Launcher\\\\\"\n\t\t\t}\n\t\t\t",
              "1\"": {
                "executable": "GSGameExe.exe",
                "type": "default",
                "config": {
                  "oslist": "windows",
                  "betakey": "kubi"
                }
              }
            },
            "usemms": "1"
          }

Versions

• steam-user: Initially found on 4.16.2, then verified on 4.24.3
• nodejs: 16.13.1

Screenshots and Error Logs

N/A

[DoctorMcKay]

VDF parsing is handled by the vdf package. This should probably be reported there. If it's not being maintained, I might have to fork it.

[mtkennerly]

The repository is archived, and the last release was 9 years ago, so no luck there. There are already a few other VDF libraries on npmjs.com, so maybe one of them would work? These seem like the most promising ones:

• https://www.npmjs.com/package/@node-steam/vdf
• https://www.npmjs.com/package/vdf-parser