chunghuihuang / firmware-mod-kit

Automatically exported from code.google.com/p/firmware-mod-kit
0 stars 0 forks source link

Error in build-ng.sh #51

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Fedora 7
2. disassembly of the firmware and the immediate assembling of a user with 
sudouser, not root
3.

What is the expected output? What do you see instead?

build succeeds, the size of match, on an empty rootfs (bug in build scripts - 
script can not read the prepared new-filesystem.skuashfs). The user also can 
not remove the new-filesystem.squashfs
What version of the product are you using? On what operating system?

Please provide any additional information below.

[user@localhost trunk]$ ./extract-ng.sh JWNR2000v2-V1.0.0.8_1.0.9.img
Scanning firmware...

DECIMAL         HEX             DESCRIPTION
--------------------------------------------------------------------------------
-----------------------
721024          0xB0080         Squashfs filesystem, big endian, version 2.0, 
size: 1695104 bytes, 686 inodes, blocksize: 65536 bytes, created: Fri Sep 30 
12:33:19 2011

Extracting 721024 bytes of  header image at offset 0
Extracting squashfs file system at offset 721024
Extracting 16 byte footer from offset 2416755
Extracting squashfs files...
Firmware extraction successful!
Firmware parts can be found in 'fmk/*'
////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////
/// is cut is not quite correct (the first 128 (?) long pieces and the model 
name), 
/// but in principle it is not particularly important for the subsequent 
assembly ...
/// FW 
http://netgear.ru/upload/firmware/jwnr2000v2/JWNR2000v2-V1.0.0.8_1.0.9.img
/// similar to the previous version of firmware:
/// Open source GPL 
ftp://downloads.netgear.com/files/GPL/jwnr2000v2-V1.0.0.8_1.0.7_GPL.tar.bz2.zip
////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////
[user@localhost trunk]$ ./build-ng.sh
Firmware Mod Kit (build-ng) 0.73 beta, (c)2011 Craig Heffner, Jeremy Collake
http://www.bitsum.com
Building new squashfs file system...
Creating big endian 2.1 filesystem on fmk/new-filesystem.squashfs, block size 
65536.
Big endian filesystem, data block size 65536, compressed data, compressed 
metadata, compressed fragments
Filesystem size 1611.41 Kbytes (1.57 Mbytes)
        26.68% of uncompressed filesystem size (6040.88 Kbytes)
Inode table size 3796 bytes (3.71 Kbytes)
        25.09% of uncompressed inode table size (15129 bytes)
Directory table size 5510 bytes (5.38 Kbytes)
        52.89% of uncompressed directory table size (10417 bytes)
Number of duplicate files found 3
Number of inodes 686
Number of files 518
Number of fragments 55
Number of symbolic links  92
Number of device nodes 45
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 31
Number of uids 1
        root (0)
Number of gids 0
cat: fmk/new-filesystem.squashfs: Отказано в доступе 
////////////////////////////translation from Russian is denied access
Remaining free bytes in firmware image: 1695731
Processing 0 header(s) from fmk/new-firmware.bin...
CRC update failed.
Firmware header not supported; firmware checksums may be incorrect. New 
firmware image has been saved to: fmk/new-firmware.bin
[user@localhost trunk]$ 
/////////////////////////////////////////// in 
build-ng.sh/////////////////////////////////////////////////////////////////////
# Append the new file system to the first part of the original firmware file
cp $HEADER_IMAGE $FWOUT  # O`k
##########################################################
#                                              ERROR ! 
# user does not have permission to read $ FSOUT 
# and $ FWOUT gets null values.
##########################################################
cat $FSOUT >> $FWOUT  # Error

Original issue reported on code.google.com by simanin...@gmail.com on 25 Jan 2012 at 6:38

GoogleCodeExporter commented 9 years ago
Should be able to work around this by running build-ng.sh as root, but I'll add 
a sudo in front of the cat command.

Original comment by heffne...@gmail.com on 26 Jan 2012 at 7:59

GoogleCodeExporter commented 9 years ago
Fix checked in. Thanks!

Original comment by heffne...@gmail.com on 12 Feb 2012 at 2:41

GoogleCodeExporter commented 9 years ago
Hi,
Could anyone tell me how to use firmware-mod-kit to extract jffs2 filesystem 
from a firmware? 
Any help will be appreciated.

Original comment by kirbyt2...@gmail.com on 16 Feb 2012 at 9:30

GoogleCodeExporter commented 9 years ago
The automated scripts don't support jffs2. However, you can use binwalk 
(included in FMK) to search a firmware image for jffs2 filesystems, then you 
just have to dd the file system out of the firmware image.

Original comment by heffne...@gmail.com on 16 Feb 2012 at 8:49

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
The unjffs2 tool will extract all the files from the jffs2 file system once it 
is extracted from the firmware image. The primary reason jffs2 support isn't 
built into the *ng scripts is that the jffs2 signature is only 2 bytes long and 
results in a lot of false positives matches. Binwalk does a pretty good job of 
filtering out false positives, but it doesn't always catch them all; this could 
potentially break other firmware if a false positive jffs2 match is hit.

It can be added to the ng scripts, but probably want to attempt to build a 
better signature, if possible.

Original comment by heffne...@gmail.com on 17 Feb 2012 at 1:16

GoogleCodeExporter commented 9 years ago
Thanks for bringing me up to speed, I was rambling about, as I do. Even at 2 
bytes there may be fewer false positives than thought. After all, if no other 
matches are found, we can defer to *trying* UNJFFS2. If it works, then we know 
it was JFFS2. If it doesn't, then false positive.

Original comment by jeremy.collake@gmail.com on 17 Feb 2012 at 1:20

GoogleCodeExporter commented 9 years ago
I will make sure UNJFFS2 returns the appropriate exit code on failure or 
success, and has proper exception handling or data validation so it won't crash 
if we feed it random data. Then, I'll integrate it on in.

Original comment by jeremy.collake@gmail.com on 17 Feb 2012 at 9:45

GoogleCodeExporter commented 9 years ago
Changed status to 'Started' since I really want to add this given the number of 
routers firmware images that may come with a 'starter' JFFS2 FS image, or even 
have their primary FS as JFFS2 (though most are smart enough to use 
squashfs-lzma, then 'overlay' it with JFFS2 to make the file-system writable).

Original comment by jeremy.collake@gmail.com on 17 Feb 2012 at 9:47

GoogleCodeExporter commented 9 years ago
Hi, 
adding that sudo did not help me fix the problem. I'm running Ubuntu 12. My 
firmware image extracts fine and fmk sees the squashfs 3.0 (it has a 
non-standard signature) but when I try to rebuild without any modifications it 
gives the following output:

Building new squashfs file system...
Parallel mksquashfs: Using 2 processors
Creating little endian 3.0 filesystem on 
/home/life/Desktop/DIR300_204_root//new-filesystem.squashfs, block size 65536.
Remaining free bytes in firmware image: 2322432
Processing 1 header(s) from 
/home/life/Desktop/DIR300_204_root//new-firmware.bin...
Processing header at offset 96...checksum(s) updated OK.
CRC(s) updated successfully.
Finished! New firmware image has been saved to: 
/home/life/Desktop/DIR300_204_root//new-firmware.bin

However 
new-filesystem.squashfs is empty and binwalk does not recognise the filesystem 
in new-firmware.bin - it's just padded with 2322432 times 0xff bytes

Original comment by urbanski...@gmail.com on 11 Dec 2012 at 7:55

GoogleCodeExporter commented 9 years ago

Original comment by jeremy.collake@gmail.com on 13 Apr 2013 at 2:08