decode bug?

[687766616e]

[DEBUG] declared web page charset 'utf-8'
+--------------------+
| password |
+--------------------+
| q\xe7\x1c\xa2)l |
+--------------------+

and I check the The encoding type of that table is cp950 (big5?) But I tried --charset=cp950 and --charset=big5, and it didn't work out

從我的 MI6，使用 FastHub 發送。

[stamparm]

1. --charsetnowadays has a different usage than before (https://github.com/sqlmapproject/sqlmap/wiki/Usage has the up to date information):

$ python sqlmap.py -hh | grep -E '\-\-(encoding|charset)'
    --charset=CHARSET   Blind SQL injection charset (e.g. "0123456789abcdef")
    --encoding=ENCOD..  Character encoding used for data retrieval (e.g. GBK)

2. Your case doesn't look like the encoding problem. This seems to be more a binary-hash value (Note: it doesn't look like something mainstream as it contains only 48 bits)

3. Try to use --binary-fields in this kind of situations to get an usable hexadecimal representation that could be used in some other (cracking) tools

[687766616e]

SELECT default_character_set_name FROM information_schema.SCHEMATA: cp950
i shoud enter --encoding=big5 / --encoding=big-5 / --encoding=cp950 or what? @stamparm

[stamparm]

@HUITC your issue is totally unrelated to this one. Maybe will conclude wrongly that he should use --encoding in cases with password-alike columns.

You should test with both of those. Also, in most cases DBMS charset is being CONVERTED to the connector one. Thus, it is possible that neither of those works (in most cases default utf8 should be sufficient)