Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Router EPUP EP9501 (Realtek 8196C) success in extract-ng.sh #38

Closed
GoogleCodeExporter opened this issue Nov 1, 2015 · 3 comments
Closed

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. extract_firmware.sh = ERROR:

 Opening EP9501N-E.bin
 read 2387843 bytes
 ERROR trx header not found
 splitter3 0.10 beta - (c)2010 Jeremy Collake
 Opening EP9501N-E.bin
 read 2387843 bytes
 SQUASHFS magic: 0x73717368
 SQUASHFS version: 4.0
 Found segment type 0x8 Kernel length is 128f81
 File system length is 11d07f
 Trailer is f83 bytes
  Writing 2/image_parts/vmlinuz
    size 1216385 from offset 0 ...
 SQUASHFS magic: 0x73717368
 SQUASHFS version: 4.0
  ! WARNING: Unknown squashfs version.
  Writing 2/image_parts/squashfs-lzma-image-x_x
    size 1167487 from offset 1216385 ...
  Writing 2/image_parts/hwid.txt
    size 3971 from offset 2383872 ...
  Done!
2. extract-ng.sh = o'k:

[root@localhost trunk]# ./extract-ng.sh EP9501N-E.bin 1
Firmware Mod Kit (build-ng) 0.71 beta, (c)2011 Craig Heffner, Jeremy Collake
http://www.bitsum.com

Scanning firmware...

DECIMAL         HEX             DESCRIPTION
--------------------------------------------------------------------------------
-----------------------
1216385         0x128F81        Squashfs filesystem, little endian, version 
4.0, size: 297826815 bytes, 382 inodes, blocksize: 0 bytes, created: Sat Jun 30 
06:08:00 1979

Extracting 1216385 bytes of  header image at offset 0
Extracting squashfs file system at offset 1216385
Extracting 16 byte footer from offset 2387827
Extracting squashfs files...
Firmware extraction successful!

Original issue reported on code.google.com by Vladimir...@gmail.com on 21 Oct 2011 at 4:27

@GoogleCodeExporter
Copy link
Author

The extract-firmware.sh script is the OLDER rendition that does not support as 
many platforms. The -NG scripts are REPLACEMENTS. The old ones are kept on the 
off chance they handle some format the new ones don't. Craig - honestly, do we 
need the old scripts still? It won't hurt my feeling is the answer is NO, but I 
assumed Yes.

Original comment by jeremy.collake@gmail.com on 21 Oct 2011 at 4:51

@GoogleCodeExporter
Copy link
Author

The extract-ng script should properly extract anything with squashfs/cramfs 
file systems (it only extracts the first file system so it doesn't support any 
images with multiple file systems). 

Re-building is a little trickier of course, but build-ng should reassemble 
anything extracted by extract-ng and patch up any uImage/TRX headers properly 
(multiple and/or mixed headers are OK); it also assumes that the kernel 
precedes the filesystem in the firmware image so anything not conforming to 
that layout may not work.

So I *think* that the NG scripts will cover all of the firmware that is 
supported by the extract_firmware/build_firmware scripts? I don't know for sure 
though and didn't test. If you don't think that the old scripts provide any 
advantages you can of course take them out if you wish, but I'll leave that at 
your discretion since you know more about them (and the firmware they were 
tested against) than I do.

Original comment by heffne...@gmail.com on 22 Oct 2011 at 1:01

@GoogleCodeExporter
Copy link
Author

Closing as invalid.

Original comment by heffne...@gmail.com on 4 Nov 2011 at 1:00

  • Changed state: Invalid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant