Parsing/converting 诺基亚 "Smart Feature OS" 备份 .ib 文件？
Parsing/converting Nokia "Smart Feature OS" backup .ib files?
我已经在 https://superuser.com/questions/1389657/backup-access-sms-on-nokia-3310-3g-2017-from-linux-pc ; basically, I'm trying to back up SMS messages on a Nokia 3310 3G onto a Ubuntu 18.04 PC; note that hardware system-on-chip and OS differs by version for a Nokia 3310 (2017):
中写了一些关于这个的内容
System on chip / Operating system:
- MediaTek MT6260 / Nokia Series 30+ (2G)
- Spreadtrum SC7701B / Java-powered Smart Feature OS (3G)
- Spreadtrum SC9820A / Yun OS (4G, CMCC)
我有 3G，所以我有一个 "Smart Feature OS" 显然是 Kai 的一个版本OS (Is there any difference between KaiOS and 'Smart Feature OS'? : KaiOS), which apparently (KaiOS – A Smartphone Operating System | Hacker News) 是 Firefox OS 的一个分支。
当您在此 phone 上点击菜单 > 存储 > 创建备份 (https://www.nokia.com/phones/en_int/support/nokia-3310-3g-user-guide/create-a-backup) 时，它会生成一个包含文件的文件夹，名称如下：
$ tree All-backup_01-01-2019_20-18-54
All-backup_01-01-2019_20-18-54
├── ibphone_head.in
├── phonebook.ib
└── sms.ib
我以前从未听说过 .ib 文件，我希望这里有人知道它们是什么。快速浏览表明 IB File Extension - Open .IB File (InterBase Database), however I tried using these .ib files with http://fbexport.sourceforge.net/fbexport.php "Tool for exporting and importing data with Firebird and InterBase databases"，我得到：
Engine Code : 335544323
Engine Message :
file ./All-backup_01-01-2019_20-18-54/phonebook.ib is not a valid database
所以，不是这样。
这是 ibphone_head.in 的 hexdump - 看起来这里没有个人身份信息：
$ hexdump -C All-backup_01-01-2019_20-18-54/ibphone_head.in
00000000 00 00 00 00 41 00 6c 00 6c 00 2d 00 62 00 61 00 |....A.l.l.-.b.a.|
00000010 63 00 6b 00 75 00 70 00 5f 00 30 00 31 00 2d 00 |c.k.u.p._.0.1.-.|
00000020 30 00 31 00 2d 00 32 00 30 00 31 00 39 00 5f 00 |0.1.-.2.0.1.9._.|
00000030 32 00 30 00 2d 00 31 00 38 00 2d 00 35 00 34 00 |2.0.-.1.8.-.5.4.|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 00 00 45 00 3a 00 5c 00 42 00 61 00 63 00 |....E.:.\.B.a.c.|
00000110 6b 00 75 00 70 00 73 00 5c 00 41 00 6c 00 6c 00 |k.u.p.s.\.A.l.l.|
00000120 2d 00 62 00 61 00 63 00 6b 00 75 00 70 00 5f 00 |-.b.a.c.k.u.p._.|
00000130 30 00 31 00 2d 00 30 00 31 00 2d 00 32 00 30 00 |0.1.-.0.1.-.2.0.|
00000140 31 00 39 00 5f 00 32 00 30 00 2d 00 31 00 38 00 |1.9._.2.0.-.1.8.|
00000150 2d 00 35 00 34 00 00 00 00 00 00 00 00 00 00 00 |-.5.4...........|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 00 00 00 00 30 30 30 31 2e 30 30 30 30 33 00 00 |....0001.00003..|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000230 00 00 00 00 00 00 6d 6d 69 6b 65 79 62 61 63 6b |......mmikeyback|
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000250 00 00 00 00 00 00 03 00 00 00 00 00 b0 cd 09 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000270 00 00 00 00 00 00 00 00 f3 dd 00 00 7e 2f 00 00 |............~/..|
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000002c4
所以，字符串似乎是用2个字节编码的，"wide char"；在大多数情况下，ibphone_head.in 似乎只是对其 containing/parent 文件夹的名称进行编码，All-backup_01-01-2019_20-18-54.
这是 phone 一本书的十六进制转储，其中我将名字匿名为 AAAAAAAAA 和 BBB：
$ hexdump -C -n 1900 All-backup_01-01-2019_20-18-54/phonebook.ib
00000000 70 00 68 00 6f 00 6e 00 65 00 62 00 6f 00 6f 00 |p.h.o.n.e.b.o.o.|
00000010 6b 00 2e 00 69 00 62 00 00 00 00 00 00 00 00 00 |k...i.b.........|
00000020 00 00 00 00 01 00 00 00 30 f8 04 00 62 01 00 00 |........0...b...|
00000030 62 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |b...............|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000240 00 00 00 00 98 03 00 00 01 00 00 00 ff ff ff ff |................|
00000250 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000360 d9 d4 37 46 00 00 00 00 00 00 01 02 00 00 04 01 |..7F............|
00000370 07 12 80 88 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000003b0 09 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 |..A.A.A.A.A.A.A.|
000003c0 41 00 41 00 00 00 00 00 00 00 00 00 00 00 00 00 |A.A.............|
000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000005e0 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff |................|
000005f0 ff ff ff ff 98 03 00 00 01 00 00 00 ff ff ff ff |................|
00000600 ff ff ff ff 04 00 01 00 00 00 00 00 00 00 00 00 |................|
00000610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000710 d9 d4 37 46 00 00 00 00 00 00 01 02 00 00 06 11 |..7F............|
00000720 83 29 23 13 58 f9 00 00 00 00 00 00 00 00 00 00 |.)#.X...........|
00000730 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000760 03 00 42 00 42 00 42 00 00 00 00 00 |..B.B.B.....|
0000076c
这里好像d9 d4 37 46是条目的分隔符，条目好像是0x3b0 = 944字节；不过，无法确定实际的 phone 号码存储在哪里。
我不会粘贴 sms.ib 的 hexdump 内容，因为我害怕泄露比我想要的更多的个人信息。
但是，也许已经发布的内容可以帮助别人看看这是否是一种已经建立的文件格式？无论如何，我想将这些文件的内容转换为纯文本...
phonebook.ib 是专有文件格式。我做了一些分析，并达到了能够从中提取名称和 phones 数字的地步。
- Header 是 580 字节，似乎没有包含任何有趣的内容。
- 条目似乎以条目长度开头，编码为 3 个 4 位十进制半字节，后跟另一个数字（可能是版本号？）。
在我的示例文件中，所有条目均为 940 字节，因此前两个字节为 94 03。我在不同偏移量处识别的其他字段条目：
- entry+0x12a [1 byte]: 表示phone个数的字节数。
- entry+0x12b [1 byte]：似乎是 two-digit 十进制编码标志。如果设置了高半字节（例如
10），则 phone 数字以 +. 开头
- entry+0x12c: Phone 数字，十进制编码。例如，
123456 将显示为 21 43 65。特殊数字：
a 是 *b 是 #f被忽略（位数不偶数时视为最后一位）。
- entry+0x16c [1 byte]: 名称长度。
- entry+0x16e：UTF-16 格式的名称（即每个字符 2 个字节）。
以您的代码段为例：
- 0x36e 是 phone 长度，4 个字节。
- 0x36f 是额外的标志，高半字节是
0 所以没有 + 前缀。
- 0x370 是 phone 数字开始的地方，
07 12 80 88 转换为 70210888。
可以在我的存储库中找到一个简单的参考解析器：https://github.com/yossigo/phonebook_ib_export
我正准备制作与 Yossi 的脚本相反的脚本来将 .vcf 文件转换回 .is 格式，这时我发现了一种解决方法，可以使用 诺基亚 3310 3G :
将联系人备份到 VCF 文件: 在您的联系人中，单击左侧按钮共享，select 所有联系人都使用左侧按钮菜单中的选项，发送通过蓝牙连接到任何设备，然后您可以从其他蓝牙设备或从 phone（如果插入 SD 卡）
根目录下的 /vCard/ 文件夹中检索 vcf 文件
从 VCF 文件恢复联系人：将文件复制到 phone 或 sd 卡上的任何位置，拔下 phone 并使用嵌入式文件浏览器找到文件，然后按照诺基亚的工程师逻辑，不使用“打开”按钮，而是单击左侧按钮并使用选项“保存 vCard
”
我已经在 https://superuser.com/questions/1389657/backup-access-sms-on-nokia-3310-3g-2017-from-linux-pc ; basically, I'm trying to back up SMS messages on a Nokia 3310 3G onto a Ubuntu 18.04 PC; note that hardware system-on-chip and OS differs by version for a Nokia 3310 (2017):
中写了一些关于这个的内容System on chip / Operating system:
- MediaTek MT6260 / Nokia Series 30+ (2G)
- Spreadtrum SC7701B / Java-powered Smart Feature OS (3G)
- Spreadtrum SC9820A / Yun OS (4G, CMCC)
我有 3G，所以我有一个 "Smart Feature OS" 显然是 Kai 的一个版本OS (Is there any difference between KaiOS and 'Smart Feature OS'? : KaiOS), which apparently (KaiOS – A Smartphone Operating System | Hacker News) 是 Firefox OS 的一个分支。
当您在此 phone 上点击菜单 > 存储 > 创建备份 (https://www.nokia.com/phones/en_int/support/nokia-3310-3g-user-guide/create-a-backup) 时，它会生成一个包含文件的文件夹，名称如下：
$ tree All-backup_01-01-2019_20-18-54
All-backup_01-01-2019_20-18-54
├── ibphone_head.in
├── phonebook.ib
└── sms.ib
我以前从未听说过 .ib 文件，我希望这里有人知道它们是什么。快速浏览表明 IB File Extension - Open .IB File (InterBase Database), however I tried using these .ib files with http://fbexport.sourceforge.net/fbexport.php "Tool for exporting and importing data with Firebird and InterBase databases"，我得到：
Engine Code : 335544323
Engine Message :
file ./All-backup_01-01-2019_20-18-54/phonebook.ib is not a valid database
所以，不是这样。
这是 ibphone_head.in 的 hexdump - 看起来这里没有个人身份信息：
$ hexdump -C All-backup_01-01-2019_20-18-54/ibphone_head.in
00000000 00 00 00 00 41 00 6c 00 6c 00 2d 00 62 00 61 00 |....A.l.l.-.b.a.|
00000010 63 00 6b 00 75 00 70 00 5f 00 30 00 31 00 2d 00 |c.k.u.p._.0.1.-.|
00000020 30 00 31 00 2d 00 32 00 30 00 31 00 39 00 5f 00 |0.1.-.2.0.1.9._.|
00000030 32 00 30 00 2d 00 31 00 38 00 2d 00 35 00 34 00 |2.0.-.1.8.-.5.4.|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 00 00 45 00 3a 00 5c 00 42 00 61 00 63 00 |....E.:.\.B.a.c.|
00000110 6b 00 75 00 70 00 73 00 5c 00 41 00 6c 00 6c 00 |k.u.p.s.\.A.l.l.|
00000120 2d 00 62 00 61 00 63 00 6b 00 75 00 70 00 5f 00 |-.b.a.c.k.u.p._.|
00000130 30 00 31 00 2d 00 30 00 31 00 2d 00 32 00 30 00 |0.1.-.0.1.-.2.0.|
00000140 31 00 39 00 5f 00 32 00 30 00 2d 00 31 00 38 00 |1.9._.2.0.-.1.8.|
00000150 2d 00 35 00 34 00 00 00 00 00 00 00 00 00 00 00 |-.5.4...........|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 00 00 00 00 30 30 30 31 2e 30 30 30 30 33 00 00 |....0001.00003..|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000230 00 00 00 00 00 00 6d 6d 69 6b 65 79 62 61 63 6b |......mmikeyback|
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000250 00 00 00 00 00 00 03 00 00 00 00 00 b0 cd 09 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000270 00 00 00 00 00 00 00 00 f3 dd 00 00 7e 2f 00 00 |............~/..|
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000002c4
所以，字符串似乎是用2个字节编码的，"wide char"；在大多数情况下，ibphone_head.in 似乎只是对其 containing/parent 文件夹的名称进行编码，All-backup_01-01-2019_20-18-54.
这是 phone 一本书的十六进制转储，其中我将名字匿名为 AAAAAAAAA 和 BBB：
$ hexdump -C -n 1900 All-backup_01-01-2019_20-18-54/phonebook.ib
00000000 70 00 68 00 6f 00 6e 00 65 00 62 00 6f 00 6f 00 |p.h.o.n.e.b.o.o.|
00000010 6b 00 2e 00 69 00 62 00 00 00 00 00 00 00 00 00 |k...i.b.........|
00000020 00 00 00 00 01 00 00 00 30 f8 04 00 62 01 00 00 |........0...b...|
00000030 62 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |b...............|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000240 00 00 00 00 98 03 00 00 01 00 00 00 ff ff ff ff |................|
00000250 ff ff ff ff 01 00 01 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000360 d9 d4 37 46 00 00 00 00 00 00 01 02 00 00 04 01 |..7F............|
00000370 07 12 80 88 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000003b0 09 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 |..A.A.A.A.A.A.A.|
000003c0 41 00 41 00 00 00 00 00 00 00 00 00 00 00 00 00 |A.A.............|
000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000005e0 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff |................|
000005f0 ff ff ff ff 98 03 00 00 01 00 00 00 ff ff ff ff |................|
00000600 ff ff ff ff 04 00 01 00 00 00 00 00 00 00 00 00 |................|
00000610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000710 d9 d4 37 46 00 00 00 00 00 00 01 02 00 00 06 11 |..7F............|
00000720 83 29 23 13 58 f9 00 00 00 00 00 00 00 00 00 00 |.)#.X...........|
00000730 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000760 03 00 42 00 42 00 42 00 00 00 00 00 |..B.B.B.....|
0000076c
这里好像d9 d4 37 46是条目的分隔符，条目好像是0x3b0 = 944字节；不过，无法确定实际的 phone 号码存储在哪里。
我不会粘贴 sms.ib 的 hexdump 内容，因为我害怕泄露比我想要的更多的个人信息。
但是，也许已经发布的内容可以帮助别人看看这是否是一种已经建立的文件格式？无论如何，我想将这些文件的内容转换为纯文本...
phonebook.ib 是专有文件格式。我做了一些分析，并达到了能够从中提取名称和 phones 数字的地步。
- Header 是 580 字节，似乎没有包含任何有趣的内容。
- 条目似乎以条目长度开头，编码为 3 个 4 位十进制半字节，后跟另一个数字（可能是版本号？）。
在我的示例文件中，所有条目均为 940 字节，因此前两个字节为 94 03。我在不同偏移量处识别的其他字段条目：
- entry+0x12a [1 byte]: 表示phone个数的字节数。
- entry+0x12b [1 byte]：似乎是 two-digit 十进制编码标志。如果设置了高半字节（例如
10），则 phone 数字以+. 开头
- entry+0x12c: Phone 数字，十进制编码。例如，
123456将显示为21 43 65。特殊数字：a是*b是#f被忽略（位数不偶数时视为最后一位）。
- entry+0x16c [1 byte]: 名称长度。
- entry+0x16e：UTF-16 格式的名称（即每个字符 2 个字节）。
以您的代码段为例：
- 0x36e 是 phone 长度，4 个字节。
- 0x36f 是额外的标志，高半字节是
0所以没有+前缀。 - 0x370 是 phone 数字开始的地方，
07 12 80 88转换为70210888。
可以在我的存储库中找到一个简单的参考解析器：https://github.com/yossigo/phonebook_ib_export
我正准备制作与 Yossi 的脚本相反的脚本来将 .vcf 文件转换回 .is 格式，这时我发现了一种解决方法，可以使用 诺基亚 3310 3G :
将联系人备份到 VCF 文件: 在您的联系人中，单击左侧按钮共享，select 所有联系人都使用左侧按钮菜单中的选项，发送通过蓝牙连接到任何设备，然后您可以从其他蓝牙设备或从 phone（如果插入 SD 卡）
根目录下的 /vCard/ 文件夹中检索 vcf 文件从 VCF 文件恢复联系人：将文件复制到 phone 或 sd 卡上的任何位置，拔下 phone 并使用嵌入式文件浏览器找到文件，然后按照诺基亚的工程师逻辑，不使用“打开”按钮，而是单击左侧按钮并使用选项“保存 vCard
”