1.“NetSarang的源码Xmanager和Xshell多种产品被植入后门事件”分析报告
2.[UVM源代码研究] 聊聊寄存器模型的后门访问
3.知名压缩软件xz被发现有后门,影响有多大?如何应对?

“NetSarang的Xmanager和Xshell多种产品被植入后门事件”分析报告

       NetSarang是一家提供安全连接解决方案的公司，产品包括Xmanager Enterprise,中带 Xmanager, Xshell, Xftp, Xlpd等远程连接管理客户端软件。近期，后门官方发布的源码软件版本中被发现nssock2.dll模块源码被植入后门。阿里云应急响应团队随即启动应急分析，中带确认后门会上传敏感数据至服务器，后门复古手游源码使用该软件的源码IT运维技术人员面临较高安全风险。

       受影响版本包括官方发布的中带多个版本。阿里云安全团队深入分析后发现，后门后门代码存在于Xshell相关的源码nssock2.dll中，该DLL具有厂商合法的中带数据签名。通过技术分析，后门发现该后门代码通过申请内存、源码抓娃娃夺宝源码解密并执行一段shellcode来上传用户、中带机器、后门网络相关信息至远程服务器，导致敏感信息泄露，风险严重。

       阿里云安全团队建议用户关注并启动自查处理，具体措施参见安全建议部分。进一步的技术分析显示，后门代码通过DGA算法生成C2域名用于数据传输，使用该算法生成的年全年C2域名已公开。后门样本会采集用户、机器信息并发送至指定域名，pubg泰服源码存在数据泄露风险。

       检测方法包括识别后门代码、检查数据上传行为及分析网络流量。针对安全风险，阿里云提供了安全解决方案，并在检测到后门代码后对外发布全网预警公告。更多技术细节和安全建议请关注云栖社区知乎机构号：阿里云云栖社区 - 知乎。

[UVM源代码研究] 聊聊寄存器模型的后门访问

       本文将深入探讨UVM源代码中寄存器模型的后门访问实现，尽管实际工作中这种访问方式相对有限，但在特定场景下其重要性不可忽视。后门访问有助于简化验证流程，特别是省鸭APP源码在检查阶段需要获取DUT寄存器值时。

       在UVM源代码中，后门访问的实现主要围绕write任务展开，核心方法是do_write()，它包括获取uvm_reg_backdoor句柄、等待访问权限和更新期望值等步骤。uvm_reg_backdoor类是用户自定义后门访问的入口，允许通过派生类实现定制化的访问方式。

       获取uvm_reg_backdoor句柄的过程会遍历寄存器模型的层次，如果没有自定义backdoor，就会从顶层寄存器模型开始查找。在默认情况下，寄存器模型使用sv语法的discuz论坛vip源码DPI方式访问，但可以通过自定义类实现其他形式的访问。

       源代码中的get_full_hdl_path函数负责获取寄存器的完整HDL路径，这涉及到uvm_hdl_path_concat和uvm_hdl_path_slice等结构，它们用于描述寄存器的物理信息。通过配置或add_hdl_path操作，可以在寄存器模型中存储和管理多个HDL路径，对应不同的寄存器实例。

       后门读写操作会调用uvm_hdl_read()函数，它是一个通过DPI-C实现的外部函数，根据编译选项的不同，可以选择使用C语言访问HDL路径。写操作成功后，会更新寄存器的镜像值并写入实际寄存器。

       总结来说，实现寄存器模型后门访问的关键步骤包括设置寄存器的HDL路径，配置单个寄存器的物理信息，并确保与HDL中的实际结构对应。需要注意的是，如果寄存器在HDL中被拆分为多个字段，需正确配置这些字段的访问路径以避免警告。

知名压缩软件xz被发现有后门,影响有多大?如何应对?

       知名压缩软件xz被发现存在后门，这一问题的揭露是由Andres Freund发现sshd进程的CPU占用率异常后进行的深入调查所促成的。

       对比分析有后门的m4脚本与原版，很难发现其中存在的问题。然而，通过执行命令`grep -aErls "#{ 4}[[:alnum:]]{ 5}#{ 4}$" ./`在源码根目录下，发现执行结果指向了`./tests/files/bad-3-corrupt_lzma2.xz`文件。这个步骤揭示了文件名虽不直接明文出现在构建脚本中，但通过`grep`命令间接匹配并确认了恶意文件的存在。

       进一步分析表明，`gl_[$1]_prefix=echo $gl_am_configmake | sed "s/.*\.//g"`这一行代码提取了恶意文件的扩展名`xz`，实际上对应于`xz`命令行工具的名称。这暗示了解压过程需要先安装`xz-utils`包。整个解压命令的执行环境主要针对Linux系统，而非非Linux系统。

       该脚本通过寻找并读取`config.status`文件来获取源码的根目录，这一过程考虑到许多发行版在编译时会单独建立`build`目录，因此`srcdir`变量保存了源码的位置。然后通过`export`命令随机读取内容，最终执行了一系列命令，其中包含多个行为，揭示了即使在非Debian或RPM系发行版中，尝试在`make`后再次执行`configure`时，也会通过其他途径执行感染。

       对于Debian或RPM系发行版，恶意代码通过将上述恶意脚本注入到`Makefile`中实现，这个过程依赖于源码编译完成后才能进行。而真正感染部分在于将原本应编译自特定源文件的`liblzma_la-crc_fast.o`和`liblzma_la-crc_fast.o`目标文件链接为恶意对象文件，同时替换指令集扩展检测函数。正确的`get_cpuid`原型被故意修改，其中`__builtin_frame_address`旨在获取函数返回地址，这可能在`x_`Linux上用于在寄存器中留下特定地址。

       值得注意的是，发布带有后门的作者Jia Tan曾在两个月前与Sam James讨论过与GCC相关的bug导致`ifunc`函数符号覆盖功能不正确的问题，最终确认了这是一个GCC的bug。

       提交代码时的实名要求对项目维护具有重要意义，尤其是当代码引发法律问题时。在Linux等重要项目中，有提交权限的人通常被强制要求实名。通过“签核”程序，开发者需在补丁说明末尾添加证明其身份的一行，确保贡献的合法性和追踪性。

       项目中采用的签署选项有助于确定提交者和审查者的身份。在更严格的场合，代码提交可能需要使用GPG签名，而线下会议可能举办Key signing party来交换GPG公钥，确保线上身份与现实一致，并获得其他人的承认。实名制是维护代码质量和法律责任的关键，虚拟人物或匿名用户无法承担相应的法律责任。