Quote from: btc-room101 on December 06, 2018, 09:36:10 PM

Here's an overview of the new brainflayer-2019, I wrote much of this code in 2017, but essentially rewrote brain-flayer,

first some terms there are keys ( private keys, usually hex, but often in wif (base58) for humans, there addresses which are public-key, which are frequently hashed and converted to base58 where they become the common btc-address, in 'hacking' its best of course to work in the world of pure-hex for everything, the WIF both addr/priv/pub keys that display is just for user usage. Of course if your going on line you need to generally use WIF format for most online database's to display history address,
What's new

1.) Full support for 64 bit, that includes the bloom filters, before they were limited to 4gb is which a search space of about 50 million keys, now with 16gb blooms you can search 200M addresses all at once ( remember here the GOAL of brainflayer is to run through possible key-space and look to see if that key's address is 'hot', but 'hot' I mean containing any value in history

2. Extensive work in addition to new hoptions -H and -P, where -H is for halt, and -P is for private key, the -H option tells brainflayer how long to run in terms of input before it re-cycles, this is important for batch file automated running, where you don't want endless running. -P causes BF to output all private-key information this is very important to to build a database of all Address/Private Key 'Pairing'

Remember what we're doing here is building a database to relate all btc addresses used in history of btc, and they're private-key/public-key information.

Also important is the public-key, as often it is ignored, but for advanced hacking I call 'super-van' because essentially I completely rewrote and gutted vanity gen, and gave it a single purpose of GPU hacking, but it needs the data from super-flayer.

...

Sometimes I will write, brainflayer sometimes 'super-flayer', there are many versions, I think this is the 3rd iteration of the BF re-write, all options have been modified

What's import

-b , the bloom filter your using is very important

-c u,c,x ; u & c of course are common in BTC, but 'x' is very important because that is the raw format, and often the 'raw' is the best information

-t sha256 is is most common a default, most of these are no longer used, the keccak does work, it is possible to hack ethereum using this tool, I did it, but there is so little 'coin' worth finding, its really not worth the bother

-x is very important here we tell SBF ( super BF ) that the input is 'hex', now what this means is that instead of converting 'passwords' we're passing the 'hex' for the passwords directly, this means you can use your own encoding scheme and then let SBF see if that 'key' was ever used to generate an address. This is very important for hacking the new 2048 scheme where you have 8-words from a dictionary, and they're hashed and combined

-k, -n are useful for baby-step, giant step DLP algos where you have a plan to hack a particular private-key ( address pair )

-B batch say's how many private-keys do I process on every cycle default is 4096 which is fine, if you have a 32GB or larger ram system, then go for 32k o as you wish, when using huge arrays it can make the ESDSA algos more efficient but you need massive memory.

-I I think this is too slow, essentially this is just telling SBF to run from nth private key and increment ( can be controlled ) and see if that priv-key matches anything in the bloom filter ( your list of addresses of value ), super-van is much better than this and 5-10x faster than the CPU

./brainflayer3 -h
Usage: ./brainflayer3 [OPTION]...

-a open output file in append mode
-b FILE check for matches against bloom filter FILE
-f FILE verify matches against sorted hash160s in FILE
-i FILE read from FILE instead of stdin
-o FILE write to FILE instead of stdout
-c TYPES use TYPES for public key to hash160 computation
   multiple can be specified, for example the default
   is 'uc', which will check for both uncompressed
   and compressed addresses using Bitcoin's algorithm
   u - uncompressed address
   c - compressed address
   e - ethereum address
   x - most signifigant bits of x coordinate
-t TYPE inputs are TYPE - supported types:
   sha256 (default) - classic brainwallet
   sha3 - sha3-256
   priv - raw private keys (requires -x)
   warp - WarpWallet (supports -s or -p)
   bwio - brainwallet.io (supports -s or -p)
   bv2 - brainv2 (supports -s or -p) VERY SLOW
   rush - rushwallet (requires -r) FAST
   keccak - keccak256 (ethercamp/old ethaddress)
   camp2 - keccak256 * 2031 (new ethercamp)
-x treat input as hex encoded
-s SALT use SALT for salted input types (default: none)
-p PASSPHRASE use PASSPHRASE for salted input types, inputs
   will be treated as salts
-r FRAGMENT use FRAGMENT for cracking rushwallet passphrase
-I HEXPRIVKEY incremental private key cracking mode, starting
   at HEXPRIVKEY (supports -n) FAST
-k K skip the first K lines of input
-n K/N use only the Kth of every N input lines
-B batch size for affine transformations
   must be a power of 2 (default/max: 4096)
-w WINDOW_SIZE window size for ecmult table (default: 16)
   uses about 3 * 2^w KiB memory on startup, but
   only about 2^w KiB once the table is built
-m FILE load ecmult table from FILE
   the ecmtabgen tool can build such a table
-v verbose - display cracking progress
-P print private key in output
-H Halt at line
-h show this help

...

Actually using SBF requires that you have built your bloom-filter files, its best to have many blooms, like 100Msatoshi.blm, 10BTC.blm, 1MSatoshi.blm, I think there are 100Million satoshi to a btc, so 0.01btc is 1m-sat, which gets down to almost dust, but I like to go for any address ever used that contained any kind of value, as in fact they do get user again, and over&over,

-w is worth playing around, I think its designed for older pc's with limited memory and power
-m is much the same, when your running SBF for hours like this model is designed, it doesn't matter to pre-compute the tables

Remember the original BF was designed to take a database of passwords, and convert them to hex with SHA, and then to use that as a private key, and look up the address with Ecdsa, and then if an address match is found in the bloom the private-key/address/password is printed to screen that was the original model.

The way that I used SBF is more to generate data, and patterns used for ML ( LSTM/RNN ) where you want to learn about real prior used keys, public-keys, and addresses and look for patterns, cyclic or FFT that can be fed into DLP algo's.

sure you will always find BTC that has real-value, but IMHO that is not the goal here, this is really about learning the patterns of bitcoin private-key/address pairs

SVM can allow you to catalogue, the different systems to compute private keys, there are many companys that provide 'wallets', and this stuff can be correlated so you start seeing the patterns of different schemes used to generate the private-keys and addresses

Also much can be done with public-keys that are found in the early pre2012 block-chain, and these are the btc of real value on the chain

Hi, I'm currently working on latest version of Kali, where brainflayer is not compile successful.
Are you rewrote that script, working on the latest version of Kali?

I have searching about this more than one month.
Please let me know.

Thanks in advance!