3、N1/N2接口破解：UE与AMF之间的NAS信令捕获与分析
各位好，我是老赵。今天咱们聊点硬核的——N1和N2接口的破解实战。这两个接口，说白了就是5G核心网里最关键的“生命线”。UE跟AMF怎么打招呼？gNB怎么跟AMF传递消息？全得靠它们。
我当年第一次在实验室抓N1接口的包时，看着满屏的NAS PDU，说实话有点懵。但后来摸清了门道，发现其实就那么几类消息在来回跑。今天我就把这点经验分享给大家。
3.1 N1接口：UE与AMF的“悄悄话”
N1接口，是UE和AMF之间的信令通道。它跑的是NAS协议。NAS消息，说白了就是手机和核心网之间的控制信令。你开机、打电话、发消息，背后都是NAS在干活。
核心要点：N1接口的NAS消息，是理解用户行为的关键。破解它，你就能知道手机在干什么、要去哪里、要什么服务。
3.1.1 NAS信令捕获
怎么抓？我习惯用Wireshark配合过滤条件。在gNB和AMF之间的N2接口上做端口镜像，或者直接在UE侧用抓包工具。嗯，这里要注意，商用网络里抓包需要权限，咱们实验室环境就随意了。
# Wireshark过滤NAS消息
nas-eps 或 nas-5gs
# 或者直接过滤N1接口的GTP-U隧道
gtp && ip.addr == [AMF_IP]我个人建议，抓包时把时间戳精度调到微秒级。为什么？因为信令流程的时序分析，有时候差几毫秒就能看出问题。我曾经遇到过一个注册失败案例，就是因为在Security Mode Complete消息后，AMF没在规定时间内收到UE的响应，结果超时了。
3.1.2 NAS消息结构
NAS消息的结构其实不复杂。它分两部分：NAS头部和NAS消息体。头部告诉你这是啥类型的消息，消息体里才是真正的参数。
| 字段 | 长度 | 说明 |
|---|---|---|
| Extended Protocol Discriminator | 1字节 | 标识是5G NAS还是EPS NAS |
| Security Header Type | 1/2字节 | 是否加密、完整性保护 |
| Message Type | 1字节 | 注册请求、服务请求、身份验证等 |
| NAS Message Body | 可变 | 具体的IE信息元素 |
你想想看，如果Security Header Type显示“未加密”，那恭喜你，这条消息里的IMSI、GUTI全是明文。这就是安全漏洞所在。
3.2 N2接口：gNB与AMF的“桥梁”
N2接口，跑的是NGAP协议。它负责管理UE的上下文、建立会话、切换基站。说白了，gNB和AMF之间所有的控制面交互，都走N2。
我的经验：N2接口的流量比N1大得多。因为每个UE的每次移动、每次业务请求，都会触发N2消息。抓包时建议按UE粒度过滤，不然数据量太大，你根本看不过来。
3.2.1 NGAP协议破解
NGAP消息分两类：UE相关的和UE无关的。UE相关的，比如Initial UE Message、Uplink NAS Transport、Downlink NAS Transport。UE无关的，比如NG Setup、Reset。
破解NGAP，关键是要看懂它的信息元素。我举个例子，Initial UE Message里有个重要字段叫“RAN UE NGAP ID”，这是gNB给UE分配的临时标识。AMF收到后，会分配一个“AMF UE NGAP ID”。这两个ID，是后续所有信令的索引。
// NGAP Initial UE Message 结构（简化）
InitialUE-Message {
protocolIEs: {
// RAN UE NGAP ID
id-RAN-UE-NGAP-ID,
// NAS-PDU (里面封装了真正的NAS消息)
id-NAS-PDU,
// 用户位置信息
id-UserLocationInformation,
// RRC Establishment Cause
id-RRCEstablishmentCause
}
}我记得有一次做渗透测试，发现某个厂商的gNB在NGAP消息里把RAN UE NGAP ID设成了固定值。这意味着什么？攻击者可以伪造任意UE的上下文，直接跟AMF通信。这就是典型的实现漏洞。
3.3 关键信令流程：注册与服务请求
这两个流程，是5G里最基础、也最重要的。你搞懂了它们，就搞懂了5G核心网的一半。
3.3.1 注册流程
UE开机，第一件事就是注册。注册流程，说白了就是UE告诉AMF：“我来了，这是我的身份，我想用网络。”
流程大致如下：
- UE发Registration Request（包含SUCI或GUTI）
- gNB封装成Initial UE Message，通过N2发给AMF
- AMF可能发起身份验证（Authentication/Security）
- AMF发Registration Accept，分配新的GUTI
- UE回Registration Complete
注意：注册流程里最容易出问题的就是身份验证环节。如果AMF没配好AUSF和UDM的地址，或者密钥不一致，UE就会卡在Security Mode Command这一步。我遇到过好几次，最后发现是UDM里的签约数据没同步。
3.3.2 服务请求流程
UE注册完了，想上网怎么办？发Service Request。这个流程比注册简单，但同样关键。
服务请求的核心目的，是让网络知道UE要开始传数据了。AMF会通知gNB建立用户面资源，然后UPF开始转发数据包。
// 服务请求的NAS消息
Service Request {
// 服务类型：信令、数据、紧急等
Service type: "data" (3)
// UE的临时标识
5G-S-TMSI: 0x12345678
// 是否允许NSSAI包含
Uplink data status: ...
}我个人觉得，服务请求流程是攻击者最喜欢下手的地方。为什么？因为UE在空闲态时，网络侧没有它的上下文。攻击者可以伪造一个Service Request，让网络误以为UE要激活会话，从而泄露用户面信息。
3.4 实战：捕获与分析
好了，理论说完了，咱们来点实际的。假设你已经在N1/N2接口上抓到了包，接下来怎么分析？
第一步，先看NAS消息类型。用Wireshark的统计功能，看看注册请求、服务请求、身份验证各占多少比例。如果身份验证消息特别多，说明网络里有人在频繁尝试接入，可能是攻击。
第二步，追踪一个UE的完整信令流。用Wireshark的“Follow”功能，按GUTI或5G-S-TMSI过滤。看看从注册到服务请求，再到去注册，整个生命周期里走了哪些消息。
第三步，检查安全参数。看NAS消息的Security Header Type，是不是所有消息都加密了？有没有明文传输的IMSI？我曾经在一个测试网络里发现，所有NAS消息都是明文，因为厂商把安全功能关了。这要是上了商用网，后果不堪设想。
避坑指南：我曾经在分析一个服务请求失败案例时，花了整整两天才找到原因。最后发现是gNB在N2接口上发的NGAP消息里，把Allowed NSSAI配错了。UE请求的切片网络不存在，AMF直接拒绝。所以，分析信令时一定要关注NSSAI相关的IE。
3.5 知识体系总览
下面这张图，是我自己整理的N1/N2接口破解的知识体系。你看一眼，就能明白今天讲的内容是怎么串起来的。
嗯，这张图基本把今天的内容都涵盖了。你把它存下来，以后做分析时对照着看，思路会清晰很多。
好了，N1/N2接口的破解就聊到这儿。记住，信令分析是个细致活，多抓包、多看、多对比，慢慢就有感觉了。下次见。
公众号:蓝海资料掘金营，微信deep3321