3 ms·

With some regular expression magic I extracted the data from Twitter, however, the data was in the wrong order. With this command in Linux, I reversed the order

by Genbox 15y ago

With some regular expression magic I extracted the data from Twitter, however, the data was in the wrong order. With this command in Linux, I reversed the order and decoded the data: tac twitData.txt | base64 -d -i > image.jpg I've uploaded the image here: http://iqsecur.blogspot.com/2012/01/sending-files-using-twitter.html http://iqsecur.blogspot.com/2012/01/sending-files-using-twit... However, it seems there is an error in the image, I'm not sure if it is the process itself or the image actually has an error. A reverse search resulted in 0 results, so I'm inclined to believe the former.

garethsprice 15y ago
The technique of splitting files into many base64-encoded chunks was popular on Usenet in the 90s (another 7-bit platform with message size limits). This was always the problem there too - 144 parts, 3 of which were missing/corrupt and the entire transfer was rendered useless.
- Terretta 15y ago
  In operation, a user will select a set of files from which the redundant data is to be made. These are known as input files and the set of them is known as the recovery set. The user will provide these to a program which generates file(s) that match the specification in this document. The program is known as a PAR 2.0 Client or client for short, and the generated files are known as PAR 2.0 files or PAR files. If the files in the recovery set ever get damaged (e.g. when they are transmitted or stored on a faulty disk) the client can read the damaged input files, read the (possibly damaged) PAR files, and regenerate the original input files. Of course, not all damages can be repaired, but many can. The redundant data in the PAR files is computed using Reed-Solomon codes. These codes can take a set of equal-sized blocks of data and produce a number of same-sized recovery blocks. Then, given a subset of original data blocks and some recovery block, it is possible to reproduce the original data blocks. Reed-Solomon codes can do this recovery as long as the number of missing data blocks does not out number the recovery blocks. http://www.par2.net/par2spec.php http://www.par2.net/par2spec.php

by Genbox 15y ago

garethsprice 15y ago

The technique of splitting files into many base64-encoded chunks was popular on Usenet in the 90s (another 7-bit platform with message size limits). This was always the problem there too - 144 parts, 3 of which were missing/corrupt and the entire transfer was rendered useless.

Terretta 15y ago
In operation, a user will select a set of files from which the redundant data is to be made. These are known as input files and the set of them is known as the recovery set. The user will provide these to a program which generates file(s) that match the specification in this document. The program is known as a PAR 2.0 Client or client for short, and the generated files are known as PAR 2.0 files or PAR files. If the files in the recovery set ever get damaged (e.g. when they are transmitted or stored on a faulty disk) the client can read the damaged input files, read the (possibly damaged) PAR files, and regenerate the original input files. Of course, not all damages can be repaired, but many can. The redundant data in the PAR files is computed using Reed-Solomon codes. These codes can take a set of equal-sized blocks of data and produce a number of same-sized recovery blocks. Then, given a subset of original data blocks and some recovery block, it is possible to reproduce the original data blocks. Reed-Solomon codes can do this recovery as long as the number of missing data blocks does not out number the recovery blocks. http://www.par2.net/par2spec.php http://www.par2.net/par2spec.php