奇怪或加密的ipcam固件

# binwalk -Bv jvs3516cs-7601.bin

Scan Time:     2018-06-13 17:52:52
Target File:   /root/jvs3516cs-7601.bin
MD5 Checksum:  8903156ca04081c393e16d6dff1580a0
Signatures:    344

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

# binwalk -EJ jvs3516cs-7601.bin

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
0             0x0             Falling entropy edge (0.316584)
270336        0x42000         Rising entropy edge (0.993798)
1904640       0x1D1000        Falling entropy edge (0.724715)
2031616       0x1F0000        Rising entropy edge (0.993043)
7753728       0x765000        Falling entropy edge (0.362255)

Entropy Exception: 'float' object cannot be interpreted as an integer




# xxd -a jvs3516cs-7601.bin | head
00000000: 5c1b 44f5 50ef dbfa 50ef dbfa 50ef dbfa  \.D.P...P...P...
00000010: 50ef dbfa 50ef dbfa 50ef dbfa 50ef dbfa  P...P...P...P...
00000020: 040c c49f e40c c49f 440b c49f 240b c49f  ........D...$...
00000030: 840b c49f 640a c49f c40a c49f 3c49 700d  ....d.......<Ip.
00000040: 441f 473f 441f 440e 441f 441f b91f 441f  D.G?D.D.D.D...D.
00000050: 401f 473f 2a2f 2c1f 441f 441f b91f 441f  @.G?*/,.D.D...D.
00000060: 4c1f 473f 441f 440d 441f 441f b91f 441f  L.G?D.D.D.D...D.
00000070: 481f 473f 273f 381f 441f 441f b91f 441f  H.G?'?8.D.D...D.
00000080: 541f 473f 441f 440e 441f 441f b91f 441f  T.G?D.D.D.D...D.
00000090: 501f 473f 2a2f 2c1f 441f 441f b91f 441f  P.G?*/,.D.D...D


# fdisk -l jvs3516cs-7601.bin
Disk jvs3516cs-7601.bin: 7,4 MiB, 7798784 bytes, 15232 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

#1 楼

现在，我没有时间一路为您提供帮助，但是我相信我可以帮助您入门。让我们想像一些公司试图掩盖外行的东西，对吧？首选通常是按位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就会得到以下内容：

$ 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映像。 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似乎可读性强。至少该部分已经过验证。

现在，正如我在开头提到的那样，我现在没有时间验证我的发现，但是我的发现将为您提供思路公司的开发商以及他们可能在商店中拥有什么。看起来确实不错，但我可能忽略了一些细节。无论哪种方式，这都可以帮助您入门。