15 ms·

How Frogger 2’s source code was recovered from a destroyed tape [video]

208 points by perching_aix 1y ago

NaOH 1y ago
Related: The long road to recover Frogger 2 source from tape drives - https://news.ycombinator.com/item?id=36061574 https://news.ycombinator.com/item?id=36061574 - May 2023 (213 comments)
CSMastermind 1y ago
Absolutely heroic effort. And that data recovery company should go out of business.
- chii 1y ago
  It is named and shamed in the comments of that video somewhere. Data recovery companies ought to have the integrity to just say no to a job, if they cannot do it risk free. Trying and failing with the risk of damaging the original data could be very costly to the customer, even if they don't charge money - the customer's lost data could be priceless.
sllabres 1y ago
A lot of work, but with success as reward! Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today.
- dehrmann 1y ago
  > Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today. The challenges will be different. Flash loses its charge in 30 years, most disks are encrypted, and on-site physical backups are mostly a thing of the past. The source might survive in a cloud repo, but it'll either be tied up for legal reasons or deleted when the customer stops paying the bill. But storage is cheap and getting cheaper!
  - ljlolel 1y ago
    Easy. The “deleted” even overwritten data can leave ghosts even multiple layers deep (think of a clay tablet or painting with multiple inscriptions) Encryption for 30 years ago? Trivially breakable with quantum
    - rjst01 1y ago
      > Encryption for 30 years ago? Trivially breakable with quantum I wouldn't be so sure - quantum computers aren't nearly as effective for symmetric algorithms as they are for pre-quantum asymmetric algorithms.
      - b112 1y ago
        Regardless of the parent's statement, just normal compute in 30 years, plus general vulnerabilities and weaknesses discovered, will ensure that anything encrypted today is easily readable in the future. I can't think of anything from 30 years ago that isn't just a joke today. The same will likely be true by 2050, quantum computing or not. I wonder how many people realise this? Even if one disagrees with my certainty, I think people should still plan for the concept that there's a strong probability it will be so. Encryption is really not about preventing data exposure, but about delaying it. Any other view regarding encryption means disappointment.
        charcircuit 1y ago
        >normal compute You are underestimating the exponential possibilities of keys. >plus general vulnerabilities and weaknesses discovered, will ensure that anything encrypted today is easily readable in the future. You can't just assume that there is always going to be new vulnerabilities that cause it to be broken. It ignores that people have improved at designing secure cryptography over time.
        b112 1y ago
        From a security perspective, I argue ypu must assume precisely that. An example being, destroying sensitive backup media upon its retirement, regardless of data encryption.
- Cthulhu_ 1y ago
  Hard, but it depends on backup / duplication strategies; this is why e.g. the internet archive is so important, and I hope there are multiple parties doing the same thing for redundancy.
- rietta 1y ago
  Hard. I am slowly writing a book set in the future where we are a “digital dark age” where little to nothing is known about our time tentatively called Professor Bitrot.
heavensteeth 1y ago
I'm not surprised by the data recovery company story, it feels like I only hear bad things about that industry. I remember something similar happened with LinusTechTips.
tomashubelbauer 1y ago
The source code: https://github.com/HighwayFrogs/frogger2-vss https://github.com/HighwayFrogs/frogger2-vss I enjoyed skimming through this: https://github.com/HighwayFrogs/frogger2-vss/blob/main/teamSpirit/FroggerII/devlog.txt https://github.com/HighwayFrogs/frogger2-vss/blob/main/teamS...
- Jean-Papoulos 1y ago
  Line 427 makes this game NSFW !
  - javcasas 1y ago
    This is dedicated to the people in the other thread about forbidding swearwords in code. Take this!
  - wkat4242 1y ago
    Which file? Now I'm curious :)
    - Rendello 1y ago
      The second link in the comment, the devlog.
      - wkat4242 1y ago
        Ahhh ok I was thinking it was in the actual code. Because the devlog wouldn't be part of the game. Thinking too literally :)
- secondcoming 1y ago
  Committing ASCII-art of a scantily clad woman is quite the power move.
  - msgodel 1y ago
    [flagged]
