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

时间：2019-01-02 16:39:36

标签： parsing nokia

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

  

片上系统/操作系统：

     
      
  • MediaTek MT6260 / Nokia Series 30+（2G）
    •   
  • 展讯SC7701B /基于Java的智能功能操作系统（3G）
    •   
  • 展讯SC9820A / Yun OS（4G，CMCC）
    •   

我有3G，所以我有一个“智能功能OS”，它显然是KaiOS（Is there any difference between KaiOS and 'Smart Feature OS'? : KaiOS）的一个版本，显然是（KaiOS – A Smartphone Operating System | Hacker News）是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 File Extension - Open .IB File (InterBase Database)，但是我尝试将这些.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内容，因为我担心泄露的个人信息超出了我的意图。

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

2 个答案:

答案 0 :(得分：3)

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

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

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

答案 1 :(得分：2)

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

相关问题
最新问题