Write partitions to emmc flash. Netgear MR1100

[Semsem8519]

Hi. I dumped partitions successfully but when I wanted to write them to the emmc it fails.

https://imgur.com/a/maKaTVy

[bkerler]

Hi, streaming write support hasn't been tested so far. I will have a look.

[Semsem8519]

Thank you so much. My device is currently bricked into 9008 mode because I apparently stupidly erased some partitions(sbl and mibib) with the flashwrite command when I telnet'ed into the device. I have a partition backup from another device but I could not get QFIL to write to the device too. I really hope I don't end up with a paperweight device. Thank you.

[jbgtenn423]

It can be revived, is that the only partitions you erased? If so I can send you something to restore those two.

[Semsem8519]

Hi. Yes I only erased those two partitions. Thank you so much for helping me. I really appreciate it.

[jbgtenn423]

What’s your email?

…

On Tue, Aug 3, 2021 at 6:09 PM Semsem8519 ***@***.***> wrote: Hi. Yes I only erased those two partitions. Thank you so much for helping me. I really appreciate it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANEYHFJC3FPQK2E3SSFGGVDT3BSJFANCNFSM5BCKCNZA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[lgeek]

Hi. Sorry about digging up an old issue, but it still seems to be valid. I'm trying to fix an MR1100 stuck in a bootloop. It didn't get fixed by regular firmware flashing with the fdt tool, so I assume something is corrupt in the settings partition or somewhere else that doesn't get modified by the firmware update. I also have a working MR1100 with the same part / hw revision number, and I've dumped the NAND of both devices using edl (thanks!).

My plan was to start overwriting each partition from the bad unit with the one from the good unit, until something changes. But writing using EDL doesn't seem to be working yet. I've been trying to fix things on my own, but now I got stuck on generating a valid partition table. Here's what I've done so far:

for the wl command:

• in edlclient/Library/streaming_client.py#L423
  -replaced self.streaming.write_flash(partition, filename) with self.streaming.write_flash(partname=partition, filename=filename) as the arguments didn't match write_flash()'s signature (first argument is lba)

This allowed execution to proceed a bit further, but then send_section_header() (called from write_flash) fails. The return value of send_section_header()'s send() is \x0eNo partition table received before open multi\n. So it sounds like the loader is always expecting to receive a partition table.

Then I noticed that the code for the w command appears to be sending the partition table, via enter_flash_mode() called with a ptable argument. I've first tried to just send it back the partition table read from the device using edl --gpt (by calling edl w with --partitionfilename). Now send_ptable() fails with \x0eUnknown error accepting partition table\n from the loader. I've also tried the code that's commented out for w to generate a partition table with a single entry for the partition I'm writing, but I get the same error. Same if I patch that code to use 0x55EE73AA and 0xE35EBDDB as the magic numbers in the header (that's what's used in the partition table of the device).

I've also taken a peek at the loader in Ghidra to see if that error message has an obvious cause, but I'm more experienced with dynamic reverse engineering and for now I got lost chasing up functions. But I'm pretty sure that there's a fair amount of code that needs to be reversed to understand why it fails with that message.

I'd appreciate any help in moving past this and, of course, if I get things working I'd be more than happy to contribute back any fixes needed to edl.

[mosasha1234]

Hi. Sorry about digging up an old issue, but it still seems to be valid. I'm trying to fix an MR1100 stuck in a bootloop. It didn't get fixed by regular firmware flashing with the fdt tool, so I assume something is corrupt in the settings partition or somewhere else that doesn't get modified by the firmware update. I also have a working MR1100 with the same part / hw revision number, and I've dumped the NAND of both devices using edl (thanks!).

My plan was to start overwriting each partition from the bad unit with the one from the good unit, until something changes. But writing using EDL doesn't seem to be working yet. I've been trying to fix things on my own, but now I got stuck on generating a valid partition table. Here's what I've done so far:

for the wl command:

• in edlclient/Library/streaming_client.py#L423
  -replaced self.streaming.write_flash(partition, filename) with self.streaming.write_flash(partname=partition, filename=filename) as the arguments didn't match write_flash()'s signature (first argument is lba)

This allowed execution to proceed a bit further, but then send_section_header() (called from write_flash) fails. The return value of send_section_header()'s send() is \x0eNo partition table received before open multi\n. So it sounds like the loader is always expecting to receive a partition table.

Then I noticed that the code for the w command appears to be sending the partition table, via enter_flash_mode() called with a ptable argument. I've first tried to just send it back the partition table read from the device using edl --gpt (by calling edl w with --partitionfilename). Now send_ptable() fails with \x0eUnknown error accepting partition table\n from the loader. I've also tried the code that's commented out for w to generate a partition table with a single entry for the partition I'm writing, but I get the same error. Same if I patch that code to use 0x55EE73AA and 0xE35EBDDB as the magic numbers in the header (that's what's used in the partition table of the device).

I've also taken a peek at the loader in Ghidra to see if that error message has an obvious cause, but I'm more experienced with dynamic reverse engineering and for now I got lost chasing up functions. But I'm pretty sure that there's a fair amount of code that needs to be reversed to understand why it fails with that message.

I'd appreciate any help in moving past this and, of course, if I get things working I'd be more than happy to contribute back any fixes needed to edl.

