/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.

Extensible Authentication Protocol
EAP是一个认证框架，EAP本身不是认证协议，它自己不支持认证功能，它是为了承载多种认证协议而生的
EAP 提供一些公共的功能，并且允许协商所希望的认证机制。这些机制被叫做 EAP 方法，现在大约有 40 种不同的方法：
EAP-MD5—MD5Hash函数容易受到字典攻击，它被使用在不支持动态WEP的EAP中
….
EAP-SIM
EAP-AKA
EAP-AKA`

主要关注 EAP-SIM/AKA

EAP-SIM/AKA 使用从移动网络中获得的鉴权三元组（EAP-SIM认证）或者五元组（EAP-AKA），得到认证需要MAC值，以及加密用的密钥
RFC 4186
RFC 4187 EAP-AKA Authentication

EAP-SIM用于GSM网络，只支持单向认证，即支持网络认证UE，但是不支持UE认证网络。
EAP-AKA是EAP-SIM的升级版本，用于3G网络中的用户认证，支持双向认证。
EAP-AKA’是一种新的EAP认证方法，在RFC5448中定义
Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement

1. 终端，发送 UMTS AKA 认证请求给USIM卡

2. USIM对AUTN 进行验证， 从而来认证网络
2.1 AUTN 不正确， 终端将拒绝这次认证；
如果SQN 失效， 将重新发起 SQN同步
2.2 如果AUTH正确， USIM将计算出 RES, IK, CK ， 返回给终端

3. 终端 从 CK 和 IK 导出所需新的密钥材料
4. 解密新的临时标识符并保存以备下次使用验证
5. 发送 含有 RES 的 EAP Response/AKA-challenge 给认证服务器

XKEY = SHA-1 (Identity | CK | IK)

FIPS 186-2 伪随机数生成器

https://www.rfc-editor.org/rfc/rfc4187.html

In the 3rd generation mobile networks, AKA is used for both radio network authentication and IP multimedia service authentication purposes.

Different user identities and formats are used for these;
the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network Access Identifier (NAI)

1. 终端向 认证服务器 发送 EAP-Request/Identity 来报告自己的身份。
2. 服务器返回 EAP-Response/Identity (包括用户的NAI)
3. 服务器运行 AKA算法，生成rand和autn
4. 服务器，下发 EAP-Request/AKA-Challenge ，里面包含
AT_RAND, AT_AUTN, AT_MAC
5. 客户端， 运行AKA算法， 验证 AUTN和MAC, 并生成RES和 session key
6. 客户端发送 EAP-Response/AKA-Challenge (包含AT_RES, AT_MAC)给服务器
7. 服务器验证RES和MAC, 发现是正确， 双方认证成功

——————–
客户端触发：
设备启动（或者设备没有重启，但是换了张 SIM卡), 并且该用户没有可用的配置时，
设备将发送一个初始http请求
—————–
永久用户名的格式

‘0’ IMSI
也就说说用户名的第一个字节是 0x30, 然后就是ascii编码的IMSI

———————–
EAP的包格式
第1个字节： Code
可能的值为
1 Request
2 Response
3 Success
4 Failure
其他值，忽略

第2个字节： Identifier
用来匹配 Request和Respone的，不然乱套了，不知道到谁是谁的响应

第3-4字节： Length
整个包的长度，包括 Code, Identifier, Length , Data

Integrity protection (AT_MAC) is based on a keyed message authentication code.
Confidentiality (AT_ENCR_DATA and AT_IV) is based on a block cipher.

The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value.
(The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes. Hence, the length of the MAC is 16 bytes.)

The derivation of the authentication key (K_aut) used in the calculation of the MAC

On EAP-AKA full authentication, a Master Key (MK) is derived from the underlying AKA values (CK and IK keys), and the identity, as follows.

MK = SHA1(Identity|IK|CK)

The Master Key is fed into a Pseudo-Random number Function (PRF),
which generates separate Transient EAP Keys (TEKs) for protecting
EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
security and an Extended Master Session Key (EMSK) for other
purposes. On fast re-authentication, the same TEKs MUST be used for
protecting EAP packets, but a new MSK and a new EMSK MUST be derived
from the original MK and from new values exchanged in the fast
re-authentication.

EAP-AKA requires two TEKs for its own purposes: the authentication
key K_aut, to be used with the AT_MAC attribute, and the encryption
key K_encr, to be used with the AT_ENCR_DATA attribute. The same
K_aut and K_encr keys are used in full authentication and subsequent
fast re-authentications.

Key derivation is based on the random number generation specified in
NIST Federal Information Processing Standards (FIPS) Publication
186-2 [PRF]. The pseudo-random number generator is specified in the
change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
specified in the change notice (page 74), when Algorithm 1 is used as
a general-purpose pseudo-random number generator, the “mod q” term in
step 3.3 is omitted. The function G used in the algorithm is
constructed via Secure Hash Standard as specified in Appendix 3.3 of
the standard. It should be noted that the function G is very similar
to SHA-1, but the message padding is different. Please refer to
[PRF] for full details. For convenience, the random number algorithm
with the correct modification is cited in Annex A.

160-bit XKEY and XVAL values are used, so b = 160. On each full
authentication, the Master Key is used as the initial secret seed-key
XKEY. The optional user input values (XSEED_j) in step 3.1 are set
to zero.

On full authentication, the resulting 320-bit random numbers x_0,
x_1, …, x_m-1 are concatenated and partitioned into suitable-sized
chunks and used as keys in the following order: K_encr (128 bits),
K_aut (128 bits), Master Session Key (64 bytes), Extended Master
Session Key (64 bytes).

On fast re-authentication, the same pseudo-random number generator
can be used to generate a new Master Session Key and a new Extended
Master Session Key. The seed value XKEY’ is calculated as follows:

XKEY’ = SHA1(Identity|counter|NONCE_S| MK)

In the formula above, the Identity denotes the fast re-authentication
identity, without any terminating null characters, from the
AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
EAP-Response/AKA-Identity was not used on fast re-authentication, it
denotes the identity string from the EAP-Response/Identity packet.
The counter denotes the counter value from the AT_COUNTER attribute
used in the EAP-Response/AKA-Reauthentication packet. The counter is
used in network byte order. NONCE_S denotes the 16-byte random
NONCE_S value from the AT_NONCE_S attribute used in the
EAP-Request/AKA-Reauthentication packet. The MK is the Master Key
derived on the preceding full authentication.

On fast re-authentication, the pseudo-random number generator is run
with the new seed value XKEY’, and the resulting 320-bit random
numbers x_0, x_1, …, x_m-1 are concatenated and partitioned into
64-byte chunks and used as the new 64-byte Master Session Key and the
new 64-byte Extended Master Session Key. Note that because K_encr
and K_aut are not derived on fast re-authentication, the Master
Session Key and the Extended Master Session key are obtained from the
beginning of the key stream x_0, x_1, ….

The first 32 bytes of the MSK can be used as the Pairwise Master Key
(PMK) for IEEE 802.11i.

When the RADIUS attributes specified in [RFC2548] are used to
transport keying material, then the first 32 bytes of the MSK
correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
(the MSK) are used.

/System/Library/PrivateFrameworks/CellularPlanManager.framework/CellularPlanManager
/System/Library/PrivateFrameworks/CellularPlanManager.framework/Contents/MacOS/CellularPlanManager
/System/Library/PrivateFrameworks/CellularBridgeUI.framework/CellularBridgeUI

—————
共享缓存机制

在iOS系统中，每个程序依赖的动态库都需要通过dyld（位于/usr/lib/dyld）一个一个加载到内存，然而，很多系统库几乎是每个程序都会用到的，如果在每个程序运行的时候都重复的去加载一次，势必造成运行缓慢，为了优化启动速度和提高程序性能，共享缓存机制就应运而生。所有默认的动态链接库被合并成一个大的缓存文件，放到/System/Library/Caches/com.apple.dyld/目录下，按不同的架构保存分别保存着
dyld_shared_cache_arm64 到 dyld_shared_cache_arm64.5

想要分析某个系统库，就需要从dyld_shared_cache里先将的原始二进制文件提取出来
———–
-[CTCellularPlanManager remotePlanLaunchInfoForEid:completion:]
-[CTCellularPlanManager didCancelRemotePlan]
-[CTCellularPlanManager pendingReleaseRemotePlan]
-[CTCellularPlanManager subscriptionDetailsForCompletion:]
-[CTCellularPlanManager didPurchaseRemotePlanForEid:imei:meid:iccid:alternateSmdpFqdn:completion:]
-[CTCellularPlanManager eraseAllRemotePlansWithCompletion:]
————————————————————————
-[CTCellularPlanItem initWithCellularPlan:uuid:iccid:name:type:phoneNumber:label:isLocalTransferToeSIMSupported:isTransferred:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem initWithCellularPlan:uuid:type:phoneNumber:label:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem initWithIccid:uuid:name:phoneNumber:label:isLocalTransferToeSIMSupported:isTransferred:transferredStatus:transferredToDeviceDisplayName:]

-[CTCellularPlanItem isLocalTransferToeSIMSupported]
-[CTCellularPlanItem setIsLocalTransferToeSIMSupported:]
————————-
-[CTCellularPlanManager setIMEIPrefix:]
-[CTCellularPlanManager getESimServerURL:]
-[CTCellularPlanManager setESimServerURL:]
———————-
int -[COSAboutDataSource getIMEI:]
void -[COSAboutDataSource getCarrierInfo:]
int -[COSAboutDataSource getSerialNumber:]
-(int)getDeviceModel:(int)
————————-
-[COSEIDDetailsController EIDString:]
———————-
+[NPHSharedUtilities isActiveWatchChinaRegionCellular]:
int -[NPHCellularBridgeUIManager startRemoteProvisioning]

-[CTCellularPlanManager addNewPlanWithUserInWebsheetWithUserConsent:completion:]
-[CTCellularPlanManager didPurchasePlanForCsn:iccid:profileServer:state:]
-[CTCellularPlanManager remotePlanLaunchInfoForEid:completion:]
CellularPlanManager这个文件
-[CTCellularPlanManager loadPlansWithUrl:postData:completion:] 联通应该是用这样

-[CTCellularPlanManager setSkipEligibilityCheck:] 跳过条件检查
-[CTCellularPlanManager getSkipEligibilityCheck:]
-[CTCellularPlanManager openInternalUrlId:]
-[CTCellularPlanManager setESimServerURL:]
-[CTCellularPlanManager getESimServerURL:]
-[CTCellularPlanManager getRemoteInfo:]
-[CTCellularPlanManager getIMEIPrefix:]
-[CTCellularPlanManager addNewRemotePlanWithAddress:matchingId:oid:confirmationCode:isPairing:withCSN:withContext:userConsent:completion:]
CTCellularPlanRequest
initWithUrl:(int)arg2 httpMethod:(int)arg3 httpHeaders:(int)arg4 httpBody

-[CTCellularPlanRequest initPostWithUrl:]
initJsonPostWithUrl
initJsonPostWithUrl
-[CTCellularPlanRequest initGetWithUrl:]
loadPlansWithUrl:(int)arg2 postData:(int)arg3 completion

+[CTCellularPlanRequest(Factory) loadPlansRequestWithUrl:postData:]

ETSI TS 102 221 V17.4.0 (2023-02)
TERMINAL CAPABILITY
————————-
GPC_SPE_007

Global Platform Card Specification – Public Release v2.3.1

The STORE DATA command message shall be coded according to the following table.

P1= 91
Last block
命令的数据域是 BER-TLV 格式

DER编码
GetEID== Tag ‘BF3E’ （GetEuiccDataRequest）
The data field SHALL indicate EID data object ‘5C 01 5A’ (tag ‘5A’ identifies the EID).
tag ‘5C’

响应 Tag ‘BF3E’
tag ‘5A’

============================
ProfileInfoListRequest ‘BF2D’
EnableProfileRequest Tag ‘BF31’
DisableProfileRequest ‘BF32’
DeleteProfileRequest ‘BF33’

GetEuiccDataResponse ‘BF3E’
————————————————–
Send Terminal Capabilities

80 aa 00 00 0a a9088100820101830107

回应

9000

Open Logical Channel and Select ISD-R

00a4040010 a0000005591010ffffffff8900000100

响应

6f81818410a0000005591010ffffffff8900000100a566735706072a864886fc6b01600b06092a864886fc6b020202630906072a864886fc6b03640b06092a864886fc6b048000650d060b2a864886fc6b05040200006618060a2b060104012a026e0103060a5354333347314d3201019f6e060077831801019f6501ffe0058203020200

9000

get status
80f2000c00

list profile
81 E2 91 00 03 BF2D00

获取EID
81 e2 91 00 06 bf3e 03 5c 01 5a

getEuiccConfiguredAddresses
81 E2 91 00 03 BF3C00

bf 3c
32
80 1f 6573696d2e7968647a642e6368696e616d6f62696c652e636f6d3a38303031 (esim.yhdzd.chinamobile.com:8001)
81 0f 6c70612e64732e67736d612e636f6d (lpa.ds.gsma.com)
9000

Enable Profile
81 E2 91 00 1A BF31 17 A0 12 4F 10 A0000005591010FFFFFFFF8900001100 8101FF

eSim Profile含有：

1个MNO-SD (卡上的运营商代表,含有OTA密钥，提供安全的OTA通道)

SSD（补充安全域)和CASD

Applets

应用（比如NFC应用)

NAAs (SIM核心元素，Network Access Application== Application residing in a Profile providing authorisation to access
a network）

文件系统的其它元素

Profile metadata(包括Profile Policy Rules)

保护与传输
Unprotected Profile Package (UPP): 未保护的Profile包，原始的 TLV 序列
Protected Profile Package (PPP): 以BSP负载TLV形式 组成的 分段保护的包
Bound Profile Package (BPP):
Segmented Bound Profile Package (SBPP): 可以用STORE DATA命令存入UICC的形式

Local Discovery Service
Local Profile Download
Local User Interface

SM-DS 的作用是提供一种机制， 允许 SM-DP+ 去通知 希望与之通信的任何设备中 的 LDS 。
SM-DS 到 LDS 通信的目的，是告诉它有一个待处理的事件。
SM-DP+ 会为 目标设备的LDS 发送一条到 SM-DS 的 事件注册消息。

在简单部署中，仅在 eUICC 上配置 Root SM-DS。 Root SM-DS地址是唯一的，填写在eUICC中。

目标设备中的 LDS 使用同样的逻辑位置 去 轮询 Root SM-DS 。
当Root SM-DS 具有目标设备的事件 ID 时, 它将使用 SM-DP+ 地址，对这次轮询进行响应;
如果没有事件 ID，则 回 一个空响应。

在级联SM-DSs的部署中， SM-DP+ 将发送一条事件注册消息 给 一个替代的SM-DS, 这个SM-DS可能没有被配置成Root SM-DS.
但是这个替代的SM-DS会将事件注册消息 级联地发给Root SM-DS.

目标设备中的LDS， 轮询Root SM-DS时，就会收到 替代的SM-DS地址。 然后LDS将向 替代的SM-DS发出 事件请求， 对应的SM-DS会响应
SM-DP+的地址。

Root SM-DS服务器由GSMA管理， 只通过同一个地址访问，后面有很多台物理服务器担当服务。

adb pull /system/framework/arm/ frm

java -jar ~/utils/baksmali-2.5.2.jar x -c boot.oat -d frm HmMyWatch.odex -o out

java -jar ~/utils/smali-2.5.2.jar a -o classes.dex out