1

I have found some chinese characters in one of a file on my linux mint 20.1 File - /proc/1/cmdline Chinese Characters - 猯楢⽮湩瑩猀汰獡h

But when i open same file in terminal using less command, it shows : /sbin/init^@splash^@

Is this normal or is there anything to worry about in terms of security?

Kusalananda
  • 333,661
Yasin
  • 13
  • Related to, if not duplicate of: https://unix.stackexchange.com/questions/526487/ps-axf-shows-sbin-init-splash-for-pid1 and https://unix.stackexchange.com/questions/519250/splash-in-pid-1 – Kusalananda Jan 18 '21 at 15:55
  • So, There's no problem?? in GUI text editors it shows chinese characters. – Yasin Jan 18 '21 at 16:03
  • What GUI text editors, exactly? If they do that by default, and it's not some kind of trick obtained by tweaking their settings, you can safely report it as a bug. –  Jan 18 '21 at 20:26
  • @user414777 Since the data contains nul bytes, I'm assuming the editor realizes it's not a file in ASCII or UTF-8 encoding and starts cycling through the available encoding until it finds one that "make sense" to it. This is IMHO a relatively useful heuristic that might do the right thing in most situations, possibly. – Kusalananda Jan 18 '21 at 23:32

1 Answers1

2

If you take the nul-terminated strings /sbin/init and splash, and convert them from the UCS-2LE (or UNICODELITTLE, or UCS-2-INTERNAL) encoding using iconv, you get

$ printf '/sbin/init\0splash\0' | iconv -f UCS-2LE
猯楢⽮湩瑩猀汰獡h

The output from less is more correct. The less utility shows nul bytes (\0) as ^@.

Conclusion: The "Chinese text" that you are seeing is due to your editor determining that the data is encoded as UCS-2LE (for whatever reason). It is not actually Chinese but simply the two nul-terminated strings /sbin/init and splash.

There is nothing you need to worry about.

For more information about /sbin/init splash see:

Additionally, you should not expect a text editor to be able to correctly understand the contents of the virtual file /proc/1/cmdline as it's not a text file. This is probably why your text editor tried to determine the file's encoding, but failed to do so correctly.

See: Encoding of /proc/<pid>/cmdline files

Kusalananda
  • 333,661