1. 拥有要下载的profile的运营商，通过调用 ES2.DownloadProfile 功能（输入数据为 SM-SR的标识符和地址，这些应该由运营商提供）。
默认情况下， profile处于disabled状态。当然，运营商可以要求SM-DP在最后启用新下载的profile

2. 受到请求的 SM-DP ，应该调用ES3.GetEIS

3. SM-SR 应基于EID来取得 euicc的 EIS信息。 如果在它的系统里，没有这张euicc的信息，应该返回一个错误。
错误信息最终返回给运营商，运营商终止 profile下载过程

4. EIS信息中， 卡上的ISD-P 用 smdp-id 将此卡与 特定的SM-DP关联起来， 如果SM-SP尝试删除此euicc旧有的profile

5. SM-DP检查 euicc是否满足download profile的一些要求。
1） uicc的特性是否同profile兼容
2） uicc的ram/storage是否够用
3） uicc是否认证过(certified)

SM-DP应该验证 EIS信息中 关于该uicc的ECASD的证书， 使用CI签发的EUM的证书，来验证 ECASD证书的 PK.ECASD.ECKA密钥

6. SM-DP调用ES3.CreateISDP

7.

扫描esim服务提供商的二维码 来下载esim数据，比自己手动收入 激活码来下载，要容易得多。

购买esim服务后，一般会收到一封电子邮件，里面含有完整的激活字符串 和/或 它的二维码，比如

LPA:1$esim.wo.com.cn$A1B2C3D4

其中 SM-DP+ 的地址就是 esim.wo.com.cn

激活码是 A1B2C3D4
确认码是 空， 也就是没有

这些内容在 SGP.22 规范中定义

中国移动

LPA:1$esim.yhdzd.chinamobile.com:8001$

既没有 激活码，也没有确认码

中国联通

LPA:1$esim.wo.com.cn$1.3.6.1.4.1.47814.101.8

没有激活码，
有确认码，为 1.3.6.1.4.1.47814.101.8

java.util.Base64 是在 Java 8 中添加的， Android早期是基于 Java 7的，所以自己搞了个android.util.Base64
android的base64编码后，默认会添加换行符号 “\n”

Base64.encodeToString(byte_array, Base64.NO_WRAP)

指定 NO_WRAP 参数，就不会换行
就同

Base64.getEncoder().encodeToString(byte_array)

的编码结果一样了

ETSI TS 133 220 V17.4.0 (2023-01) 第44页

FC = 0x01
P0 = gba-me 也就是 十六进制 67 62 61 2d 6d 65 , Ks_NAF 和 Ks_ext_NAF都用这个参数
L0 = P0的长度， 6字节， 也就是 00 06
P1 = RAND
L1 = RAND的长度，16字节， 也就是00 10
P2 = IMPI ，以 UTF-8 编码
L2 = IMPI的长度， 不大于 65535
P3 = BSF_Id ， 以 UTF-8 编码
L3 = BSF_Id的长度，小于 65535

BSF_Id 就是生成 B-TID的 BSF 服务器，在DNS系统的完整名称（比如 bsf.mnc002.mcc460.pub.3gppnetwork.org）， 同Ua安全协议标识符
01 00 00 01 00 的拼接

Ks就是 CK IK的拼接。
TMPI 就是 TEMP@tmpi.org
其中 TEMP是 KDF输出的最前面的24个字节的 base64编码

python代码如下

s = fc + p0 +l0 + p1 + l1 + p2 + l2 + p3 + l3
k = ck +ik
h = hmac.new(k, digetmod=hashlib.sha256)
h.update(s)
temp = h.diget()[:24]
tmpi = base64.b64encode(temp).decode() + '@tmpi.bsf.3gppnetwork.org'

Ua安全协议标识符 是一个5个字节的 字符串(string).
第1个字节，表示， 制定该Ua安全协议的 组织。
后面的4个字节，则指 该组织 定义的某种安全协议。

组织者字节
01 = 3GPP
02 = 3GPP2
03 = Open Mobile Alliance
04 = GSMA

01 00 00 00 00 = 按照TS 33.221定义的安全协议
01 00 00 00 01 = TS 33.246
01 00 00 00 02 = TS 24.109 定义的 Ua security protocol HTTP digest authentication
01 00 00 00 03 = TS 26.237 定义的 Ua security protocols used with HTTP-based security procedures for
MBMS user services
01 00 00 00 04 = TS 26.237定义的 Ua security protocols used with SIP-based security procedures for
MBMS user services

