charles2gan / charles2gan/firmware-mod-kit
CramFS extraction failed due to missing cleaning up
- Dominant language
- C
- Stars
- 7
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
```
While trying to extract a CramFS filesystem with binwalk, I narrowed down the
extraction failure to one script: uncramfs_all.sh
Here is what happens (traced through a "bash -x"):
1. the script tries to extract it with LZMA compression and fails because this
particular one is not compressed with LZMA.
2. then a cramfsck occurs and returns an exit code of 4
3. It tries to extract it with uncramfs which, launched manually succeeds but
as the script did not cleaned up the extracted files from the LZMA attempt, it
fails because files already exists.
Unsure about the need of cleaning also before calling cramfsck.
Here is a working patch:
diff --git a/uncramfs_all.sh b/uncramfs_all.sh
index 7b8a7af..f67242d 100755
--- a/uncramfs_all.sh
+++ b/uncramfs_all.sh
@@ -105,6 +105,7 @@ then
exit 0
fi
+ rm -rf "$ROOTFS"
./src/uncramfs/uncramfs "$ROOTFS" "$FSIMG.le" 2>/dev/null
if [ $? -eq 0 ]
then
```
Original issue reported on code.google.com by `jmiche...@gmail.com` on 21 Jul 2014 at 8:14
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with uncramfs_all.sh and reproduce the reported CramFS extraction path with bash -x, including the failed LZMA attempt, cramfsck exit code 4, and final uncramfs call. Check the extraction directory state between these steps; done means a non-LZMA CramFS image extracts successfully without existing-file collisions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bash, shell
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100