chris_wot 1y ago
Here’s a gist that might be enlightening: https://github.com/Kneesnap/onstream-data-recovery/blob/main/info/INTRO.MD https://github.com/Kneesnap/onstream-data-recovery/blob/main...
Simran-B 1y ago
Another entertaining piece by the Lego Island guy! My takeaway is that you should choose a passion project as your hobby and put in the time to learn and do whatever is necessary to achieve your goal on your own or together with similarly motivated people rather than relying on anyone external you have to pay - things go downhill fairly often and quickly it seems. Is any business a scam to some degree nowadays?
dylan604 1y ago
I once wrote a DAM that wrote to LTO tapes just using tar. The tape was operated with forward/rewind commands from mt. Nobody needed access to the tapes until after I was no longer at the company. Apparently, they spent weeks trying to install various backup software to read the tapes, but none could. They eventually contacted me, but due to how much software they had tried to use the original computer it was attached to was no longer the OS. At that point, they asked 3rd party companies for help and eventually found someone with a drive attached to a Linux system. I was then able to walk them through how to read and extract data. Tape storage can be an absolute nightmare. Most will do the writes, some will say they verify with a read, but few actually test with a full restore. Just because the software says it can read the tape to show you the listings does not mean it can read the files themselves. This was alluded to in TFA(TFV??) but been there done that on trying to read from a bum tape/bad write. It gets worse if you write in one tape drive and read from another also mentioned in TFV. Now I feel old just thinking about it all
nullc 1y ago
AFAICT the way most 'recovery' places work is that they'll recover data if there are no issues and any ordinarily skilled IT tech could also recover it. And then otherwise they'll claim it's unrecoverable. Sometimes, it seems, they'll even just claim its unrecoverable because they didn't happen to have or find a compatible drive when that's all that was needed. I've recovered data from media a number of times a recovery company said it was unrecoverable with no particular difficulty.
xenadu02 1y ago
This seemed to be a point of confusion in the original story and the video wasn't super clear but: Pretty much all tape backup software writes headers as it is streaming the file to tape. Just more bytes in the buffer. For normal restores it consults its local database because that is way faster. If you don't have the local database you do a "Catalog Tape" operation that scans the file headers on the tape to reconstruct the database. For whatever reason ARCServe couldn't complete the catalog with that specific kind of tape. Whether that was the specific version he found or was a general problem with support for those tape drives I don't know.
ultiuix 1y ago
[flagged]

208 points by perching_aix 1y ago

NaOH 1y ago

Related: The long road to recover Frogger 2 source from tape drives - https://news.ycombinator.com/item?id=36061574 https://news.ycombinator.com/item?id=36061574 - May 2023 (213 comments)

CSMastermind 1y ago

Absolutely heroic effort. And that data recovery company should go out of business.

chii 1y ago
It is named and shamed in the comments of that video somewhere. Data recovery companies ought to have the integrity to just say no to a job, if they cannot do it risk free. Trying and failing with the risk of damaging the original data could be very costly to the customer, even if they don't charge money - the customer's lost data could be priceless.

sllabres 1y ago

A lot of work, but with success as reward! Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today.

dehrmann 1y ago
> Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today. The challenges will be different. Flash loses its charge in 30 years, most disks are encrypted, and on-site physical backups are mostly a thing of the past. The source might survive in a cloud repo, but it'll either be tied up for legal reasons or deleted when the customer stops paying the bill. But storage is cheap and getting cheaper!
- ljlolel 1y ago
  Easy. The “deleted” even overwritten data can leave ghosts even multiple layers deep (think of a clay tablet or painting with multiple inscriptions) Encryption for 30 years ago? Trivially breakable with quantum
  - rjst01 1y ago
    > Encryption for 30 years ago? Trivially breakable with quantum I wouldn't be so sure - quantum computers aren't nearly as effective for symmetric algorithms as they are for pre-quantum asymmetric algorithms.
    - b112 1y ago
      Regardless of the parent's statement, just normal compute in 30 years, plus general vulnerabilities and weaknesses discovered, will ensure that anything encrypted today is easily readable in the future. I can't think of anything from 30 years ago that isn't just a joke today. The same will likely be true by 2050, quantum computing or not. I wonder how many people realise this? Even if one disagrees with my certainty, I think people should still plan for the concept that there's a strong probability it will be so. Encryption is really not about preventing data exposure, but about delaying it. Any other view regarding encryption means disappointment.
      - charcircuit 1y ago
        >normal compute You are underestimating the exponential possibilities of keys. >plus general vulnerabilities and weaknesses discovered, will ensure that anything encrypted today is easily readable in the future. You can't just assume that there is always going to be new vulnerabilities that cause it to be broken. It ignores that people have improved at designing secure cryptography over time.
        b112 1y ago
        From a security perspective, I argue ypu must assume precisely that. An example being, destroying sensitive backup media upon its retirement, regardless of data encryption.
Cthulhu_ 1y ago
Hard, but it depends on backup / duplication strategies; this is why e.g. the internet archive is so important, and I hope there are multiple parties doing the same thing for redundancy.
rietta 1y ago
Hard. I am slowly writing a book set in the future where we are a “digital dark age” where little to nothing is known about our time tentatively called Professor Bitrot.

heavensteeth 1y ago

I'm not surprised by the data recovery company story, it feels like I only hear bad things about that industry. I remember something similar happened with LinusTechTips.

tomashubelbauer 1y ago

The source code: https://github.com/HighwayFrogs/frogger2-vss https://github.com/HighwayFrogs/frogger2-vss I enjoyed skimming through this: https://github.com/HighwayFrogs/frogger2-vss/blob/main/teamSpirit/FroggerII/devlog.txt https://github.com/HighwayFrogs/frogger2-vss/blob/main/teamS...

Jean-Papoulos 1y ago
Line 427 makes this game NSFW !
- javcasas 1y ago
  This is dedicated to the people in the other thread about forbidding swearwords in code. Take this!
- wkat4242 1y ago
  Which file? Now I'm curious :)
  - Rendello 1y ago
    The second link in the comment, the devlog.
    - wkat4242 1y ago
      Ahhh ok I was thinking it was in the actual code. Because the devlog wouldn't be part of the game. Thinking too literally :)
secondcoming 1y ago
Committing ASCII-art of a scantily clad woman is quite the power move.
- msgodel 1y ago
  [flagged]

chris_wot 1y ago

Here’s a gist that might be enlightening: https://github.com/Kneesnap/onstream-data-recovery/blob/main/info/INTRO.MD https://github.com/Kneesnap/onstream-data-recovery/blob/main...

Simran-B 1y ago

Another entertaining piece by the Lego Island guy! My takeaway is that you should choose a passion project as your hobby and put in the time to learn and do whatever is necessary to achieve your goal on your own or together with similarly motivated people rather than relying on anyone external you have to pay - things go downhill fairly often and quickly it seems. Is any business a scam to some degree nowadays?

dylan604 1y ago

I once wrote a DAM that wrote to LTO tapes just using tar. The tape was operated with forward/rewind commands from mt. Nobody needed access to the tapes until after I was no longer at the company. Apparently, they spent weeks trying to install various backup software to read the tapes, but none could. They eventually contacted me, but due to how much software they had tried to use the original computer it was attached to was no longer the OS. At that point, they asked 3rd party companies for help and eventually found someone with a drive attached to a Linux system. I was then able to walk them through how to read and extract data. Tape storage can be an absolute nightmare. Most will do the writes, some will say they verify with a read, but few actually test with a full restore. Just because the software says it can read the tape to show you the listings does not mean it can read the files themselves. This was alluded to in TFA(TFV??) but been there done that on trying to read from a bum tape/bad write. It gets worse if you write in one tape drive and read from another also mentioned in TFV. Now I feel old just thinking about it all

nullc 1y ago

AFAICT the way most 'recovery' places work is that they'll recover data if there are no issues and any ordinarily skilled IT tech could also recover it. And then otherwise they'll claim it's unrecoverable. Sometimes, it seems, they'll even just claim its unrecoverable because they didn't happen to have or find a compatible drive when that's all that was needed. I've recovered data from media a number of times a recovery company said it was unrecoverable with no particular difficulty.

xenadu02 1y ago

This seemed to be a point of confusion in the original story and the video wasn't super clear but: Pretty much all tape backup software writes headers as it is streaming the file to tape. Just more bytes in the buffer. For normal restores it consults its local database because that is way faster. If you don't have the local database you do a "Catalog Tape" operation that scans the file headers on the tape to reconstruct the database. For whatever reason ARCServe couldn't complete the catalog with that specific kind of tape. Whether that was the specific version he found or was a general problem with support for those tape drives I don't know.

ultiuix 1y ago

[flagged]