Firefox可疑子进程（原来是合法的FF行为）
我昨天发现了这个，因为它在其他闲置的Ubuntu 14.04台式机上产生了系统负载。
今天，我已经在另一个Ubuntu实例（Virtualbox VM中的17.10）中确认了这种行为
命令行中的子进程如下所示（为了防止askubuntu.com更改/转义内容，我将其作为下面的图片）
对我来说，它看起来像漏洞/恶意软件。 或者至少有一些东西需要隐藏。
甚至对于urlhttps://www.google.com/也会发生这种情况
这与Firefox的多进程function有关，请通过以下官方链接。
https://support.mozilla.org/en-US/questions/1147868#answer-938004
还有许多其他Linux线程，与您发布的输出相同，都与Firefox的多进程function有关。
最新版本的Firefox运行多进程而不是单个进程。
关于多进程
自Firefox 54于2017年6月首次亮相以来，该多进程适用于所有Firefox用户。 Multiprocess Firefox文档描述了Firefox在与Web内容不同的进程中运行浏览器UI。 因此，用户可能会在进程列表中看到“可疑子进程”。
许多最终用户似乎都关注子流程的神秘部分，正如本论坛上关于mozillaZine和Mozilla支持的论坛post所提出的那样; 这里引用的太多了。
直接答案
对我来说，它看起来像漏洞/恶意软件（子进程是恶意的吗？）
不，最新版本的Firefox行为就是这样。
或者至少有一些东西需要隐藏（有什么东西可以隐藏吗？）
不，没有隐藏的东西。 最终用户可能会看到与开发人员看到的不同。 很少有用户可能注意到在这个过程中没有什么可隐藏的。
怎么可以肯定
我们可以肯定有两个原因：
-
开发人员不愿意解释子流程的细节这一事实是我们可以确定它不是恶意的原因。 至少，到目前为止我还没有找到这样的细节。
-
2017年末，Stack Farflow的TT Farreo的部分答案暗示了子流程的神秘部分与Mozilla列入黑名单的列表有关。
[…]奇怪的字符列表似乎对应于http://kb.mozillazine.org/Network.IDN.blacklist_chars […]中列出的列入黑名单的字符
现在我们可以理解奇怪的角色了：
- 看那些分数字符？ 经过。
- 看那些二进制块字符？ 经过。
- 看那些看不见的空间？ 经过。
- 看到弧度的弧度单位？ 经过。
- 看黑钻字符的问号？ 经过。
Stack Overflow的答案还包括指向Firefox使用的内容过程源代码的链接。 最终用户通常不会深入研究这么多细节，这就是为什么Ask Ubuntu的答案本来就足够好的原因。
子流程是正常的，这一切都很重要。
昨晚我注意到了同样的事情，我开始用xxd检查它。 我最好的猜测是，这是一种传达指向共享资源或识别自身的方式（相邻的虚拟位置和恒定长度会导致周期性），但有些事情让我信服。
c783 cb90 3f3f d689 d68a d783 d7b4 d889 d88a d9aa db94 dc81 dc82 dc83 dc84 e185 9fe1 85a0 e19c b5e2 8080 e280 81e2 8082 e280 83e2 8084 e280 85e2 8086 e280 87e2 8088 e280 89e2 808a 3f3f 3fe2 8090 e280 99e2 80a4 e280 a73f 3f3f 3f3f 3f3f e280 afe2 80b9 e280 bae2 8181 e281 84e2 8192 e281 9fe2 8593 e285 94e2 8595 e285 96e2 8597 e285 98e2 8599 e285 9a3f e285 9ce2 859d e285 9ee2 859f e288 95e2 88b6 e28e aee2 95b1 e2a7 b6e2 a7b8 e2ab bbe2 abbd e2bf b0e2 bfb1 e2bf b2e2 bfb3 e2bf b4e2 bfb5 e2bf b6e2 bfb7 e2bf b8e2 bfb9 e2bf bae2 bfbb e380 80e3 8082 e380 94e3 8095 e380 b3e3 82a0 e385 a4e3 889d e388 9ee3 8eae e38e afe3 8f86 e38f 9fea 9e89 efb8 94ef b895 efb8 bfef b99d efb9 9e3f efbc 8eef bc8f efbd a1ef bea0 3f3f 3fef bfbc efbf bd0a
我修剪到前面的换行符（并留下它， 0a ，在结尾处。）我仅基于重复对齐它，即每行12个字节直到部分第25行。 我按照我的方式划分字节的原因是为了显示（看起来像） UTF8连续 （底部的表格）。但是，值得一提的是，遵循已建立的和众所周知的编码的惯例提供了同样的好处：你可以代表大的价值，但保持小的紧凑。 另一方面，出于某种原因，他们似乎在串联? 并且只有大于80的字节。该维基百科页面的下一部分显示该范围内有可打印字符，但间距越来越少。 我不相信这个目标与编写非常宽的UTF8字符有什么关系，相反，它就好像它们避免了ASCII集中更普遍可打印的字符。 在这一点上，我能想到的最好的是他们知道他们必须编码和嵌入任意长度的字符串，即’stringPrefs’，并且可能选择使用低字节夹住的高字节，这使得它更容易提取。 据我所知，这个? 作为分隔符和填充。
我不满意，但我没有更多的东西可以提供。 为了我的利益，我开始替换最常见的角色，并且更容易看到发生了什么：
c783 cb90 d689 d68a d783 d7b4 d889 d88a d9aa db94 dc81 dc82 dc83 dc84 e185 9fe1 85a0 e19c b5++ ---- ++-- 81++ --82 ++-- 83++ --84 ++-- 85++ --86 ++-- 87++ --88 ++-- 89++ --8a ++ --90 ++-- 99++ --a4 ++-- a7 ++-- af++ --b9 ++-- ba++ 8181 ++81 84++ 8192 ++81 9f++ 8593 ++85 94++ 8595 ++85 96++ 8597 ++85 98++ 8599 ++85 9a ++85 9c++ 859d ++85 9e++ 859f ++88 95++ 88b6 ++8e ae++ 95b1 ++a7 b6++ a7b8 ++ab bb++ abbd ++bf b0++ bfb1 ++bf b2++ bfb3 ++bf b4++ bfb5 ++bf b6++ bfb7 ++bf b8++ bfb9 ++bf ba++ bfbb e3-- --e3 --82 e3-- 94e3 --95 e3-- b3e3 82a0 e385 a4e3 889d e388 9ee3 8eae e38e afe3 8f86 e38f 9fea 9e89 efb8 94ef b895 efb8 bfef b99d efb9 9e efbc 8eef bc8f efbd a1ef bea0 ef bfbc efbf bd0a
我看到的结构比加密和编码的字符串要多得多，除非这是某种隐写术。 如果有人可以接受接力棒，我会感激不尽，而不仅仅是因为我很好奇 – 我想早点知道，如果有什么值得藏在那里的话。