01 00 00 01 00 = Generation of TMPI
0x01,0x00,0x01,yy,zz = TS 33.222定义的 Ua security protocol for “Shared key-based UE authentication with
certificate-based NAF authentication” 或者 “Shared key-based mutual authentication between UE and NAF” for TLS 1.2 (see above for Ua security protocol identifier for TLS 1.3 with shared keys)
这里， “yy,zz” 是保护机制 CipherSuite code, 定义在 IANA 加密套件的TLS CipherSuites的定义的值。 RFC 8446
比如， The TLS 1.2 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 的值是 { 0xC0,0x2B }

( 0x01,0x00,0x02,yy,zz )

/private/var/mobile/Library/Carrier Bundles/Overlay/

device+carrier+46000+N71+50.0.plist
用iplistutils从 binary转为 xml

bison build-essential curl flex g++-multilib gcc-multilib git git-lfs gnupg
liblz4-tool libncurses libncurses-dev
libssl-dev libxml2 libxml2-utils lzop pngcrush rsync
zip zlib1g-dev

ccache

尤其是 git-lfs 要装上， 不然

方法1： https://www.mobibrw.com/2021/28588

将 gadget
bullhead/out/target/product/bullhead/system/lib/
bullhead/out/target/product/bullhead/system/lib64/
两个目录中
libgood.so

touch libgood.config.so
内容为

{
  "interaction": {
    "type": "listen",
    "address": "127.0.0.1",
    "port": 27042,
    "on_load": "resume"
  }
}

没有这个配置文件，默认也是采用这个配置。

只需要监听子进程，不需要在Zygote中加载，因此只需要在源代码 frameworks/base/core/jni/com_android_internal_os_Zygote.cpp 的com_android_internal_os_Zygote_nativeForkAndSpecialize函数中增加加载代码：

位于
framework/base/core/jni/com_android_internal_os_Zygote.cpp

在 build/make/target/product/handheld_system.mk 添加对 so的复制

=======================
https://www.sunofbeach.net/a/1620356163351797762

修改app的启动流程，在启动期间去加载so。

在frameworks/base/core/java/android/app/ActivityThread.java中的handleBindApplication

方法中，找到Application创建之前的位置，经过我的测试onCreate之后加载so也可以的！加入如下代码：

这阶段主要是判断app是否需要持久化hook，不是所有的app都需要这样，正常流程。
==================

http://zhuoyue360.com/crack/78.html

================
https://blog.csdn.net/Crazy__Hope/article/details/123113405

0. 在Debian bookworm 准备编译环境

apt install git gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5   libx11-dev  libxml2-utils  unzip fontconfig

1. 安装repo

apt install repo
或者
curl -o ~/bin/repo https://storage.googleapis.com/git-repo-downloads/repo 
检查版本， 2.15版本以上
repo version

3. 查看要构建的 Pixel版本

https://source.android.com/docs/setup/about/build-numbers?hl=zh-cn#source-code-tags-and-builds

SP1A.210812.016.C2 android-12.0.0_r34 Android12 Pixel 3、Pixel 3 XL 2021-10-05
选择 SP1A.210812.016.C2 android-12.0.0_r34

https://developers.google.com/android/drivers#bluelinesp1a.210812.016.c2

https://dl.google.com/dl/android/aosp/google_devices-blueline-sp1a.210812.016.c2-47172864.tgz
https://dl.google.com/dl/android/aosp/qcom-blueline-sp1a.210812.016.c2-7c544085.tgz

4. 下载源代码， 选择 r34

mkdir aaos_on_phone
cd aaos_on_phone
repo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r34 --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M
repo sync -j8 -c -q

新的 –use-superproject –partial-clone 很有用，只下载有用的部分，会加快下载速度

5.下载并解压缩 专有二进制文件和补丁程序 （供应商映像和 Qualcomm 驱动程序）

curl --output - https://dl.google.com/dl/android/aosp/google_devices-blueline-sp1a.210812.016.c2-47172864.tgz  | tar -xzvf -
tail -n +315 extract-google_devices-blueline.sh | tar -zxvf -

