Possible bug

[MrWoo]

Hi n7. It has been awhile since I needed to update my inf maker. I decided I wanted to update it a bit, and was still wanting to fix that hex(1) issue. Regardless, I have a new script now, and in trying it out, I ran yours beside it. I have a reg file with lot's of different values, some from what you posted over at Ryans for me, and others that I have found from my own xp registry.

Anyway, here is a value that I noticed yours did not convert correctly.

[HKEY_LOCAL_MACHINE\SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}]
"IPAddress"=hex(7):31,00,00,00,39,00,00,00,32,00,00,00,2e,00,00,00,31,00,00,00,\
  36,00,00,00,38,00,00,00,2e,00,00,00,31,00,00,00,2e,00,00,00,31,00,00,00,30,\
  00,00,00,00,00,00,00,00,00,00,00
"SubnetMask"=hex(7):32,00,00,00,35,00,00,00,35,00,00,00,2e,00,00,00,32,00,00,\
  00,35,00,00,00,35,00,00,00,2e,00,00,00,32,00,00,00,35,00,00,00,35,00,00,00,\
  2e,00,00,00,30,00,00,00,00,00,00,00,00,00,00,00

Here is the result in your converter

HKLM,"SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}","IPAddress",0x10000,"1","9","2",".","1","6","8",".","1",".","1","0"
HKLM,"SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}","SubnetMask",0x10000,"2","5","5",".","2","5","5",".","2","5","5",".","0"

Here is what mine is currently outputting

HKLM,"SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}","IPAddress",0x00010000,"192.168.1.10"
HKLM,"SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}","SubnetMask",0x00010000,"255.255.255.0"

If it is indeed a bug, my fix was to do a hex step, looking for a pattern of 00,00 typically seen in a hex(7) value, broken down like this

; if not a pattern of 00,00,00,xx then pattern is 00,xx,00,xx .....
; if not a pattern then parse 00,00,00 as multi-line
; else if pattern, parse as single line

If it is of any use anyway. Perhaps yours is right and mine is wrong. I don't know if mine is 100% or not, but I am pretty sure that yours is not correct for that type of value.

MrWoo

[MrWoo]

May have found another one, not so much a bug but that when you find a hive key, and within that hive key resides a hex(1) value, your output states an error correctly, but it would appear that a string value after that, which contains a bracket (I assume), will be identified as also an error. A standard value after that will resume appropriate conversion. Here is a snip from my reg file that I know contains hex(1) values

[HKEY_LOCAL_MACHINE\SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task]

"ByExtensionExtensions"=".EXE
.COM
.SYS
.VXD
.DLL
.DRV
.SCR
.386
.XL?
.DOC
.DOT
.OV?
.CPL
"
"DisplayMessage"="F-Prot Antivirus - OnDemand Scanner has found a virus.


Virus : [15015]

Location :  [15013][15012]"
"EmailMessage"="F-Prot Antivirus - OnDemand Scanner has found a virus  on host [15014].For more information see report file.[15016]"

"MoveToFolder"="C:\\Program Files\\FSI\\F-Prot\\Moved"

"NEW KEY"="line\\line\"line%2f"
@=";I;a;m;ABug!@#$%^&*()\"Welcome\"\"ConfuseMeBaby\""
"new value"="hello","hi"

Here is the output from your version 46 converter

HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","ByExtensionExtensions",0x0
; Failed (Invalid syntax): (.COM
.SYS
.VXD
.DLL
.DRV
.SCR
.386
.XL?
.DOC
.DOT
.OV?
.CPL
"
"DisplayMessage"="F-Prot Antivirus - OnDemand Scanner has found a virus.)
; Failed (Invalid syntax): (Virus : [15015]

Location :  [15013][15012]"
"EmailMessage"="F-Prot Antivirus - OnDemand Scanner has found a virus  on host [15014].For more information see report file.[15016]")
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","MoveToFolder",0x0,"C:\Program Files\FSI\F-Prot\Moved"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","NEW KEY",0x0,"line\line""line%%2f"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task",,0x0,";I;a;m;ABug!@#$%%^&*()""Welcome""""ConfuseMeBaby"""
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","new value",0x0,"hello"",""hi"

Here is what I am outputting

;___UN-SUPPORTED DATA TYPE hex(1)___HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","ByExtensionExtensions",".EXE' & @LF & '.COM' & @LF & '.SYS' & @LF & '.VXD' & @LF & '.DLL' & @LF & '.DRV' & @LF & '.SCR' & @LF & '.386' & @LF & '.XL?' & @LF & '.DOC' & @LF & '.DOT' & @LF & '.OV?' & @LF & '.CPL' & @LF & '"
;___UN-SUPPORTED DATA TYPE hex(1)___HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","DisplayMessage","F-Prot Antivirus - OnDemand Scanner has found a virus.' & @LF & '' & @LF & '' & @LF & 'Virus : [15015]' & @LF & '' & @LF & 'Location :  [15013][15012]"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","EmailMessage",0x0,"F-Prot Antivirus - OnDemand Scanner has found a virus  on host [15014].For more information see report file.[15016]"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","MoveToFolder",0x0,"C:\Program Files\FSI\F-Prot\Moved"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","NEW KEY",0x0,"line\line""line%%2f"
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task",,0x0,";I;a;m;ABug!@#$%%^&*()""Welcome""""ConfuseMeBaby"""
HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","new value",0x0,"hello","hi"

Those darn hex(1) values. I really wish I could find a fix in .inf for them.

Now maybe you can answer a question. How does your routine handle the proper conversion of this

"new value"="hello","hi"

Your output is proper I believe, being

HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","new value",0x0,"hello"",""hi"

While mine is like this

HKLM,"SOFTWARE\AA_TEST\FRISK Software International\FP-Win\Default Task","new value",0x0,"hello","hi"

How do you segregate the instances of double quotes in a structure like that from one of the other more complicated variety? If I double up on a reg_sz, it affects them all.

Anyway, more learning comin up.

MrWoo

[n7Epsilon]

[HKEY_LOCAL_MACHINE\SOFTWARE\AA_TEST\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{52092522-9F89-4099-B205-6E3578154614}]
"IPAddress"=hex(7):31,00,00,00,39,00,00,00,32,00,00,00,2e,00,00,00,31,00,00,00,\
  36,00,00,00,38,00,00,00,2e,00,00,00,31,00,00,00,2e,00,00,00,31,00,00,00,30,\
  00,00,00,00,00,00,00,00,00,00,00
"SubnetMask"=hex(7):32,00,00,00,35,00,00,00,35,00,00,00,2e,00,00,00,32,00,00,\
  00,35,00,00,00,35,00,00,00,2e,00,00,00,32,00,00,00,35,00,00,00,35,00,00,00,\
  2e,00,00,00,30,00,00,00,00,00,00,00,00,00,00,00

The output of reg2inf for this value is correct as it is now. According to Microsoft's documentation (MSDN):

A REG_MULTI_SZ structure is supposed to be as follows:
(String - null) - (String - null) - (String - null) - null
Just a sequential series of null terminated strings terminated at the end by an extra null character.

In REG v5 reg file, it is unicode, so each letter (including the null itself) is represented by 2 character ucs2le (utf-16)

In REG v4 reg file, it is ansi, so each letter (including the null itself) is represented by 1 character only.

So now look in the hex(7) value you posted and you will see that I am converting it correctly as reg v5.

As for the hex(1) error, that output is just me trying to comment the invalid syntax value and saying that an error occurred, but due to a change in the regular expression being used from the previous version, it is being handled by generic error handler which just adds a ; to the beginning, thus making this corrupt situation, I will fix that in the next version, but values of this type are extremely rare anyway.

Look in Reg2Inf.cs (source code) at ApplyFixes function and you will see how I handle this:

/// <summary>
/// Apply fixes (\\ > \)|(\" > "")|(% > %%)
/// </summary>
/// <param name="Line">Line to apply fixes to</param>
/// <param name="SkipQuotesConversion">REG_MULTI_SZ, REG_SZ (hex notation) and REG_EXPAND_SZ 
/// already put the quotes correctly so if you fix them again you will damage the value, so for 
/// those put true here to skip that part and only to do the double-quote and percent fixes.</param>
/// <returns>New Data</returns>
private static string ApplyFixes(string Line, bool SkipQuotesConversion)
{
    if (!SkipQuotesConversion)
    {
        // Unescape slashes
        Line = Regex.Replace(Line, @"\\\\", @"\",
            RegexOptions.IgnoreCase | RegexOptions.Multiline | RegexOptions.ExplicitCapture);

        // Unescape quotes
        Line = Regex.Replace(Line, @"\\""", @"""",
            RegexOptions.Singleline | RegexOptions.ExplicitCapture | RegexOptions.IgnoreCase);
    }

    // Double the quotes
    Line = Regex.Replace(Line, @"""", @"""""",
        RegexOptions.Singleline | RegexOptions.ExplicitCapture | RegexOptions.IgnoreCase);

    // Double the percentages
    Line = Regex.Replace(Line, @"%", @"%%",
        RegexOptions.ExplicitCapture | RegexOptions.Singleline | RegexOptions.IgnoreCase);

    return Line;
}

I apply this function on the subkey name, the value name, and the string value data, expand string and each one of the multi strings.

[MrWoo]

The output of reg2inf for this value is correct as it is now. According to Microsoft's documentation (MSDN):

A REG_MULTI_SZ structure is supposed to be as follows:
(String - null) - (String - null) - (String - null) - null
Just a sequential series of null terminated strings terminated at the end by an extra null character.

How true. Yours does indeed convert correctly. I am unsure where exactly I got that reg file from, and I realize that it has too many null characters, but it was exported from one of my computers a year or two ago. I have some other hex(7) values that appear the same way, and in fact when converted 'properly' appear as V A L U E instead of VALUE.

So I am not sure if that is a bug in the export routine from xp, or how it became that way. I only know that it needed to be handled.

Perhaps it is not a valid reg file, so maybe it is a MS bug.

As for hex(1) values, you are correct, I have only seen this one instance of them. I thought you may like some info though.

later.
MrWoo

[jakeruston]

Strange, I'm not having this problem...