hello igeek
sorry to trouble you,
but i also have a bootlooping mr1100 and i am trying to recover it, so if you could please send me the dump you have taken from the other working device. it will be highly appreciated

thanks in advance and best regards

[Semsem8519]

Hi. Sorry about digging up an old issue, but it still seems to be valid. I'm trying to fix an MR1100 stuck in a bootloop. It didn't get fixed by regular firmware flashing with the fdt tool, so I assume something is corrupt in the settings partition or somewhere else that doesn't get modified by the firmware update. I also have a working MR1100 with the same part / hw revision number, and I've dumped the NAND of both devices using edl (thanks!).
My plan was to start overwriting each partition from the bad unit with the one from the good unit, until something changes. But writing using EDL doesn't seem to be working yet. I've been trying to fix things on my own, but now I got stuck on generating a valid partition table. Here's what I've done so far:
for the wl command:

• in edlclient/Library/streaming_client.py#L423
  -replaced self.streaming.write_flash(partition, filename) with self.streaming.write_flash(partname=partition, filename=filename) as the arguments didn't match write_flash()'s signature (first argument is lba)

This allowed execution to proceed a bit further, but then send_section_header() (called from write_flash) fails. The return value of send_section_header()'s send() is \x0eNo partition table received before open multi\n. So it sounds like the loader is always expecting to receive a partition table.
Then I noticed that the code for the w command appears to be sending the partition table, via enter_flash_mode() called with a ptable argument. I've first tried to just send it back the partition table read from the device using edl --gpt (by calling edl w with --partitionfilename). Now send_ptable() fails with \x0eUnknown error accepting partition table\n from the loader. I've also tried the code that's commented out for w to generate a partition table with a single entry for the partition I'm writing, but I get the same error. Same if I patch that code to use 0x55EE73AA and 0xE35EBDDB as the magic numbers in the header (that's what's used in the partition table of the device).
I've also taken a peek at the loader in Ghidra to see if that error message has an obvious cause, but I'm more experienced with dynamic reverse engineering and for now I got lost chasing up functions. But I'm pretty sure that there's a fair amount of code that needs to be reversed to understand why it fails with that message.
I'd appreciate any help in moving past this and, of course, if I get things working I'd be more than happy to contribute back any fixes needed to edl.

hello igeek sorry to trouble you, but i also have a bootlooping mr1100 and i am trying to recover it, so if you could please send me the dump you have taken from the other working device. it will be highly appreciated

thanks in advance and best regards

What is your email? We can try something that might be successful in getting your device to boot normally.

[Akhtian]

Hi. I also have bootloop issue. Also i have working device. Can you help me with it ? I tried to do dump from working device, but there is no success. My email is akhtian@gmail.com

[jericsmith504]

Hi. Sorry about digging up an old issue, but it still seems to be valid. I'm trying to fix an MR1100 stuck in a bootloop. It didn't get fixed by regular firmware flashing with the fdt tool, so I assume something is corrupt in the settings partition or somewhere else that doesn't get modified by the firmware update. I also have a working MR1100 with the same part / hw revision number, and I've dumped the NAND of both devices using edl (thanks!).
My plan was to start overwriting each partition from the bad unit with the one from the good unit, until something changes. But writing using EDL doesn't seem to be working yet. I've been trying to fix things on my own, but now I got stuck on generating a valid partition table. Here's what I've done so far:
for the wl command:

• in edlclient/Library/streaming_client.py#L423
  -replaced self.streaming.write_flash(partition, filename) with self.streaming.write_flash(partname=partition, filename=filename) as the arguments didn't match write_flash()'s signature (first argument is lba)

This allowed execution to proceed a bit further, but then send_section_header() (called from write_flash) fails. The return value of send_section_header()'s send() is \x0eNo partition table received before open multi\n. So it sounds like the loader is always expecting to receive a partition table.
Then I noticed that the code for the w command appears to be sending the partition table, via enter_flash_mode() called with a ptable argument. I've first tried to just send it back the partition table read from the device using edl --gpt (by calling edl w with --partitionfilename). Now send_ptable() fails with \x0eUnknown error accepting partition table\n from the loader. I've also tried the code that's commented out for w to generate a partition table with a single entry for the partition I'm writing, but I get the same error. Same if I patch that code to use 0x55EE73AA and 0xE35EBDDB as the magic numbers in the header (that's what's used in the partition table of the device).
I've also taken a peek at the loader in Ghidra to see if that error message has an obvious cause, but I'm more experienced with dynamic reverse engineering and for now I got lost chasing up functions. But I'm pretty sure that there's a fair amount of code that needs to be reversed to understand why it fails with that message.
I'd appreciate any help in moving past this and, of course, if I get things working I'd be more than happy to contribute back any fixes needed to edl.

hello igeek sorry to trouble you, but i also have a bootlooping mr1100 and i am trying to recover it, so if you could please send me the dump you have taken from the other working device. it will be highly appreciated
thanks in advance and best regards

What is your email? We can try something that might be successful in getting your device to boot normally.

Apologies for opening old issue, if there is a solution here, would greatly appreciate any assistance as I appear to be in same boat with looping MR1100 that fails normal firmware attempts with fdt. my email is eric@nola4.com if anyone out there is watching. Thank you!!