Anonymous 04/06/2017 (Thu) 21:53:51 Id: 47279e No. 37962 del
I tried to follow it, but neither have the technical know-how or the secure setup to do so. Below is some of the stuff I gathered while it was happening. I remember something freaky happening with the transaction IDs after they were tampered with, and a HUGE cyberattack coming from DynCorp(?). Please DO NOT run any python scripts, open any zips, etc without good OpSec. Attachments wouldn't parse, 4096 char limit here we go:

The goal is to make very simple code that is easy to use and understand so that everyone can do this. This is a rough explanation of how it works.
There are two main approaches users are taking to decode messages in the blockchain. Scanning transactions, let's call this 'tx scanning', and scanning blocks, let's call this 'block scanning'. The main reason users are not yet able to see meaningful content is because both approaches have to be combined.
TX SCANNING: When you scan by transactions, you look for a transaction number (tx id), and decode its contents. When you know the tx id, you can easily see which wallets were involved. Some messages require you to combine the decoded data from multiple tx ids. You can identify which tx ids are relevant by looking at transaction histories of the wallets involved. This strategy is used for the 'Cablegate Backup'. In that case, the list of tx ids is directly told to the readers in the first message. However, you can compile this list on your own by 'tx crawling'. To do this, follow these steps: . For each tx, look at the wallets that received money and find those that spend it (in this case it is only one per tx). . For that wallet, look at its transaction history and find a transaction that follows a similar pattern, i.e., it involves multiple wallets and only one spends the funds. . Continue doing this until you are not able to see the pattern repeat itself.
BLOCK SCANNING: When you scan by block, you will be able to find encoded data more easily but it is harder to extract the tx id and wallets. One benefit of block scanning is that you can explicitly search for file headers and important strings. For example you can directly search for the magic numbers in GPG files. When you find one of these, you can then tx crawl from that starting point in order to get all pieces of the file. More concretely, if you want to find the Cablegate Backup with a block scanner, you could search for the magic number of Zip files. Then, when one is found, you can find the tx id that contains it, and finally tx crawl to get all the pieces. Yet, file headers are just one of the many other patterns that can be used to find important transactions. Examples of others are: . Magic numbers: Look for the first bytes in different types of file. 'file' can be used in UNIX. . Ability to compress: Compress the decoded output. If the size is reduced, the output is possibly a message or part of a file. . Text: If the decoded output has text, it might have information. . Keywords (Very important): Search for relevant keywords, e.g., checksums for files in, checksums for the insurance files, hashes, dates, names, time stamps, etc. . Reversibility: Some messages are in reverse and need to be flipped. This should be tried both before and after decoding. Both scanners have to be used. The starting points for the searches should be Wikileak's wallet, important dates (for example, during the DDoS attacks), previous messages and checksum hashes. The Cablegate Backup was a bit simpler than the more recent messages. In that case, only one wallet spent the funds in each transaction, and simply looking at wallet's next transaction was enough to find all the pieces. Newer messages are bit more complicated. Some of the wallets that receive money make multiple transactions with no encoded data before proceeding with the 'real' transaction. Moreover, in a lot of cases, all wallets involved spend the funds (not just one). 1/3