Repacking of firmware after extraction

Feature Request:

Is it possible to add a repack option so that after running an extraction and modifying the contents we can repack the image back together?

General Question:

How could this be done manually? For instance if I have the signature output of:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
13632         0x3540          U-Boot version string, "U-Boot 1.1.4 (Aug 17 2012 - 15:21:07)"
13680         0x3570          CRC32 polynomial table, big endian
14976         0x3A80          uImage header, header size: 64 bytes, header CRC: 0x71A58DBE, created: 2012-08-17 07:21:08, image size: 32798 bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0xF13C6F0C, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
15040         0x3AC0          LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 93688 bytes
131584        0x20200         LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 2753096 bytes
1039828       0xFDDD4         Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2684880 bytes, 786 inodes, blocksize: 262144 bytes, created: 2014-02-04 10:24:21
3735552       0x390000        JFFS2 filesystem, big endian

And I wish to extract, modify, and repack the Squashfs filesystem where my data resides, what would be the steps in doing so?

Should I split the binary in three parts: 1) 0x000000 -> 0xFDDD4, 2) 0xFDDD4 -> 0x390000 3) 0x390000 -> end of binary. Proceed to extract the 2nd part (the squashfs file system), modify it, and resquash it with the same settings. Then finally merge the 3 parts back together again?

Or is that not the right way to go about this?

My objective is to modify some configuration files in the squashfs portion of the binary to open up a way into the device since all other options are closed.

Thanks.

[ArionMiles]

Firmware mod kit has long been abandoned. It doesn’t work for me, and I can’t even submit an issue to anyone. Would be nice if someone created a new firmware mod kit, possibly forking the previous one and adding more features on it.

[ArionMiles]

This problem isn’t directly binwalk related but please give it a read and if you can help, please reply.

The only problem I’m facing at this point is when I extract the filesystem with binwalk into a squashfs-root directory and squash it back into a filesys.squashfs using mksquashfs squasfs-root filesys.squashfs with lzma compression (as the original filesystem also uses lzma)

Now, I put this modified filesystem by two methods with same results:

#Method 1:

dd if=filesys.squashfs of=firmware.bin bs=1 seek=1180160 conv=notrunc where 1180160 is the starting point of filesystem.

#Method 2:

I use the tpl-tool included in firmware mod kit for tp-link firmwares (this is a tp-link firmware I’m trying to modify)

I get a firmware.bin-rootfs file along with -bootloader -kernel -header files. I rename my filesys.squashfs to firmware.bin-rootfs and replace it with the firmware.bin-rootfs originally extracted by tpl-tool and run the tpl-tool -b firmware.bin and get a modifed firmware.bin-new file.

#RESULT:

Extracting the modifed firmware with binwalk in both the results gets me a squashfs-root folder where all the files previously arranged into bin usr tmp var sbin www and the likes are directly placed into the squashfs-root folder with no arrangement whatsoever. There are also the bin, usr, www, etc. folders inside this directory with same files. So my question is… WHAT IS GOING ON?