时镜过迁，转眼即逝，基于Sandboxie意图快速构建解决方案，除了看源码，还可以借助AI学习，对于"技术老炮"游刃有余，每当有年轻朋友来寻找答案，总会多提一句，调试，实践，分享会有更多收获。
  本篇是关于COM隔离方案见解，COM和DCOM不是一回事，是包含关系，COM是标准，容易混淆概念，Sandboxie COM隔离也是非常复杂。
  DCOM是基于微软Component Object Model(COM)协议扩展，最早是用来跨网络对象通信，是一种跨主机的通信解决方案，经典应用包括打印机共享，WMI等。DCOM和RPC有关联？DCOM是基于RPC协议扩展，来传递对象引用，需要对Object Remote Procedure Call一起处理，这里表述两者因果关系。
  题外记，琐碎时间空隙，很多年前还在甲方实习，听到乙方大佬谈论RPC/COM逃逸提权，天方夜谭，无从下手，坚持，挣扎，放弃。

  编译部署或Github/官方下载安装程序，线上版安装到本地，把自己编译好的程序替换，附加调试。
  注意！基于Sandboxie-Plus版本调试驱动会有签名检测，替换SbieSvc启动会失败。

  驱动中有签名认证，SbieSvc初始化设置端口，签名检验失败，驱动返回STATUS_INVALID_SIGNATURE错误，SbieSvc服务会退出。

编码测试单元，能够在沙箱触发COM操作

  代码通过COM口打开IE对象并访问百度网站，RPC连接，沙箱中效果如下，Unit.exe COM操作被Sandbox重定向到沙箱内的DcomLaunch.exe，进程树清晰，SboxDcomLaunch和SandboxieRpcSs是父子进程关系，SboxDcomLaunch负责执行IE相关的操作。

  如何附加调试呢？先修改测试用例，main函数的地方添加暂停，程序被加载后先不调用COM口函数。

  SbieSvc，SbieDrv先要通过KmdUtil停止卸载，自编译程序SbieDrv.sys，SbieSvc.exe，SbieDll.dll，SandboxieDcomLaunch.exe和SandboxieRpcSs.exe替换至Sandbox目录，重新启动沙箱，加载编译后的组件。

  SbieDll工程附加到Unit.exe上，RPC和DCOM附加SandboxieRpcSs.exe
和SandboxieDcomLaunch.exe，这时候程序回车运行，开始动态调试。
  沙箱内进程通过LDR注入成功后，进程加载系统DLL会被SbieDLL感染，Unit.exe调用CoCreateInstance方法会被挂钩至SbieDLL!Com_CoCreateInstance，下断后Unit.exe中回车，如下图所示：

  Sandboxie RPC，COM处理分为两个步骤，重定向和隔离。沙箱通过SbieDll Hook进程RPC，COM相关API，将沙箱内进程请求重定向至SandboxieRpcSs进程，SandboxieRpcSs实现隔离，部分重定向操作等同于隔离，需要具体区分。

  SandboxieRpcSs是一个被遗忘的进程，以往的见解中，包括各类QQ群"老炮"给出的解决方案，对SandboxieRpcSs绝口不提，对于RPC特别喜欢把重定向和隔离的概念混淆，另外绕过重定向和绕过隔离也是两个概念，不能混为一谈。
  代码还没有运行，发现RpcSs和DcomLaunch进程已经启动，虽然SbieDll也有触发时机，并不是启动RPC最早的时机。

  沙箱内RPC进程通过SbieSvc.exe启动，SboxSvc中有处理COMProxy的模块。

  RpcSs启动失败会抛出2337的错误，Plus这个地方做了重试，会不停的启动RpcSs服务。
  epmapper是RPC架构服务之一，负责RPC动态端口分配的服务，可以列出公开接口。客户端请求RPC，这时候就会找epmapper来询问相关信息，epmapper返回给客户端正确的端口和数据。
  DCOM请求先要构造出来RPC服务，才能处理DCOM请求。SandboxieRpcSs是基础组件，沙箱内任何进程请求epmapper都应该先拉起SandboxieRpcSs进程，否则沙箱内肯定是处理不了RPC请求。
