Enter one-line summary

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ./extract-ng.sh firm.bin
2. (nothing changed just testing)
3. ./build-ng.sh

What is the expected output? What do you see instead?
I was expected:
"Finished! New firmware image has been saved to: fmk/new-firmware.bin" but 
instead I got not surprisingly:
"...
ERROR: New firmware image will be larger than original image!
....
Refusing to create new firmware image.
Original file size: 3145730
Current file size:  3145728
.."
Actually this is not quite correct the new Firmware is smaller than Original

Tried second time with -min option:
1. ./extract-ng.sh firm.bin -min
2. ./build-ng.sh

and got this:
Building new squashfs file system...
./src/squashfs-3.0/mksquashfs: -b block size not power of two or not between 
4096 and 64K
Failed to create new file system! Quitting...

Third time: edited the build-ng.sh changed the:
if [ "$FILLER_SIZE" -lt 0 ]
to:
if [ "$FILLER_SIZE" -gt 0 ]

and now it passed okay:
"Processing header at offset 20...checksum(s) updated OK.
CRC(s) updated successfully.
Finished! New firmware image has been saved to: fmk/new-firmware.bin"

But when I tried to upload it turned out that the CRC was mismatched.
Hmmm... check on CRC of Original
-header CRC: 0x8F5EE626
-data CRC: 0xAF7E7C15
and the new firmware
-header CRC: 0x8F5EE626
-data CRC: 0xAF7E7C15

Quite the same. Tried to change them manually:
./src/crcalc/crcalc fmk/new-firmware.bin fmk/logs/binwalk.log
and got success result, but when checked with hexview, no changes in CRC 
values. Tried to flash, again the same problem about the CRC.
What I do wrong?

What version of the product are you using? On what operating system?

Debian Linux 3.2.0-23-generic-pae and the firmware image is from Edimax BR6504N

Additional information:
My goal is to add telnetd service to this firmware in order to have shell 
access remotely, and maybe later ssh with ipkg. 

Original issue reported on code.google.com by velinr...@gmail.com on 19 Nov 2012 at 1:00

[GoogleCodeExporter]

You didn't mention what firmware header was being processed, but I suspect the 
CRC mismatch issue lies with the file size errors.

First, it is important to note that depending on the exact squashfs version 
used and the options passed to the squashfs utility when the vendor built the 
original file system, the file system that is re-built by FMK most likely will 
differ in it's CRC and size. 

The error message is perhaps a bit misleading, but it is in fact correct: it 
says that the new image WILL be larger than the original, then displays the 
CURRENT size of the new image. In other words, it has not finished building the 
new firmware image, but it has calculated that it does not have enough 
remaining room to proceed.

The second issue regarding the use of the -min option and the block size error 
is a problem with the squashfs-3.0 binary not supporting larger block sizes 
(the -min option attempts to set the block size to 1MB). Larger squashfs block 
sizes result in smaller squashfs images, The default block size should be 64K, 
which in this case is the max block size for squashfs-3.0 anyway, so there 
isn't any optimization the -min option can do in this regard.

When you edited build-ng to skip the size check, you built a firmware image 
that was larger than the original. The crcalc utility uses the size field in 
the supported headers (TRX, uImage) to determine how much data needs to be 
checksummed. The size field in the headers reflects the original firmware image 
size, not the new firmware image size, so it's not surprising that the CRC is 
incorrect. 

With that said, I notice that the header identified by cracalc is 20 bytes into 
the firmware image, and that the CRC calculated by crcalc is always the same. 
The problem is likely that the header at offset 20 is only a header for the 
Linux kernel, and there is a proprietary header before that which calculates a 
checksum over the entire image, including the file system. This is more likely 
the source of your failed checksum errors.

If you can provide a link to the exact firmware image you are working on, I 
might be able to get something working, but I can't guarantee any timeframe, 
things are quite busy at the moment.

Original comment by heffne...@gmail.com on 26 Nov 2012 at 3:57

[GoogleCodeExporter]

Thank you for your response.
Now I understand more precisely what exactly is happening, I was thinking that 
it is much less complicated: something like parse the firmware file, cut it 
into pieces, grab the piece where data resides (in that case squashfs image), 
extract it, modify it repack and reassembly the firmware from the other 
cuts...but there're some pitfails:)
I though that there might be a problem with an internal checksums, and I also 
believe there's more than one build inside the image itself, somewhere in 
around the squashfs data, but when I saw the equivalence of the both firmware 
images - the modified one and the original one, I stick to this info.
I'll investigate more thoughtfully 
Here is the link to the mentioned problematic firmware image:
http://www.edimax.com/images/Image/Firmware/Wireless/Router/BR-6504n/EdiEngBR650
4N_1.51.zip
I'll be grateful if you manage to tweak it somehow, but do not worry about the 
time. I'll try couple of tricks meanwhile.

Just a question.. what does this mean: "it says that the new image WILL be 
larger than the original, then displays the CURRENT size of the new image."
At the end it turns out that the new image is even smaller than the original by 
few bits. And more there's 4MB of flash on that particular device. Or this 
message means that there will be a difference in size of the images, and the 
new image will be larger than the firmware package? (if there're some 
boundaries defined inside the firmware itself for its internal components)

Original comment by velinr...@gmail.com on 26 Nov 2012 at 4:25

[GoogleCodeExporter]

When the size error message is displayed, the firmware image is not complete. 
build-ng looks at the current size of the image, plus the size of the remaining 
data that it needs to append to the image, and checks to see if the final size 
will exceed the size of the original image. If so, it will abort the build 
process and will not add the remaining data to the output image. So yes, the 
size of the new image on disk is less than the original image, but the new 
image is also incomplete.

The image you created after editing build-ng.sh should have been larger than 
the original image.

Original comment by heffne...@gmail.com on 27 Nov 2012 at 12:30

[GoogleCodeExporter]

I think I got it guys.
What I did is the following.
Extracted the squashfs-tools3.0 from Firmware modification kit from 
sourceforge, I believe it is a fork to your tool. Compiled it and test it 
against a small folder.
then downloaded the original firmware from Edimax for BR6504n.
Scanned it with binwalk and extracted the squashfs into a file using dd. Then 
unsquashed it using squashfs-tools.
edited the init.sh located at the /bin folder of the filesystem and added at 
the end after last line /usr/sbin/telnetd &. 
Save, then mksquash from the root-image-folder. 
Extracted the first part of the firmware (the kernel) to a new file and 
concatenated the new squashed file system. Now the tricky part!
After carefully review of what you've wrote here:
"..there is a proprietary header before that which calculates a checksum over 
the entire image.."
So I started reviewing the Header part.. the first 40 bytes of the firmware 
file. And I got it. Zeroed the following address: 0x10,0x11,0x12 and uploaded 
it using web interface.
And voila!! I've a port 23 nicely open and welcoming me to enter my credentials.
So far so good, but it turns out that the prompt is not taken from /bin/login, 
but instead from /bin/setup. And the username/password are not red from passwd 
file. Tried to apply strings on /bin/setup file, and found two possible 
suspicious strings:
"super" and "linuxsupergo". Unfortunately it didn't work with neither of them 
in whatever combinations.
Still working to provide a shell to this device!

Original comment by velinr...@gmail.com on 22 Mar 2013 at 7:27

[GoogleCodeExporter]

Original comment by jeremy.collake@gmail.com on 11 Jun 2013 at 8:19

• Changed state: Fixed