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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.