PDA

View Full Version : Use remote panic codes for emergency repair...



tivomaster
08-26-2004, 10:01 AM
The hacking community spends some time pulling their respective drives because they messed up something. This is getting more and more common since the flurry of tivoapp patches, although there are numerous ways to get your tivo into a boot loop which can cause you to have to pull the drive/mount it in a pc/fix it/put back in the tivo/rinse/repeat.....

This thread got me to thinking....
Secret Sequences (http://www.dealdatabase.com/forum/showthread.php?p=181138)

Looking at how this is done it appears that rc.sysinit checks for a user generated "panic" code from the remote. If I see this right it is doen by this code:


if [ $panic -ne 0 ] ; then
case $panic in
169)
echo "Kickstart code 5 2 - emergency reinstall"
export EMERGENCY_REINSTALL=1
;;
170)
echo "Kickstart code 5 3 - BER testing"
export rsoff=true
;;
171)
echo "Kickstart code 5 4 - HDD test"
export do_hdd_test=1
;;
172)
echo "Kickstart code 5 5 - Tuner/AFT test"
export do_aft_test=1
;;
173)
echo "Kickstart code 5 6 - software install"
export swupgrade=true
;;
174)
echo "Kickstart code 5 7 - force MFS check"
do_mfs_assert=1
;;
175)
echo "Kickstart code 5 8 - perform MFS cleanup"
do_mfs_cleanup=1
;;
240)
echo "Retailer Reset code - initiate factory reset"
do_factory_reset=1
;;
*)
kickstart $panic
reboot
;;
esac
fi

My thoughts are...
What if we put our own "panic" code,say using remote code 59, that simply branches out to a rc.panic script. This script would simply be a stripped down rc.sysint that simply brings up the stuff needed to get a telnet session... What do you experts think?
Doable?
Worth the effort?

TM.....

JJBliss
08-26-2004, 10:18 AM
My thoughts are...
What if we put our own "panic" code,say using remote code 59, that simply branches out to a rc.panic script. This script would simply be a stripped down rc.sysint that simply brings up the stuff needed to get a telnet session... What do you experts think?
Doable?
Worth the effort?

TM.....


Sounds like a pretty good idea. How do you plan to begin your development? I recommend doing your testing on a Tivo that you don't use for watching television. It lowers the stress level.

Good luck with your programming and testing.

Lost Dog
08-26-2004, 11:43 AM
This kind of goes along with a thought that I've been playing with. I know nothing about how all this works so I'm studying and learning but would this be possible?

Many people use an additional partition to keep their hacks in. What if you put several patch scripts, such as killhdinitrd or the superpatch in that partition, plus something that updates your rc.sysinit.author for the needed hack tool lines (ethernet drivers, etc).

If your system get hosed, force the "repair" then force the "patches". Due to the fact that these are on the extra partition they won't get wiped during any repair process.

Ok, I'll go sit in the corner now....

tivomaster
08-26-2004, 12:59 PM
Sounds like a pretty good idea. How do you plan to begin your development? I recommend doing your testing on a Tivo that you don't use for watching television. It lowers the stress level.

Good luck with your programming and testing.

Cool, I was hoping that one of the GREATS would confim that it was doable.
What I was thinking was to do the rc.sysinit mod to fire off a script that simply put a message in the log and returned then work from there....

I will start playing with it tonight if I can find the time....

NutKase
08-26-2004, 05:44 PM
My thoughts are...
What if we put our own "panic" code,say using remote code 59, that simply branches out to a rc.panic script.

That's a great idea, doable and worth the effort. I've been playing with where to put 'tnlited' to start telnet for a while.

I'll test and help as necessary.


NutKase