SandboxieRpcSs进程启动以后，关键逻辑如下：

  WinSxs全称叫Side by Side，负责管理组件版本，系统位置C:\Windows\WinSxS，Sxs是微软提出"并行组件存储"解决方案。简单理解WinSxs下可以同时保存多个副本VC++运行库，每个程序都用自己的DLL版本。复杂的COM应用中，为不同组件分配独立的激活上下文，避免全局DLL版本冲突。
  Sandbox启动RPCSS服务的时候，Sxs_Thread线程非常关键，目的是为了Sandbox沙箱提供隔离的组件版本管理，非常有意思的隔离方案。
  sxs.dll和ole32.dll动态库加载SxsGenerateActivationContext，CreateStreamOnHGlobal，基于SxsGenerateActivationContext确保插件依赖的正确版本DLL被加载，使用CreateStreamOnHGlobal将插件配置或资源数据封装为流，供COM组件安全使用。

  创建队列，接收沙盘请求SbieDll_QueueCreate，Sxs_Request处理，Sxs_Generate解析请求数据，比如清单/配置文件，语言，架构等等，用来生成上下文句柄，并通过pCreateStreamOnHGlobal创建ManifestStream，ConfigStream，创建IStream对象.

  Sxs_GenerateHelper版本差异化处理，根据Windows版本将ISteam对象填充SXS_GENERATE_ACTIVATION_CONTEXT_VISTA_ARGS结构，通过pSxsGenerateActivationContext生成hSection.

沙盒进程通过hSection映射私有组件数据，LPC将数据回包给RPCSS_SXS

  除了上述Sxs处理，还做了网络隔离，服务隔离，注册表权限模拟，StartRpcEptMapper和Service_Start_ServiceMain，分别创建了RpcEptMapper和RPCSS服务。
  RPCSS服务COM/DCOM的核心服务，处理对象激活请求、解析分布式组件分布式通信的基石，Win7以上系统，需要额外启动RpcEptMapper服务，用于管理RPC端点映射数据库，确保RPC接口标识符的正确解析，注册会被SCM Hook拦截进入到my_StartServiceCtrlDispatcherW启动。

  ServiceMain调用会触发RpcRt_RpcBindingFromStringBindingW和AlpcConnect，最终会通过Ipc_Start沙箱内部启动RpcSs服务。

  ncalrpc:[lsasspirpc]是LSASS（Local Security Authority Subsystem Service）进程关联，负责系统安全策略、用户认证（如 NTLM/Kerberos）、凭证管理等敏感操作。
  ncalrpc:[lsapolicylookup]用于LSA（Local Security Authority）策略查询，例如检查用户权限、安全组策略、域信任关系等。
  actkernel是启动SandboxieDcomLaunch定义的服务事件，并非RPC标准的功能。
  题外话，Mimikatz通过ncalrpc:[lsasspirpc]连接到 LSASS，调用 Lsapirpc 接口读取进程内存，提取明文密码或票据。

Rpcss服务的依赖关系

  DCOM Server Process Launcher负责启动和监控DCOM服务进程，按需激活DCOM对象，管理DCOM的进程周期，另外要与RPCSS服务协同工作，确保分布式跨进程/机器的通信。DCOM服务依赖于RPCSS的UUID解析，测试用例中调用了CoCreateInstance，就是激活了DCOM对象。
  See DoLingerLeader和linger.c文件，提供了一种LingerProcess机制来检测沙箱内服务，Add_LL_Entry将SandboxieDcomLaunch添加成LingerProcess，包括Crypto，BITS，WUAU等组件。

  ProcessStartMonitor线程监听SESSION_PROCESS事件，通过SbieApi_EnumProcessEx枚举沙盒内进程，有新进程调用AddPid注册进程句柄监控。

  RpcSs进程Hook_Service_Control_Manager对SCM服务进行了Hook，重定向到沙盒内部。

  沙箱内对CreateFileMappingW函数做了处理，创建共享内存区域ComPlusCOMRegTable，模拟DCOM注册表的全局状态。

  SandboxieRpcSs初始化成功以后，会向SbieSvc发送MSGID_SBIE_INI_RUN_SBIE_CTRL的消息事件。

  SandboxieDcomLaunch启动以后，对SCM,Token进行了HOOK，注册了DCOMLAUNCH的服务，模拟Dcom服务加载对应的请求，DcomLauncher本身没太多技术细节，不做详细分析。

  沙箱内进程COM请求重定向到RpcSs进程服务中，有很多种解决方案可以用，sandboxie这块做的也比较细化，有黑白名单的概念。

  CoCreateInstance/CoCreateInstanceEx：拦截对象创建，检查CLSID是否在允许列表，也可以阻止特定类实例化，如ClosedClsid直接返回失败。
  Com_IClassFactory_New使用自定义工厂实例化对象，转发请求到沙箱内进程。CoGetClassObject也需要做同样的处理，创建和获取都不会绕过沙箱对CLSID处理。

  沙箱没设置CLSID授权列表，测试用例创建和获取COM对象，不会执行Com_IClassFactory_New，直接调用系统函数__sys_CoCreateInstance，如何将请求重定向沙箱SandboxRpcSs进程呢？
  See Ipc_NtAlpcConnectPort，Unit进程请求了InternetExplorer.Application的实例，实例被转换成了CLSID，会触发\RPC Control\epmapper，如果是沙箱内进程epmapper请求，检测DocmLaunch注册表和DcomLaunch Event.

