[Resolved] Mystery Strings?

Are there characters in the unicode table that can ruin an otherwise healthy string as it is being written to the registry, or as it is sent to a text box?

I ask because I have written a routine that uses a Blowfish Encryption class to conceal a password (and other info) which is then stored in the registry as a REG_SZ value (string). The routine works perfectly most of the time, but on rare instances, the output is truncated as it is being written to the registry or to a simple text box.

I have tested the encryption routine by encrypting a string and then immediately decrypting it, followed by comparing the original string to the decrypted string, in memory. They are the same up to the moment they are being written to a text box (or registry) using something as simple as the code below:

Code:

---

  Text1.Text = EncryptedHash

---

Is it possible that VB6 (SP6) is trying to interpret the string as it is being written out, and then stumbling on some unprintable character that is causing the line to be erased, in part? The line I am working with currently is 120 characters while in memory, but just 9 by the time it hits the text box.

Any insight concerning this puzzle would be most helpful. Thanks!

check for any null in the string

If you find null, tell us, so we can help you better..

I think you guys are onto something!

I wrote a routine that would list the ASCII value of each character in the encrypted hash. The 10th, and 23rd values were zeros! So, yes, a null character exists. It makes sense that the 9th character is where the new string blew up knowing that the 10th was a null.

Now that I know that null characters are a problem, I am not too sure what to do about it. What would you recommend?

as you have no control over the encryption, perhaps store the encrypted string as a byte array values

Thank you for your suggestion!

I may be misunderstanding the use of a byte array, but when using the code below, I still hit a road block when I convert the array back to unicode.

Code:

---

Dim s As String
Dim bArray(1 To 21) As Byte

bArray(1) = 81
bArray(2) = 117
bArray(3) = 105
bArray(4) = 118
bArray(5) = 101
bArray(6) = 114
bArray(7) = 51
bArray(8) = 49
bArray(9) = 56
bArray(10) = 32
bArray(11) = 103
bArray(12) = 114
bArray(13) = 101
bArray(14) = 101
bArray(15) = 116
bArray(16) = 115
bArray(17) = 32
bArray(18) = 121
bArray(19) = 111
bArray(20) = 117
bArray(21) = 33

s = StrConv(bArray, vbUnicode)
x = MsgBox(s, vbInformation, "Converted Bytes back to Unicode")

---

If you change the 10th array element from a value of 32 to 0 (inserting a null instead of a space), and run this code, it will truncate the final conversion.

Do I have the wrong idea about byte arrays, or should I be trying another method ... or both?

Why not convert the encrypted string to hex before storing it? Even more secure, is storing the password in MD5 form. It cannot be recovered this way but it also can't be decrypted.

Here is an example of converting it to hex and back:

Code:

---

Option Explicit

Private Function PrefixZero(Data As String) As String
    If Len(Data) = 1 Then
        PrefixZero = "0" & Data
    Else
        PrefixZero = Data
    End If
End Function

Private Function StrToHex(Data As String) As String
    Dim l As Long, strRet As String
    For l = 1 To Len(Data)
        strRet = strRet & PrefixZero(Hex$(Asc(Mid$(Data, l, 1))))
    Next l
    StrToHex = strRet
End Function

Private Function HexToStr(HexData As String) As String
    Dim l As Long, strRet As String
    For l = 1 To Len(HexData) Step 2
        strRet = strRet & Chr$("&H" & Mid$(HexData, l, 2))
    Next l
    HexToStr = strRet
End Function

Private Sub Form_Load()
    Dim strPassword As String, strHex As String
   
    strPassword = "0123 this is a password"
    Debug.Print "Password:  " & strPassword

    strHex = StrToHex(strPassword)
    Debug.Print "Hex:      " & strHex

    strPassword = HexToStr(strHex)
    Debug.Print "Password:  " & strPassword
End Sub

---

Edit: You'd of course use the hex function on the encrypted string, not the plain password, or that wouldn't be very secure at all.

For info:

Many registry routines look for the FIRST null in a retrieved REG_SZ and truncate the remainder of the string. If you are using the APIs to retrieve the value, your routine should simply remove the LAST null. Note that VB.Net doesn't give you a choice - it will ALWAYS truncate at the first null. This is also likely with 3rd party controls.

A REG_SZ will happily accomodate embedded nulls. You can check for the validity of the value in the registry by right-clicking on the value and choosing "Modify Binary Data". As each character in a REG_SZ is seperated by a null, an embedded null will be show as 3 consecutive nulls.

Writing/reading a REG_SZ with embedded nulls isn't a problem - it's whether the rest of the code can handle them.

VB controls such as textboxes won't display anything after a null, or store it as a propery - although a string with embedded nulls will happily "live" in a string variable. ie Manipulate strings with embedded nulls in variables, and only display them when all the nulls have been converted to something readable.

Thanks for the fine tips and explanations, everyone!

I ended up using the Hex solution, although in retrospect, the byte array method would have worked just as well. I guess I did not have my brain facing in the right direction, earlier, or I would have realized it. :D