Floored Latency

The speed of the experience you can offer your users is floored by a few variables, most notably the physical distance from the origin server to where the user is actually sitting.

Us-east-1 (appropriately located right by “Centreville, Virginia”) is one of the main data centers run by AWS. If you’re a startup (or even quite a few mature companies), you are likely to deploy your application here. If you manage a stateful service, or your architecture doesn’t support distributed compute, you are likely to only deploy here. If you have users in Sydney, Australia, any network request you make will need to travel 15,677km to make it there, as the crow flies.

Distance from Centreville, Virginia to Sydney, Australia

If you’re traveling at:

1) The speed of light

2) as the crow flies

3) with no overhead

then that means that you are floored at 104ms of latency for your request.

Time in takes for the speed of light to travel from us-east-1 to Sydney

And this is assuming no interference, other traffic, or time spent handling the request.

In reality, the ping you’ll experience will be worse, at around 215ms (which is a pretty amazing feat in and of itself - all those factors above only double the time it takes to get from Sydney to the eastern US).

Ping to various cities around the globe

And this is just what is added on top of everything else that happens on a request - TLS termination and DNS lookup. This isn’t a one-time hit to performance - every connection the client opens needs to go through TLS termination, or be queued up on the same connection and be executed serially. For simple sites that are basic html and css this isn’t an issue, but for many sites you’ll have dozens of requests to different domains, and each one will need to be established and terminated.

Compounding latency

The full TLS 1.2 handshake requires 2 round-trips to complete, and when combined with TCP’s SYN and SYN-ACK negotiation it extends to 3 full round-trips. While, TLS 1.3 reduces that to two round-trips when under TCP, it still adds considerable latency to every connection. ¹

The problem gets compounded when you realize many requests are chained, or dependent on each other. Images in CSS files can only be requested once the CSS has been downloaded, and the CSS can only be downloaded once the browser has parsed the HTML. HTTP/2 and its multiplexing improves this but doesn’t completely solve this - each of these could be hosted on a different domain, or saturate the max concurrent connections from your browser.

Protocol improvements also don’t fix fundamental issues with how the site is architected - if you have an SPA that hasn’t been optimized properly, your browser needs to first download all the content, then execute the javascript, and only once the JS has executed will it begin to make the API requests and fetch the assets to populate the content of the page.

It’s cascading latency hell. In aggregate this can add thousands of milliseconds for a simple site.

Realized latency

Having spent so much time trying to optimize web pages and API responses for performance, I’ve gotten a pretty good internal model for latency. I can’t quite tell the difference between a us-east-1 server when I’m in New York versus San Francisco, but I can definitely tell if you’ve got an instance deployed in eu-central-1 or not when I’m in Italy, or ap-east-1 when I’m in Sydney. It’s much easier to tell with native apps, where the UI is much more responsive and the only variable is the duration of the API request. You’ll pull to refresh on a list and it’ll hang for just a little longer than you’re used to.

Using a global CDN can help get your assets to your users quicker, and most companies by this point are using something like Cloudflare or Vercel, but many still only serve static or cached content this way. Very frequently the origin server will still be a centralized monolith deployed in only one location, or there will only be a single database cluster.

As soon as you land back in the United States and turn of Airplane mode on your phone everything just starts feeling… snappier? A little more fluid? As much as T-Mobile and Verizon would like to take credit for that I don’t think theres much more to it than the physical location of the servers and where you are at that moment.

Magic Link is a web3 wallet-as-a-service. They provide an SDK that enables users to have a crypto wallet linked to just their email address, instead of having to install a chrome extension or local wallet.

I wanted to explore how it worked, and what it was actually doing under the hood.

Web3 Wallets

There are broadly two options for storing your crypto assets - custodial and non-custodial.

A custodial solution is something like coinbase - typically a single company, which manages the private key to your wallet for you, and which is the centralized gatekeeper to your funds.

A non custodial solution is one in which you store the private key yourself - the wallet simply provides the software that you run locally that generates and stores the key. This looks like Metamask or Phantom - you will typically install a chrome extension, go through an onboarding flow, save your recovery pass phrase, and only then can you begin to use it on various dapps or to move tokens around.

Generally speaking, the user experience with custodial services is better, and allows for easier user onboarding. However, it comes with some fairly major downsides, including centralization and greater likelihood of regulatory scrutiny.

Magic is somewhere in between - they say they are non custodial, but offer the UX of a custodial solution. No need for a user to install a separater chrome extension - they just need an email address and their browser.

Under the hood

Magic is relies on AWS for their product. Their sign in and user logic uses AWS Cognito, and their key storage uses KMS.

AWS Cognito is the identity solution offered by AWS - they will handle authenticating your users for you, and offer a wide variety of sign on methods, including email/password, phone number, 3rd party, and magic email.

When setting up a Magic wallet, you start with your email address. This will talk to AWS, which will send a link to your email address containing a unique token.

Embedded Magic Link form (in this case, ImmutableX)

Confirmation code for auth sign in

Once you’re on the verification page, your browser will talk to AWS to authenticate you, and Magic will start creating your key.

They will first generate the private key for the chain you’re using in the browser, using javascript, and keep that in memory. This is the root key material, which is used to sign transactions for whichver chain you’re using - this can be imported into metamask, a hardware wallet, etc.

This key, which we’ll call user key (UK), is never shown to the user. If you intercept the network request for initial encryption you’ll see it, base64 encoded.

It will then talk to KMS, using the user account that was just authenticated for you, and create a new key within KMS. This is the key that lives inside of Amazons data centers, and which will be used to encrypt and decrypt the UK.

Your browser will send the UK in plain text to KMS directly, never speaking to Magic links servers. It will retrieve the encrypted material, and store that both within the browser cache and with magic link.

Decrypted private key coming back from KMS

If you copy and paste the “Plaintext” from above into Metamask, you can use your Magic.link private key outside of the Magic ecosystem.

Once they have the encrypted key contents, the decrypted key in memory, and the public key, magic will create an account for you on their centralized servers. They will save the encrypted key contents, and will use this for subsequent logins on new devices.

{
  "data": {
    "auth_user_id": "my-magic-link-id",
    "auth_user_mfa_active": false,
    "auth_user_wallet_id": "my-wallet-id=",
    "challenge_message": null,
    "client_id": "my-client-id",
    "consent": {},
    "delegated_wallet_info": {
      "delegated_access_token": "{\"ciphertext\": \"cipher text\"}",
      "delegated_identity_id": "us-west-2:aws-key-id",
      "delegated_key_id": "delegated-key-id",
      "delegated_pool_id": "us-west-2:delegated-pool-id",
      "should_create_delegated_wallet": false
    },
    "encrypted_private_address": "long base64 encoded encrypted private key",
    "encrypted_seed_phrase": null,
    "hd_path": null,
    "login": {
      "identifiers": [],
      "oauth2": null,
      "type": "email_link",
      "webauthn": null
    },
    "public_address": "0xmypublickey",
    "recovery_factors": [],
    "utc_timestamp_ms": 1687790408203
  },
  "error_code": "",
  "message": "",
  "status": "ok"
}

Any subsequent logins follow this same setup, with the only difference being that once you’ve authenticated with AWS, your browser will first check with Magic to see if you already have an encrypted key stored with them, and if so, will retrieve the encrypted key and decrypt it using AWS KMS.

Is this safe?

The common refrain amongst crypto purists is “not your keys not your tokens” - this is in reference to custodial services, like Coinbase and FTX.

Magic is being a bit disingenous when they say they say they are non custodial - while it’s true that in their current set up they don’t directly have access to your raw private keys, they are still the admins of their AWS account. They are limited only by the policies they themselves have put in place - they can just go into their AWS console and change the key policy, and decrypt the encrypted private keys they have for every account.

Additionally, every time you authenticate on a new device, the raw key is transmitted over HTTPS to your machine. If your machine is being man in the middle’d, an attacker will be able to see your raw key materials if you sign in. Additionally, because this is in-browser, Magic is not using any form of certificate pinning for AWS.

This isn’t ideal. This isn’t MPC or any sort of advanced cryptography - it’s just using AWS as your trust layer, and some clever engineering to make the user experience good. I’m a bit skeptical of their claims that this isn’t custodial, since Magic technically has the ability to just recover everyone’s private keys. This might be good enough, though, and the users magic is targeting (web3 gamers and casual users) are’t likely to care about the security implications.

I’ve always been surprised at how slow and and clunky it is to search in iMessage. It feels like it doesn’t search through your whole history, the UI for the results is too small given the prominence of the feature, and there exist quite literally no ways to filter or refine your search.

I realized that iMessage just stores its database locally as a sqlite file, so I went about building an alternate UI for searching, and adding in a few features that I thought would be interesting. These include:

• Semantic Search - I wanted to create embeddings for every message/conversation and then add proper semantic search on top of it
• Wrapped - I really like seeing stats about my life, and I really enjoy what Spotify has done with Wrapped, so I set out to do the same for iMessage
• AI Conversations - Talk with your friends, AI-ifiied; once you have all the context around a conversation, you can understand how that person texts and what their tone it. Then it’s as simple as plugging it into ChatGPT
• Export - Export your conversations in JSON or plain text

Your iMessage Wrapped

Reverse Engineering the Database Schema

The database sits at /Library/Messages/chat.db, while all the attachments live in ~/Library/Messages/Attachments. I made a copy of it and then opened it up and datagrip and then was ready to go. The database schema is relatively straightforward to understand - there where message, chat, handle, and attachment tables, each containing the data you’d expect. A rust library named imessage-exporter was particularly useful for understanding how the tables were joined together and what queries to make.

A few gotchas were:

• iMessage does not receive raw text as its messages - it actually receives a typedstream, and then later on post processes it and backfills in the text column. There’s a fairly obscure library for parsing these in typescript (with a bug fixed) here

• When using Messages in iCloud, your messages app won’t have all your conversations and attachments. This will make your old conversations look much more sparse than they really are. You can force iMessage to download all your conversations by toggling it on and off in iMessage settings.

Wrapped

Wrapped gives you a breakdown of your iMessage habits, broken down by year and by conversation/person.

I actually used ChatGPT to generate the product features included in iMessage Wrapped - as soon as it can do figma mocks I’ll redesign the UI using that, as well.

ChatGPT's suggestions for the features in wrapped

AI Conversations

I’ve always thought the amount of information stored in iMessage wasn’t being used appropriately - I thought that it could learn more about you, or the person you’re talking to, and suggest more things or be smarter about your interactions.

One of the first ideas that came to mind when I was building this was to use GPT4 to just continue any conversation, right where you left off.

AI generated chat that really can't make it to dinner

I started building Mimessage on April 1st, and just a few days ago I saw someone on hackernews had had the same idea to clone their friends. I think that training a model is actually a much smarter way of accomplishing this, and seems to lead to better results than naively continuing the conversation with GPT4. I’ll try and get it running locally with LLaMA soon.

Better Search

I added in global search with filters, as well as a chat specific search that allows you to do either fuzzy matching using fuse.js or just writing raw regex in the query itself.

Global search with filters

I also created a virtual FTS5 table in the sqlite messages copy, which does MATCh searches ordered by rank, and raw LIKE %QUERY% queries as well. This is really really fast, and a way better text searching experience than iMessage.

Semantic Search

I also wanted to add semantic search, as those results will often blow pure text searches out of the water. I used OpenAI and ChromaDB to create and store the embeddings for each text message, respectively.

Enabling semantic search on top of imessage

This takes quite a while and costs money, as well as requiring you to send your data off to OpenAI, so I’m planning on migrating to an entirely on device version soon.

Yak shaving the actually cool part

The coolest part of this project was actually in using a tool I created for this project called repo-refactor - it’s a library that will convert a github repo from one language to another https://github.com/jonluca/repo-refactor. The rust library I mentioned above had already done some of the heavy lifting in creating data models and structures representing the schema, as well as writing some of the base queries. This was really useful for creating and understanding types early on, and for actually reading the rust code (admittedly not my forte).

The tool is very much in its infancy, and works successfully somewhere between 40 and 80 percent of the time. It doesn’t do great on long files, and some clear failure modes (going from weakly typed -> strongly typed is pretty bad), but I think there are some cheap techniques that can be implemented to make it way more accurate. It’s still pretty incredible that it works this well with very little prompt engineering or manual cleanup.

Next Steps

The whole project was built in open source here and you can grab a copy of the latest working code from the releases page. I want to get the inference running entirely locally, probably with alpaca or with vicuna weights, so that it’s free and privacy preserving.

I also want to add more stats to the wrapped page, and make it more of an experience like Spotify’s is - if there’s any designer reading this that wants to collaborate on it, shoot me an email

Their UI was pretty bad, and it was quite slow. It also wouldn’t let you search without an area code, and the majority of area codes that I tried said that they didn’t have any numbers associated with them. I figured it would be faster to do this programatically.

Finding the endpoints

I used burpsuite to find out which API endpoint Verizon was hitting to fetch the available phone numbers.

From here I could just export it to code - my preferred method is to copy the request as curl from within BurpSuite and then use a tool like CurlConverter to turn it into the language of choice, although BurpSuite does have plugins that do this natively as well.

Calling the API programatically

Curl converter gave me a nice little code snippet that I could use. I put it into a jupyter notebook and was happy to see it all worked. Their endpoint didn’t seem to use any signing or on-device auth that would’ve made this difficult, besides a static basic auth token as an HTTP header.

import requests

headers = {
    'Host': 'api-v.vzmessages.com',
    'Cache-Control': 'no-cache',
    'Connection': 'close',
    'Accept': '*/*',
    'User-Agent': 'Verizon%20My%20Numbers/1 CFNetwork/1333.0.4 Darwin/21.5.0',
    'Accept-Language': 'en-US,en;q=0.9',
    'Authorization': 'Basic <Auth-Token>',
}

params = {
    'state': 'CA',
    'acode': '213',
}

response = requests.get('https://api-v.vzmessages.com/VirtualNumber/listOfMVNs/US', params=params, headers=headers, verify=False)

It seemed like multiple calls to this endpoint with the same params gave different replies, which meant it was non deterministic.

It also seemed like if you removed the params, it would remove the filter and return back many more numbers - I didn’t really care what the area code was, so removing the params should make it easier to find a number I liked.

I wrote a quick script to repeatedly call the API and try and find a number with at least 3 consecutive numbers.

def contains_cons(num):
    for i in range(len(num) - 2):
        if num[i] == num[i + 1] and num[i + 1] == num[i + 2]:
            return True
    return False

and then just kept calling that infinitely.

seen = set()
while True:
    response = requests.get('https://api-v.vzmessages.com/VirtualNumber/listOfMVNs/US', headers=headers)
    nums = response.json()
    for num in nums:
        if num in seen:
            continue
        seen.add(num)
        is_valid = contains_cons(num)
        if is_valid:
            print(num)
            break

Finding valid numbers

I let this run for a few minutes and checked back and found that there were quite a few good candidates.

These are the numbers that had at least three consecutive digits (along with the number I actually ended up using, blacked out).

Purchasing the number

I went through and bought a dummy number to figure out how to purchase the number programatically, and then did the same method as above to purchase it. Luckily there weren’t any unique IDs or anything, I could just swap out the number and it would work.

import requests

headers = {
    'Host': 'api-v.vzmessages.com',
    'User-Agent': 'Verizon%20My%20Numbers/1 CFNetwork/1333.0.4 Darwin/21.5.0',
    'Connection': 'close',
    'Accept': '*/*',
    'Accept-Language': 'en-US,en;q=0.9',
    'Cache-Control': 'no-cache',
}

json_data = {
    'countryCode': 'US',
    'zipcode': '<your billing zipcode',
    'deviceId': '<your device id>',
    'contentId': 'Content2',
    'price': '15',
    'mvn': '<number you want>',
    'mdn': '<your hard line number>',
}

response = requests.post('https://api-v.vzmessages.com/VirtualNumber/purchase', headers=headers, json=json_data)

Success

Using this I was able to purchase the number, and now it shows up in the app. One drawback is that it’s not really integrated fully in your phone - for instance, iMessages to that number won’t work, and the calls need to be made through the app. It’s still nice to have, and a nice number to give out when you don’t want to give out your real one.

This investigation uncovered similar vulnerabilities in NFT exchanges, yet to be publicized.

Background

Metaplex’s Candy Machine, a Solana program which handles the logistics of NFT issuance, just launched last September. You instantiate it with their CLI, feed it your images, and it handles the rest. It will deal with all the technically complex parts of putting the images on chain and creating the smart contracts to mint them to the buyers.

It’s extremely simple to launch an NFT sale with Metaplex; you choose the price you want to set, the timing of the collection drop and any other configs - it handles the rest and mints right to recipients wallets.

This simplicity greatly lowered the barrier to entry - you didn’t need to have any Rust knowledge or Solana API experience to use it. When it first came out it led to a huge increase in NFT collections.

Since its inception, over 14,800 candy machines have been created, each corresponding to an NFT collection.

Impact

The goal of this research was to identify how the attacker exploited the vulnerability, trace the funds and their total dollar denominated value, and then to determine which projects were impacted.

The attacker targeted 4,410 of the 14,800 candy machines that were created at the time. I’m guessing they didn’t target every vulnerable program because they had trouble pulling the historical candy machine creation records.

They fired off withdrawal transactions that took advantage of the reinitialization bug over the period of an hour.

The withdrawal transactions lasted between 5:57am and 6:49am EST on January 4th 2022. At 6:20am, the patched contract was deployed, causing every subsequent transaction by the attacker to fail.

Of the 4,410 candy machines targeted, 3,470 were completely drained. The vulnerability didn’t give the attacker permanent control of the candy machines - only for the duration of that transaction, which means that the candy machines that were impacted are not currently vulnerable.

Some of the notable projects impacted by this vulnerability are SolSteads, Contrastive, and Degen Ape Society, with a full list below.

Vulnerability

The bug was subtle - the attacker was injecting pre-initialized accounts and the program was not checking if the account had already been initialized, meaning an attacker could populate their own address as the authority of the contract.

The fix itself was fairly straightforward.

The hack seems fairly unsophisticated - the damage this vulnerability could do was pretty high, as the bug effectively allowed any account to control the Candy Machine. The attacker submitted the transactions slowly, and would probably have been able to capture the entirety of the vulnerable set of candy machines had they submitted the transactions through their own RPC pool without rate limits.

What’s also interesting about the fix is that it was actually fixed in code on December 31st for Candy Machine v2, but the CMv1 contract wasn’t redeployed until it was actively being exploited.

Fund extraction

The attacker used Serum DEX and RaydiumSwapV2 to convert the SOL to USDC, then sent the USDC to a FTX address. It should be fairly easy to reverse their idea from FTXs end if they’ve KYC’d properly.

Candy Machine

Candy Machine v1 is now deprecated, and any new candy machines created should be v2s. From their docs:

The second iteration of the well-known Candy Machine, a fully on-chain generative NFT distribution program, provides many improvements over its predecessor. The new version also allows you to create a whole new set of distribution scenarios and offers protection from bot attacks, while providing the same easy-to-use experience.

Research

Querying for historical data on chain in Solana is a time consuming process. I tried doing research in jupyter notebook at first, but the volume of data made it hard to parse and query.

I ended up cloning the historical transactions into a local database, and indexing that for faster queries.

export class MongoClient {
  init = async () => {
    log.info("Connecting...");
    await connect("mongodb://127.0.0.1:27017", {
      keepAlive: true,
      keepAliveInitialDelay: 300000,
      dbName: "candymachine",
      minPoolSize: 50,
      maxPoolSize: 500,
    });
    log.info("Connected to mongo db");
  };

  saveHashes = async (hashes: object[]) => {
    log.debug("Saving batch...");
    try {
      await Txhashes.insertMany(hashes, { ordered: false });
    } catch (e: any) {
      // ignore dup key errors
      if (!e.message.includes("E11000")) {
        log.error(e);
      }
    }
    const count = await Txhashes.count();
    log.debug(`Saved batch - ${count} total documents`);
  };

  getHashes = async (filter: FilterQuery<typeof Txhashes> = {}) => {
    const docs = await Txhashes.find(filter).limit(25000);
    return docs;
  };
}

I first cloned all the transaction hashes into Mongo - I set up a connection pool of various RPCs to accomplish this, as there’s no way of getting it from the Solana mainnet-beta RPC in a reasonable amount of time.

const history = await con.getSignaturesForAddress(
  new PublicKey(publicKey),
  options
);

for (const c of chunk(history, 100000)) {
  await mc.saveHashes(c);
  log.info("Completed chunk");
}

Then, after fetching all the hashes, I would clone the parsed transaction details into Mongo

const run = async () => {
  await mc.init();
  log.info("Fetching hashes");
  let hashesToFetch = await mc.getHashes({ tx: null });
  log.info("Fetched hashes");
  let i = 0;
  while (hashesToFetch.length) {
    let isNearEnd = hashesToFetch.length < 10000;
    const chunkSize = isNearEnd ? 10 : 200;
    if (isNearEnd) {
      shuffle(hashesToFetch);
    }
    const chunkedHistory = chunk(hashesToFetch, chunkSize) as string[][];
    const processChunk = async (hashes: any[]) => {
      let message = `Fetched txs ${i}`;
      let savedTxMessage = `Saved txs ${i}`;
      i++;

      console.time(message);
      const hashMap = {};
      hashes.forEach((hash) => {
        if (hash.signature) {
          hashMap[hash.signature] = hash;
        } else {
          console.error("what");
        }
      });

      try {
        const { c, tx: txs } = await fetchTxsWithFallbackWithConnection(
          hashes.map((p) => p.signature)
        );

        console.timeLog(message, c?._rpcEndpoint);
        console.timeEnd(message);
        let failureCount = 0;
        txs.forEach((tx) => {
          if (!tx) {
            failureCount++;

            return;
          }
          tx.transaction.signatures.forEach((s) => {
            if (hashMap[s]) {
              hashMap[s].tx = tx;
            }
          });
        });
        if (failureCount) {
          console.error(`Invalid txs: ${failureCount}`);
        }
        console.time(savedTxMessage);
        await Txhashes.bulkSave(hashes);
        console.timeEnd(savedTxMessage);
      } catch (e) {
        return;
      }
    };
    try {
      const promises = chunkedHistory.map((h) => limit(() => processChunk(h)));
      await Promise.all(promises);
    } catch (e) {
      console.error(e);
      console.error(
        `Chunk failed with total history length of ${hashesToFetch.length}`
      );
    }
    console.log("Finished chunk");
    log.info("Fetching hashes");
    hashesToFetch = await mc.getHashes({ tx: null });
    log.info("Fetched hashes");
  }
};

I also pulled every transaction (legitimate and the attackers) that called the withdraw function on the candy machines.

Of the 14,800 candy machines, 11,848 have had the withdraw function executed on them. The top accounts associated with these functions are below.

Only cHfYkrVAwfEoe3Mr2GbvzpNQJboDL6AiBoFZDsf8dxj seems to be doing this maliciously - the other accounts are all calling legitimate withdraw functions.

F9fER1Cb8hmjapWGZDukzcEYshAUDbSFpbXkj9QuBaQj actually seems to have created over 2,000 candy machines, and then attempted to call withdraw on them, single handedly creating ~14% of all candy machines on Solana.

[Redacted Pending Vulnerability Disclosure]

[Redacted pending vulnerability disclosure of Solana exchange]

[Redacted Pending Vulnerability Disclosure]

[Redacted pending vulnerability disclosure of Solana exchange]

Identified Projects

I went through and fetched the public keys to all known affected projects and tried to map them back to the hacked machines. I identified 334 unique projects that were actively listed on Magic Eden, Solanart, DigitalEyez, and Solsea as being affected.

012Funksaicy 0xDRIP 100Radials 169 Pixel Gang 3D Flowers A Pixel Art Abstergo Aeterna Civitas Afrobubble AI: Baby Bots Aircrafts AIRDOGS Alphabet Originals Angomon Angry BaboonS Angry Bunny Club Angry Citizens AngryWorms Anti Artist Club ApexDucks Halloween Arcade ‘88 Art by NRG – Pop Sushi Artificial Irrelevants Autistic Reindeer Herd Baby Ape Social Club Baby Bait Baby Frogs Baby Goblin Bad Bromatoes BADBOYS BalisariNFT Bannurs Bare Bones Society: The Kingdom Of Secrets Beat Drops V1 Boat Boys BoldFrames Boopie Gen 1 Bored Ape Social Club Boss Babes Broken Robot Burger Bar bugbearz Bunny Warriors CASSETS Audio CatPunk CATPUNK OG PASS Cats Club NFT Chickenz ChihuahuaSol Classic Art Mashups Coherence Combat Women NFT Contrastive Crazy Pickles Creepy Girls Crypto Greeks Crypto Idolz - Faces CryptoCream CryptoCubs CryptoCubs Mutants Cryptone™ Cryptonic Creations CryptoRock CryptoTeds CryptZero Season 2 - Ghosts Cult of Meerkats CyberKeys Danger Valley Danuki Dojo Deadass Deeps Degen Ape Society DegenEggs Degeneggs - Gen 2 Desolates Metaverse Dessert Girls DigiLife Dinos Zone Dippy Dragons NFT Doll Society Dragon Eggs NFT Dragon Slayerz Dreamland Monkeys Element Art NFT 2D Enigma Expanses enviro Enviro Epoch Labs Ethereans Eyeballz Eyes WTF Fallen Traveler Fast Food Thugbirdz Finefolk Floppy Disk Nft Flutter Fractures G.O.A.T. Collection Galactic Goose GAMEKIDZ GANder g0 Gem Heroes Ghostface Ghostly Sols Ghoulie Gang Gremlins NFT Hallow Birds Happy Pups Hellish Party Boollons Hello World! NFT Hemp Heroes and Villains: PASS High Roller Hippo Clique HOAG play Honorary Space Bums Hot Bunnies NFT Houses Of pixel Iceland - 0xDRIP Icy Bearz NFT Idle Planets - Autumn 2021 Moon Idle Planets - Holiday 2021 Moon Infamous Apes InnerMind Intersolar iTrading_Bot Jelly Beasts Jingle Monkeys Joeian’s Collection JOSEPHTAYLOR.ART: CRYSTAL BEAMS Jungle Cats Just Blocks Kitten Coup Knightdom KoreanPunkz Krunk Roach NFT Kyoudai Academy: Solana Arcade Games Labyrinth Lanabots Lazy Heroes Little Noots Los Cactus Hermanos LuchaLucha NFT Lucky Kittens LuxAI Mad Vikings Arms Collection Magic Solana Shits Make your own NFT Mark McKenna’s Heroes & Villains: Origins Megumi Meta Homes Metadroids Metakatz metaSpheres MetaSpheres Mickey Degods Millionaire Apes Club Mindfolk Mini Royale: Nations - Season 1 (Premium) Mob Monkettez MogulWars Monkey Ball MonkeyBall Gen Zero My name Is Sol My Name is Sol Myopa Mystic Potion Neopets Metaverse NFT Poetry NFTrees Solana NGMIPandas Nifty Nanas NON-FUNGIBLE “BEES” Nyan Heroes OGbottles Oink Club NFT OinkClub NFT PEEPS Pengu Love Personify Pesky Ice Cube Phantom Pilgrim Society PIMP MY THUG Pirates of Sol Bay - Bottles Pirates of Sol Bay - Treasures pitcrew Pix World NFT Pixel Island NFT PixelWorms PixWorldNFT Platypusol Family Playground Waves Playground: Waves PopsicleNFT Posh Dolphs Powder Heroes Prickly Pete’s Platoon - OG Cactoon Series PSY Network | PlanetZ Pudgy Pigeons Rabbit Punks Realm Kings Red paperclip RowdyRex Rug Toadz Ruled by Randomness: The Genesis SantaClaus Savage Dray by Squeak Brigade SavagesTotsys SawBunny Secret Duck Society SGF United Shadowy Super Coder Shadowy Super Coder DAO SharkBros shatteredmarble ShroomZ Slimeballz sLoot Smileys Smolpenguins Snek Gang soAlien SocksOnSolana Sol Diamond Hands Sol Lions SOL NFL PLAYER’S SOL NFL Players SOL Parasites Sol Slugs Sol Tamagotchi Sol Tapes SOLadies Solagon SolAlbums Solamids Solana Baby Monkey Business Solana Bananas Solana Birbs Solana Bros Solana Cat Gang Solana Fan The Game of Squid Solana Feline Business Solana Havana Cigar Club Solana Locks Solana Mystery Box Items Solana Mystery Items Solana Pickles Solana Reversed Monkey Business Solana Robot Business Solana Samurai Journey Solana Slugs SOLANA SUPERCAR CLUB Solana Surfers Solana Tactical RPG STACC solanabets | The Clique NFT SolArc NFT Solarnauts: Mission Bravo SolBlocks Solbusters Solccoons SolCrocos Soldalas SolDice SOLDIER RABBITS SolEmoji Solez SolFoxes SolGalaxy SolGangsta Solloons Sollyfish Solmon Solmoverse: Collection 0 Solmushies SOLNANA SolNauts SolOrbs Solryx SolSlimes SolSneakers Solsteads Surreal Estate SolStoners SolTowers Solutions Solvaders SolWatchers Soul Dogs Soulofox Space Bums Space Bums: Galaxy Mint Pass Spiderverse Spirits of Solana Squareheadz Squid Society Squirrelz Stash StratosNFT Structs Superballz Surging Bulls Synesthesia, by Labyrinth Terrarium Tanks Test Guys Test Guys Item Outpost The Assembly The Baby Boogles The Beverly Hills Car Club The Collectoooooor The Elementies The Exiled Apes The Nasty Boys The Rock theBULL by metaCOLLECTIVE TheDragonClub Thirsty Cactus Garden Party Thoughtful Folk NFT ThugDragonz Tiny Tigers Titanz ToneBox Undead Sols Vale Unleashed Rel Vampires of SOL Vampires Of SOL WallStreetPunkS Wicked Pigeon Posse Wieners Wieners Club Wildfire Native Winter Tiny Tigers Wolves On Wallstreet WOOFers World of Deities NFT WUKONGSOL Xperiment

Bug Bounty

In conjunction with this vulnerability research, Metaplex has launched a bug bounty program.

Earlier this week the @Metaplex Foundation announced a Bug Bounty program—our commitment to white-hat developers we’ve been spinning up for months.

Our first contributor, @jonluca, uncovered a vulnerability in CMv1 back in January. More below. 👇 https://t.co/sq0cjtLtTj

— Metaplex (@metaplex) March 18, 2022

Timeline

• Dec 31st - Fix for CMv2 is landed
• Tue Jan 04 2022 05:57:11 GMT-0500 - First attacker transaction is executed
• Tue Jan 04 2022 06:20:29 GMT-0500 - First transaction that tries to interact with the newly updated contracted is executed
• Tue Jan 04 2022 06:49:27 GMT-0500 - Last transaction that tries to interact with the newly updated contracted is executed
• Tue Jan 06, 2022, 18:25 GMT-0500 - Fix for CMv1 is landed
• Tue Jan 15, 2022, 21:15 GMT-0500 - Metaplex is alerted to this specific vulnerability.
• Fri Mar 11, 2022 - Metaplex bug bounty program is launched in conjunction with this post
• Fri Mar 18, 2022 - Metaplex bug bounty for CMv1 is announced

Appendix

This vulnerability was discussed in Discord’s and on Twitter but was not widely analyzed.

All the code for this research will be made public pending final vulnerability disclosures on various exchanges.

The former is what most traditional scraping looks like - you manually inspect a web page, you determine the right xpath/css selectors to follow, and then instruct a scraper to statically request the page and scrape it.

The rise of SPAs has made this approach a bit less impractical - you now have to actually render the content, which is is significantly slower, to have the content you want to scrape show up in the DOM.

At the same time, it made web scraping as a whole much easier - sites that used to be server rendered now have nice, machine readable routes that serve JSON. This has lead to tools like Burp Suite and Charles Proxy being coopted from their original use of finding security vulnerabilities to being primarily used for web scraping.

In this article I want to introduce a third, more niche attack surface for scraping web pages - scraping through memory snapshots and their respective dominator graph. It’s particularly applicable when the client is encrypting its network requests and responses.

Chrome Devtools

Devtools has a nice feature to detect memory leaks - the Memory tab.

It will take a snapshot of the current tabs memory, and built a graph out of it to inspect.

The memory tab is mostly used to compare different memory snapshots - you take a snapshot, perform some actions on the page, take another snapshot, and look at everything that got allocated to see if there are any memory leaks.

Since it’s pretty much a full memory snapshot, it stores all strings and objects - which, for something like React or Vue, will include all props and (typically) network request responses.

Memory snapshots

Inspecting memory isn’t new in the reverse engineering space - for native apps, it’s one of the most common ways of finding out what an application is doing and how its internal logic is structured.

Within the web world, though, it’s hardly ever used. Most of the literature online is regarding finding memory leaks. All the tools and software around it are therefore built around that - they don’t care about the contents of the memory, they care about the origination source/allocator and the references/dominators to it.

When does this make sense?

Using memory snapshots makes sense in two cases - 1), when the client encrypts the network response, and you don’t have the time or energy to reverse the bundle to understand how to decrypt it programatically (like in Blind’s case, which I did here) and 2) when the client requests are machine readable, but there are multiple requests that get stitched together in memory to create the desired objects.

Reversing the spec

Saving a memory snapshot generates a heapsnapshot file - this is a JSON file with a given format, that is not document anywhere as far as I can tell. These snapshots are the same in Node and in Chrome, and all documentation for both just tell you to upload it to the memory tab in a new devtools instance to view it.

Luckily the code for devtools is public, so I managed to reverse it and turn it into a CLI tool - this accepts heapsnapshots as inputs, and can parse them into the graph.

Extracting JSON

At this point, you can just go through and try and parse every string in memory as JSON, and see what sticks around. This will be an easy way to find in memory JSON strings - however, these aren’t as common as you might think. The v8 compiler is pretty efficient in knowing what to keep in memory and what to discard, so it’ll typically just keep the parsed objects.

Reconstructing objects

You can reconstruct objects in memory by traversing through the graph and stitching the nodes together - everything ends up being a primitive, and graph nodes can just contain properties, so they’re proxies for objects.

It’s useful to sort by retained size (which the code in the repo has a function for), and look at the heaviest objects - these are typically going to be your most interesting allocations, especailly if you perform an allocation recording.

Future plans

The code for the project can be found here, which will parse any chrome or node heapsnapshot.. In part 2 I’m going to add the ability to fully reconstruct objects from this graph.

Function.length

Call Function.length will return the number of arguments a function is expecting.

The spread operator will not be included in the count.

Array.map(func)

when you call Array.map(func), the mapped function gets called with 3 arguments, not just the value.

So for:

["10", "11", "12"].map(parseInt);

You’d expect to get

[10, 11, 12];

but in reality get

[10, NaN, 1];

This is because .map(parseInt) calls the function with three arguments - (currentValue, index, array). This is normally not an issue, but becomes an issue when the mapped function takes additional arguments that do not correspond to the ones being passed in.

parseInt takes in two arguments - value, [, radix], and thus tries to parse 11 with radix 1, which is NaN

Values are truth-y by default

The only falsey values are:

[0, -0, 0n, "", "", null, undefined, NaN, false];

Everything else is truthy - including [], an empty Set(), and an empty object.

Null comparisons to 0

I ran into a nasty bug once where a value I thought was guaranteed to be a number was actually explicitly set to null. I was doing a comparison with 0 and ran into this weird behavior:

Array.sort sorts by string sequence code

Call .sort() on an array of numbers will not sort them numerically. Which is perplexing

Null is not equal to zero, and is not greater than zero, but is greater than or equal to zero.

String.replace() only replaces the first instance of a match

It’s almost a rite of passage for javascript developers to be bewildered that String.replace only replaces the first instance of a match in a string.

Thankfully in ES2021 we now have String.replaceAll, which behaves as you’d expect.

WTFJS

Someone also pointed out WTFJS.com which is a site that has a lot more javascript oddities and examples.

I’ve gone through a few generations - I’ll use this post to catalogue where I started and what I’m doing now. If you want to skip the post and just see the final code, it can be found here.

Gen 1

Generation one was trusty old requests. Need to make 10 requests? Wrap it in a for loop and make them iteratively.

import requests

results = {}
for i in range(10):
    resp = requests.get('https://jsonplaceholder.typicode.com/todos/1')
    results[i] = resp.json()

This isn’t bad - 40 requests in 2.8s, or 1 req/70ms. Not an issue at all. This is fine when you need to bruteforce a 3 digit passcode - you can get 1000 requests done in 70s. Not great, but fast enough, and no need for external libraries or any research.

As soon as you get to something in the 4 character range, though, this becomes unwieldy.

Gen 2

The next step here was to find ways to make these requests using Threads. Spin off a native thread for each request, and let them run behind the scenes.

Set up a queue and pool to pull URLs from, and we’re good. The queue and Worker threads are defined pretty simply below:

from queue import Queue

from threading import Thread


class Worker(Thread):
  """ Thread executing tasks from a given tasks queue """

  def __init__(self, tasks):
    Thread.__init__(self)
    self.tasks = tasks
    self.daemon = True
    self.start()

  def run(self):
    while True:
      func, args, kargs = self.tasks.get()
      try:
        func(*args, **kargs)
      except Exception as e:
        # An exception happened in this thread
        print(e)
      finally:
        # Mark this task as done, whether an exception happened or not
        self.tasks.task_done()


class ThreadPool:
  """ Pool of threads consuming tasks from a queue """

  def __init__(self, num_threads):
    self.tasks = Queue(num_threads)
    for _ in range(num_threads):
      Worker(self.tasks)

  def add_task(self, func, *args, **kargs):
    """ Add a task to the queue """
    self.tasks.put((func, args, kargs))

  def map(self, func, args_list):
    """ Add a list of tasks to the queue """
    for args in args_list:
      self.add_task(func, args)

  def wait_completion(self):
    """ Wait for completion of all the tasks in the queue """
    self.tasks.join()

And the actual query code is fairly straightforward - just define a function that’ll populate a global variable using some unique ID, and have it make the request off in its own thread.

urls = [f"https://jsonplaceholder.typicode.com/todos/{i}" for i in range(40)]
pool = ThreadPool(40)

r = requests.session()


def get(url):
    resp = r.get(url)
    results[i] = resp.json()


pool.map(get, urls)
pool.wait_completion()

Now we’re getting somewhere - 40 requests in 365ms, or 9.125ms per request. The same 1000 requests that would’ve taken 1m10s earlier now finishes in a little over nine seconds, or just about a 7x speed up. Not bad for a pretty naive implementation of threading. Can we get it even faster, though?

Gen 3

A few years back I was introduced to the library aiohttp - which is Asynchronous HTTP Client/Server for asyncio and Python. This leverages the new (at the time) async capabilities of python and lose the actual overhead of Threads.

There is a bit of monkey patching I’ve had to do to make it work with all the various request types - specifically around its conformance to the cookie spec and to get it to work properly in jupyter notebook, where I like to play around with a lot of network requests.

Once we start looking at a pool of thousands of requests, we also want to be able to throttle ourselves - our laptops can only open so many TCP connections at once, and fire off so many bits in a given second. I defined a helper called gather_with_concurrency - it’s a way of using asyncios gather with a semaphore, to limit the amount of tasks we work on in any given second.

This slows us down a bit due to the semaphore overhead, but if you’re doing anything in the alphanumeric 4 digit space you’re looking at 36^4, or 1.7m requests, which should probably be pooled and throttled a bit, and the overhead from the semaphore is worth it.

async def gather_with_concurrency(n, *tasks):
    semaphore = asyncio.Semaphore(n)

    async def sem_task(task):
        async with semaphore:
            return await task

    return await asyncio.gather(*(sem_task(task) for task in tasks))

Next we set up the connector and the custom session

conn = aiohttp.TCPConnector(limit=None, ttl_dns_cache=300)
session = aiohttp.ClientSession(connector=conn)

Here we limit each host to none - it won’t throttle itself internally, since we want to control that externally. We also bump up the dns cache TTL. For the purposes of this blog post this won’t matter, but by default it’s 10s, which saves us from the occasional DNS query.

Finally we define our actual async function, which should look pretty familiar if you’re already used to requests. We also disable SSL verification for that slight speed boost as well.

async def get(url):
    async with session.get(url, ssl=False) as response:
        obj = await response.read()
        all_offers[url] = obj

Now we’re really going! 40 requests in 100ms, or 4ms per requests. We can do about 250 requests per second - however, at this speed, the overhead of the initial function set up and jupyter notebook is actually a significant portion of the overall cost.

If we bump it up to 4000 requests, we see that we actually get closer to a 1.574s execution time, or about 56% of the time it took us to make 10 requests iteratively.

We can make one request every 0.393ms, or 393 microseconds. We can blast through the entire alphanumeric space for a 4 character permutation in about 660 million microseconds, or 11 minutes, all from my MacBook pro.

Our Threading implementation also benefits from the increase in pool - giving it a 100 threads (the same as the semaphore in the asyncio version) gives us a time to completion of 8s for 4000 urls, or a little over 2ms per URL. Nowhere near our aiohttp implementation but not terrible either.

The same 36^4 requests using the ThreadPool would take 48 minutes, though.

We can clean up the code and optimize it slightly as well:

import sys
import os
import json
import asyncio
import aiohttp


# Initialize connection pool
conn = aiohttp.TCPConnector(limit_per_host=100, limit=0, ttl_dns_cache=300)
PARALLEL_REQUESTS = 100
results = []
urls = ['https://jsonplaceholder.typicode.com/todos/1' for i in range(4000)] #array of urls

async def gather_with_concurrency(n):
    semaphore = asyncio.Semaphore(n)
    session = aiohttp.ClientSession(connector=conn)

    # heres the logic for the generator
    async def get(url):
        async with semaphore:
            async with session.get(url, ssl=False) as response:
                obj = json.loads(await response.read())
                results.append(obj)
    await asyncio.gather(*(get(url) for url in urls))
    await session.close()

loop = asyncio.get_event_loop()
loop.run_until_complete(gather_with_concurrency(PARALLEL_REQUESTS))
conn.close()

print(f"Completed {len(urls)} requests with {len(results)} results")

Optimal semaphore size?

If we bump our concurrent requests to 4k we see a drastic loss in performance.

This is nearly a 3x slow down due to resource contention issues locally.

The optimal number will depend on your host - beefier set ups will have higher concurrency limits, and if you’re running this on a remote host on something like digital ocean you can crank this number up quite a bit.

Interestingly enough the optimal semaphore value was right around 60.

I mostly do this locally at home, though, for my side projects - introducing parallelization and multiple hosts can get you numbers that are an order of magnituded better than this, but the purpose of this excercise is seeing what we can hit on a local machine with jupyter notebook.

Gen 4

Know of a faster implementation of an HTTP library that is stateful and works locally? Let me know!

HTTPX

Update - 6/17/21

A poster on lobste.rs said that I should try out httpx. HTTPX is a modern implementation of a python web client.

Unfortunately, in my testing, it was strictly slower than aiohttp. I used their async library with the same sempahore restricting the number of processes ran, but it was still slower.

I also tried a native gather, with punting the concurrency down to the library - this did not help either.

PyCurl

Someone on that same lobste.er’s thread suggested pycurl.

PyCurl is different in that it feels like a pretty raw wrapper to curl. Writing the code felt more like dispatching actions and opening sockets than dealing with a nice http library.

The results were impressive, but the aiohttp library was still faster. This was my first time writing a pycurl implementation, though, based on this template - introducing native threading might be able to speed it up, but I still haven’t seen anything faster than the 393 microseconds approach.

If you know how to set up HTTPX or PyCurl in a way that’s faster let me know!

UVLoop

Addendum: 8/27/21 - I received an email from Steve telling me about uvloop, a faster, drop in replacement for asyncio’s event loop.

It doesn’t seem to have impacted the performance all that much - it did have lower variance, though. Across multiple runs of a regular asyncio event loop, I would get as high as 3s for the same 4000 requests; with uvloop, it never broke 2.1s.

For a drop in replacement it seems pretty great - I don’t think it’ll help much at this stage, though, because most of the timing is due to the actual network call at this point. The threading and event loop implementation isn’t adding that much overhead, I’m guessing.

Repo

• React 17
• Typescript 4.3
• Vite with Vite SSR
• GitHub Actions
• Tailwind CSS
• Prettier & ESLint

The SSR is accomplished through an Express server.

Vite HMR

Vite

Vite HMR is baked into the server, so we get the blazingly fast code changes reflected on the client seen in the video above. The server rendering logic currently does not have any type of prop injection or initial state.

Opinions

This boilerplate is slightly opinionated, specifically around linting and code format. The TypeScript config is set up such as to allow for the greatest flexibility

When running in development mode, the application uses ts-node to natively run the Express server and load in the Vite HMR. In development, the rendering is still done client side. In production, all requests are server rendered. Read more on SSR on the Vite docs.

There is no selected front end state management library or back end database. There is a simple React Context for basic state.

Hosting

This assumes a traditional hosting infrastructure. The goal of the project is to provide as little lock-in as possible. You’re required to set up the deployment infrastructure, as well as containerizing the application.

You can get this boilerplate here.

Prerequisites

Roughly 250,000 GitHub users qualified. You must have had at least 15 followers during the week of 2019-02-04. If you didn’t have a GitHub account at the time, or didn’t have 15 followers, or didn’t have a valid public SSH key uploaded, you were not eligible for the airdrop.

First steps

Download hs-airdrop and register for an account on https://namebase.io. Namebase will create a free HNS wallet for you, which you can easily transfer to BTC.

git clone https://github.com/handshake-org/hs-airdrop.git && cd hs-airdrop && npm install

Next go to https://www.namebase.io/ and find your wallets address.

To redeem your HNS you’ll need:

• The hs-airdrop binary
• The path to your private key
• Your wallet address

Namebase also has similar instructions on redeeming these coins at https://www.namebase.io/airdrop.

SSH

If you want to use SSH, first confirm that the key you want to use is registered on GitHub, and was associated with your account on February 4th, 2019.

List all your keys with

$ ls ~/.ssh/

Most likely it will be named id_rsa. Then run the hs-airdrop binary with the path to your private key.

./bin/hs-airdrop --bare ~/.ssh/id_rsa hs1...<your address from namebase> 0.1

It will ask you to decrypt your private key. Note that the private key is never sent anywhere - you can verify this yourself from the source code of hs-airdrop, here: https://github.com/handshake-org/hs-airdrop. This will then proceed to submit your confirmation and check if it is in the airdrop tree. If it is, you’ll get a base64 confirmation, which you’ll submit below.

PGP

PGP is a little more tricky - the documentation on the repo is a bit lacking.

On MacOS, using PGP Suite, you can do the following.

First, get all your available keys:

$ gpg --list-keys
/Users/jonlucadecaro/.gnupg/pubring.kbx
---------------------------------------
pub   rsa4096 2017-08-24 [SC] [expires: 2033-08-20]
      849E61D17094A964866AE510E6DC4811DD593AC7
uid           [ultimate] JonLuca De Caro <jonlucadecaro96@gmail.com>
sub   rsa4096 2017-08-24 [E] [expires: 2033-08-20]

The key ID is the value below the pub key (in the case of the above, 849E61D17094A964866AE510E6DC4811DD593AC7). You now want to export the private key, replacing my public key ID with yours.

$ gpg --armor --export-secret-keys 849E61D17094A964866AE510E6DC4811DD593AC7 > ~/Desktop/sec.asc

It will ask you for the keys password.

to check if your key is in the airdrop tree, you next run, again replacing my key with yours:

./bin/hs-airdrop --bare ~/Desktop/sec.asc 849E61D17094A964866AE510E6DC4811DD593AC7 hs1...<your address> 0.1

This will tell you if your key is in the airdrop tree, and if it is, it will print out a base64 string with your airdrop redemption.

Submitting your confirmation

If your SSH or public key was in the airdrop tree, it will print a base64 string. Go to https://www.namebase.io/airdrop and paste it into the 5th box.

If it was valid, you’ll receive your HNS in roughly 16 hours.

You can then proceed to sell it on namebase.

Just paste in whatever BTC balance you want to send it to, and it’ll show up in a few minutes to hours. You can also use the coins to bid on names in namespace, or to support additional FOSS projects!

Multiple keys

Note that if you have multiple SSH keys, it will only allow you to redeem for one. It will create valid nonces for each key, but once you redeem one in the chain, it invalidates the rest. If you submit the base64 for it it will look like it was accepted, but it will be rejected by the miners

Other Airdrops

• Keybase did an XLM drop worth about $1000 USD as of May 2021 - check your https://keybase.io account
• Uniswap did a 400 ETH drop worth about $16,000 USD as of May 2021 - https://airdrops.io/uniswap/