现在我没有时间一路帮助你，但我相信我可以让你开始。让我们想像一些公司试图从外行人那里混淆一些东西，对吧？第一个选择通常是按位xor。

由于jvs3516cs-7601-ver.bin.

现在查看jvs3516cs-7601.bin十六进制编辑器中的 会发现一个迷人的模式：（44 1F或D.）。通常，我们希望00在具有此熵（文件开头）的数据上看到相当多的事件，但我们看到的是这种D.模式。

不要问我是否与开发人员的名字或类似的东西有某种联系，但我们现在有了一个可行的理论。该.bin文件可能已与0x1F44（或者0x441F如果它是 Big Endian）逐字异或。摘抄：

5C 1B 44 F5 50 EF DB FA 50 EF DB FA 50 EF DB FA
50 EF DB FA 50 EF DB FA 50 EF DB FA 50 EF DB FA
04 0C C4 9F E4 0C C4 9F 44 0B C4 9F 24 0B C4 9F
84 0B C4 9F 64 0A C4 9F C4 0A C4 9F 3C 49 70 0D
44 1F 47 3F 44 1F 44 0E 44 1F 44 1F B9 1F 44 1F
40 1F 47 3F 2A 2F 2C 1F 44 1F 44 1F B9 1F 44 1F
4C 1F 47 3F 44 1F 44 0D 44 1F 44 1F B9 1F 44 1F
48 1F 47 3F 27 3F 38 1F 44 1F 44 1F B9 1F 44 1F
54 1F 47 3F 44 1F 44 0E 44 1F 44 1F B9 1F 44 1F
50 1F 47 3F 2A 2F 2C 1F 44 1F 44 1F B9 1F 44 1F
64 1F 47 3F 44 1F 44 04 44 1F 44 1F B9 1F 44 1F
60 1F 47 3F A5 5F 38 1F 44 1F 44 1F B9 1F 44 1F
6C 1F 47 3F 54 1F 44 1F 44 1F 44 1F B9 1F 44 1F
AC 1F 47 3F 4B 1F 44 1F 44 1F 44 1F 44 1F 59 1F
6C 1F 47 3F 44 1F 44 1F 44 1F 44 1F 61 37 44 1F
6C 1F 47 3F 44 1F 44 1F 44 1F 44 1F 41 4F 44 1F
6C 1F 47 3F 45 1F 44 1F 44 1F 44 1F 41 4F 44 1F
40 1F 44 0F EE 15 44 1F 44 1F 44 1F 19 1F 44 1F

下面的 Python 小脚本从中获取知识jvs3516cs-7601-ver.bin并将其放入parts变量（三元组/元组列表）中。然后它打开输入文件（这里没有复杂的错误或路径处理，所以从所在的文件夹中运行jvs3516cs-7601.bin）并逐个读取部分，然后按照元组内容将它们转储到输出文件中：

# Tested with Python 2.7!
import io
import struct

parts = [("uboot.img", 0, 0x40000), ("kernel.img", 0x40000, 0x1B0000), ("fs.img", 0x1F0000, 0x580000)]
inpname = "jvs3516cs-7601.bin"

with io.open(inpname, "rb") as infile:
    for nm, offset, size in parts:
        infile.seek(offset)
        x = infile.read(size)
        assert len(x) / 2, "%s has odd length." % (nm)
        newx = ""
        for woffs in range(0, len(x), 2):
            word = struct.unpack("H", x[woffs:woffs+2])
            val = word[0] ^ 0x1F44 # the magic xor value we assume based on "D."
            newx += struct.pack("H", val)
        assert len(newx) == len(x), "Input and output size differ."
        assert len(newx) == size, "Output size (%d) for %s differs from expected value %d." % (len(newx), nm, size)
        with io.open(nm, "wb") as outf:
            outf.write(newx)

结果是三个文件，粗略看一下，似乎是真的。即反混淆后的 uImage、内核映像和文件系统映像。

一旦我们有了这些文件，file在 shell 上使用会给出如下内容：

$ file *.img
fs.img:     Squashfs filesystem, little endian, version 4.0, 5722880 bytes, 614 inodes, blocksize: 262144 bytes, created: Fri Oct 20 10:32:21 2017
kernel.img: u-boot legacy uImage, Linux-3.0.8, Linux/ARM, OS Kernel Image (Not compressed), 1644712 bytes, Thu Nov  5 07:18:50 2015, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xAAC0A340, Data CRC: 0x1FDABC77
uboot.img:  data

我不确定为什么它不能识别 U-Boot 映像。但它也可能是一个专有加载程序，取代以前的 U-Boot 映像。

如果您创建了一个文件夹rootfs并安装了 (Debian) 软件包squashfuse，则可以运行sudo mount -t squashfs fs.img rootfs以挂载 SquashFS 映像。结果将如下所示：

$ ls -l rootfs/
total 2
drwxrwxrwx 2 root root 1386 2017-09-30 08:11 bin
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:05 boot
drwxrwxrwx 2 1001 1001    3 2017-06-30 05:57 dev
drwxrwxrwx 7 root root  259 2017-10-20 12:32 etc
drwxrwxrwx 5 root root  149 2017-09-30 08:11 home
lrwxrwxrwx 1 1001 1001    9 2013-09-23 12:46 init -> sbin/init
drwxrwxrwx 2 1001 1001  650 2014-05-04 08:36 lib
lrwxrwxrwx 1 1001 1001   11 2013-09-23 12:46 linuxrc -> bin/busybox
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:04 lost+found
-rwxrwxrwx 1 1001 1001 1341 2011-04-21 05:40 mkimg.rootfs
-rwxrwxrwx 1 1001 1001  431 2011-04-21 05:40 mknod_console
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:05 mnt
drwxrwxrwx 2 1001 1001    3 2008-05-21 11:17 nfsroot
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:04 opt
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:04 proc
drwxrwxrwx 7 root root  143 2017-09-30 08:11 progs
drwxrwxrwx 2 1001 1001   31 2013-08-22 03:35 root
drwxrwxrwx 2 1001 1001  878 2017-10-20 12:32 sbin
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:05 share
drwxrwxrwx 2 1001 1001    3 2006-04-19 06:04 sys
drwxrwxrwx 2 1001 1001    3 2006-04-19 10:46 tmp
drwxrwxrwx 6 1001 1001   62 2013-08-22 03:35 usr
drwxrwxrwx 3 1001 1001   26 2013-08-22 03:35 var
lrwxrwxrwx 1 root root   10 2017-10-20 12:32 wifi -> /home/wifi

所以看起来 SquashFS 是可读的和健全的。至少那部分已经过验证。

现在，正如我在开头提到的，到目前为止，我没有时间验证我的发现，但是我的发现将让您了解公司开发人员的心态以及他们可能拥有的其他东西。看起来是真的，但我可能忽略了一些细节。无论哪种方式，这都应该让您开始。