PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,153
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Counter-question: What do you know about the structure of a PE executable at all and the ".data" section of a recovery program specially?
There are many possible approaches to extract the mentioned section from the file - read/research the "basics" and you could find, that this section contains at least a "run-length encoded" filesystem image, obviously starting at an offset, that's only a few bytes within this file (section).
This image starts with the signature of "sqsh" (expectable, if you know, how a file is structured, which may be used to start a FRITZ!Box device from RAM) and ends somewhere in the ".data" section - one tool, usable to translate the RLE data to the binary form, is this: https://github.com/PeterPawn/YourFritz/blob/master/tools/rle_decode.c
I haven't any idea, how long this RLE data is in your file ... but it's not my task to find this out. It's yours ... and the only fact, that's already known, is - once again obviously - that this ".data" section has to contain additional data (at least a Linux kernel image and if an "urlader image" exists, it has to be stored somewhere, too).
This will start somewhere behind the filesystem image (you should pay attention to the fact, that this filesystem image isn't really a "native" SquashFS image - VR9 models use an "ext2" wrapper filesystem in this place, please research the "basics") and if the recovery program contains really an "urlader image", this should lay somewhere behind the filesystem image, too.
But please do not ask again, whether the kernel image or the "urlader image" comes first after the filesystem image ... it's possible to research this yourself.
After you've detected the (real) length of RLE data for the "ext2" image, next data will be either of the two binary "images" (mentioned above) and you have to/should compare this data with the stream, that will be stored by the recovery program to RAM (use a network packet sniffer in this place).
The part of data, which preced the ext2 image on upload to the box, is the Linux kernel - I don't know, whether this one is run-length encoded, too, or not ... while it's stored in the recovery file, 'cause the uploaded data will be decompressed always.
And data, that's not part of the ext2 image, the kernel image or the (real) data segment of the recovery program, will be the "urlader image" - do you agree?
And one more time I don't know yet, whether this "urlader image" is stored as RLE data or not - but I'm sure, you will find it out yourself.
You should know the maximum length of the loader code (it can't be larger than the partition size in the SPI flash, right?) and even if you're unable to find the real end of the loader code, it shouldn't matter, if there's some junk at the end ... as long as all needed data is contained.
(Little hint from myself: Often such data is prepended with a length field or something else ... the program itself has to know this length, too, and so it's usually stored somewhere in such a program.)
I know, it's a hard task to collect the needed knowledge ... but I don't see any alternative, if you really want to repair your device.
But you are putting the patience of others to a hard test if, instead of doing your own research/searches, you only ask if anyone can explain it to you again.
I've seen and realized (I swear), that you've tried to find some info by your own ... but these attempts were not really "professional" or seriously, when they lead (or led) to wrong results (as the attempt, to load a "busybox" binary into RAM - found at your C# source above).
Maybe I'm wrong, but my impression is, that you're easily distracted by new info, which you've read/found and instead of following a clean path to a clear target, you're bouncing to the left and right of this way and if you see any flower, you're checking, how it smells.
Do not create/get a new idea, how you could solve your problem, every 5 minutes ... define the goal once and as long as you did not find out, that this one is really(!) unrealistic, try to follow the path to its end in any way.
I tend to think, that you are changing the current ideas for a solution over and over again and that there's no "real plan", what you're doing (due to the lack of the mentioned "basic knowledge", how a FRITZ!Box device works).
That's no offense or attack ... it's only an attempt to show you, where/what your current mistakes are - from my own point of view, which hasn't to be the right one.
You've got a good idea and had some luck, that there's a recovery program containing an update of the "urlader code" - that's not often the case for these files. If you're now trying to flash this loader code to your device, you should collect the needed info (yourself), how the recovery program is structured and where you may find some code or examples, how to dissect this file into its ingredients.
That's not too easy, but it's possible and you know already (as far as I've seen), that there's a "Freetz" project, where you may find some of the needed info - inter alia even a script, that may be used to dissect these files (extract-images). It's possible, that it will not work "out of the box" in your case - but it should be able to provide you an idea, how it works and then you're in charge of all further actions.
Don't get me wrong ... if there are concrete questions as to whether the path taken is the right one and whether something can/will work or not, then it is perfectly legitimate to ask about it here. But a "How do I do it?" is (usually) a longer story and it's not necessarily fun to tell it several times, even if it can be easily read elsewhere.
Nevertheless it's matter of course here to answer (qualified) questions ... but it's simply impossible to ask qualified questions, if there's a lack of basic knowledge and this is your (hard) part to be done first.
There are many possible approaches to extract the mentioned section from the file - read/research the "basics" and you could find, that this section contains at least a "run-length encoded" filesystem image, obviously starting at an offset, that's only a few bytes within this file (section).
This image starts with the signature of "sqsh" (expectable, if you know, how a file is structured, which may be used to start a FRITZ!Box device from RAM) and ends somewhere in the ".data" section - one tool, usable to translate the RLE data to the binary form, is this: https://github.com/PeterPawn/YourFritz/blob/master/tools/rle_decode.c
I haven't any idea, how long this RLE data is in your file ... but it's not my task to find this out. It's yours ... and the only fact, that's already known, is - once again obviously - that this ".data" section has to contain additional data (at least a Linux kernel image and if an "urlader image" exists, it has to be stored somewhere, too).
This will start somewhere behind the filesystem image (you should pay attention to the fact, that this filesystem image isn't really a "native" SquashFS image - VR9 models use an "ext2" wrapper filesystem in this place, please research the "basics") and if the recovery program contains really an "urlader image", this should lay somewhere behind the filesystem image, too.
But please do not ask again, whether the kernel image or the "urlader image" comes first after the filesystem image ... it's possible to research this yourself.
After you've detected the (real) length of RLE data for the "ext2" image, next data will be either of the two binary "images" (mentioned above) and you have to/should compare this data with the stream, that will be stored by the recovery program to RAM (use a network packet sniffer in this place).
The part of data, which preced the ext2 image on upload to the box, is the Linux kernel - I don't know, whether this one is run-length encoded, too, or not ... while it's stored in the recovery file, 'cause the uploaded data will be decompressed always.
And data, that's not part of the ext2 image, the kernel image or the (real) data segment of the recovery program, will be the "urlader image" - do you agree?
And one more time I don't know yet, whether this "urlader image" is stored as RLE data or not - but I'm sure, you will find it out yourself.
You should know the maximum length of the loader code (it can't be larger than the partition size in the SPI flash, right?) and even if you're unable to find the real end of the loader code, it shouldn't matter, if there's some junk at the end ... as long as all needed data is contained.
(Little hint from myself: Often such data is prepended with a length field or something else ... the program itself has to know this length, too, and so it's usually stored somewhere in such a program.)
I know, it's a hard task to collect the needed knowledge ... but I don't see any alternative, if you really want to repair your device.
But you are putting the patience of others to a hard test if, instead of doing your own research/searches, you only ask if anyone can explain it to you again.
I've seen and realized (I swear), that you've tried to find some info by your own ... but these attempts were not really "professional" or seriously, when they lead (or led) to wrong results (as the attempt, to load a "busybox" binary into RAM - found at your C# source above).
Maybe I'm wrong, but my impression is, that you're easily distracted by new info, which you've read/found and instead of following a clean path to a clear target, you're bouncing to the left and right of this way and if you see any flower, you're checking, how it smells.
Do not create/get a new idea, how you could solve your problem, every 5 minutes ... define the goal once and as long as you did not find out, that this one is really(!) unrealistic, try to follow the path to its end in any way.
I tend to think, that you are changing the current ideas for a solution over and over again and that there's no "real plan", what you're doing (due to the lack of the mentioned "basic knowledge", how a FRITZ!Box device works).
That's no offense or attack ... it's only an attempt to show you, where/what your current mistakes are - from my own point of view, which hasn't to be the right one.
You've got a good idea and had some luck, that there's a recovery program containing an update of the "urlader code" - that's not often the case for these files. If you're now trying to flash this loader code to your device, you should collect the needed info (yourself), how the recovery program is structured and where you may find some code or examples, how to dissect this file into its ingredients.
That's not too easy, but it's possible and you know already (as far as I've seen), that there's a "Freetz" project, where you may find some of the needed info - inter alia even a script, that may be used to dissect these files (extract-images). It's possible, that it will not work "out of the box" in your case - but it should be able to provide you an idea, how it works and then you're in charge of all further actions.
Don't get me wrong ... if there are concrete questions as to whether the path taken is the right one and whether something can/will work or not, then it is perfectly legitimate to ask about it here. But a "How do I do it?" is (usually) a longer story and it's not necessarily fun to tell it several times, even if it can be easily read elsewhere.
Nevertheless it's matter of course here to answer (qualified) questions ... but it's simply impossible to ask qualified questions, if there's a lack of basic knowledge and this is your (hard) part to be done first.
Zuletzt bearbeitet:
