2

I have this Ubiquiti firmware and I successfully extract the firmware and rebuild it, I modify Squashfs filesystem and rebuild it using build-firmware.sh script from firmware-mod-kit, but the problem I have is CRC Not the same as the original value, so how can I bypass CRC checksum also what is this "CRC32 polynomial table, big endian"

this output for original firmware 

Scan Time: 2016-03-16 11:23:35 Target File: /home/security/Desktop/XW.v5.6.3-beta3.28377.150922.1830_2.bin MD5 Checksum: c7227eeeb31a1c5a8fbcbfc7f70587f0 Signatures: 351 DECIMAL HEXADECIMAL DESCRIPTION ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 0 0x0 Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0xB49B5747, version: "XW.ar934x.v5.6.3-beta3.28377.150922.1830" 260 0x104 Ubiquiti partition header, header size: 56 bytes, name: "PARTu-boot", base address: 0x00000000, data size: 0 bytes 127444 0x1F1D4 Certificate in DER format (x509 v3), header length: 4, sequence length: 64 151956 0x25194 U-Boot version string, "U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20)" 152244 0x252B4 CRC32 polynomial table, big endian 222808 0x36658 CRC32 polynomial table, big endian 225032 0x36F08 Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E 228848 0x37DF0 Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel", base address: 0x00000001, data size: -2147475456 bytes 228912 0x37E30 uImage header, header size: 64 bytes, header CRC: 0x4A2F55E8, created: 2015-09-22 15:31:31, image size: 952264 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x533245A9, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Ubiquiti Linux-2.6.32.67" 228976 0x37E70 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2783164 bytes 1181240 0x120638 Ubiquiti partition header, header size: 56 bytes, name: "PARTrootfs", base address: 0x00000002, data size: 0 bytes 1181304 0x120678 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 5877613 bytes, 1185 inodes, blocksize: 131072 bytes, created: 2015-09-22 15:31:33 7210680 0x6E06B8 gzip compressed data, from Unix, last modified: 2015-09-22 15:30:15

the output for modified firmware is here http://pastebin.com/uWxG59pu
*also can i make fake CRC to look like the original value

Improve this question

2 Answers 2

Reset to default
2

You cannot bypass it, you must recalculate all required checksums.

Ubiquiti XW firmware is made from parts below:

UBNT <version-string> CRC32(header part) <4byte padding> PART u-boot <content> CRC32(u-boot part) <4byte padding> PART kernel <content> CRC32(kernel part) <4byte padding> PART rootfs <content><squashfs md5 checksum> CRC32(rootfs part) <4byte padding> EXEC script <content> CRC32(script part) <4byte padding> END. CRC32(all parts above> <4byte padding>

If you replace content of rootfs part, you mast recalculate CRC32 for that part and recalculate CRC in END. part

BTW firmware-mod-kit creates very broken images for Ubiquiti, ignores all content after squash filesystem, and not recalculate final END. checksum.

Improve this answer
1
  • so is there any other tool I can use instead of firmware-mod-kit to create working Ubiquiti firmware. Commented Jul 4, 2016 at 20:45
0

If you modify the firmware and rebuild it, then the CRC values should be changed. So, the new CRC values may be correct.

You don't have to do anything with the CRC32 polynomial table, because it means only that binwalk found a CRC32 table in the boot loader. This table is used to calculate the CRC32 value in a fast way.

Improve this answer
3
  • it give me "corrupted firmware file is uploaded. please upload the correct file and try again." so may be the problem from CRC32 Commented Mar 17, 2016 at 11:53
  • Unfortunately I don't know the Ubiquiti firmware format, but the corrupted firmware file may mean that the CRC value is not correct, but the firmware may contain other checks also, such as digital signatures. If GPL source pack is available for that firmware, it may contain the correct firmware packing method. Otherwise you may have to reverse the boot loader or the binary responsible for firmware update. Commented Mar 17, 2016 at 12:11
  • binwalk github.com/devttys0/binwalk/blob/master/src/binwalk/magic/… Have well documented format, also GPL Archive dl.ubnt.com/firmwares/XN-fw/v5.6.3/GPL.UBNT.v5.6.3.tar.bz2 Commented Mar 17, 2016 at 13:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.