4 ms·

Why sign the reboot code if you're always sending the same code? Like, the signing is useless. The signed code is now the new reboot code and it's effectively u

Why sign the reboot code if you're always sending the same code? Like, the signing is useless. The signed code is now the new reboot code and it's effectively unsigned.

rtkwe 7y ago
True but omitting any challenge response means the master node can just push the info out without having to communicate with any of the child nodes. It's true it's basically just a reboot code but a cryptographically random number to a randomly chosen port is honestly a fairly safe choice Roku just got cosmically unlucky if the theory is correct.
- DSMan195276 7y ago
  I agree with your point, but there's just no way that's true. A bare minimum MD5 signature is 16-bytes (Obviously not secure, but this isn't safe from replay attacks anyway), with a more acceptable SHA256 obviously being 32-bytes. Any type of signature should be sufficiently random that Nintendo is never going to accidentally match them, so that means the odds of matching a random 64-bit integer is already 16 quintillion to one, and just for MD5 we're talking 16 quintillino times 16 quintillion - that's beyond hopeless. It's the same thing as calling heads or tails correctly either 128 or 256 times in a row. If I had to guess it's probably something silly like not actually checking the signature for validity, or (more likely, IMO) incorrectly checking the length of the packet and getting a buffer overflow/underflow that eventually crashes the Roku.
  - rtkwe 7y ago
    Maybe. Could also be they did include some half-hearted validation like the message includes "reboot after" with some long or variable validity period. That would increase the number of possible valid codes. Also I get the huge unlikeliness of this happening but massively unlikely things do occasionally happen.
    - DSMan195276 7y ago
      > Also I get the huge unlikeliness of this happening but massively unlikely things do occasionally happen. This is less likely then two people generating the same random GUID. For SHA256, it's the same as generating two GUIDs in the same message and having them both be identical.

Why sign the reboot code if you're always sending the same code? Like, the signing is useless. The signed code is now the new reboot code and it's effectively unsigned.

rtkwe 7y ago

True but omitting any challenge response means the master node can just push the info out without having to communicate with any of the child nodes. It's true it's basically just a reboot code but a cryptographically random number to a randomly chosen port is honestly a fairly safe choice Roku just got cosmically unlucky if the theory is correct.

DSMan195276 7y ago
I agree with your point, but there's just no way that's true. A bare minimum MD5 signature is 16-bytes (Obviously not secure, but this isn't safe from replay attacks anyway), with a more acceptable SHA256 obviously being 32-bytes. Any type of signature should be sufficiently random that Nintendo is never going to accidentally match them, so that means the odds of matching a random 64-bit integer is already 16 quintillion to one, and just for MD5 we're talking 16 quintillino times 16 quintillion - that's beyond hopeless. It's the same thing as calling heads or tails correctly either 128 or 256 times in a row. If I had to guess it's probably something silly like not actually checking the signature for validity, or (more likely, IMO) incorrectly checking the length of the packet and getting a buffer overflow/underflow that eventually crashes the Roku.
- rtkwe 7y ago
  Maybe. Could also be they did include some half-hearted validation like the message includes "reboot after" with some long or variable validity period. That would increase the number of possible valid codes. Also I get the huge unlikeliness of this happening but massively unlikely things do occasionally happen.
  - DSMan195276 7y ago
    > Also I get the huge unlikeliness of this happening but massively unlikely things do occasionally happen. This is less likely then two people generating the same random GUID. For SHA256, it's the same as generating two GUIDs in the same message and having them both be identical.