Fritz!5490 EVA bootloader lost!!

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,884
Punkte für Reaktionen
962
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.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: EcbBc

EcbBc

Neuer User
Mitglied seit
4 Mrz 2020
Beiträge
27
Punkte für Reaktionen
1
Punkte
3
I will try to modify the 7490 EVA bootloader or extract the EVA bootloader from the recovery tool.

If someone gets an EVA booloader from router 5490 that warns me.

Anyway thank you very much for the help, I will continue investigating. :)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,884
Punkte für Reaktionen
962
Punkte
113
I will try to modify the 7490 EVA bootloader
This is only the 2nd best idea ... better follow the path with extraction of a proper one from the recovery program.

My suggestion to modify the NAND chip parameter table in the 7490 loader, was only a "first thought" and as you've got now the code of a better fitted loader (even if it has to be extracted first), that's the best manner.

So you should change the order of your approaches.
 

EcbBc

Neuer User
Mitglied seit
4 Mrz 2020
Beiträge
27
Punkte für Reaktionen
1
Punkte
3
when you have the code extracted from the recovery software.

How can i test it?

Burning the flash chip with the programmer?

or

Can it be run directly in memory?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,884
Punkte für Reaktionen
962
Punkte
113
If you've extracted the code, you should burn it to the SPI chip ... it can't be loaded into RAM by EVA (from the 7490 loader), because it's "raw binary", while EVA (and ADAM2 as its predecessor) uses a special header here (with fields for the (absolute and real) address of the loaded code and its length).

It the extracted code is really wrong (what should not occur, because you may compare the 7490 and 5490 version of the code as a verfication - both should start with the same machine instructions), you may flash the now-running 7490 loader again.

EDIT: You've kept the necessity in mind, to use a valid "device specific block" at offset 0x580 of the new loader?
 

EcbBc

Neuer User
Mitglied seit
4 Mrz 2020
Beiträge
27
Punkte für Reaktionen
1
Punkte
3
Erase and write the SPI chip has a limited number of attempts?
The chip wears out?

I have not uploaded the extracted binary.

But if necessary I can send it.

Thank's
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,884
Punkte für Reaktionen
962
Punkte
113
These cells, where the loader code is stored (offset 0 in SPI flash), aren't written usually and so it's quite unlikely, that these cell will get damaged with some additional attempts. In most boxes, these cells were used with less than 10 erase/write cycles in the past - and their durability is much higher.
 
  • Like
Reaktionen: EcbBc