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

Homeware Recovery Project #514

Open
LuKePicci opened this issue Feb 24, 2019 · 11 comments
Open

Homeware Recovery Project #514

LuKePicci opened this issue Feb 24, 2019 · 11 comments
Labels

Comments

@LuKePicci
Copy link

@LuKePicci LuKePicci commented Feb 24, 2019

I've got an idea about a possible way to implement a sort of recovery mechanism for OpenWrt based Homeware firmwares exploiting dual-bank design.

I hereby describe very briefly the general idea and let you think about how to implement it correctly, if feasible.

In a normally functional state the overall situation should look like this:

  • the active bank is bank_1
  • the booted bank is bank_2
  • the bank_1 content (mtd3) is not a valid bootable firmware
    -- optionally, bank_1 (mtd3) may contain the custom gui www folder, to save some space on the overlay jffs2 fs
  • the bank_2 content (mtd4) is the operating firmware
  • /overlay/bank_1 contains only minimal scripts to allow recovery working as described below
  • /overlay/bank_2 contains usual user contents, settings and customizations

The recovery handler scripts must behave in this way with no relaxations:

  • if the booted bank is bank_1 we are in recovery mode, otherwise exit
  • mark bank_1 as active, to ensure it is
  • clone bank_1 to bank_2 (mtd3 -> mtd4)
  • mark bank_1 image as not bootable (writing 0xFF in the first first 4 bytes of mtd3)
  • if overlay is not critically full, wait a bit to allow manual intervention from serial/ssh
  • erase userfs/rootfs_data (mtd2) completely and unconditionally
  • reboot

In order to enter recovery mode user has to simply load a valid firmware in bank_1 via TFTP flashing in BOOTP mode.
At the end of recovery process user has to repeat the device unlock from the beginning and possibly restore a working overlay backup.
If user loads a valid firmware which is not exploiting the recovery scripts inside /overlay/bank_1 nothing bad should happen, it should suffice to reload the correct one again from TFTP.
If user loads a valid firmware which gets cloned into bank_2 but it is not directly unlockable and user has no valid rooted config.bin backups then, yes, he will need to trigger failsafe bankswitching.
Ordinary firmware upgrades have to be performed from within the booted firmware and written into bank_2, not by TFTP

@FrancYescO

This comment has been minimized.

Copy link
Collaborator

@FrancYescO FrancYescO commented Feb 24, 2019

-- optionally, bank_2 (mtd4) may contain the custom gui www folder, to save some space on the overlay jffs2 fs

How can we write in mtd4 and than boot it?!

I think we should use this exploit also to use mtd3 as an expansion of mtd2

@LuKePicci

This comment has been minimized.

Copy link
Author

@LuKePicci LuKePicci commented Feb 24, 2019

Of course, I just edited. This is pretty nice since custom www contents gets cleaned in the recovery process by TFTP flashing itself.
If mtd3 could be mounted as an extra overlay on top of /www folder, or /www should simply be changed into a symlink to a separate jffs2 partition it's up to you.

@kevdagoat

This comment has been minimized.

Copy link
Contributor

@kevdagoat kevdagoat commented Feb 25, 2019

This should be an entirely new project. It would be good if all of this were hosted under an organisation

@flywire

This comment has been minimized.

Copy link
Contributor

@flywire flywire commented Feb 27, 2019

@nutterthanos

This comment has been minimized.

Copy link

@nutterthanos nutterthanos commented Jul 17, 2019

Is it possible to do OpenWrt Failsafe Boot on any Technicolor Gateway even with full jffs2 partition?

@LuKePicci

This comment has been minimized.

Copy link
Author

@LuKePicci LuKePicci commented Jul 17, 2019

@nutterthanos

This comment has been minimized.

Copy link

@nutterthanos nutterthanos commented Jul 17, 2019

Oh lol so if the jffs2 partition gets full after reboot without mtd erase whatever bank is booted and other bank is empty so your pretty much screwed if bank 1 has firmware on it.
Edit: If jffs2 is full and you reboot without mtd erase your gateway is done for like pretty much dommed. Because tftp/bootp flash won’t fix anything if the partition is full. So if that happens what do we do then?

@LuKePicci LuKePicci mentioned this issue Jul 17, 2019
@LuKePicci

This comment has been minimized.

Copy link
Author

@LuKePicci LuKePicci commented Jul 17, 2019

I can't completely understand what you say, but if my intuition is correct, you are asking what to do when jffs2 is full. You need to flash a firmware into bank_1 with tftp which is capable of booting fine (no bootloops) with current /overlay/bank_1 contents. That's why it is fundamental to keep a simple root setup with no further mods into /overlay/bank_1 and mess up with /overlay/bank_2 at will instead.
Keeping bank_1 active and wiped simply allows you to avoid difficult bootfail procedures. Just insert a firmware into bank_1 with tftp and it will boot in place of the messed up bank_2.
As mentioned in the OP, it would be even better to mod /overlay/bank_1 contents a little bit to perform an mtd erase of jffs2 automatically, such that it can recover even where a normal boot will cause a bootloop in case jffs2 is full.

@nutterthanos

This comment has been minimized.

Copy link

@nutterthanos nutterthanos commented Jul 17, 2019

Yeah so as soon as it get’s to like 99% full or someone the gateway will automatically erase the full partition.

@LuKePicci

This comment has been minimized.

Copy link
Author

@LuKePicci LuKePicci commented Jul 17, 2019

I would say 96%

@nutterthanos

This comment has been minimized.

Copy link

@nutterthanos nutterthanos commented Jul 18, 2019

So how should we make a script for that?
Like make a cron script?

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

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.