Parsing 解析/转换诺基亚“;智能功能操作系统“;备份.ib文件?

Parsing 解析/转换诺基亚“;智能功能操作系统“;备份.ib文件?,parsing,nokia,Parsing,Nokia,我已经写了一些关于这方面的文章;基本上,我正在尝试将诺基亚3310 3G手机上的短信备份到Ubuntu 18.04 PC上;请注意,硬件片上系统和操作系统因版本不同而有所不同: 片上系统/操作系统: 联发科MT6260/诺基亚30+系列(2G) 展讯SC7701B/Java智能功能操作系统(3G) 展讯SC9820A/Yun操作系统(4G,中国移动) 我有3G,所以我有一个“智能功能操作系统”,它显然是KaiOS()的一个版本,它显然是Firefox操作系统的一个分支 当您在此手机上点击功能

我已经写了一些关于这方面的文章;基本上,我正在尝试将诺基亚3310 3G手机上的短信备份到Ubuntu 18.04 PC上;请注意,硬件片上系统和操作系统因版本不同而有所不同:

片上系统/操作系统:

  • 联发科MT6260/诺基亚30+系列(2G)
  • 展讯SC7701B/Java智能功能操作系统(3G)
  • 展讯SC9820A/Yun操作系统(4G,中国移动)
我有3G,所以我有一个“智能功能操作系统”,它显然是KaiOS()的一个版本,它显然是Firefox操作系统的一个分支

当您在此手机上点击功能表>存储>创建备份()时,它会生成一个包含文件的文件夹,名称如下:

$ 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
文件与“用于使用Firebird和InterBase数据库导出和导入数据的工具”一起使用,我得到:

Engine Code    : 335544323
Engine Message :
file ./All-backup_01-01-2019_20-18-54/phonebook.ib is not a valid database
所以,不是这样

这是一个iPhone头的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个字节编码的,“宽字符”;在大多数情况下,
ibphone\u head.in
似乎只是对其包含/父文件夹的名称进行编码,
All-backup\u 01-01-2019\u 20-18-54

这是一个电话簿的垃圾堆,我把名字匿名化为AAAAA和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
的hextump内容,因为我害怕透露更多的个人信息


然而,可能已经发布的内容将帮助某人查看这是否是一种已建立的文件格式?无论如何,我想把这些文件的内容转换成纯文本

电话簿.ib是一种专有文件格式。我做了一些分析,终于能够从中提取姓名和电话号码

  • 标头是580字节,似乎不包含任何有趣的内容
  • 条目似乎以条目长度开始,编码为3个4位十进制半字节,后跟另一个数字(可能是版本号?)
在我的示例文件中,所有条目都是940字节,因此前两个字节是
9403
。我在不同偏移处确定的其他字段条目:

  • 条目+0x12a[1字节]:表示电话号码的字节数
  • 条目+0x12b[1字节]:看起来像是两位十进制编码标志。如果设置了高半字节(例如
    10
    ),则电话号码以
    +
    开头
  • 条目+0x12c:电话号码,十进制编码。例如,
    123456
    将显示为
    214365
    。特殊数字:
    • a
      *
    • b
      #
    • f
      被忽略(当位数不是偶数时被视为最后一位)
  • 条目+0x16c[1字节]:名称长度
  • 条目+0x16e:UTF-16中的名称(即每个字符2个字节)
以您的代码片段为例:

  • 0x36e是电话长度,4字节
  • 0x36f是额外标志,高半字节是
    0
    ,因此没有
    +
    前缀
  • 0x370是电话号码的开头,
    07128088
    转换为
    70210888

在my repo上可以找到一个简单的参考解析器:

电话簿.ib是一种专有文件格式。我做了一些分析,终于能够从中提取姓名和电话号码

  • 标头是580字节,似乎不包含任何有趣的内容
  • 条目似乎以条目长度开始,编码为3个4位十进制半字节,后跟另一个数字(可能是版本号?)
在我的示例文件中,所有条目都是940字节,因此前两个字节是
9403
。我在不同偏移处确定的其他字段条目:

  • 条目+0x12a[1字节]:表示电话号码的字节数
  • 条目+0x12b[1字节]:看起来像是两位十进制编码标志。如果设置了高半字节(例如
    10
    ),则电话号码以
    +
    开头
  • 条目+0x12c:电话号码,十进制编码。例如,
    123456
    将显示为
    214365
    。特殊数字:
    • a
      *
    • b
      #
    • f
      被忽略(当位数不是偶数时被视为最后一位)
  • 条目+0x16c[1字节]:名称长度
  • 条目+0x16e:UTF-16中的名称(即每个字符2个字节)
以您的代码片段为例:

  • 0x36e是电话长度,4字节
  • 0x36f是额外标志,高半字节是
    0
    ,因此没有
    +
    前缀
  • 0x370是电话号码的开头,
    07128088
    转换为
    70210888

在我的repo中可以找到一个简单的参考解析器:

我正准备编写与Yossi相反的脚本来将.vcf文件转换回.is格式,这时我找到了一个解决方法,可以使用诺基亚3310 3G将所有联系人备份到vcf文件格式并从中恢复:

将联系人备份到VCF文件:在您的联系人中,单击左键共享,使用左键菜单中的选项选择所有联系人,通过蓝牙发送到任何设备,然后您可以从其他蓝牙设备或手机根目录下的/vCard/文件夹中检索VCF文件(如果已插入sd卡)

从VCF文件还原联系人:将文件复制到手机或sd卡上的任意位置,拔下手机插头并使用嵌入式VCF