"f5a5a608"的hashCode为0
Java Object 中定义了hashCode()方法，返回一个hash 值，当两个对象equals 时，hashCode需要相同
String 类重写了该方法
有一个特殊的字符串"f5a5a608"，hashCode的值为 0，在构造 Jdk7u21 payload 的过程中利用到了这一点
Dynamic Proxy
在ysoserial 的代码中，大量使用了到动态代理机制来构造payload，我们来简单了解一下
当需要增加或者修改某些已存在class的功能时，会使用动态代理机制，通过创建 proxyobject 来代理实际的对象。主要涉及接口为InvocationHandler
接口中只定义了一个方法invoke()，所有 proxy object 的方法调用都会转换为调用 invoke()方法，调用方法和参数通过method和 args来传递
来看一个代理Map 接口的例子，会在所有方法的执行之前打印start 、执行完成后打印finish
Java Object 中定义了hashCode()方法，返回一个hash 值，当两个对象equals 时，hashCode需要相同
String 类重写了该方法
有一个特殊的字符串"f5a5a608"，hashCode的值为 0，在构造 Jdk7u21 payload 的过程中利用到了这一点
Dynamic Proxy
在ysoserial 的代码中，大量使用了到动态代理机制来构造payload，我们来简单了解一下
当需要增加或者修改某些已存在class的功能时，会使用动态代理机制，通过创建 proxyobject 来代理实际的对象。主要涉及接口为InvocationHandler
接口中只定义了一个方法invoke()，所有 proxy object 的方法调用都会转换为调用 invoke()方法，调用方法和参数通过method和 args来传递
来看一个代理Map 接口的例子，会在所有方法的执行之前打印start 、执行完成后打印finish
Payload分析 & 构造
TemplatesImpl
在利用payload 中，TemplatesImpl类主要的作用为：
使用_bytecodes成员变量存储恶意字节码( 恶意class=> byte array )
提供加载恶意字节码并触发执行的函数，加载在defineTransletClasses()方法中，方法触发为getOutputProperties()或 newTransformer()
我们来具体看一下，该类位于com.sun.org.apache.xalan.internal.xsltc.trax包中，用于xml document 的处理和转换，定义
TemplatesImpl 类实现了Templates和 Serializable两个接口
其中Templates接口定义如下，包含了两个方法，即之前提到触发恶意代码执行所的方法，在TemplatesImpl类中有一个private 方法 defineTransletClasses()
在方法中，调用了ClassLoader.defineClass()方法，参数为实例变量_bytecodes内的元素，该方法会将字节数组转换为Class，并加载
也就是说，通过设置_bytecodes的内容 ，调用 defineTransletClasses() 方法即可加载指定的 Class。
在代码中，一共有三个地方调用了这个方法
getTransletClasses()
getTransletIndex()
getTransletInstance()
在Java static initializer 部分提到 ClassLoader.defineClass() 并不会执行 static 代码块，所以前两个方法不满足条件，再看一下 getTransletInstance()方法
TemplatesImpl
在利用payload 中，TemplatesImpl类主要的作用为：
使用_bytecodes成员变量存储恶意字节码( 恶意class=> byte array )
提供加载恶意字节码并触发执行的函数，加载在defineTransletClasses()方法中，方法触发为getOutputProperties()或 newTransformer()
我们来具体看一下，该类位于com.sun.org.apache.xalan.internal.xsltc.trax包中，用于xml document 的处理和转换，定义
TemplatesImpl 类实现了Templates和 Serializable两个接口
其中Templates接口定义如下，包含了两个方法，即之前提到触发恶意代码执行所的方法，在TemplatesImpl类中有一个private 方法 defineTransletClasses()
在方法中，调用了ClassLoader.defineClass()方法，参数为实例变量_bytecodes内的元素，该方法会将字节数组转换为Class，并加载
也就是说，通过设置_bytecodes的内容 ，调用 defineTransletClasses() 方法即可加载指定的 Class。
在代码中，一共有三个地方调用了这个方法
getTransletClasses()
getTransletIndex()
getTransletInstance()
在Java static initializer 部分提到 ClassLoader.defineClass() 并不会执行 static 代码块，所以前两个方法不满足条件，再看一下 getTransletInstance()方法
漏洞利用
根据上一节对漏洞原因的分析，我们利用漏洞绕过eBPF verifier机制后，就可以执行任意eBPF支持的指令，当然最直接的就是读写任意内存。漏洞利用步骤如下：
1.构造eBPF指令，利用ALU指令缺陷，绕过eBPF verifier机制；
2.构造eBPF指令，读取内核栈基址；
3.根据泄漏的SP地址，继续构造eBPF指令，读取task_struct地址，进而得到task_struct->cred地址；
4.构造eBPF指令，覆写cred->uid, cred->gid为0，完成提权。
漏洞利用的核心，在于精心构造的恶意eBPF指令，这段指令在Vitaly Nikolenko的exp中是16机制字符串(char *__prog)，并不直观，笔者为了方便，写了个小工具，把这些指令还原成比较友好的形式，当然也可以利用eBPF的调试机制，在内核log中打印出eBPF指令的可读形式。
我们来看下这段eBPF程序，共41条指令(笔者写的小工具的输出)：
parsing eBPF prog, size 328, len 41
ins 0: code(b4) alu | = | imm, dst_reg 9, src_reg 0, off 0, imm ffffffff
ins 1: code(55) jmp | != | imm, dst_reg 9, src_reg 0, off 2, imm ffffffff
ins 2: code(b7) alu64 | = | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 3: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 4: code(18) ld | BPF_IMM | u64, dst_reg 9, src_reg 1, off 0, imm 3
ins 5: code(00) ld | BPF_IMM | u32, dst_reg 0, src_reg 0, off 0, imm 0
ins 6: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 7: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 8: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 9: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 0
ins 10: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 11: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 12: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 13: code(79) ldx | BPF_MEM | u64, dst_reg 6, src_reg 0, off 0, imm 0
ins 14: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 15: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 16: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 17: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 1
ins 18: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 19: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 20: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 21: code(79) ldx | BPF_MEM | u64, dst_reg 7, src_reg 0, off 0, imm 0
ins 22: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 23: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 24: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 25: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 2
ins 26: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 27: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 28: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 29: code(79) ldx | BPF_MEM | u64, dst_reg 8, src_reg 0, off 0, imm 0
ins 30: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg 0, off 0, imm 0
ins 31: code(b7) alu64 | = | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 32: code(55) jmp | != | imm, dst_reg 6, src_reg 0, off 3, imm 0
ins 33: code(79) ldx | BPF_MEM | u64, dst_reg 3, src_reg 7, off 0, imm 0
ins 34: code(7b) stx | BPF_MEM | u64, dst_reg 2, src_reg 3, off 0, imm 0
ins 35: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 36: code(55) jmp | != | imm, dst_reg 6, src_reg 0, off 2, imm 1
ins 37: code(7b) stx | BPF_MEM | u64, dst_reg 2, src_reg a, off 0, imm 0
ins 38: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 39: code(7b) stx | BPF_MEM | u64, dst_reg 7, src_reg 8, off 0, imm 0
ins 40: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
parsed 41 ins, total 41
稍微解释下，ins 0 和 ins 1 一起完成了绕过eBPF verifier机制。ins 0指令后，regs[9] = 0xffffffff，但在verifier中，regs[9].imm = -1，当执行ins 1时，jmp指令判断regs[9] == 0xffffffff，注意regs[9]是64bit integer，因为sign extension，regs[9] == 0xffffffff结果为false，eBPF跳过2(off)条指令，继续往下执行；而在verifier中，jmp指令的regs[9].imm == insn->imm结果为true，程序走另一个分支，会执行ins 3 jmp|exit指令，导致verifier认为程序已结束，不会去检查其余的dead code。
这样因为eBPF的检测逻辑和运行时逻辑不一致，我们就绕过了verifier。后续的指令就是配合用户态exp完成对kernel内存的读写。
这里还需要知道下eBPF的map机制，eBPF为了用户态更高效的与内核态交互，设计了一套map机制，用户态程序和eBPF程序都可以对map区域的内存进行读写，交换数据。利用代码中，就是利用map机制，完成用户态程序与eBPF程序的交互。
ins4-ins5: regs[9] = struct bpf_map *map，得到用户态程序申请的map的地址，注意这2条指令，笔者的静态解析并不准确，获取map指针的指令，在eBPF verifi
根据上一节对漏洞原因的分析，我们利用漏洞绕过eBPF verifier机制后，就可以执行任意eBPF支持的指令，当然最直接的就是读写任意内存。漏洞利用步骤如下：
1.构造eBPF指令，利用ALU指令缺陷，绕过eBPF verifier机制；
2.构造eBPF指令，读取内核栈基址；
3.根据泄漏的SP地址，继续构造eBPF指令，读取task_struct地址，进而得到task_struct->cred地址；
4.构造eBPF指令，覆写cred->uid, cred->gid为0，完成提权。
漏洞利用的核心，在于精心构造的恶意eBPF指令，这段指令在Vitaly Nikolenko的exp中是16机制字符串(char *__prog)，并不直观，笔者为了方便，写了个小工具，把这些指令还原成比较友好的形式，当然也可以利用eBPF的调试机制，在内核log中打印出eBPF指令的可读形式。
我们来看下这段eBPF程序，共41条指令(笔者写的小工具的输出)：
parsing eBPF prog, size 328, len 41
ins 0: code(b4) alu | = | imm, dst_reg 9, src_reg 0, off 0, imm ffffffff
ins 1: code(55) jmp | != | imm, dst_reg 9, src_reg 0, off 2, imm ffffffff
ins 2: code(b7) alu64 | = | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 3: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 4: code(18) ld | BPF_IMM | u64, dst_reg 9, src_reg 1, off 0, imm 3
ins 5: code(00) ld | BPF_IMM | u32, dst_reg 0, src_reg 0, off 0, imm 0
ins 6: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 7: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 8: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 9: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 0
ins 10: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 11: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 12: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 13: code(79) ldx | BPF_MEM | u64, dst_reg 6, src_reg 0, off 0, imm 0
ins 14: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 15: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 16: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 17: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 1
ins 18: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 19: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 20: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 21: code(79) ldx | BPF_MEM | u64, dst_reg 7, src_reg 0, off 0, imm 0
ins 22: code(bf) alu64 | = | src_reg, dst_reg 1, src_reg 9, off 0, imm 0
ins 23: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg a, off 0, imm 0
ins 24: code(07) alu64 | += | imm, dst_reg 2, src_reg 0, off 0, imm fffffffc
ins 25: code(62) st | BPF_MEM | u32, dst_reg a, src_reg 0, off fffffffc, imm 2
ins 26: code(85) jmp | call | imm, dst_reg 0, src_reg 0, off 0, imm 1
ins 27: code(55) jmp | != | imm, dst_reg 0, src_reg 0, off 1, imm 0
ins 28: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 29: code(79) ldx | BPF_MEM | u64, dst_reg 8, src_reg 0, off 0, imm 0
ins 30: code(bf) alu64 | = | src_reg, dst_reg 2, src_reg 0, off 0, imm 0
ins 31: code(b7) alu64 | = | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 32: code(55) jmp | != | imm, dst_reg 6, src_reg 0, off 3, imm 0
ins 33: code(79) ldx | BPF_MEM | u64, dst_reg 3, src_reg 7, off 0, imm 0
ins 34: code(7b) stx | BPF_MEM | u64, dst_reg 2, src_reg 3, off 0, imm 0
ins 35: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 36: code(55) jmp | != | imm, dst_reg 6, src_reg 0, off 2, imm 1
ins 37: code(7b) stx | BPF_MEM | u64, dst_reg 2, src_reg a, off 0, imm 0
ins 38: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
ins 39: code(7b) stx | BPF_MEM | u64, dst_reg 7, src_reg 8, off 0, imm 0
ins 40: code(95) jmp | exit | imm, dst_reg 0, src_reg 0, off 0, imm 0
parsed 41 ins, total 41
稍微解释下，ins 0 和 ins 1 一起完成了绕过eBPF verifier机制。ins 0指令后，regs[9] = 0xffffffff，但在verifier中，regs[9].imm = -1，当执行ins 1时，jmp指令判断regs[9] == 0xffffffff，注意regs[9]是64bit integer，因为sign extension，regs[9] == 0xffffffff结果为false，eBPF跳过2(off)条指令，继续往下执行；而在verifier中，jmp指令的regs[9].imm == insn->imm结果为true，程序走另一个分支，会执行ins 3 jmp|exit指令，导致verifier认为程序已结束，不会去检查其余的dead code。
这样因为eBPF的检测逻辑和运行时逻辑不一致，我们就绕过了verifier。后续的指令就是配合用户态exp完成对kernel内存的读写。
这里还需要知道下eBPF的map机制，eBPF为了用户态更高效的与内核态交互，设计了一套map机制，用户态程序和eBPF程序都可以对map区域的内存进行读写，交换数据。利用代码中，就是利用map机制，完成用户态程序与eBPF程序的交互。
ins4-ins5: regs[9] = struct bpf_map *map，得到用户态程序申请的map的地址，注意这2条指令，笔者的静态解析并不准确，获取map指针的指令，在eBPF verifi
漏洞影响范围&修复
因为linux kernel的内核版本众多，对于安全漏洞的影响范围往往并不容易确认，最准确的方式是搞清楚漏洞根因后，从代码层面判断，但这也带来了高成本的问题，快速应急时，我们往往需要尽快确认漏洞影响范围。
从前面的漏洞原理来看，笔者大致给一个全面的linux kernel受影响版本：
3.18-4.4所有版本(包括longterm 3.18，4.1，4.4)；
<3.18，因内核eBPF还未引入verifier机制，不受影响。
对于大量用户使用的各个发行版，还需要具体确认，因为该漏洞的触发，还需要2个条件
1.Kernel编译选项CONFIG_BPF_SYSCALL打开，启用了bpf syscall；
2./proc/sys/kernel/unprivileged_bpf_disabled设置为0，允许非特权用户调用bpf syscall
而Ubuntu正好满足以上3个条件。
关于修复，upstream kernel在3月22日发布的4.4.123版已经修复该漏洞[11][12]， Ubuntu官方4月5日也正式发布了安全公告和修复版本[13][14]，没有修复的同学可以尽快升级了。
但现在距漏洞Exp公开已经过去20多天了，在漏洞应急时，我们显然等不了这么久，回过头看看当初的临时修复方案：
1.设置/proc/sys/kernel/unprivileged_bpf_disabled为1，也是最简单有效的方式，虽然漏洞仍然存在，但会让exp失效；
2.使用Ubuntu的预发布源，更新Ubuntu 4.4的内核版本，因为是非正式版，其稳定性无法确认。
因为linux kernel的内核版本众多，对于安全漏洞的影响范围往往并不容易确认，最准确的方式是搞清楚漏洞根因后，从代码层面判断，但这也带来了高成本的问题，快速应急时，我们往往需要尽快确认漏洞影响范围。
从前面的漏洞原理来看，笔者大致给一个全面的linux kernel受影响版本：
3.18-4.4所有版本(包括longterm 3.18，4.1，4.4)；
<3.18，因内核eBPF还未引入verifier机制，不受影响。
对于大量用户使用的各个发行版，还需要具体确认，因为该漏洞的触发，还需要2个条件
1.Kernel编译选项CONFIG_BPF_SYSCALL打开，启用了bpf syscall；
2./proc/sys/kernel/unprivileged_bpf_disabled设置为0，允许非特权用户调用bpf syscall
而Ubuntu正好满足以上3个条件。
关于修复，upstream kernel在3月22日发布的4.4.123版已经修复该漏洞[11][12]， Ubuntu官方4月5日也正式发布了安全公告和修复版本[13][14]，没有修复的同学可以尽快升级了。
但现在距漏洞Exp公开已经过去20多天了，在漏洞应急时，我们显然等不了这么久，回过头看看当初的临时修复方案：
1.设置/proc/sys/kernel/unprivileged_bpf_disabled为1，也是最简单有效的方式，虽然漏洞仍然存在，但会让exp失效；
2.使用Ubuntu的预发布源，更新Ubuntu 4.4的内核版本，因为是非正式版，其稳定性无法确认。
网络安全公司CrowdStrike旗下的猎鹰传感器（Falcon Sensor）的一次软件更新引发了一场全球危机，导致全球安装有Windows系统计算机出现大规模的蓝屏死机（blue screen of death,即BSOD），结果数千架航班被迫停飞、医院陷入混乱、支付系统崩溃，直接影响了数百万用户，成为历史上最大的 IT 故障。初步统计，宕机事件给财富 500 强企业造成高达 54 亿美元的损失。
此次宕机是由于CrowdStrike猎鹰传感器的更新中存在缺陷而引发的，相关更新出现一个逻辑错误进而导致系统崩溃，特别是Windows设备。
此次宕机是由于CrowdStrike猎鹰传感器的更新中存在缺陷而引发的，相关更新出现一个逻辑错误进而导致系统崩溃，特别是Windows设备。
Premise 在 2019 年为美国为首的阿富汗联合特种作战特遣部队准备的一项技术宣传中，提出了三种潜在用途，这些用途可以响应指挥官的信息需求：1、衡量美国信息作战的有效性; 2、侦察和绘制关键的社会结构，如清真寺、银行和网吧；3、在 100 平方公里的区域内秘密监控信号塔和 Wi-Fi 信号
从这份材料的介绍显示，阿富汗的接包者上传的数据非常有价值，只可惜美国要撤军阿富汗，可能之后单子会越来越少了
非洲特种作战司令部 (SOCAFRICA) 的美国空军 (USAF) 组成部分与海军特种作战 (NSW) 部队一起，需要下一代情报、监视和侦察 (ISR) 能力，以实现远程和动态重新分配任务地面进入作战环境 (OE) 以支持后果严重的反暴力极端主义组织 (VEO) 任务。使用数据科学和机器学习 (ML)，Premise 的目标是通过一个由超过 600,000 名人类数据贡献者组成的呈指数增长的全球网络来满足 SOCAFRICA 的关键要求，从而在整个非洲大陆实现大规模可扩展的虚拟收集（定向观察、相关情感和无线网络映射）。 ”在2020年7 月，Premise 向英国政府提交了一份功能性描述的文件，称它可以从其贡献者的手机中捕获 100 多种类型的元数据，并将其提供给付费客户：包括手机的位置、类型、电池电量和已安装的应用程序。
从这份材料的介绍显示，阿富汗的接包者上传的数据非常有价值，只可惜美国要撤军阿富汗，可能之后单子会越来越少了
非洲特种作战司令部 (SOCAFRICA) 的美国空军 (USAF) 组成部分与海军特种作战 (NSW) 部队一起，需要下一代情报、监视和侦察 (ISR) 能力，以实现远程和动态重新分配任务地面进入作战环境 (OE) 以支持后果严重的反暴力极端主义组织 (VEO) 任务。使用数据科学和机器学习 (ML)，Premise 的目标是通过一个由超过 600,000 名人类数据贡献者组成的呈指数增长的全球网络来满足 SOCAFRICA 的关键要求，从而在整个非洲大陆实现大规模可扩展的虚拟收集（定向观察、相关情感和无线网络映射）。 ”在2020年7 月，Premise 向英国政府提交了一份功能性描述的文件，称它可以从其贡献者的手机中捕获 100 多种类型的元数据，并将其提供给付费客户：包括手机的位置、类型、电池电量和已安装的应用程序。
华尔街日报还报道称，该公司的APP曾对阿富汗的用户发布了几项任务，其中有识别和拍摄喀布尔西部主要由哈扎拉什叶派少数民族成员组成的部分地区的什叶派清真寺。在过去五年中，该地区曾多次遭到XX袭击，被采访的阿富汗用户说他认为这些任务可能涉及间谍活动，因此没有接受
国际钓鱼执法行动收网：通过加密聊天平台截获通讯信息
在2018年，美国FBI与澳大利亚警方在联合查封了加密聊天平台 Phantom Secure ，并通过在控制平台期间抓捕了大量犯罪分子，而该事件的发生也让FBI产生了新的想法，为何不自己运营一个加密聊天平台进行钓鱼执法呢？
当想法一出，行动立马跟上，同年一个名为 Ironside 的钓鱼执法行动正式执行开启。主要原因在于他们由于查封了前一个加密聊天平台，那么其中的犯罪分子必然会转移到一个新的平台，因此控制另一个新的平台成为FBI的主要目标。
除了单独发行聊天软件外，该平台有一项服务是一台主打安全性的智能手机，该手机不会运行除 An0m 之外的其它任何应用程序，而An0m程序功能非常简单，只有发短信、变声发语音、录视频的功能，并会提供比特币支付，完全是给犯罪分子量身定做。
这项服务通过用户之间互相推荐以及通过 http://anom.io 网站进行传播，但激活软件需要有推荐码才可正常使用，因此使用该加密聊天平台的基本都是犯罪分子社交圈的。
该服务宣称允许手机用户在设备之间发送加密的文本和语音消息，并阻止他们安装任何其它应用程序。
此外，这款 An0m应用程序无需通过手机号码来注册使用，并通过 An0m 的服务器控制平台转发所有消息。
黑鸟通过查阅诉讼书，发现自2018年10月起An0m 内部人员提供了对 FBI 的访问权限，并建立了一个中转机制，使其能够向FBI发送所有消息的副本。
诉讼书还称，所有位于美国境外的 An0m 设备都配置为将所有消息发送到第三方 XMPP 机器人，机器人将解密消息，然后使用由 FBI 管理的加密密钥重新加密它们。这种设计使 FBI 能够拦截帮派成员相互发送的消息和解密文本。
虽然联邦调查局已经制定了该计划，但由于管辖权问题，主要是澳大利亚当局审查了这些消息，诉讼书表示该计划非常成功，一个欧洲国家托管了另一台机器人服务器，并帮助筛选了超过 2600 万条加密消息。
FBI最初依靠卧底特工来推广 An0m 设备，但随着执法机构关闭EncroChat 和 Sky ECC等加密聊天竞争平台 ，犯罪团伙开始慢慢转向An0m平台，截止收网有300多个犯罪集团，大约12000 个加密设备被 100 多个国家犯罪分子使用
An0m用户分布情况如下，可以看见我国也有用户
在收网行动期间，澳大利亚联合欧美多国机构的力量，以拦截遍布世界各地的犯罪团伙成员之间的秘密通讯。被捕的数百名犯罪分子的涉及澳大利亚、亚洲和南美，且涉及毒、武器和人口贩运等
在2018年，美国FBI与澳大利亚警方在联合查封了加密聊天平台 Phantom Secure ，并通过在控制平台期间抓捕了大量犯罪分子，而该事件的发生也让FBI产生了新的想法，为何不自己运营一个加密聊天平台进行钓鱼执法呢？
当想法一出，行动立马跟上，同年一个名为 Ironside 的钓鱼执法行动正式执行开启。主要原因在于他们由于查封了前一个加密聊天平台，那么其中的犯罪分子必然会转移到一个新的平台，因此控制另一个新的平台成为FBI的主要目标。
除了单独发行聊天软件外，该平台有一项服务是一台主打安全性的智能手机，该手机不会运行除 An0m 之外的其它任何应用程序，而An0m程序功能非常简单，只有发短信、变声发语音、录视频的功能，并会提供比特币支付，完全是给犯罪分子量身定做。
这项服务通过用户之间互相推荐以及通过 http://anom.io 网站进行传播，但激活软件需要有推荐码才可正常使用，因此使用该加密聊天平台的基本都是犯罪分子社交圈的。
该服务宣称允许手机用户在设备之间发送加密的文本和语音消息，并阻止他们安装任何其它应用程序。
此外，这款 An0m应用程序无需通过手机号码来注册使用，并通过 An0m 的服务器控制平台转发所有消息。
黑鸟通过查阅诉讼书，发现自2018年10月起An0m 内部人员提供了对 FBI 的访问权限，并建立了一个中转机制，使其能够向FBI发送所有消息的副本。
诉讼书还称，所有位于美国境外的 An0m 设备都配置为将所有消息发送到第三方 XMPP 机器人，机器人将解密消息，然后使用由 FBI 管理的加密密钥重新加密它们。这种设计使 FBI 能够拦截帮派成员相互发送的消息和解密文本。
虽然联邦调查局已经制定了该计划，但由于管辖权问题，主要是澳大利亚当局审查了这些消息，诉讼书表示该计划非常成功，一个欧洲国家托管了另一台机器人服务器，并帮助筛选了超过 2600 万条加密消息。
FBI最初依靠卧底特工来推广 An0m 设备，但随着执法机构关闭EncroChat 和 Sky ECC等加密聊天竞争平台 ，犯罪团伙开始慢慢转向An0m平台，截止收网有300多个犯罪集团，大约12000 个加密设备被 100 多个国家犯罪分子使用
An0m用户分布情况如下，可以看见我国也有用户
在收网行动期间，澳大利亚联合欧美多国机构的力量，以拦截遍布世界各地的犯罪团伙成员之间的秘密通讯。被捕的数百名犯罪分子的涉及澳大利亚、亚洲和南美，且涉及毒、武器和人口贩运等