my0gr81
08-27-2004, 03:06 PM
We could add a code that specifically calls commands in rc.arch or rc.net since one of them (don't know which) gets executed before rc.sysinit.

Basically, if a panic code is recieved, the code in rc.arch/rc.net initiates an alternate sysinit. We could even monte another kernel of just pivot_root to another root partition with clean software without any of the changes that got our system hosed to begin with. Fix without pulling the drive.

philhu
08-27-2004, 04:12 PM
Well, the emergency repair hack...

You do not want it doing too much, since the upgrade might make the hacks unuseable anyway.

I thin an emergency repair that sets up network, starts telnet and ftp would be enough to get hacks back up on a system without disk pulling.

The only problem is that the rc.sysinit/repair settings are restored to original during a bootup and system upgrade.

tivomaster
08-27-2004, 04:18 PM
Well, the emergency repair hack...

You do not want it doing too much, since the upgrade might make the hacks unuseable anyway.

I thin an emergency repair that sets up network, starts telnet and ftp would be enough to get hacks back up on a system without disk pulling.

The only problem is that the rc.sysinit/repair settings are restored to original during a bootup and system upgrade.

Such is true. I was thinking that the only thing the repair scritpt fires off is network and a telent daemon. If you want to start a ftp you can do it after you get telneted in... My thought are Keep it Simple.... Less stuff to go wrong.

On the survive an upgrade, I don't see any way any of this would survive an upgrade. I plan on getting started setting up my test machine tonight to see if this "therory" works...

philhu
08-27-2004, 04:33 PM
Such is true. I was thinking that the only thing the repair scritpt fires off is network and a telent daemon. If you want to start a ftp you can do it after you get telneted in... My thought are Keep it Simple.... Less stuff to go wrong.

On the survive an upgrade, I don't see any way any of this would survive an upgrade. I plan on getting started setting up my test machine tonight to see if this "therory" works...


A while back, one of the elders DID have a way the startup or part of the startup would survive upgrade. It was a pretty convoluted method, but anything persisting an upgrade would have to be.

It might have been back in the boot params days though :(

rc3105
08-27-2004, 08:03 PM
the upgrade / repair process depends on a few support utils like /tvlib/tcl/updateSoftware.tcl and /sbin/bootpage

neutering updateSoftware.tcl & renaming bootpage + writing a wrapper script named bootpage is all easy enough. so is an rc.sysinit (or wrapper) that checks certain conditions before starting up

my rc.sysinit is renamed rc.sysinit.real and the rc.sysinit the kernel invokes is a wrapper that checks certain conditions & determines whether to panic (serial bash + telnet & ftp) monte (load the end user kernel from /monte/vmlinux.px) or just hand control off to rc.sysinit.real

since there's generally a 2 meg hda2 or hda5 to play with (thanks mfstool) you could fsmake a tiny ext2 partition, use it as your boot parm root & install the wrappers / emergency utils there

tivomaster
08-28-2004, 11:36 PM
My first phase on development is to get serial bash after entering panic code 5-0...
I was succesfull although I have a little problem...

Here is what I have done so far..
Added the following code to the checkpanic code in rc.sysinit...


177)
echo "Kickstart code 5 0 - perform hackemr routine"
/etc/rc.d/hackemr/emergencyscript
;;
What this does is when you enter a 5 0 code causes /etc/rc.d/hackemr/emergencyscript to run...

In /etc/rc.d/hackemr/emergencyscript I have the below code:

#!/bin/bash
#
# Emergency Repair Script
#

#Start BASH
echo "Starting serial BASH"
/bin/bash</dev/ttyS2&>/dev/ttyS2&
cd /
sleep 30

The problem is that rc.sysinit continues to run...
How do I stop rc.sysinit from continuing?

Thanks
TM

tivomaster
08-29-2004, 09:37 AM
177)
echo "Kickstart code 5 0 - perform hackemr routine"
/etc/rc.d/hackemr/emergencyscript &
exit
;;


or some such...

Ahhhhh..
I should have thought of that.....
Thanks

tivomaster
08-30-2004, 12:22 AM
Success......
I have successfully used the serial bash from checkpanic 5 0 to fire up a telnet session....
Now all this is left to do is put the telnet stuff in a script, do some testing, and publish this puppy....

tivomaster
09-01-2004, 12:00 AM
Ok, I have finished it...
Attached is stoploop......
There is a stoploop.txt file in the attached zip. Read it, and understand it fully before attempting to install......

What stoploop does:
1. Provides a means of breaking out of a reboot loop so you can hopefully fix problems without pulling the drive.
2. Provides a "clean" environment (tivoapp, etc, not running) so you can test drivers, etc...

What it does not do:
1. Provide a fool proof bootup script. For example, this script depends on having a good rc.sysinit script. If you have been editing it and messed it up this script will not do you any good.
2. Provide any other connectivity besides telnet and serial bash (ftp etc..). I intentionally kept this as barebones as I could. If you need ftp, etc, fire it up after you get the bash prompt.

WARNING WARNING WILL ROBINSON.......
While this hack is fairly simple it does require some level of expertise. If you are new to hacking I would suggest you know exactly what you are doing prior to performing this.
THIS IS NOT A "SLEEPER" SCRIPT TYPE OF ACTIVITY.
DO NOT attempt it if you are not fairly proficient......
Performing actions involved in installing this such as editing your rc.sysinit, modifying files in /etc/rc/d etc... CAN EASILY CONVERT YOUR TIVO TO A DOORSTOP and thereby cause your wife to divorce you, your kids to hate you, and your dog to bite you....

YOU HAVE BEEN WARNED!!!!!!!!
This utility comes with NO warrenty.. If it screws up or you mess up the installation and your TiVo is turned into doorstop don't blame me....

Tivomaster.....

jonequest
09-06-2004, 04:22 AM
Great tool, but if I may ask can you tell me where to get to my rc.net file so I can try to edit it with joe? I hosed my xtreme by installing native net drivers, so far I have joe'd into everthing that I can find with no sign of rc.net

NutKase
09-06-2004, 06:10 AM
Mods...

...might want to delete/move the last 8 (now 10) posts... sorry, I answered to teach... :)

NutKase

jonequest
09-06-2004, 01:13 PM
I got it fixed, see my other post.

AVD
09-06-2004, 11:00 PM
/etc/rc.d/rc.net

woracan
09-26-2009, 01:17 AM
Here is an alternate method I use to recover from reboot loops that sometimes happen when I'm testing tivoapp patches.

First I created /etc/rc.d/StageE_PreApplication/rc.Sequence_950.CheckForRebootLoop.sh

if [ -f /var/persist/RebootLoop ]; then
mount -o remount,rw /
mv /tvbin/tivoapp /tvbin/tivoapp.tmp
cp /tvbin/tivoapp.orig /tvbin/tivoapp
rm /var/persist/RebootLoop
else
/devbin/touch /var/persist/RebootLoop
/devbin/scripts/SuccessfulBoot.sh &
fi


Next, I created /devbin/scripts/SuccessfulBoot.sh

#!/bin/bash
sleep 600
rm /var/persist/RebootLoop

Naturally, I did chmod 755 /devbin/scripts/SuccessfulBoot.sh

Finally, I added the following two lines to my patch script where they only get executed if the patch applied successfully.

catch {file delete -force /var/persist/RebootLoop}
exec reboot