Loading ...
Sorry, an error occurred while loading the content.

The Redboot 'upgrade' mode and the Linux 'download' process

Expand Messages
  • jkpeters_37
    I was doing some spelunking in the modified redboot source and found what the upgrade and assign commands do. From what I can tell, the upgrade mode sets
    Message 1 of 12 , Aug 29 10:06 PM
    • 0 Attachment
      I was doing some spelunking in the modified redboot source and found
      what the 'upgrade' and 'assign' commands do. From what I can tell,
      the upgrade mode sets up an little server that allows you to program
      and verify the flash (but only the kernel and ramdisk partitions) via
      a simple ethernet (apparently not TCP/IP) protocol. The assign mode
      is similar, except it's just for setting the ethernet MAC address
      (also located in flash).

      Interestingly, there are other ways to get into these modes. These
      checks are all in the 'boot' command:

      1) if your MAC address is blank it will go into assign mode

      2) if your kernel is blank it will go into upgrade mode

      3) if the reset button is down the Ready/Status LED will turn orange

      4) if the button is released within 3 seconds it will go into upgrade mode

      5) if the button is released between 3 and 6 seconds it will go into
      assign mode

      6) Otherwise, boot normally

      So, for the non-hacker, it may be easier use a program that implements
      this upgrade protocol than having to change IP addresses and then
      telnetting at just the right time and then typing in lots of complex
      commands. In some ways it's actually safer than even the 'official'
      firmware upgrade method since it deosn't (and can't) touch redboot itself.

      I'm also intrigued by the 'download' Linux process that appears to be
      running all the time. Does anyone know what it does? All the
      comments in the source of the upgrade mode start with 'download:' and
      I have this thought that maybe this process implements the same
      protocol. On the one hand that would make it even easier to upgrade
      the kernel and ramdisk; on the other, I wonder what kind of security
      it has...

      jkp
    • itwerx3
      Intel has a PDF documenting RedBoot here: http://www.intel.com/design/network/swsup/IXP400-RedBoot-1_94-relnotes_061604.pdf ... upgrade mode ... itself.
      Message 2 of 12 , Aug 30 10:35 AM
      • 0 Attachment
        Intel has a PDF documenting RedBoot here:
        http://www.intel.com/design/network/swsup/IXP400-RedBoot-1_94-relnotes_061604.pdf


        --- In nslu2-linux@yahoogroups.com, "jkpeters_37" <johnandtina@b...>
        wrote:
        > I was doing some spelunking in the modified redboot source and found
        > what the 'upgrade' and 'assign' commands do. From what I can tell,
        > the upgrade mode sets up an little server that allows you to program
        > and verify the flash (but only the kernel and ramdisk partitions) via
        > a simple ethernet (apparently not TCP/IP) protocol. The assign mode
        > is similar, except it's just for setting the ethernet MAC address
        > (also located in flash).
        >
        > Interestingly, there are other ways to get into these modes. These
        > checks are all in the 'boot' command:
        >
        > 1) if your MAC address is blank it will go into assign mode
        >
        > 2) if your kernel is blank it will go into upgrade mode
        >
        > 3) if the reset button is down the Ready/Status LED will turn orange
        >
        > 4) if the button is released within 3 seconds it will go into
        upgrade mode
        >
        > 5) if the button is released between 3 and 6 seconds it will go into
        > assign mode
        >
        > 6) Otherwise, boot normally
        >
        > So, for the non-hacker, it may be easier use a program that implements
        > this upgrade protocol than having to change IP addresses and then
        > telnetting at just the right time and then typing in lots of complex
        > commands. In some ways it's actually safer than even the 'official'
        > firmware upgrade method since it deosn't (and can't) touch redboot
        itself.
        >
        > I'm also intrigued by the 'download' Linux process that appears to be
        > running all the time. Does anyone know what it does? All the
        > comments in the source of the upgrade mode start with 'download:' and
        > I have this thought that maybe this process implements the same
        > protocol. On the one hand that would make it even easier to upgrade
        > the kernel and ramdisk; on the other, I wonder what kind of security
        > it has...
        >
        > jkp
      • paulbart1234
        ... relnotes_061604.pdf upgrade and assign are LinkSys additions, so wouldn t be described in the standard Redboot docs. - Paulb
        Message 3 of 12 , Aug 30 11:17 AM
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "itwerx3" <yahoo@i...> wrote:
          > Intel has a PDF documenting RedBoot here:
          > http://www.intel.com/design/network/swsup/IXP400-RedBoot-1_94-
          relnotes_061604.pdf

          'upgrade' and 'assign' are LinkSys additions, so wouldn't be
          described in the standard Redboot docs.

          - Paulb
        • jkpeters_37
          These commands are modifications made by SerComm/Linksys, not by Intel. ... relnotes_061604.pdf ... ... found ... tell, ... program ...
          Message 4 of 12 , Aug 30 11:20 AM
          • 0 Attachment
            These commands are modifications made by SerComm/Linksys, not by
            Intel.

            --- In nslu2-linux@yahoogroups.com, "itwerx3" <yahoo@i...> wrote:
            > Intel has a PDF documenting RedBoot here:
            > http://www.intel.com/design/network/swsup/IXP400-RedBoot-1_94-
            relnotes_061604.pdf
            >
            >
            > --- In nslu2-linux@yahoogroups.com, "jkpeters_37"
            <johnandtina@b...>
            > wrote:
            > > I was doing some spelunking in the modified redboot source and
            found
            > > what the 'upgrade' and 'assign' commands do. From what I can
            tell,
            > > the upgrade mode sets up an little server that allows you to
            program
            > > and verify the flash (but only the kernel and ramdisk
            partitions) via
            > > a simple ethernet (apparently not TCP/IP) protocol. The assign
            mode
            > > is similar, except it's just for setting the ethernet MAC address
            > > (also located in flash).
            > >
            > > Interestingly, there are other ways to get into these modes.
            These
            > > checks are all in the 'boot' command:
            > >
            > > 1) if your MAC address is blank it will go into assign mode
            > >
            > > 2) if your kernel is blank it will go into upgrade mode
            > >
            > > 3) if the reset button is down the Ready/Status LED will turn
            orange
            > >
            > > 4) if the button is released within 3 seconds it will go into
            > upgrade mode
            > >
            > > 5) if the button is released between 3 and 6 seconds it will go
            into
            > > assign mode
            > >
            > > 6) Otherwise, boot normally
            > >
            > > So, for the non-hacker, it may be easier use a program that
            implements
            > > this upgrade protocol than having to change IP addresses and then
            > > telnetting at just the right time and then typing in lots of
            complex
            > > commands. In some ways it's actually safer than even
            the 'official'
            > > firmware upgrade method since it deosn't (and can't) touch
            redboot
            > itself.
            > >
            > > I'm also intrigued by the 'download' Linux process that appears
            to be
            > > running all the time. Does anyone know what it does? All the
            > > comments in the source of the upgrade mode start
            with 'download:' and
            > > I have this thought that maybe this process implements the same
            > > protocol. On the one hand that would make it even easier to
            upgrade
            > > the kernel and ramdisk; on the other, I wonder what kind of
            security
            > > it has...
            > >
            > > jkp
          • jkpeters_37
            Well, it looks like the download process does indeed respond to the same protocol as the redboot upgrade mode. As I was testing the program I was writing
            Message 5 of 12 , Sep 1, 2004
            • 0 Attachment
              Well, it looks like the 'download' process does indeed respond to the
              same protocol as the redboot 'upgrade' mode. As I was testing the
              program I was writing to send a "GET_VERSION_INFO" packet, the nslu2
              surprised me by actually responding when in linux and not redboot:

              00:14:44.153733 0:30:65:a9:bc:38 0:4:5a:f:ad:a1 8888 624:
              0000 0000 0000 0000 0000 0000 0000 0000
              0000 0000 0000 0000 0000 0000 0000 0000
              0000 0000 0000 0000 0000 0000 0000 0000
              0000 0000 0000 0000 0000 0000 0000 0000
              0000 0000 0000 0000 0000 0000 0000 0000
              0000
              00:14:44.154892 0:4:5a:f:ad:a1 0:30:65:a9:bc:38 8888 84:
              0000 0000 0000 0000 3800 0001 0000 0470
              3195 5810 0000 0000 0000 0000 0000 0000
              0000 0000 0000 0000 0000 0000 0000 0000
              0001 0000 0000 0000 0003 0000 2325 0000
              0020 535d e128

              Of course, I then had to see if I could reboot it with the
              "DOWN_RESET" packet...and I can. Then I tried both in redboot upgrade
              mode, and the work the same there, too.

              So, to reiterate. I believe this (once I finish it) can write to any
              of the non-redboot flash partitions and automatically reboot.
              "De-bricking" and loading custom kernels and/or ramdisks then become
              very, very easy.

              jkp

              --- In nslu2-linux@yahoogroups.com, "jkpeters_37" <johnandtina@b...>
              wrote:
              > I was doing some spelunking in the modified redboot source and found
              > what the 'upgrade' and 'assign' commands do. From what I can tell,
              > the upgrade mode sets up an little server that allows you to program
              > and verify the flash (but only the kernel and ramdisk partitions) via
              > a simple ethernet (apparently not TCP/IP) protocol. The assign mode
              > is similar, except it's just for setting the ethernet MAC address
              > (also located in flash).
              >
              > Interestingly, there are other ways to get into these modes. These
              > checks are all in the 'boot' command:
              >
              > 1) if your MAC address is blank it will go into assign mode
              >
              > 2) if your kernel is blank it will go into upgrade mode
              >
              > 3) if the reset button is down the Ready/Status LED will turn orange
              >
              > 4) if the button is released within 3 seconds it will go into
              upgrade mode
              >
              > 5) if the button is released between 3 and 6 seconds it will go into
              > assign mode
              >
              > 6) Otherwise, boot normally
              >
              > So, for the non-hacker, it may be easier use a program that implements
              > this upgrade protocol than having to change IP addresses and then
              > telnetting at just the right time and then typing in lots of complex
              > commands. In some ways it's actually safer than even the 'official'
              > firmware upgrade method since it deosn't (and can't) touch redboot
              itself.
              >
              > I'm also intrigued by the 'download' Linux process that appears to be
              > running all the time. Does anyone know what it does? All the
              > comments in the source of the upgrade mode start with 'download:' and
              > I have this thought that maybe this process implements the same
              > protocol. On the one hand that would make it even easier to upgrade
              > the kernel and ramdisk; on the other, I wonder what kind of security
              > it has...
              >
              > jkp
            • Mark Rakes
              are you saying you can cause the NSLU2 to reboot by sending it a packet? at any time? or that you can push software to it at any time as well? does this seem
              Message 6 of 12 , Sep 2, 2004
              • 0 Attachment
                are you saying you can cause the NSLU2 to reboot by sending it a packet?
                at any time? or that you can push software to it at any time as well?
                does this seem insecure to you?

                -mark

                On Sep 1, 2004, at 11:53 PM, jkpeters_37 wrote:

                > Well, it looks like the 'download' process does indeed respond to the
                > same protocol as the redboot 'upgrade' mode. As I was testing the
                > program I was writing to send a "GET_VERSION_INFO" packet, the nslu2
                > surprised me by actually responding when in linux and not redboot:
                >
                > 00:14:44.153733 0:30:65:a9:bc:38 0:4:5a:f:ad:a1 8888 624:
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0000
                > 00:14:44.154892 0:4:5a:f:ad:a1 0:30:65:a9:bc:38 8888 84:
                > 0000 0000 0000 0000 3800 0001 0000 0470
                > 3195 5810 0000 0000 0000 0000 0000 0000
                > 0000 0000 0000 0000 0000 0000 0000 0000
                > 0001 0000 0000 0000 0003 0000 2325 0000
                > 0020 535d e128
                >
                > Of course, I then had to see if I could reboot it with the
                > "DOWN_RESET" packet...and I can. Then I tried both in redboot upgrade
                > mode, and the work the same there, too.
                >
                > So, to reiterate. I believe this (once I finish it) can write to any
                > of the non-redboot flash partitions and automatically reboot.
                > "De-bricking" and loading custom kernels and/or ramdisks then become
                > very, very easy.
                >
                > jkp
                >
                > --- In nslu2-linux@yahoogroups.com, "jkpeters_37" <johnandtina@b...>
                > wrote:
                >> I was doing some spelunking in the modified redboot source and found
                >> what the 'upgrade' and 'assign' commands do. From what I can tell,
                >> the upgrade mode sets up an little server that allows you to program
                >> and verify the flash (but only the kernel and ramdisk partitions) via
                >> a simple ethernet (apparently not TCP/IP) protocol. The assign mode
                >> is similar, except it's just for setting the ethernet MAC address
                >> (also located in flash).
                >>
                >> Interestingly, there are other ways to get into these modes. These
                >> checks are all in the 'boot' command:
                >>
                >> 1) if your MAC address is blank it will go into assign mode
                >>
                >> 2) if your kernel is blank it will go into upgrade mode
                >>
                >> 3) if the reset button is down the Ready/Status LED will turn orange
                >>
                >> 4) if the button is released within 3 seconds it will go into
                > upgrade mode
                >>
                >> 5) if the button is released between 3 and 6 seconds it will go into
                >> assign mode
                >>
                >> 6) Otherwise, boot normally
                >>
                >> So, for the non-hacker, it may be easier use a program that implements
                >> this upgrade protocol than having to change IP addresses and then
                >> telnetting at just the right time and then typing in lots of complex
                >> commands. In some ways it's actually safer than even the 'official'
                >> firmware upgrade method since it deosn't (and can't) touch redboot
                > itself.
                >>
                >> I'm also intrigued by the 'download' Linux process that appears to be
                >> running all the time. Does anyone know what it does? All the
                >> comments in the source of the upgrade mode start with 'download:' and
                >> I have this thought that maybe this process implements the same
                >> protocol. On the one hand that would make it even easier to upgrade
                >> the kernel and ramdisk; on the other, I wonder what kind of security
                >> it has...
                >>
                >> jkp
              • Daniel Leu
                Is bootp in Redboot enabled? If yes, you could setup a simple bootp server and have Redboot fetch the images from there. So you could issue your DOWN_RESET
                Message 7 of 12 , Sep 2, 2004
                • 0 Attachment
                  Is bootp in Redboot enabled? If yes, you could setup a simple bootp
                  server and have Redboot fetch the images from there. So you could
                  issue your 'DOWN_RESET' to force NSLU2 to reboot and load a new image
                  which would be local on your server.

                  Just a thought.

                  /daniel


                  On Thu, 2 Sep 2004 10:58:57 -0700, Mark Rakes <mrakes@...> wrote:
                  > are you saying you can cause the NSLU2 to reboot by sending it a packet?
                  > at any time? or that you can push software to it at any time as well?
                  > does this seem insecure to you?
                  >
                  > -mark
                  >
                  >
                  >
                  > On Sep 1, 2004, at 11:53 PM, jkpeters_37 wrote:
                  >
                  > > Well, it looks like the 'download' process does indeed respond to the
                  > > same protocol as the redboot 'upgrade' mode. As I was testing the
                  > > program I was writing to send a "GET_VERSION_INFO" packet, the nslu2
                  > > surprised me by actually responding when in linux and not redboot:
                  > >
                  > > 00:14:44.153733 0:30:65:a9:bc:38 0:4:5a:f:ad:a1 8888 624:
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0000
                  > > 00:14:44.154892 0:4:5a:f:ad:a1 0:30:65:a9:bc:38 8888 84:
                  > > 0000 0000 0000 0000 3800 0001 0000 0470
                  > > 3195 5810 0000 0000 0000 0000 0000 0000
                  > > 0000 0000 0000 0000 0000 0000 0000 0000
                  > > 0001 0000 0000 0000 0003 0000 2325 0000
                  > > 0020 535d e128
                  > >
                  > > Of course, I then had to see if I could reboot it with the
                  > > "DOWN_RESET" packet...and I can. Then I tried both in redboot upgrade
                  > > mode, and the work the same there, too.
                  > >
                  > > So, to reiterate. I believe this (once I finish it) can write to any
                  > > of the non-redboot flash partitions and automatically reboot.
                  > > "De-bricking" and loading custom kernels and/or ramdisks then become
                  > > very, very easy.
                  > >
                  > > jkp
                  > >
                  > > --- In nslu2-linux@yahoogroups.com, "jkpeters_37" <johnandtina@b...>
                  > > wrote:
                  > >> I was doing some spelunking in the modified redboot source and found
                  > >> what the 'upgrade' and 'assign' commands do. From what I can tell,
                  > >> the upgrade mode sets up an little server that allows you to program
                  > >> and verify the flash (but only the kernel and ramdisk partitions) via
                  > >> a simple ethernet (apparently not TCP/IP) protocol. The assign mode
                  > >> is similar, except it's just for setting the ethernet MAC address
                  > >> (also located in flash).
                  > >>
                  > >> Interestingly, there are other ways to get into these modes. These
                  > >> checks are all in the 'boot' command:
                  > >>
                  > >> 1) if your MAC address is blank it will go into assign mode
                  > >>
                  > >> 2) if your kernel is blank it will go into upgrade mode
                  > >>
                  > >> 3) if the reset button is down the Ready/Status LED will turn orange
                  > >>
                  > >> 4) if the button is released within 3 seconds it will go into
                  > > upgrade mode
                  > >>
                  > >> 5) if the button is released between 3 and 6 seconds it will go into
                  > >> assign mode
                  > >>
                  > >> 6) Otherwise, boot normally
                  > >>
                  > >> So, for the non-hacker, it may be easier use a program that implements
                  > >> this upgrade protocol than having to change IP addresses and then
                  > >> telnetting at just the right time and then typing in lots of complex
                  > >> commands. In some ways it's actually safer than even the 'official'
                  > >> firmware upgrade method since it deosn't (and can't) touch redboot
                  > > itself.
                  > >>
                  > >> I'm also intrigued by the 'download' Linux process that appears to be
                  > >> running all the time. Does anyone know what it does? All the
                  > >> comments in the source of the upgrade mode start with 'download:' and
                  > >> I have this thought that maybe this process implements the same
                  > >> protocol. On the one hand that would make it even easier to upgrade
                  > >> the kernel and ramdisk; on the other, I wonder what kind of security
                  > >> it has...
                  > >>
                  > >> jkp
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >


                  --
                  -- Daniel
                • jkpeters_37
                  ... That surely seems to be the case on all counts. Remember, though, these are just ethernet packets, not TCP/IP, so they don t route and you can t send them
                  Message 8 of 12 , Sep 2, 2004
                  • 0 Attachment
                    --- In nslu2-linux@yahoogroups.com, Mark Rakes <mrakes@m...> wrote:
                    > are you saying you can cause the NSLU2 to reboot by sending it a
                    > packet? at any time? or that you can push software to it at any
                    > time as well? does this seem insecure to you?
                    >
                    > -mark

                    That surely seems to be the case on all counts. Remember, though,
                    these are just ethernet packets, not TCP/IP, so they don't route and
                    you can't send them across the 'net. It does, however, bring a new
                    danger to wireless on your home network, doesn't it? ...and a new
                    challenge to war drivers.

                    jkp

                    > On Sep 1, 2004, at 11:53 PM, jkpeters_37 wrote:
                    >
                    > > Well, it looks like the 'download' process does indeed respond
                    > > to the same protocol as the redboot 'upgrade' mode. As I was
                    > > testing the program I was writing to send a "GET_VERSION_INFO"
                    > > packet, the nslu2 surprised me by actually responding when in
                    > > linux and not redboot:
                    > >
                    > > [...]
                    > >
                    > > Of course, I then had to see if I could reboot it with the
                    > > "DOWN_RESET" packet...and I can. Then I tried both in redboot
                    > > upgrade mode, and the work the same there, too.
                    > >
                    > > So, to reiterate. I believe this (once I finish it) can write
                    > > to any of the non-redboot flash partitions and automatically
                    > > reboot. "De-bricking" and loading custom kernels and/or ramdisks
                    > > then become very, very easy.
                    > >
                    > > jkp
                  • jkpeters_37
                    I don t think bootp is enabled in redboot--or can be without replacing redboot. ... packet? ... well?
                    Message 9 of 12 , Sep 2, 2004
                    • 0 Attachment
                      I don't think bootp is enabled in redboot--or can be without
                      replacing redboot.

                      --- In nslu2-linux@yahoogroups.com, Daniel Leu <daniel.leu@g...>
                      wrote:
                      > Is bootp in Redboot enabled? If yes, you could setup a simple bootp
                      > server and have Redboot fetch the images from there. So you could
                      > issue your 'DOWN_RESET' to force NSLU2 to reboot and load a new
                      > image which would be local on your server.
                      >
                      > Just a thought.
                      >
                      > /daniel
                      >
                      >
                      > On Thu, 2 Sep 2004 10:58:57 -0700, Mark Rakes <mrakes@m...> wrote:
                      > > are you saying you can cause the NSLU2 to reboot by sending it a
                      packet?
                      > > at any time? or that you can push software to it at any time as
                      well?
                      > > does this seem insecure to you?
                      > >
                      > > -mark
                    • Mark Rakes
                      ... yes, especially anyone using WDS. or a cable modem, for that matter. makes me want to completely replace the firmware all the more. :) -mark
                      Message 10 of 12 , Sep 2, 2004
                      • 0 Attachment
                        On Sep 2, 2004, at 1:15 PM, jkpeters_37 wrote:
                        > --- In nslu2-linux@yahoogroups.com, Mark Rakes <mrakes@m...> wrote:
                        >> are you saying you can cause the NSLU2 to reboot by sending it a
                        >> packet? at any time? or that you can push software to it at any
                        >> time as well? does this seem insecure to you?
                        >>
                        >> -mark
                        >
                        > That surely seems to be the case on all counts. Remember, though,
                        > these are just ethernet packets, not TCP/IP, so they don't route and
                        > you can't send them across the 'net. It does, however, bring a new
                        > danger to wireless on your home network, doesn't it? ...and a new
                        > challenge to war drivers.
                        >
                        > jkp
                        yes, especially anyone using WDS. or a cable modem, for that matter.
                        makes me want to completely replace the firmware all the more. :)

                        -mark


                        >> On Sep 1, 2004, at 11:53 PM, jkpeters_37 wrote:
                        >>> Well, it looks like the 'download' process does indeed respond
                        >>> to the same protocol as the redboot 'upgrade' mode. As I was
                        >>> testing the program I was writing to send a "GET_VERSION_INFO"
                        >>> packet, the nslu2 surprised me by actually responding when in
                        >>> linux and not redboot:
                        >>>
                        >>> [...]
                        >>>
                        >>> Of course, I then had to see if I could reboot it with the
                        >>> "DOWN_RESET" packet...and I can. Then I tried both in redboot
                        >>> upgrade mode, and the work the same there, too.
                        >>>
                        >>> So, to reiterate. I believe this (once I finish it) can write
                        >>> to any of the non-redboot flash partitions and automatically
                        >>> reboot. "De-bricking" and loading custom kernels and/or ramdisks
                        >>> then become very, very easy.
                        >>>
                        >>> jkp
                      • jkpeters_37
                        ...or at least disable the download process. jkp
                        Message 11 of 12 , Sep 2, 2004
                        • 0 Attachment
                          ...or at least disable the 'download' process.

                          jkp

                          --- In nslu2-linux@yahoogroups.com, Mark Rakes <mrakes@m...> wrote:
                          > yes, especially anyone using WDS. or a cable modem, for that matter.
                          > makes me want to completely replace the firmware all the more. :)
                          >
                          > -mark
                          >
                          >
                          > On Sep 2, 2004, at 1:15 PM, jkpeters_37 wrote:
                          > > --- In nslu2-linux@yahoogroups.com, Mark Rakes <mrakes@m...> wrote:
                          > >> are you saying you can cause the NSLU2 to reboot by sending it a
                          > >> packet? at any time? or that you can push software to it at any
                          > >> time as well? does this seem insecure to you?
                          > >>
                          > >> -mark
                          > >
                          > > That surely seems to be the case on all counts. Remember, though,
                          > > these are just ethernet packets, not TCP/IP, so they don't route and
                          > > you can't send them across the 'net. It does, however, bring a new
                          > > danger to wireless on your home network, doesn't it? ...and a new
                          > > challenge to war drivers.
                          > >
                          > > jkp
                        • jkpeters_37
                          ... While studying the redboot mods a little closer, I discovered that the part about doesn t (and can t) touch redboot isn t true. There are actually two
                          Message 12 of 12 , Sep 3, 2004
                          • 0 Attachment
                            --- In nslu2-linux@yahoogroups.com, "jkpeters_37" <johnandtina@b...>
                            wrote:
                            > I was doing some spelunking in the modified redboot source and found
                            > what the 'upgrade' and 'assign' commands do. From what I can tell,
                            > the upgrade mode sets up an little server that allows you to program
                            > and verify the flash (but only the kernel and ramdisk partitions) via
                            > a simple ethernet (apparently not TCP/IP) protocol.
                            >
                            > [...]
                            >
                            > So, for the non-hacker, it may be easier use a program that implements
                            > this upgrade protocol than having to change IP addresses and then
                            > telnetting at just the right time and then typing in lots of complex
                            > commands. In some ways it's actually safer than even the 'official'
                            > firmware upgrade method since it deosn't (and can't) touch redboot
                            > itself.

                            While studying the redboot mods a little closer, I discovered that the
                            part about "doesn't (and can't) touch redboot" isn't true. There are
                            actually two different modes you can use during the 'upgrade' mode:
                            one ignores writes to redboot and config, the other will write to the
                            whole flash! Yikes! (It does appear to save and replace the MAC
                            address, however.) The annoying part is that the verify function will
                            only verify the kernel and ramdisk sections.

                            I sure hope the 'download' process doesn't support the "flash-all"
                            function...or a baddy on your network could pretty much destroy your
                            unit...


                            jkp
                          Your message has been successfully submitted and would be delivered to recipients shortly.