curl --output - https://dl.google.com/dl/android/aosp/qcom-blueline-sp1a.210812.016.c2-7c544085.tgz | tar -xzvf -
tail -n +315 extract-qcom-blueline.sh | tar -xzvf -

6. 编译

. build/envsetup.sh
lunch aosp_blueline-userdebug
m

make -j8

7. 刷入手机

adb reboot bootloader
fastboot -w flashall

因为 $ANDROID_PRODUCT_OUT 变量设置为 out/target/product/blueline ， 所以可以用上面的命令

编译内核

export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo'
repo init --depth 1 -u https://aosp.tuna.tsinghua.edu.cn/kernel/manifest -b android-msm-crosshatch-4.9-android11
repo sync -j20

https://hqw700.github.io/2021/01/02/aosp-kernel-build/
https://hqw700.github.io/2021/01/01/aosp-build/

Generic Bootstrapping Architecture (GBA) ETSI TS 133.220

UE 用户设备
NAF: Network Application Function 网络应用功能，需要对UE认证的第3方服务
Bootstrapping Server Function 运营商提供的认证服务器

大致流程：
1. UE访问 NAF
携带自己的 X-3GPP-Intended-Identity 和/或 subscriber-id（IMSI)

2. 如果NAF要求使用 通过GBA方式获得的key, 而UE 的请求中没有包含
GBA相关的参数， NAF就应该回复一个 bootstrapping 初始化消息。

3. 当UE需要同NAF交互，并且它也知道需要bootstrapping过程。那么，
它应该首先执行一个 bootstrapping认证过程。
否则， 只有如下3种情况
1）当UE收到 “bootstrap初始化要求”消息时，
2） 来自NAF的bootstrap协商指示
3） UE里的key过期
它才会执行 bootstrap 认证。

