Simple Analysis of Chinese Characters in SQL Injection

For those who often play SQL Injection, it is often boring and painful to guess the characters, especially to detect Chinese characters. The input is rejected again and again. However, it is said that this is a very good way to cultivate patience. Have you ever thought about automatic injection? Please refer to my article SQL Server data information for automatic detection. (Make an advertisement, don't throw eggs, or I don't have to eat this evening .)

Chinese characters in SQL Server
In SQL Server, Chinese ASCII is a positive number. However, because it is a UNICODE double-bit encoding, the ascii Code cannot be obtained using the function ASCII (). The unicode value must be returned using the function unicode, use the nchar function to obtain the corresponding Chinese characters.
After detecting the Unicode encoding of Chinese Characters in SQL Server, how can we know the corresponding Chinese characters? I cannot find the tool. After research, I found three solutions.
1. add "and nchar (unicode encoding for Chinese characters)> 0" after injection address, for example: http://www.xxx.com/id=1 and nchar (20013), because nchar () function return type is nvarchar, compare the nvarchar value with the int value with 0. The system first tries to convert the nvarchar value to the int type. Of course, the conversion process will definitely fail. The error message of SQLServer is as follows:
Microsoft ole db Provider for ODBC Drivers error 80040e07
A syntax error occurs when [Microsoft] [odbc SQL Server Driver] [SQL Server] converts an nvarchar value to an int column.
The information we want to know. In this way, we can know the corresponding Chinese characters.
2. Use SQL Server. This may be the reason for the so-called "the person who needs to ring the bell. Through the SQL Server Query analyzer or Enterprise Manager, we construct the query condition select nchar (20013) and execute the query operation. Have you seen the query results?
3. Use the character table. This is the focus of this article and an important issue that must be addressed in automatic SQL Server injection.
We know that the Unicode encoding of any Chinese character is unique, and its GB18030 code is also unique. Otherwise, the same encoding represents more than N Chinese characters. Do you know what it is? So what is the relationship between the Unicode code of the same Chinese character and the GB18030 code? Equal? Is it so troublesome to convert it into Chinese characters directly. We do not need to know the relationship between them for the time being. As long as we know that the same Chinese character has a unique Unicode encoding, the corresponding GB18030 code is also the only one. That is to say, knowing the Unicode encoding of a Chinese character can only correspond to a GB18030 code. Through GB18030 code, we can now find the original Chinese character.
For Unicode and GB18030 corresponding code table, you can download it in the http://www.uighurlinux.org/download.htm. The Unicode code table corresponding to GB18030 is hexadecimal and does not contain any Chinese characters. However, we can convert GB18030 to Chinese characters.
The following task is to convert the Unicode and GB18030 corresponding code table into a Unicode-GB18030-Chinese character table. Here I want to explain that for the four-digit GB18030 code, after the hexadecimal format is converted to decimal, the corresponding Chinese characters (including ASCII characters) can be obtained using the chr (number ), but for the eight-bit GB18030 Code, for example, 82328D35, I do not know what it is. Fortunately, it does not affect our understanding of Chinese characters, because the four-digit hexadecimal GB18030 code already contains enough Chinese characters, at least until now, I have not encountered any Chinese characters that I cannot guess. For the specific conversion process, I will not be here. I will put it in the additional documentation, and also include the tables in use that I have converted and the Access format.
With the Access format of the Unicode-GB18030-Chinese character table, we can now in the automatic injection program to query the Unicode encoding of Chinese characters. The method is very simple. The following is the program code for querying the comparison table during Automatic injection. Pay attention to the lines I write comments.
Function Get_Field_Name (iUrl, Flen)
Dim conn, I, rs, ch, SQL, result, char
Result = ""
Set conn = GetConnection (server. MapPath ("UnicodeMap. mdb "), "")'
For I = 1 To Flen
Ch = GetChar (Replace (iUrl, "[POS]", I), 0)
SQL = "select chr from GB18030 where DU =" & Ch' Chinese characters of the unicode code obtained during query Injection
Set rs = get_rs (conn, SQL, 1)
If rs. recordcount = 1 then' find the corresponding Chinese characters, including ASCII
Char = rs (0)
Else
Response. write "no corresponding characters"
Resoponse. end
End if
Result = result & char
Rs. close
Set rs = nothing
Next
Conn. close 'close the data connection
Set conn = nothing
Get_Field_Name = result
End Function
In addition, for obtaining Unicode encoding for Chinese Characters in SQL Server, I have already made it very clear in my SQL Server data information automatic detection article. We can determine the Unicode encoding of any Chinese character for 16 times and only 16 times.

Chinese characters in Access
For Access, the character processing function is different from that in SQL Server. See the following table.
Access SQL Server description
Asc (character) unicode (character) returns the encoding of a character
Chr (number) nchar (number) is opposite to asc, Return Characters Based on number encoding
Mid (string, N, L)
Substring (string, N, L)
Returns a substring of L from N characters, that is, a string between N and N + L.
When guessing Chinese characters, we can also use the GetFieldValue (iUrl, TableName, FieldName, PrimaryKey, PKValue, minlen, maxlen) function to call them. However, pay attention to the following points:
1. the query condition is changed:
CheckFieldValue = "and 1 = (select count (*) from [TABLE] where [IDN] = [ID] and asc (mid ([FN], [POS], 1)> [N])"
2. value range of Asc code. I have not tried the value range after the Chinese characters are computed using the ASC function. I do not know the minimum value is negative. Therefore, the value range is determined by the minimum value. You only need to include the Chinese characters you guessed. However, it does not matter if the scope is too large. After all, the processing function here will narrow down the scope of the guess in an exponential manner, making it a big deal to calculate a few times.
As for the upper limit, zero removal is certainly not a problem. If there are ASCII characters, you can set the maximum value to 255. I think this will have almost no impact on the computing time. You can only guess one character and calculate it once more. For the sake of universality, take 255.
3. After the ASC value is obtained in the GetFieldValue function, the chr () function is used to convert it into Chinese characters or characters without calling the character comparison table.
After reading this article N times, I feel that the range of Chinese Characters in Asscess is always incorrect. After all, time is life. There are several times and there are several times. For a single character, it may not matter. However, if the amount of data to be guessed is large, this may have a great impact on the program execution efficiency. After I tested the chr function parameters, I found that the effective range of the chr function parameters is-32768-65535, so the ASC code value range of Chinese characters (-32768,0 ), after 16 guesses, you can know the corresponding ASC code. If ASCII characters are added, 17 guesses are required.
This article puts forward some opinions and opinions on the question of Chinese Characters in automatic SQL injection. If there is anything wrong with it, I hope you will criticize and correct it. A comprehensive character encoding query tool can be attached for mutual query in the Chinese character-Chinese Character Unicode encoding-Asc code.