2. Presentation Overview
• Introduction
• An overview of Bitcoin, Blockchain, and Vocabulary used in
presentation
• How can we encode data and store it in a blockchain
• Plaintext
• Files
• How can we detect and extract encoded data within the
blockchain?
• How can we encrypt our data to prevent unintended
2
3. jburke$ whoami && echo Introduction
Jesse V. Burke (Twitter:
@Jesse_V_Burke)
• Co-Owner Wapack Labs (4 of 4)
• Team Leader Wapack Labs’ Team Jaeger
• Wapack Labs’ Underground
collections department
• Responsible for training interns and
Wounded Warrior Project
employees
• OPSEC trainer & coordinator
• Studied Computer Science & Criminal
Justice for three years at Suffolk
University and two years at UMASS
Boston
• Involved in cryptocurrency since 2010
• Senior Software Developer and Cyber
Intelligence Analyst by day
• Passions (Not in order):
• Cryptography & Cryptographic Attacks
• Cryptocurrency
• Robotics; Raspberry Pis, Arduinos, UAVs,
quadcopters, boats, submarines, etc.
• Radio Frequency use, recording/replaying,
interception, and MiTM
• Linux
3
4. What is blockchain?
A continuously growing list of records called blocks which are linked and secured
using cryptography. Conceptually a cryptographic doubly-linked list
Each block contains a cryptographic hash of the previous
block, a timestamp and transaction data. By design, a
blockchain is inherently resistant to modification of the data. It
is "an open, distributed ledger that can record transactions
between two parties efficiently and in a verifiable and
permanent way". For use as a distributed ledger, a blockchain
is typically managed by a peer-to-peer network collectively
adhering to a protocol for inter-node communication and
validating new blocks. Once recorded, the data in any given
block cannot be altered retroactively without the alteration of
all subsequent blocks, which requires collusion of the network
majority.
4
5. Bitcoin (BTC) & Blockchain Terminology
• Address
• A Bitcoin address is a 160-bit hash of the public portion of a public/private ECDSA keypair.
• Private Key
• Using public-key cryptography, one can "sign" data with their private key and anyone who knows their public key can verify that the
signature is valid.
• Satoshi (measurement)
• Named in homage to bitcoin's creator, a satoshi is the smallest amount within bitcoin representing 0.00000001 bitcoins, one
hundred millionth of a bitcoin.
• Bit (1 Bit = 100 Satoshis)
• Bit is a common unit used to designate a sub-unit of a Bitcoin - 1,000,000 bits is equal to 1 Bitcoin (BTC). This unit is usually more
convenient for pricing tips, goods and services.
• Block
• A block is a record in the block chain that contains and confirms many waiting transactions. Roughly every 10 minutes, on average, a
new block including transactions is appended to the block chain through mining.
• Blockchain
• The blockchain is a public record of Bitcoin transactions in chronological order.
• Confirmation
• Confirmation means that a transaction has been processed by the network and is highly unlikely to be reversed. Transactions receive a
confirmation when they are included in a block and for each subsequent block. Even a single confirmation can be considered secure for
low value transactions, although for larger amounts like 1000 US$, it makes sense to wait for 6 confirmations or more. Each
confirmation exponentially decreases the risk of a reversed transaction.
• Mining
• Bitcoin mining is the process of making computer hardware do mathematical calculations for the Bitcoin network to confirm
transactions. Bitcoin miners can collect transaction fees for the transactions they confirm, along with newly created bitcoins. 5
6. Bitcoin Addresses & Cryptography (Simple)
How to generate a Bitcoin address manually:
• Generate a ECDSA Private & Public Key
• SHA256 Hash the Public Key
• Perform RIPEMD-160 on the result of the SHA256
• Add version byte in front of RIPEMD-160 (0x00 for main net, anything else is test or
devnet)
• Perform SHA256 hash on the extended RIPEMD-160 result
• Perform SHA256 hash on the result of the previous SHA256 hash
• Take the first 4 bytes of the second SHA256 hash. This is the address
checksum
• Add the 4 checksum bytes at the end of the extended RIPEMD-160
hash. This is the 25 byte binary Bitcoin address
• Convert the result from byte string into Base58Check encoding.
TLDR:
<version_byte><20 bytes of RIPEMD-160(SHA-256(PublicKey))><4
bytes checksum> = Base58Encode(25 bytes) //note 4 byte checksum
must be calculated, see instructions above
6
7. WARNING DRAGONS AHEAD!
The next 10 minutes are extremely mathematical and not necessary for how to encode/decode data into the
blockchain but teaches about the cryptographic algorithms bitcoin utilizes.
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
7
8. Bitcoin Addresses & Cryptography (Detailed Math)
ECDSA is short for Elliptic Curve Digital Signature Algorithm. It's a process that uses an elliptic curve and a
finite field to "sign" data in such a way that third parties can verify the authenticity of the signature while the
signer retains the exclusive ability to create the signature. With bitcoin, the data that is signed is the
transaction that transfers ownership.
ECDSA has separate procedures for signing and verification. Each procedure is an algorithm composed of a
few arithmetic operations. The signing algorithm makes use of the private key, and the verification process
makes use of the public key.
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
8
9. Bitcoin Addresses & Cryptography (Detailed Math)
• Elliptic curve cryptography is a branch of
mathematics that deals with curves or functions that
take the format
• y2=x3+ax+b
• The Bitcoin curve is based secp256k1 curve
based on modular mathematics and takes the
form below:
• y2 = x3 + 7 defined over field Z2
256
-2
32
-977, which
means the X and Y coordinates are 256-bit
integers modulo a large number
• Transformation of a Private Key to a Public
Key:
• Public_K= G * Private_K
• In this case the Public_K is a point in the secp256k1
curve with both x and y coordinates and G is the
generator point. The generator point is the same for
everyone and is just an arbitrarily defined point.
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
Source: https://www.coindesk.com/math-behind-bitcoin/
9
10. Bitcoin Addresses & Cryptography (Detailed Math)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
A non-vertical line intersecting two non-tangent points on the curve will always intersect a third point on the curve. A further property is that a non-
vertical line tangent to the curve at one point will intersect precisely one other point on the curve. We can use these properties to define two
operations: point addition and point doubling.
10
11. Bitcoin Addresses & Cryptography (Detailed Math)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
Scalar Multiplcation:
Together, point addition & point doubling are used for scalar multiplication, R = a P, defined by adding the point P to itself a times. For
example:
R = 7P
R = P + (P + (P + (P + (P + (P + P)))))
The process of scalar multiplication is normally simplified by using a combination of point addition and point doubling operations. For
example:
R = 7P
R = P + 6P
R = P + 2 (3P)
R = P + 2 (P + 2P)
Here, 7P has been broken down into two point doubling steps and two point addition steps.
Finite Fields:
A finite field, in the context of ECDSA, can be thought of as a predefined range of positive numbers within which every calculation must fall. Any
number outside this range "wraps around" so as to fall within the range.
The simplest way to think about this is calculating remainders, as represented by the modulus (mod) operator.
For example, 9/7 gives 1 with a remainder of 2:
9 mod 7 = 2
Here our finite field is modulo 7, and all mod operations over this field yield a result falling within a range from 0 to 6.
11
12. Bitcoin Addresses & Cryptography (Detailed Math)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
The recipe for signing is as follows:
1. Choose some integer k between 1 and n - 1.
2. Calculate the point (x, y) = k * G, using scalar multiplication.
3. Find r = x mod n. If r = 0, return to step 1.
4. Find s = (z + r * d) / k mod n. If s = 0, return to step 1.
5. The signature is the pair (r, s)
WARNING: As a reminder, in step 4, if the numbers result in a fraction (which in
real life they almost always will), the numerator should be multiplied by the
inverse of the denominator. In step 1, it is important that knot be repeated in
different signatures and that it not be guessable by a third party. That is, should
either be random or generated by deterministic means that are kept secret from
third parties. Otherwise it would be possible to extract the private key from step 4,
since s, z, r, k and n are all known.
We now have some data and a signature for
that data. A third party who has our public key
can receive our data and signature, and verify
that we are the senders. Let's see how this
works.
With Q being the public key and the other
variables defined as before, the steps for
verifying a signature are as follows:
1. Verify that r and s are between 1 and n - 1.
2. Calculate w = s-1 mod n
3. Calculate u = z * w mod n
4. Calculate v = r * w mod n
5. Calculate the point (x, y) = uG + vQ
6. Verify that r = x mod n. The signature is
invalid if it is not.
12
13. Bitcoin Addresses & Cryptography (Detailed)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
ECDSA uses elliptic curves in the context of a finite field, which
greatly changes their appearance but not their underlying
equations or special properties. The same equation for
secp256k1 show previously, in a finite field of modulo 67, looks
like this:
Point addition and doubling are now slightly different
visually. Lines drawn on this graph will wrap around the
horizontal and vertical directions, just like in a game of
Asteroids, maintaining the same slope. So adding points (2,
22) and (6, 25) looks like this:
The third intersecting
point is (47, 39) and
its reflection point is
(47, 28).
13
14. Bitcoin Addresses & Cryptography (Detailed)
Prime Numbers & Cryptography:
Most basic and general explanation: cryptography is all about number theory, and
all integer numbers (except 0 and 1) are made up of primes, so one deal with primes a lot
in number theory.
More specifically, some important cryptographic algorithms such as RSA critically depend
on the fact that prime factorization of large numbers takes a long time. Basically you have
a "public key" consisting of a product of two large primes used to encrypt a message, and
a "secret key" consisting of those two primes used to decrypt the message.
You can make the public key public, and everyone can use it to encrypt messages to you,
but only you know the prime factors and can decrypt the messages. Everyone else would
have to factor the number, which takes too long to be practical, given the current state of
the art of number theory.
Fun fact: The Cicada3301 is named Cicada
because of a Cicada bug’s mathematical based
life.
14
15. Bitcoin Addresses & Cryptography (Detailed)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
A protocol such as bitcoin selects a set of parameters for the elliptic curve and its finite field representation that is fixed for all users of the protocol.
The parameters include the equation used, the prime modulo of the field, and a base point that falls on the curve. The order of the base point, which
is not independently selected but is a function of the other parameters, can be thought of graphically as the number of times the point can be added
to itself until its slope is infinite, or a vertical line. The base point is selected such that the order is a large prime number.
Bitcoin uses very large numbers for its base point, prime modulo, and order. In fact, all practical applications of ECDSA use enormous values. The
security of the algorithm relies on these values being large, and therefore impractical to brute force or reverse engineer.
In the case of bitcoin:
Elliptic curve equation: y2 = x3 + 7
Prime modulo = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
Base point = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC
0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Order = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
15
16. Bitcoin Addresses & Cryptography (Detailed)
TLDR:
Bitcoin public keys are valid points on a secp256k1 elliptical curve derived by a generator point
multiplied by the private key. The input parameters of secp256k1 are clearly too large to be
efficiently brute forced. The amount of processing power it would take would make more sense to
just mine several blocks
Source: https://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec2_final.pdf
So where did those secp256k1 parameters come from? These
parameters have been thoroughly tested by cryptographers and
are acceptable for use in the field of cryptography. The graph
looks simple… but the graph is a misrepresentation of blockchain’s
implementation of secp256k1:
Due to being defined over a large Z field the graph may not make sense geometrically
anymore if viewed, but it still has all properties you need. A line (which means, a group of
points with equation ay + bx + c = 0) that 'intersects' 2 points of the curve, will intersect
a third. Tangent again has no geometric interpretation anymore, but you can still
compute a local linear approximation for the curve equation in a given point, which will
have the property of intersecting the curve in a second point.
Everything we just reviewed was the inner workings of secp256k1 cryptography and not
necessary for learning how to decode/encode data but necessary to convey the
absolute mathematical impossibility of deriving blockchain private keys from public
keys.
16
17. secp256k1 vs secp256r1
Source: https://chrispacia.wordpress.com/2013/10/30/nsa-backdoors-and-bitcoin/
“Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing transactions. This is how you use your private key to “prove” you
own the bitcoins associated with your address. ECDSA keys are derived from elliptic curves that themselves are generated using certain parameters.
NIST has been actively recommending that everyone use the secp256r1 parameters because they “are the most secure”. However, there appears to
be some funny business with secp256r1 that is eerily similar to the backdoor in Dual_EC_DRBG.
Secp256r1 is supposed to use a random number in generating the curves. The way it allegedly creates this random number is by using a one-way
hash function of a “seed” to produce a nothing up my sleeve number. The seed need not be random since the output of the hash function is not
predictable. Instead of using a relatively innocuous seed like, say, the number 15, secp256r1 uses the very suspicious looking seed:
c49d360886e704936a6678e1139d26b7819f7e90. And like Dual_EC_DRBG, it provides no documentation for how or why this number was chosen.
However, the kicker in all this is that the parameters for secp256r1 were developed by the head of elliptic curve research at the NSA! The
unbelievable thing is that rather than using secp256r1 like nearly all other applications, Bitcoin uses secp256k1 which uses Koblitz curves instead of
pseudorandom curves and is still believed to be secure. Now the decision to use secp256k1 instead of secp256r1 was made by Satoshi”
That sounds a lot like conspiracy… let’s see some code/previous examples with
RSA:
Source: https://gist.github.com/ryancdotorg/9bd3873e488740f86ebb
Ryan Castellucci’s RSA RNG backdoor script
Castelluci backdoor Detection Script by Sam Vartaka.
Source: https://github.com/samvartaka/crypto_backdoors/blob/master/rsa_curve25519/detectbd.py
On the Possibility of a Back Door in the NIST SP800-90 Dual EC Prng by Dan Shumow and Niels
Ferguson @ Microsoft
17
18. secp256k1 vs secp256r1
The main difference is that secp256k1 is
a Koblitz curve, while secp256r1 is not.
Koblitz curves are known to be a few
bits weaker than other curves, but since
we are talking about 256-bit curves,
neither is broken in "5-10 years" unless
there's a breakthrough.
The other difference is how the
parameters have been chosen. In
secp256r1 they are supposedly from
random numbers... The Koblitz curve,
on the other hand, has had its
parameters chosen relatively rigidly.
So rather than saying one is more
secure, one could say that the risks are
different. If neither curve has backdoors
or accidental weaknesses, both are
secure. It would have been easier to
backdoor the secp256r1 curve, but on
the other hand, Koblitz curves as a class
could be completely weak in some way
not currently known.
I.e. which to prefer is somewhat
subjective. If you don't like Koblitz
curves but are afraid secp256r1 is
backdoored, there's always the option to
secp256r
1
secp256k1
Programmers
18
19. Transactions, this is where the magic happens!
Script:
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from
left to right. It is intentionally not Turing-complete, with no loops.
A script is essentially a list of instructions recorded with each transaction that describe how the next person
wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin
transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things:
the spender must provide
a public key that, when hashed, yields destination address D embedded in the script, and
a signature to prove ownership of the private key corresponding to the public key just provided.
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For
example, the scripting system could be used to require two private keys, or a combination of several keys, or
even no keys at all.
A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-
zero) when the script exits. The party that originally sent the Bitcoins now being spent dictates the script
operations that will occur last in order to release them for use in another transaction. The party wanting to
spend them must provide the input(s) to the previously recorded script that results in the combined script
completing execution with a true value on the top of the stack.
The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-
length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is
represented by any representation of non-zero. Byte vectors on the stack are not allowed to be more than
520 bytes long. Opcodes which take integers and bools off the stack require that they be no more than 4
Source: https://en.bitcoin.it/wiki/Script
19
20. Transactions & Operands + OpCodes
Some examples of Script operands:
Source: https://en.bitcoin.it/wiki/Script
20
21. P2SH, P2PKH, P2PK, & P2WPKH Transactions
P2PKH: "Pay To Public Key Hash"
This is how transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key.
The transaction output script will use the signature and public key and through some cryptographic functions will check if it
matches with the public key hash, if it does, then the funds will be spendable. This method conceals your public key in the form
of a hash for extra security.
P2PK: "Pay To Public Key"
This is similar to P2PKH; the difference is that it does not conceal your public key. Anyone using this method to send funds over
the P2P network is showing people their public key in the transaction details.
P2SH: "Pay To Script Hash"
The outputs of a transaction are just scripts that, if are executed with specific parameters, will result in a boolean of true or false.
If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired
output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before
accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH
transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the
money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.
The difference between BTC held in P2SH and Unspent P2SH Output:
Unspent P2SH output means outputs have not been redeemed, or parameters have not been met previously.
P2WPKH: "Pay To Witness Public Key Hash"
This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction
validity, there is a new part of the transaction called witness where the validity occurs. 21
22. P2SH, P2PKH, P2PK, & P2WPKH Transactions
So for decoding we need to
remove the first 6 and last 4
characters from the hex
string before attempting to
decode… ✅ :
Caption: Sloppy allocation but when control is returned
from function back to main() garbage collector is called
anyways…
22
24. Peter Todd’s Hash Collision Bug Bounty Challenges - P2SH Use
Bitcoin Core Developer Peter Todd notes:
1) We advise mining the block in which you collect your bounty yourself; scriptSigs satisfying
the above scriptPubKeys do not cryptographically sign the transaction's outputs. If the bounty
value is sufficiently large other miners may find it profitable to reorganize the chain to kill your
block and collect the reward themselves. This is particularly profitable for larger, centralized,
mining pools.
2) Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2
bounty may be diminished by the act of collecting it.
3) Due to limitations of the Bitcoin scripting language bounties can only be collected with
solutions using messages less than 521 bytes in size.
4) "When Will We See Collisions for SHA-1?" - Bruce Schneier -
https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
Recent Collisions:
1. https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf
Xiaoyun Wang, Yiqun Yin, Hongbo Yu, Finding Collisions in the Full SHA-1, Advances in Cryptology-Crypto 05, LNCS 3621: 17-36, 2005.
2. https://www.theregister.co.uk/2017/02/23/google_first_sha1_collision/
3. Shattered.io
24
25. Peter Todd’s Hash Collision Bug Bounty Challenges - P2SH Use
RIPEMD160 (RACE Integrity Primitives Evaluation
Message Digest) :
• A 128-bit hash result does not offer sufficient protection
anymore. A brute force collision search attack on a 128-bit hash
result requires 264 or about 2.1019 evaluations of the function. In
1994 Paul van Oorschot and Mike Wiener showed that this brute-
force job can be done in less than a month with a $10 million
investment (``Parallel collision search with applications to hash
functions and discrete logarithms,'' 2nd ACM Conference on
Computer and Communications Security, ACM Press, 1994, pp.
210-218). This cost is expected to halve every 18 months.
• At the rump session of Crypto 2004 it was announced that
Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu found
collisions for MD4, MD5, RIPEMD, and the 128-bit version of
HAVAL.
• There is tons of research on RIPEMD160 hash collisions, but
nobody has claimed the bounty embedded in the blockchain for
one yet! 25
27. Encoding plaintext messages into the blockchain - P2PK Use
• Source:
https://blockchain.info/tx/0d605442753cedadfa301423d156e6ae518891d83b58475d457c4b0c5d39d937?show_adv=tru
e
27
28. Encoding plaintext messages into the blockchain - P2PK Use
• Source:
https://blockchain.info/tx/0d605442753cedadfa301423d156e6ae518891d83b58475d457c4b0c5d39d937?show_adv=tru
e
28
29. Encoding plaintext messages into the blockchain - P2PK Use
Recall: “So for decoding
we need to remove the
first 6 and last 4
characters from the hex
string before attempting
to decode”
29
30. Encoding Text Messages into the Blockchain (AMI priv8 key leak) - P2PK
Use
• Source: https://threatpost.com/ami-firmware-source-code-private-key-leaked-040513/77703/
30
31. Encoding Text Messages into the Blockchain (AMI priv8 key leak) - P2PK
Use
• Source: https://threatpost.com/ami-firmware-source-code-private-key-leaked-040513/77703/
Transaction 1: https://blockexplorer.com/tx/08654f9dc9d673b3527b48ad06ab1b199ad47b61fd54033af30c2ee975c588bd
Transaction 2: https://blockexplorer.com/tx/b96af3b69b48a82c5eae3e44ebb6ef93f30d7764b1d5b40243e11b0d374ac1b7
This transaction has a link about a leaked private key, followed by 1K of hex
bytes as text, which supposedly is the private key for some AMI firmware.
The change from transaction #1 was used for transaction #2, which references
the Wikipedia page on illegal primes, followed by two supposedly-illegal
primes from that page.
The change from transaction #2 was then used for the Wikileaks Cablegate
messages in Transaction #3, implying the same person was behind all these
messages. (See next slide for Transaction #3)
31
32. Source:
https://blockchain.info/tx/691dd277dc0e90a462a3d652a1171686de49cf19067cd33c7df0392833fb986a
Cablegate files (Wikileaks) in the Blockchain - P2PK Multisig Use
Using the satoshi_download.py
tool embedded in the
blockchain one can download a
copy of the Wikileaks Cablegate
files. The satoshi_download.py
tool requires a copy of the
blockchain and bitcoinrpc be
installed locally, my PHP
scripts do not require
bitcoinrpc but are limited
when downloading files
across multiple transactions.
One would have to write a wrapper script
to take each transaction and feed to my
script modifying the input param to be an
$argv[1] param being fed by the wrapper.32
33. One interesting thing is that the change address from the Wikileaks description transaction was
then used for three 86 kilobyte GPG-encoded files. From the "magic numbers" at the beginning of
these files I know that these are GPG files encrypted using CAST5, but what is in these files is a
mystery. Without the passphrase, they can't be decrypted.
The encrypted GPG files are in
transactions 7379ab5047b143c0b6cfe5d8d79ad240b4b4f8cced55aa26f86d1d3d370c0d4c#o448,d
3c1cb2cdbf07c25e3c5f513de5ee36081a7c590e621f1f1eab62e8d4b50b635#o448, and
cce82f3bde0537f82a55f3b8458cb50d632977f85c81dad3e1983a3348638f5c.
PGP Encrypted Messages & Keys in Blockchain - P2PK Multisig Use
What is inside the files we may never know… without the password they
cannot be opened.
Note: Appending .BFE file
extension and using bcrypt on
the files will prompt for a
password
33
35. Bitcoin Core Developer Gregory Maxwell’s P2PK encoded XSS
Source:
https://blockchain.info/tx/59bd7b2cff5da929581fc9fef31a2fba14508f1477e366befb1eb42a8810a000
Gregory Maxwell aka gmaxwell’s XSS - P2PK Use
This XSS demo was used to report a vulnerability to Coinbase, blockchain.info, and several others by Gregory
Maxwell. The public thread about the vulnerability submission also addresses mining block XSS and is
addressed by Peter Todd.
Source: https://www.reddit.com/r/Bitcoin/comments/1n57uj/im_attempting_to_reach_a_security_contact_at/
35
36. How did Gregory Maxwell get his unique BTC address? Source: https://github.com/samr7/vanitygen
A Bitcoin Vanity address is an address that starts with a certain set of characters. One repeats the process of generating a private key and finding
the public key coordinates on the elliptic curve and the following hashing and conversion to base 58. The process is just the same as mining to
secure the blockchain – one repeats it until you get the required result.
In the case of mining this is defined as the difficulty that the miners are trying to reach, or essentially the number of zeros at the start of the ending
hash – but with a vanity address it is the wanted result at the start. As all bitcoin addresses start with a 1 apart from on the testnet and other
circumstances, a vanity address will start with a 1. Two examples are below:
1GOOGLEzZDwTGhXJwPSapWtViWJf2NJYyt
1googLemzFVj8ALj6mfBsbifRoD4miY36v
The longer the intended sequence in the vanity address the more difficult is to create and the more valuable it is. There are two methods to create
a vanity address, do it yourself or have a service generate it. The other vanitygen.com and similar services which charge and do not guarantee the
security of the private and public keys.
Google searching "vanitygen.com scam" reveals once one has 3 BTC+ in their Vanity wallet a theft occurs…
Vanity Addresses
36
37. Vanity Addresses – Darknet Market Phishing
Source: https://www.justice.gov/usao-ct/pr/wallingford-man-
charged-stealing-bitcoins-dark-web-phishing-scheme
“Deirdre M. Daly, United States Attorney for the District of Connecticut, and Patricia M. Ferrick,
Special Agent in Charge of the New Haven Division of the Federal Bureau of Investigation,
announced that MICHAEL RICHO, 34, of Wallingford, was arrested today on a criminal
complaint charging him with access device fraud, computer fraud, wire fraud, identity theft and
money laundering offenses in connection with a scheme to steal bitcoins in an online phishing
scheme.
According to the criminal complaint, RICHO engaged in an online phishing scheme to steal
bitcoins from individuals on the dark web. Bitcoins are a form of electronic currency and online
marketplaces on the dark web typically accept them as a payment method.
The complaint alleges that RICHO posted fake links to online marketplaces on dark web
forums. The links directed individuals to a fake login page that looked like the real login pages
for the various online marketplaces. When individuals attempted to log in, RICHO stole his or
her username and password. Once he had an individual’s username and password, RICHO
monitored the individual’s bitcoin balance at the real marketplace. If the individual later
deposited bitcoins with the real marketplace, RICHO withdrew the bitcoins before the individual
could spend them and caused the stolen bitcoins to be deposited into his own bitcoin
wallet. RICHO then sold the stolen bitcoins to others in exchange for U.S. currency, which was
deposited into a bank account that RICHO controlled.
The complaint alleges that RICHO had over 10,000 stolen usernames and passwords saved on
his computer.
RICHO appeared this afternoon before U.S. Magistrate Judge Sarah A. L. Merriam in New Haven
and was released on a $100,000 bond.” 37
39. Why take away first 6 and last 4 bits?
76a914 is the first 6 bits we
remove and 88ac is the last
4 bits.
39
40. The Genesis Block contains encoded data!
In the Bitcoin protocol, every mined block has a transaction that creates new bitcoins. Part of that transaction is an
arbitrary coinbase field of up to 100 bytes in the Script language. Normally the coinbase field has data such as the
block number, timestamp, difficulty, and an arbitrary nonce number.
To quickly browse encoded data created by miners use bitcoinstrings.com
Note: This does not give the transaction ID or addresses involved, only the
decoded output from the block file.
40
41. Prayers in Eligius mining pool early blocks
Mining Pool Eligius, founded by Bitcoin Core Developer Luke-Jr (also wrote bgf-miner), initially was embedding prayers and versus from the
Catholic Bible into the blockchain upon mining new blocks. The prayers were embedded in Latin & English and can be seen as early as
blk00003.txt. Saint Eligius (11 June 588 – 1 December 660) is the patron saint of goldsmiths, other metalworkers, and coin collectors. Appointed the
bishop of Noyon-Tournai three years after the king's death in 642, Eligius worked for twenty years to convert the pagan population of Flanders to
Christianity; Luke-Jr’s Eligius attempts the same.
Note: If one has a copy of the Blockchain from using a wallet which requires a copy downloaded the blocks can be inspected locally. If not,
https://bitcoinstrings.com/blk00003.txt
In the following block, blk00004.txt, the message “FFS Luke-JR
Leave the blockchain alone!” can be seen embedded. Shortly
after the message several Rick Rolls were embedded into the
blockchain by other miners in an attempt to disrupt the prayers.
Luke-Jr is a very controversial Bitcoin Core Developer
known for launching 51% attacks against altcoins he
either believes are scams or he does not agree with the
core developers values.
41
44. Let’s not forget satoshi_uploader.py
• Source:
https://blockchain.info/tx/4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b93
6e17
44
45. Bitcoin whitepaper:
https://blockexplorer.com/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78
f4e4186e713
satoshi_downloader.py or
PDFs and files in the Blockchain
import subprocess
# raw = full hex of raw Tx using Bitcoin-cli
txid =
“54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713”
raw = subprocess.check_output(["bitcoin-cli", "getrawtransaction", ”txid"])
outputs = raw.split("0100000000000000")
pdf = ""
for output in outputs[1:-2]:
# there are 3 65-byte parts in this that we need
cur = 6
pdf += output[cur:cur+130].decode('hex')
cur += 132
pdf += output[cur:cur+130].decode('hex')
cur += 132
pdf += output[cur:cur+130].decode('hex')
pdf += outputs[-2][6:-4].decode("hex")
f = open("bitcoin.pdf", "wb")
f.write(pdf[8:])
45
47. When is the weaponizing part?
EVERYTHING PRESENTED TODAY has
shown how to encode/decode,
read/write files of various types,
highlighted PGP encrypted files and
exploits embedded with PHP & Python
code examples… RTFM!
47
48. Questions & Comments?
Contact:
jburke@wapacklabs.com
Feel free to contact about
Linux, robotics, embedded
systems, drones, exploits,
hacking, hacker forums
(parsing & monitoring),
coding, Tor usage,
cryptocurrency, etc. Also
available in the Red Sky
Alliance portal 24/7
End
48
>> EOF | END