AlpcConnectPort将PortName修改成沙箱内的SboxName，\Sandbox\zy.chen\DefaultBox\Session_3\RPC Control\epmapper

  还有个概念，比如新的进程iexplore.exe进程会向RPCSS服务注册一个唯一的RPC端点，也会被重定向沙箱内，Ipc_NtAlpcCreatePort也会重定向到沙箱内路径。

  CoCreateInstance原理感兴趣朋友，可以基于combase.dll组件对CoCreateInstance流程IDA逆向下，也可以基于DeepSeek来分析下，坑肯定有的，把符号表和汇编输入，输出的结果如下：

  DeepSeek仅做参考，另一种快捷的梳理方式，基于vs2019可以直接栈回溯，这里在SbieDll!Alpc模块下断，Ipc_NtAlpcConnectPortEx栈回溯

  除了上面的Alpc Name重定向之外，上文提到SandboxieRpcSs Sxe_Thread线程会处理来自于沙箱内的Rpc_Sxs消息，处理Sandboxie Sxs请求。消息事件的生产者是进程调用Sxs_CreateActCtxW产生的Sxs数据，调用SbieDll!Sxs_CallService将进程Sxs请求转发至RpcSs中处理，端口是RPCS_SXS.

  RpcSs中Sxs_CreateActCtxW处理打印如下，Sxs隔离方案是非常重要的环节，也是对抗水位较高的地方。

  SbieDLL!Ipc_StartServer函数中对死锁和策略绕过有细节处理，CreateProcess启动流程复杂，内部会加载LoadLibrary，线程B已持有加载器锁，并等待SandboxieRpcSs启动完成，就会造成死锁。

  DLL初始化阶段，调用CreateProcess启动RPC进程可能会出现这种情况，Sandboxie通过SbieSvc ProcessServer来启动。
  SbieSvc服务发消息MSGID_PROCESS_RUN_SANDBOXED，通过SbieDll_RunSandboxed函数负责发送，Svc收到消息后处理，关于SRP和AppLocker策略绕过方案，也可以直接抄作业。

  还有两个关于COM API基本处理，CoMarshalInterface和CoUnmarshalInterface，msdn对两个函数介绍，通俗来讲是序列化和反序列化。

  接口封送：Com_CoMarshalInterface将COM接口指针序列化时，若目标上下文为跨沙箱，则生成指向沙箱代理的OBJREF，确保反序列化时在沙箱内重建，另外对ISearchNotifyInlineSite对象做了特殊处理。

  比如类型dwDestContext等于MSHCTX_DIFFERENTMACHINE，这是由宿主环境的epmapper生成，代理OBJERF数据构建，通过SbieDll_CallServer封送。

  接口解封：Com_CoUnmarshalInterface检测到外部封送数据时，通过COM_UNMARSHAL_INTERFACE_REQ请求SbieSvc在沙箱内解封，返回本地代理对象。

  Com_CoUnmarshalInterface Hook函数用来解决什么问题呢？是解决SbieSvc OXID解析冲突，Sandboxie对epmapper做了隔离，处理不了沙箱外的SbieSvc epmapper注册的OXID，如果解析失败返回OR_INVALID_OXID，回滚流的位置，调用Com_CoUnmarshalInterface_Common自定义处理。
  Com_CoUnmarshalInterface_Common自定义处理，构造COM_UNMARSHAL_INTERFACE_REQ请求，通过Com_CreateProxy发送SBieSvc来处理，将SbieSvc解析的数据，在接收objidx和封送数据，SbieSvc返回激活上下文数据映射到当前进程。

  Sandboxie还有很多细节处理，Rpc，Com Hook囊括了多数关键接口，篇幅长短，不一一完整列举，本篇基础加以代码动态调试，也许可以给大家带来更多见解和思路，文中难免有纰漏，多多包涵。

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！