On a Windows Server 2008 machine found registry key "潓瑦慷敲卜湹潣敶祲" under HKEY_CURRENT_USER of the administrator account. It contains a value "敓癲捩剥湵楮杮" of type REG_DWORD which is set to 0.

I scanned the machine without a result with Kaspersky Rescue Disk 10, Avira AntiVir Rescue System, F-Secure Rescue CD and Malwarebytes Anti-Malware Free. I also reinstalled all software that I manually installed since I last accessed this part of the registry in separate virtual machine under the assumption that a software installation might have inserted the registry key.

This leaves me with three imaginable scenarios:

  • The registry key was present when I last examined this part of the registry, I overlooked it and it was inserted by software installed on the server.
  • The registry key was inserted by software managed through Windows Update.
  • The Registry Editor misinterprets some encoding or the registry key is the result of some kind of encoding error.
  • The server was target of a custom attack and is infected with malware that is not recognized by standard software.

The last scenario seems unlikely, the affected system contains no valueable data and a targeted attack would probably leave no traces.

Machine translation software couldn't translate the strings to anything meaningful. Search engines don't have meaningful results for the strings.

Has anyone seems something like this? Do the strings have a translation?


2 Answers 2


the registry key is the result of some kind of encoding error.



encoded in UTF-16LE (Windows's usual encoding for Unicode strings) is the byte sequence:

53 6f 66 74 77 61 72 65 5c 53 79 6e 63 6f 76 65 72 79

Which represents the ASCII string:


So it would seem Syncovery called a Win32 Unicode API to write a registry value, but passed strings that were actually ANSI. Whoops!

No indication of a security issue, unless you weren't expecting Syncovery to be running...

  • That makes more sense than the Google's English translation of '潓瑦慷敲卜湹潣敶祲', which is 'Hui Wukangqiaobu Chanminzhenjin' :-)
    – Johnny
    Commented Jun 13, 2013 at 20:48
  • And yet again the simplest possible explanation was correct.
    – user27140
    Commented Jun 17, 2013 at 12:19

the new version 6.33 of Syncovery fixes this and removes the incorrect key, if it still exists.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .