Pete Corey Writing Work Contact

Inject Detect is Live!

Written by Pete Corey on Sep 11, 2017.

My latest project, Inject Detect is officially live and open to the public! If you have a Meteor application and you’re concerned about the threat of NoSQL Injection, I made this for you!

As I mentioned last week, it’s been a long and winding road to the launch of Inject Detect, but I couldn’t be happier with the results.

Your Inject Detect dashboard.

My original goals in building Inject Detect were to help safeguard Meteor application owners and developers from the most common vulnerability I’ve seen in Meteor applications: NoSQL Injection. I wanted to offer a more affordable and effective alternative to my hands-on security assessment process. Inject Detect is the result.

Inject Detect is designed to detect and notify you of potential NoSQL Injection attacks as they happen in your application. It does this by building up a set of “expected queries” and monitoring for any queries that are structurally dissimilar from any of the queries in that set.

Unexpected queries in an application.

In an “always on” utility service, affordability is key. Inject Detect uses a “pay-as-you-go” pricing structure where every processed query costs a mere one one hundredth of a cent ($0.0001). This means that the peace of mind afforded by Inject Detect’s watchful eye will never break your project’s bank.

In addition to using a “pay-as-you-go” pricing structure, I’m also giving new users an initial ten dollar ($10.00) account credit so you can try out Inject Detect on the house for as long as that balance lasts you.

An application’s set of expected queries.

If you’re interested in learning more about Inject Detect and NoSQL Injection, or are just curious about what I’ve been working on for the past few months, check out these related articles:

If you’re eager to cut to the chase, you can sign up for Inject Detect here!

An unexpected query.

I’m incredibly excited to see how Inject Detect can safeguard your application and your data. Don’t hesitate to reach out and let me know if you have any comments, feedback, or questions about the project.

Controlling a Bitcoin Node with Elixir

Written by Pete Corey on Sep 4, 2017.

I’ve been bit by the Bitcoin bug, and I’ve been bit hard. To satiate my thirst for knowledge, I’ve been reading the fantastic Mastering Bitcoin (affiliate link) book by Andreas Antonopoulos, and diving into the brave new world of Bitcoin development.

Mastering Bitcoin does a fantastic job of outlining the technical underpinnings of Bitcoin, but I wanted to solidify my understanding with some hands-on experience.

Writing a simple Elixir application to communicate and control a Bitcoin Core full node through its JSON-RPC interface seems like a fantastic “hello world” exercise. Let’s get to it!

You’ll Need a Full Node

The first step in communicating with a Bitcoin Core full node is getting our hands on one. While publicly available nodes with wide open JSON-RPC interfaces are few and far between, it’s fairly simple to run our own Bitcoin Core node locally.

Assuming we’ve installed the bitcoind daemon on our system, we’ll need to configure it with a bitcoin.config file:


The <username> and <password> values we define in our configuration will be used to authenticate ourselves when making requests to the Bitcoin node.

Once we’ve created our configuration file, we can spin up our full node:

bitcoind -conf=<path to bitcoin.config> -daemon

Once started, our full node daemon will begin connecting to peer nodes, downloading, and verifying blocks from the blockchain.

We can verify that everything is working as expected:

bitcoin-cli getinfo

This command should return some basic information about the node, including the node’s "version", and the number of "blocks" it’s received and verified. It may take several days to download and verify the entire blockchain, but we can keep continue on with our project in the meantime.

The Bitcoin Node’s JSON-RPC

Our Bitcoin full node implements a JSON-based RPC API which can be used to retrieve information about the Bitcoin blockchain, and to interact with the node itself.

Interestingly, the bitcoin-cli tool that we used to get information about the node leverages this JSON-RPC API. You can fetch a list of all of the available RPC commands on the node by calling bitcoin-cli help, or by browsing through the Bitcoin Wiki.

The node’s JSON-RPC accepts incoming commands through an HTTP server, which means that we can manually craft these RPC commands and bypass the bitcoin-cli tool entirely.

For example, we can run getinfo manually with curl:

curl --data-binary '{"jsonrpc":"1.0","method":"getinfo","params":[]}' \

Similarly, we can execute these commands from any programming environment with an HTTP client, like Elixir!

Setting Up Our Elixir Application

Now that we have a strategy for communicating with our Bitcoin full node, let’s start building out our Elixir application.

First, we’ll create a new Elixir project and update our mix.exs to add dependencies on poison, which we’ll need to encode and decode JSON objects, and httpoison, our go-to Elixir HTTP client.

defp deps do
    {:httpoison, "~> 0.13"},
    {:poison, "~> 3.1"}

Now that we’ve laid out the scaffolding for our application, let’s turn our attention towards talking with our Bitcoin node.

We’ll start by gutting our HelloBitcoin module, and stubbing out a new getinfo function:

defmodule HelloBitcoin do

  def getinfo do
    raise "TODO: Implement getinfo"


To keep things simple, we’ll interact with this module through iex -S mix. As a sanity check, let’s verify that everything is working correctly before moving on to the next section.

Calling our HelloBitcoin.getinfo stub should raise a runtime exception:

iex(1)> HelloBitcoin.getinfo
** (RuntimeError) TODO: Implement getinfo
    (hello_bitcoin) lib/hello_bitcoin.ex:4: HelloBitcoin.getinfo/0

Perfect. Progress through failure.

Constructing the GetInfo Command

Let’s start to flesh out our getinfo function.

To recap, our goal is to send a POST HTTP request to our Bitcoin node’s HTTP server (usually listening on http://localhost:8332), passing in a JSON object that holds the command we’re trying to execute and any required parameters.

It turns out this is incredibly easy with httpoison:

def getinfo do
  with url     <- Application.get_env(:hello_bitcoin, :bitcoin_url),
       command <- %{jsonrpc: "1.0", method: "getinfo", params: []},
       body    <- Poison.encode!(command),
       headers <- [{"Content-Type", "application/json"}] do!(url, body, headers)

We start by pulling our url from the bitcoin_url key in our application’s configuration. This needs to be set in config/config.exs and should point to your local node:

config :hello_bitcoin, bitcoin_url: "http://<user>:<password>@localhost:8332"

Next, we build a map that represents our JSON-RPC command. In this case, our method is "getinfo", which requires no params. Finally, we construct the body of our request by JSON encoding our command with Poison.encode!.

Calling HelloBitcoin.getinfo should give us a successful 200 response from the Bitcoin node, along with the JSON encoded response to our getinfo command:

  body: "{\"result\":{\"version\":140200,\"protocolversion\":70015,\"walletversion\":130000,\"balance\":0.00000000,\"blocks\":482864,\"timeoffset\":-1,\"connections\":8,\"proxy\":\"\",\"difficulty\":888171856257.3206,\"testnet\":false,\"keypoololdest\":1503512537,\"keypoolsize\":100,\"paytxfee\":0.00000000,\"relayfee\":0.00001000,\"errors\":\"\"},\"error\":null,\"id\":null}\n",
  headers: [{"Content-Type", "application/json"}, {"Date", "Thu, 31 Aug 2017 21:27:02 GMT"}, {"Content-Length", "328"}],
  request_url: "http://localhost:8332",
  status_code: 200


Let’s decode the resulting JSON in body and return the result:!(url, body)
|> Map.get(:body)
|> Poison.decode!

Now our call to HelloBitcoin.getinfo returns the result returned by bitcoind in a more usable format:

%{"error" => nil, "id" => nil,
  "result" => %{"balance" => 0.0, "blocks" => 483001, "connections" => 8,
    "difficulty" => 888171856257.3206, "errors" => "",
    "keypoololdest" => 1503512537, "keypoolsize" => 100, "paytxfee" => 0.0,
    "protocolversion" => 70015, "proxy" => "", "relayfee" => 1.0e-5,
    "testnet" => false, "timeoffset" => -1, "version" => 140200,
    "walletversion" => 130000}}

You’ll notice that the "result", the data we actually want, is wrapped in a map containing metadata about the request itself. This metadata includes a potential error string, and the id of the request.

Let’s refactor our getinfo function to include some error handling, and to return the actual data we care about in the case of an error-free response:

with url <- Application.get_env(:hello_bitcoin, :bitcoin_url),
     command <- %{jsonrpc: "1.0", method: "getinfo", params: []},
     {:ok, body} <- Poison.encode(command),
     {:ok, response} <-, body),
     {:ok, metadata} <- Poison.decode(response.body),
     %{"error" => nil, "result" => result} <- metadata do
  %{"error" => reason} -> {:error, reason}
  error -> error

Now our getinfo function will return an {:ok, result} tuple containing the result of our getinfo RPC call if everything goes well. In the case of an error we’ll receive an {:error, reason} tuple, explaining the failure.

Generalizing Commands

We could implement another Bitcoin RPC command, like getblockhash, in a nearly identical fashion:

def getblockhash(index) do
  with url <- Application.get_env(:hello_bitcoin, :bitcoin_url),
       command <- %{jsonrpc: "1.0", method: "getblockhash", params: [index]},
       {:ok, body} <- Poison.encode(command),
       {:ok, response} <-, body),
       {:ok, metadata} <- Poison.decode(response.body),
       %{"error" => nil, "result" => result} <- metadata do
    {:ok, result}
    %{"error" => reason} -> {:error, reason}
    error -> error

Calling our new getblockhash with an index of 0 gives us the hash of the Bitcoin genesis block, as we would expect.


{:ok, "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"}

While it’s great that this works, you’ll notice that there’s a huge amount of code duplication going on here. Our getblockhash function is nearly identical to our getinfo function.

Let’s abstract out the common functionality into a new bitcoin_rpc helper function:

defp bitcoin_rpc(method, params \\ []) do
  with url <- Application.get_env(:hello_bitcoin, :bitcoin_url),
       command <- %{jsonrpc: "1.0", method: method, params: params},
       {:ok, body} <- Poison.encode(command),
       {:ok, response} <-, body),
       {:ok, metadata} <- Poison.decode(response.body),
       %{"error" => nil, "result" => result} <- metadata do
    {:ok, result}
    %{"error" => reason} -> {:error, reason}
    error -> error

Now we can redefine our getinfo and getblockhash functions in terms of this new bitcoin_rpc helper function:

def getinfo, do: bitcoin_rpc("getinfo")

def getblockhash(index), do: bitcoin_rpc("getblockhash", [index])

Our bitcoin_rpc now acts as a fully functional and complete Bitcoin RPC interface. We can easily implement any of the Bitcoin RPC commands using this helper function.

If you’re curious and want to interact with a Bitcoin node yourself, the full source for this HelloBitcoin project is available on GitHub.

Wrap Up

In hindsight, this was a long article explaining a relatively simple idea. The Bitcoin full node software exposes a JSON-RPC interface that can easily be accessed by your favorite language or stack, such as Elixir.

I’m incredibly excited about Bitcoin development, and I’m planning on spending more time diving deeper into this world in the future.

If you’re interested in the technical ideas behind Bitcoin, or are interested in Bitcoin development, I highly recommend you read Mastering Bitcoin (affiliate link).

Inject Detect is Launching Soon

Written by Pete Corey on Aug 28, 2017.

It’s been a long and winding road, but development and testing on the initial release of my latest project, Inject Detect, is done.


I first announced Inject Detect back in March of this year. At that time, I estimated that the project would be finished and released mid-year.

At that point in time, I estimated that three to four months of development time was ample for the project I intended to build. Unfortunately, as software projects often do (especially when personal projects), scope creeped and timelines extended.

Take a look at the project timeline below:

As you can see, development took longer than expected. Work on the project largely took place in the evenings and in free blocks of time scheduled around my existing client work.

Not only that, but Inject Detect underwent three large refactors during its first iteration. Check out this GitHub graph of insertions and deletions for a visualization of my inner turmoil:

In hindsight, I should have prioritized shipping over perfecting my engineering vision.

That being said, I’m happy I took the time to explore alternative implementations of my idea. Along the way I learned a great deal about event sourcing, building distributed systems, Elixir, Phoenix, GraphQL, and React.

The development of Inject Detect is finished, but it’s not currently available to the public as of yet.

If you’re interested in getting your hands on Inject Detect as soon as possible, be sure to sign up for the Inject Detect newsletter where I’ll be first announcing the release in the coming weeks!