4. 认证遵循的技术规范–TS 33.102 AKA , RFC 3310 HTTP digest AKA
4.1 UE发送请求(包含自己的identity,imsi或者mdn）给 BSF
4.2 BSF同 HSS沟通，拿到鉴权向量(AV)和用户profile
4.3 BSF发送 401 未授权响应 给UE, 响应中包括(RAND, AUTN)
4.4 UE 在USIM卡上运行 AKA算法， 验证AUTN， 并从RES中生成key
4.5 发送认证请求给BSF, 请求中带有RES
4.6 BSF检查RES是否正确， 生成B-TID标识和对应的生命周期

在UE向BSF请求的头部， user-agent必须使用
User-Agent: 3gpp-gba-tmpi
BSF给UE的响应中，也要带这个头部

5.1 UE发送给BSF的http请求中，如果同IMPI关联的TMPI,已经可以在UE中可用。那么
UE应该将此TMPI放到 username参数中，否则， UE应该将IMPI放到 username参数。

5.2 BSF可以从username参数识别出它是TMPI还是IMPI.
如果是TMPI, 它将被本地的数据库中查询对应的IMPI
如果BSF没有找到对应的IMPI, 它将返回一个错误信息给UE.
UE将删除此TMPI,并使用IMPI重发请求。

5.3 BSF从HSS获取一组 AV(rand, autn, xres, ck,ik), 并
用HTTP 401响应 转发 RAND和AUTH给UE, 响应中不含(CK, IK, XRES,这些是需要UE自己计算的）
5.4 UE检查AUTN, 验证网络是否靠谱。也用RAND计算出CK, IK， RES.
5.5 UE发送另外一个http请求，里面包含有 AKA响应（计算出的res)给BSF
5.6 BSF通过aka 响应认证这个UE
请注意：AKAv1的 HTTP Digest AKA里的password是二进制格式
5.7 BSF用CK和IK生成 Ks. B-TID应该用 NAI个格式， 并以rand来做base64：
bas64encode(RAND)@BSF_servers_domain_name
注意：如果HSS 使用了好的随机数生成器，B-TID冲突的可能性为0.
但万一冲突， 那么从NAF取得的key,可能同 UE生成的，不匹配。
这是， NAF会再次要求做bootstrap, 重建新的B-TID和Ks
5.8 BSF发送 200 OK响应，包含B-TID, 发送给UE,告诉他 认证成功。

5.9
Ks_NAF = KDF(Ks, “gba-me”, RAND, IMPI, NAF_Id)
这里 KDF, 是一个密钥生成算法
NAF_Id = NAF的FQDN || Ua 安全协议标志

3GPP TS 23.003 从 IMSI或者IMPI 生成 BSF的地址， 例如 ： bsf.mnc002.mcc460.pub.3gppnetwork.org

bootstrap 基于 HTTP Digest AKA算法

ETSI TS 124 109 V17.2.0 (2022-07) 第48页

The UE generates the HTTP request by calculating the Authorization header values using the bootstrapping
transaction identifier B-TID it received from the BSF as the username and the NAF specific key material
Ks_(ext)_NAF (base64 encoded) as the password, and sends the request to the AP.

B-TID 作为 username, Ks_NAF(用base64编码过）作为 password, 计算 HTTP Digest响应，并发送给AP

UE在http头部 将UserAgent设置为 3gpp-gba-tmpi ，来告诉BSF，自己是支持TMPI的
BSF也要在响应头部中，设置 “Server” 为 3gpp-gba-tmpi, 来告诉UE, 自己是支持 TMPI的

If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI,
according to 3GPP TS 23.003
如果SIM卡中没有ISAM的AID, 那么也就不存在IMPI文件，那么IMPI应该按照 TS 23.003 从 IMSI构造

在BSF阶段， username应为 IMPI 或者 TMPI
uri 可以为相对路径 “/”

The key material shall be derived from AKA parameters as specified in 3GPP TS 33.220
就是 CK/Ik的拼接

ETSI TS 124 109 V17.2.0 (2022-07) 第16页
NAF阶段
username 就是 boottrap返回的 B-TID
GBA_ME模式下， password就是Ks_NAF（ NAF specific key material）
Ks_NAF由Ks生成，算法在 3GPP TS 33.220 定义

The NAF specific key material (Ks_NAF）使用是要按照 RFC 4648 进行base64编码

GBA-ME情况下， realm的形式应该是 3GPP-bootstrapping@naf_FQDN
比如 “3GPP-bootstrapping@naf1.operator.com”

UE 和 NAF 使用 HTTPS 进行认证
在进行http通信前， 有三种认证方式
1） 基于共享密钥的UE认证（(HTTP Digest)，同时 基于证书的NAF认证(TLS)
2) UE和NAF 基于共享密钥的双向认证 (PSK TLS)
3) UE 和 AS 基于 证书的 双向认证

UE和NAF 应该支持在 3GPP TS 33.310 附录 E中 所指定的TLS版本
3GPP TS 33.222的 5.3.1 节 有对TLS的详细描述

第1种认证方式：
基于ME的应用所要求的认证机制，在ME中必须实现，在NAF中可选实现。
基于UICC的应用所要求的认证机制，在UICC和NAF中，都是可选实现。

（1）在UE同NAF通信时， 它应该同NAF建立一个TLS通道。
NAF 通过公钥证书向 UE 进行身份验证。 UE应验证 服务器证书 是否 它与之建立隧道的 NAF 的 FQDN是对应的。
没有 客户端身份验证 作为 TLS 的一部分执行（不需要客户端证书）。
（2）UE将在 TLS通道(https，也就是http over tls)发送 http请求给NAF, 这与前面讲的 http digest 认证是一样的
（3）NAF跟之前的一样，用 HTTP Digest 认证 UE的请求

第2种认证（共享密钥的双向认证）：
基于ME的应用，这第2种认证方式，在ME和NAF中都是可选的
基于UICC的， 第2种认证方式，在 UICC和NAF中也都是可选的

基于 PSK 的 TLS 身份验证 (PSK TLS) 可以与自举安全关联一起用作身份验证、机密性和完整性保护方法。 与 PSK TLS 一起使用的 TLS 和 TLS 扩展的配置文件在 3GPP TS 33.310 的附件 E 中定义

使用TLS 1.2的认证过程
（1）
….

nonce= base64(RAND + AUTN + server specific data)

The BSF generates the bootstrapping transaction identifier (B-TID) for the IMPI and stores the tuple
(b-tid,impi,ck,ik)

The key material Ks is generated in UE by concatenating CK and IK. In the case of GBA_ME, the ME stores
the tuple (B-TID,Ks)

The NAF specific key material (Ks_NAF in the case of GBA_ME), is derived from Ks during the Ua interface procedures, and is used for securing the Ua interface. In the case of GBA_ME, the ME stores the tuple (B-TID,Ks_NAF)

For detailed bootstrapping key material generation procedure for NAF specific key (Ks_NAF) see 3GPP TS 33.220

If the conversation is taking place inside a server-authenticated TLS tunnel, the options for the qop attribute can also contain “auth” meaning that the payload of the following HTTP requests and responses are not protected by HTTP Digest. The integrity protection is handled on the TLS layer instead.

The realm attribute contains two parts delimited by “@” sign. The first part is a constant string “3GPP-bootstrapping” instructing the UE to use a bootstrapped security association. The second part is the FQDN of the NAF.
————-
UE内NAF特定key的生成

UE verifies that the second part of the realm attribute does correspond to the server it is talking to. In
particular, if the conversation is taking place inside a server-authenticated TLS tunnel, the UE shall verify
that the server name in the server’s TLS certificate matches the server name in the realm attribute of the
WWW-Authenticate header.
UE验证realm属性的第二部分，是否与它正在交谈的服务器一致。特殊地，如果会话发生在 一个服务器认证了的TLS通道内， UE应该验证服务器的TLS证书的服务器名称， 与 WWW-Authenticate头部里的realm属性的服务器名称是否匹配。

UE derives the NAF specific key material Ks_(ext)_NAF as specified in 3GPP TS 33.220 .
—————————-
43页

UE generates the HTTP request by calculating the Authorization header values using the bootstrapping
transaction identifier B-TID it received from the BSF as the username and the NAF specific key material
Ks_(ext)_NAF (base64 encoded) as the password, and sends the request to NAF.

If the conversation is taking place inside a server-authenticated TLS tunnel, the qop attribute can be set to “auth” as well.
———–
The NAF also verifies that the DNS name in the realm attribute matches its own. If the conversation is taking
place inside a server-authenticated TLS tunnel, the NAF shall also verify that this DNS name is the same as
that of the TLS server certificate.

NAF也可以验证 UE发送过来的头部的realm属性的DNS名称是否同自己的匹配。
如果会话发生在 服务器认证了的TLS通道内， 那么NAF应该也验证 这个DNS名称是同 TLS证书的名称是一样的
——————-
The “X-3GPP-Intended-Identity” header is used optionally by the UE to indicate the user identity intended to be used
with the AS. It contains the user identity surrounded by quotation marks (“).

————–

In the following request to NAF the HTTPS client sends a response with an Authorization header field where
Digest is inserted using the B-TID as username.The NAF-specific key (Ks_(ext)_NAF in the case of ME-based
application (including GBA_Digest) or Ks_int_NAF in the case of UICC-based application) is used as password
in the Digest calculation.
——-
The Ua security protocol identifier to be used is (0x01,0x00,0x02,yy,zz) as specified in Annex H of 3GPP TS 33.220
, where yy and zz are the protection mechanism CipherSuite as specified in relevant TLS specifications by IETF.

HTML FORM is tunneled through TLS, therefore the first consideration might be to use the Ua security protocol identifier for Ua security protocols that are based on TLS (HTTP Digest with HTTPS and Pre-shared key TLS) that is already specified in Annex H of 3GPP TS 33.220 (0x01,0x00,0x01,yy,zz).

This protocol id is used when the NAF specific key is used as a password in the TLS tunneled HTTP Digest case. This is substantially different, for example, from the case where HTML FORM based authentication within TLS tunnel is used, therefore a different Ua protocol id is used.

3GPP TS 33.220 Annex H中规定使用的Ua安全协议标识符为(0x01,0x00,0x02,yy,zz)，其中yy和zz为IETF相关TLS规范中规定的保护机制CipherSuite。

当 NAF 特定密钥用作 TLS 隧道 HTTP 摘要案例中的密码时，将使用此协议 ID。 这与使用 TLS 隧道内基于 HTML FORM 的身份验证的情况有很大不同，因此使用了不同的 Ua 协议 id。

HTML FORM 是通过 TLS 传输的，因此首先要考虑的是使用 Ua 安全协议标识符，该标识符基于 3GPP 附件 H 中已经规定的基于 TLS（HTTP 摘要与 HTTPS 和预共享密钥 TLS）的 Ua 安全协议 TS 33.220 (0x01,0x00,0x01,yy,zz)。

Ua security protocol identifier can be derived from the used TLS ciphersuite.
FQDN of the NAF and the Ua security protocol identifier form the NAF_ID.