解析/转换诺基亚“ Smart Feature OS”备份.ib文件？

Question

我已经在https://superuser.com/questions/1389657/backup-access-sms-on-nokia-3310-3g-2017-from-linux-pc上写了一些内容； 基本上，我正在尝试将Nokia 3310 3G上的SMS消息备份到Ubuntu 18.04 PC上； 请注意， 诺基亚3310（2017）的版本不同，硬件片上系统和操作系统也有所不同：

片上系统/操作系统：

• 联发科技MT6260 /诺基亚30+系列（2G）
• 展讯SC7701B /基于Java的智能功能操作系统（3G）
• 展讯SC9820A / Yun OS（4G，CMCC）

我有3G，所以我有一个“智能功能OS”，它显然是KaiOS的版本（ KaiOS和“智能功能OS”之间有什么区别吗？：KaiOS ），显然是（ KaiOS –智能手机操作系统|黑客）新闻 ）是Firefox OS的分支。

当您在此手机上点击菜单>存储>创建备份（ 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文件扩展名-打开.IB文件（InterBase数据库） ，但是我尝试将这些.ib文件与http://fbexport.sourceforge.net/fbexport.php “使用Firebird和InterBase导出和导入数据的工具”一起使用数据库”，我得到：

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 -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个字节编码的，即“宽字符”； 在大多数情况下， ibphone_head.in似乎只是对其包含/父文件夹的名称All-backup_01-01-2019_20-18-54 。

这是电话簿的十六进制转储，其中我将名称匿名命名为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字节； 但是，无法确定实际的电话号码存储在哪里。

我不会粘贴sms.ib的hexdump内容，因为我担心泄露的个人信息超出了我的意图。

但是，也许已经发布了什么内容，将帮助某人查看这是否是已建立的文件格式吗？ 无论如何，我想将这些文件的内容转换为纯文本...

Answer 1

phonebook.ib是专有文件格式。 我进行了一些分析，以至能够从中提取姓名和电话号码。

• 标头为580个字节，似乎没有包含任何有趣的内容。
• 条目似乎以条目长度开始，编码为3个4位十进制半字节，后跟另一个数字（可能是版本号？）。

在我的样本文件中，所有条目均为940字节，因此前两个字节为94 03 。 我以其他偏移量标识的其他字段条目：

• entry + 0x12a [1字节]：代表电话号码的字节数。
• entry + 0x12b [1字节]：好像是两位十进制编码标志。 如果设置了高半字节（例如10 ），则电话号码以+开头。
• entry + 0x12c：电话号码，十进制编码。 例如， 123456将显示为21 43 65 。 特殊数字：
  • a是*
  • b是#
  • f被忽略（当位数不为偶数时，视为最后一位）。
• entry + 0x16c [1字节]：名称长度。
• entry + 0x16e：名称为UTF-16（即，每个字符2个字节）。

以您的代码段为例：

• 电话长度0x36e，4个字节。
• 0x36f是额外的标志，高半字节为0因此没有+前缀。
• 电话号码以0x370开头， 07 12 80 88转换为70210888 。

在我的仓库中可以找到一个简单的引用解析器： https : //github.com/yossigo/phonebook_ib_export

Answer 2

当我找到一种解决方法，将诺基亚3310 3G的vcf文件格式备份和还原所有联系人时，我将制作与Yossi相反的脚本，将.vcf文件转换回.is格式：

将联系人备份到VCF文件 ：在联系人中，单击向左按钮进行共享，然后使用向左按钮菜单中的选项选择所有联系人，通过蓝牙发送到任何设备，然后可以从另一台蓝牙设备检索vcf文件，或者从手机根目录的/ vCard /文件夹中（如果插入了SD卡，则为SD卡）

从VCF文件还原联系人 ：将文件复制到手机或sd卡上的任何位置，拔出手机并使用嵌入式文件浏览器查找文件，然后按照诺基亚的工程师的逻辑，不使用“打开”按钮，而是单击左侧的按钮，然后使用选项保存电子名片