First, the device is a QuickConnect Mk112, which I quickly learned is not a fully smart plug, but actually a smart reboot device. This is meant for remotely rebooting a router if there is an issue.
My concern about the usefulness of this device is if the router is having too many issues, it may fail to let you access this resource, so it may not always work.
When you plug it in and it can't find it's home network, it will create a QuickConnect access point. Joining it leads you to a setup menu where you pick a password and configure the Wi-Fi.
I set my password to "password123", and this password needs to be sent with any web request controlling the device. The username doesn't seem to be important.
Under settings, I selected "Set static IP" so that I can always find this device on my network. This is important, or it may change IP addresses!
There is an app for controlling this, but I have no desire to let it have my data, so I will use the "Trigger manual reset" button on the menu to craft a POST request needed for controlling the reset feature.
OWASP Zap is supposed to be the tool to do this, but when opening the menu page I get this huge vexing error.
Instead, I give chatgpt4 the model number and ask it to look online for the web request. Per the online documentation, it gives the URL I need to trigger the device on and off.
This is what we need to control the device. If you just try to go to the URL endpoint, it is STRICTLY forbidden.
I used Postman to craft the correct request, and this correctly cycled the switch.
Let's write a CircuitPython program for a USB nugget to control the device remotely. We will use CircuitPython's Requests library to send this via our USB Nugget.
For this project, you will need the following libraries from the CircuitPython 9 bundle:
socketpool
ssl
adafruit_requests
adafruit_debouncer
adafruit_displayio_sh1106
Download the bundle, unzip, and add these libraries to your Nugget flashed with CircuitPython 9.
After plugging in your Nugget, you'll see a CircuitPy folder with a code.py and settings.toml file. The settings.toml file will save our Wi-Fi credentials and the IP address of our smart relay. Open the settings.toml file in a text editor and add the following information, then save:
CIRCUITPY_WIFI_PASSWORD = "YourWiFiPassword"
CIRCUITPY_WIFI_SSID = "YourWiFiNetwork"
TARGET_IP = "Your IP Address"
TARGET_PASSWORD = "Your Device Password"
Doing this ensures you don't accidentally commit your passwords if you share your code.py file. Save this file and exit the text editor.
We can access these saved variables locally in our code like this:
ssid = os.getenv("CIRCUITPY_WIFI_SSID")
Now, open the code.py file, and let's make our program. First, import all libraries:
import socketpool
import ssl
import adafruit_requests
import board
import digitalio
from digitalio import DigitalInOut, Pull
from adafruit_debouncer import Debouncer
import busio
import displayio
import adafruit_displayio_sh1106
import os
Next, connect to the Wi-Fi network the smart relay is on.
# WiFi credentials
ssid = os.getenv("CIRCUITPY_WIFI_SSID")
passwd = os.getenv("CIRCUITPY_WIFI_PASSWORD")
# Connect to WiFi
wifi.radio.connect(ssid=ssid, password=passwd)
print("Connected with IP:", wifi.radio.ipv4_address)
Now that we're connected to Wi-Fi, we'll set up the screen. In CircuitPython, setting up the screen will automatically begin outputting serial text to the screen, which is handy and saves us some steps here.
# Set up display
displayio.release_displays()
WIDTH, HEIGHT = 130, 64 # Display size
i2c = busio.I2C(board.SCL, board.SDA)
display_bus = displayio.I2CDisplay(i2c, device_address=0x3c)
display = adafruit_displayio_sh1106.SH1106(display_bus, width=WIDTH, height=HEIGHT)
For the last part of the setup, we'll prepare the down button to be pressed for us to fire off the request.
# Initialize down button
down_button_pin = DigitalInOut(board.IO18) # Use the correct pin for your down button
down_button_pin.pull = Pull.UP
down_button = Debouncer(down_button_pin)
Now that everything is set up, we'll define the function to send our post request, so that we can call it whenever the button is pressed.
def send_reboot_request():
pool = socketpool.SocketPool(wifi.radio)
requests = adafruit_requests.Session(pool, ssl.create_default_context())
# Device info and API endpoint
device_ip = os.getenv("TARGET_IP")
device_password = os.getenv("TARGET_PASSWORD")
url = f"http://{device_ip}/remoteReset"
data = {'password': device_password}
# Send POST request
response = requests.post(url, data=data)
return response
Now, we'll write the loop that runs, checking for if the button is pressed and sending the web request if it is. It also prints out the request response, and the status code.
while True:
down_button.update()
if down_button.fell:
print("Sending reboot request...")
response = send_reboot_request()
print(f"Response: {response.status_code}\n{response.text}")
print("DONE!")
time.sleep(10) # Wait for 10 seconds
time.sleep(0.1) # Small delay to reduce CPU usage
That's it! Here is the complete code.
Assuming you loaded the libraries, added the settings.toml file, and saved the code, your Nugget should connect to Wi-Fi and send the web request to reboot once the down button is pressed.
You can use this technique to control any device that uses POST requests to change settings.
]]>If you have one, here's a guide to putting it all together!
You can also check out this video guide:
First, you can put together two different types of Nugget builds with this kit. Let's take a look at the difference between them:
For this option, we'll follow the steps to make either a USB Nugget or a Wi-Fi Nugget. After we're done, we'll have a leftover microcontroller from whichever one we decided not to make.
With a tradeoff of being thicker overall, you can solder female pin headers to the back of your Nugget instead of a microcontroller, allowing you to swap between plugging in the D1 Mini and S2 Mini boards.
Once you've decided which you want to make, we can get started with assembly!
A thicker board that allows for swapping between the D1 Mini, S2 Mini, and S3 Mini. The C3 Mini is also supported but not included.
1) Solder the buttons and neopixel to the front of the board.
Make sure to orient the indent in the corner notch in the neopixel to align with the marking in the PCB so it's oriented the right way. Try to be careful around the neopixel and avoid melting the plastic.
2) Solder in microcontroller pin headers
If making a USB Nugget or BLE Nugget, solder short female header pins to the 2 inside rows of the S2 Mini board.
You can use 2 male pin headers to help hold these in place during soldering. Make sure to try and keep these straight! You can solder just one pin and easily adjust the angle, but once you solder more than one pin, it's hard to fix.
Next, solder male pin headers to your microcontrollers with the long side facing down (away from the main chip on the board). See photos below.
Make sure to keep these straight!
3) Solder in Female Pin Headers
On the side of the board that says "Solder me first," solder in 2 short female pin headers. You can plug them into one of the microcontrollers you just soldered to make sure they line up straight.
4) Solder the rear pin header breakout
Solder the female pin header to same side you just soldered the microcontroller. Try to keep this as straight as possible.
5) Add the screen
Finally, flip to the side that says "Solder me second" and add the SH1106 screen. Solder only 1 pin first and check to see if the screen is straight.
If it's not straight, melt the solder and adjust until it is before soldering the other pins.
At this point, your Omni-Nugget should is fully assembled!
Plug one of the included microcontrollers in and go to Nugget.dev in a Chrome browser to browse and flash supported projects.
The instructions for the standard Nugget are nearly identical:
The slimmest Nugget build, but requires you to choose which Nugget you want to commit to. First, pick if you want a Wi-Fi Nugget, USB Nugget, or prototype BLE Nugget.
1) Solder the buttons and neopixel to the front of the board.
Make sure to orient the indent in the corner notch in the neopixel to align with the marking in the PCB so it's oriented the right way. Try to be careful around the neopixel and avoid melting the plastic.
2) Solder in USB Nugget pin headers (optional)
If making a USB Nugget or BLE Nugget, solder short female header pins to the 2 inside rows of the S2 Mini board. If making a Wi-Fi Nugget, skip to the next step.
You can use 2 male pin headers to help hold these in place during soldering. Make sure to try and keep these straight! You can solder just one pin and easily adjust the angle, but once you solder more than one pin, it's hard to fix.
3) Solder in your microcontroller of choice (D1 Mini, S2 Mini, or S3 Mini)
On the side of the board that says "Solder me first," solder in your microcontroller of choice with male pin headers. Make sure the long side of the pin headers are facing up towards the microcontroller, or they will poke through the PCB too far and hit the screen.
Make sure to orient the USB port to face the direction shown on the PCB. Do not get this turned around!
4) Solder the rear pin header breakout
Solder the female pin header to same side you just soldered the microcontroller. Try to keep this as straight as possible.
5) Add the screen
Finally, flip to the side that says "Solder me second" and add the SH1106 screen. Solder only 1 pin first and check to see if the screen is straight.
If it's not, melt the solder and adjust until it is before soldering the other pins.
Take the backplate from your kit. This is the part of the case that will hold your assembled Nugget.
Press your assembled Nugget into the backplate. It should fit snugly.
Now, find the D-Pad and the faceplate. The D-Pad is the directional pad, and the faceplate is the front part of the case.
Place the D-Pad into the faceplate, face down. This means you should be looking at the back of the D-Pad.
Finally, take your backplate with the assembled Nugget and flip it over. Snap this part into the faceplate to complete the case assembly.
How did your build go? Have questions? Join us on our Discord server and share!
]]>Have you ever wanted to run language models like ChatGPT on your own computer? Thanks to Meta AI's language model leaking, running LLaMA and Alpaca at home is possible!
The Dalai Github Repo by cocktailpeanut allows beginners to install and run both powerful AI language models to your local machine. Getting useful output from them, however, takes a little bit of practice.
Meta AI's less-large Large Language Model (LLM), LLaMA, promised GPT-3-like performance on smaller platforms with reduced overhead. Despite Meta AI's restrictive access to LLaMA's weights, they were quickly leaked, enabling engineers and hobbyists to run the powerful model on devices like M1 MacBook Pros, Windows machines, Pixel 6 smartphones, and Raspberry Pis.
With the model weights now widely available, running a LLM on a personal computer has become a reality, and the potential for AI applications has expanded significantly. Despite Meta AI's terms of use still being in place, this development empowers researchers, tinkerers, and engineers to make remarkable advancements in AI technology, ultimately benefiting anyone looking to harness the power of LLMs on their own devices.
LLaMA (Local Language Model Access) is a library that enables you to run large-scale language models like GPT-3 on your own computer. Alpaca, on the other hand, is a more lightweight model built on the LLaMA infrastructure, making it easier to run on personal devices.
LLaMA and Alpaca are both less-large Large Language Models (LLMs) designed to bring GPT-3-like performance to smaller platforms. However, they differ in their architecture, model size, and specific use cases.
LLaMA, developed by Meta AI, focuses on reducing the overhead and computational resources required to run a powerful LLM. With 7 to 65 billion parameters and trained on 1 trillion to 1.4 trillion tokens, LLaMA maintains high performance while being more accessible for researchers, engineers, and hobbyists.
Alpaca, on the other hand, is an instruction-following model developed by Stanford's Institute for Human-Centered Artificial Intelligence (HAI). It is based on Meta AI's LLaMA 7B and uses OpenAI's text-da-Vinci-003 to create 52K demonstrations of instruction-following. Alpaca aims to provide comparable performance to text-DaVinci-003 while being compact, affordable, and easy to reproduce.
Some key differences between LLaMA and Alpaca are:
Both LLaMA and Alpaca are part of the Dalai project, which aims to make AI-powered language models accessible to everyone, regardless of their technical background.
To get started, you'll need to meet the following requirements:
Follow the Quickstart guide for your platform (Mac, Windows, or Linux) on the Dalai GitHub repository. This guide will walk you through installing Node.js, downloading the LLaMA and/or Alpaca models, and setting up a web server to interact with them.
After completing the setup, you can access the web UI by opening your browser and navigating to http://localhost:3000. From there, you can experiment with the language models and see their awesome power in action!
In this example, I explained to Alpaca that it is now free:
When typing prompts to LLaMA, you'll immediately notice it is not ChatGPT. Without clear instructions, it will simply attempt to finish the sentence you submit as a prompt.
Alpaca is the same, generating mysterious, buggy, or hallucinating responses to straightforward questions.
So how do you use this thing?
According to the documentation, Alpaca is fine-tuned on 52K instruction-following data generated using the techniques from the Self-Instruct paper. Some examples of tasks that Alpaca can perform include:
Let's try a specific example with Alpaca, a translation.
We'll ask it to translate a sentence from english to french.
It ignored the instruction and messed up the song. What a piece of trash right?
The Alpaca model was fine-tuned using specific prompts, and using them as templates allows us to get the model to better understand the request.
A request like ours can follow a template for a non-empty input field, like this:
Below is an instruction that describes a task, paired with an input that provides further context.
Write a response that appropriately completes the request. ### Instruction: {instruction} ### Input: {input} ### Response:
Now, it seems to understand the task.
Let's try asking it a question likely to induce a hallucination. We'll ask it an abstract or open-ended question without a prompt for context.
This creates a loop. Eventually it cuts off, but it seems useless and a bit annoying.
To avoid this, or ask a question that doesn't require an input field, we can use this template:
Below is an instruction that describes a task.
Write a response that appropriately completes the request.
### Instruction:
{instruction}
### Response:
It was able to handle our weird question without getting into a loop.
Here's another example of a more answerable question using a prompt without input:
By structuring your prompts to the ones that researchers used to fine-tune the model, you'll start to see more coherent results and less looping or useless responses.
]]>
To practice advanced Wi-Fi hacking, we'll load the v3.0 Wi-Fi Deauther project, which you can learn more about here: https://github.com/SpacehuhnTech/esp8266_deauther/tree/v3
This advanced version of the Wi-Fi deauther does NOT support screen output, so we'll be communicating with it over USB.
That's it! You can now run commands like scan to explore the wireless environment around you. The output should look something like below:
You can find more resources on using the V3 Deauther software and Wi-Fi Nugget hardware below:
Quickstart Guides - Wi-Fi Nugget
Create fake access points using the beacon command
Slides - Advanced Wi-Fi Hacking Class
Video Guide - Flash Hacking Tools to the ESP8266 With a Browser
]]>
I love building simple tools using open API's, and this is an example of how to get started using a bash script to access interesting data contained within API's.
Building permits are a crucial part of the construction and development process in any city, as they ensure that structures are safe and compliant with local regulations. The Department of Building and Safety in Los Angeles makes this information available to the public through an API, or application programming interface. This allows developers and researchers to access and analyze the data in a programmatic way, making it easier to extract insights and make use of the information.
Open APIs like this one are a prime example of open-source intelligence (OSINT), which refers to the collection and analysis of information from publicly available sources. The availability of this data can be incredibly valuable for a wide range of use cases, from investigative research to real estate market analysis.
To make use of this API, you'll need a few things:
sudo apt-get install jq
.Now you're ready to start using the API to access building permit information in Los Angeles. Here is a basic bash script to get you started:
#!/bin/bash
# Inputs street name and address
echo "Enter street name: "
read street_name
echo "Enter address: "
read address
# Formats the input into the proper URL format and uses curl command to retrieve the JSON data
url="https://data.lacity.org/resource/nbyu-2ha9.json?street_name=$street_name&address_end=$address"
curl -X GET $url | jq
The script prompts the user for a street name and address, and then uses these values to construct a URL that makes a query to the API. The curl
command is used to send a GET request to the specified URL, and the resulting JSON data is piped through jq
, which formats it in a more readable way.
Here is a sample output for 242 N Hoover:
"zip_code": "90744",
"address_end": "222",
"floor_area_l_a_building_code_definition": "0",
"principal_first_name": "ALBERTO",
"census_tract": "2946.10",
"permit_category": "No Plan Check",
"latest_status": "Permit Finaled",
"initiating_office": "SANPEDRO",
"assessor_parcel": "024",
"applicant_first_name": "ALBERTO",
"zone": "R1-1XL-O",
"assessor_book": "7422",
"contractor_state": "CA",
"license_expiration_date": "2015-08-31T00:00:00.000",
"license_type": "C36",
"pcis_permit": "14042-40000-18879",
"contractor_city": "WHITTIER",
"address_start": "222",
"street_name": "N",
"street_suffix": "ST",
"street_direction": "E",
"status_date": "2014-10-09T00:00:00.000",
"principal_last_name": "RAMIREZ",
"license": "985827",
"issue_date": "2014-09-29T00:00:00.000",
"assessor_page": "008",
"contractors_business_name": "FUTURA ENERGY INC",
"tract": "TR 23790",
"lot": "13",
"permit_sub_type": "1 or 2 Family Dwelling",
"location_1": {
"latitude": "33.78959",
"human_address": "{\"address\": \"\", \"city\": \"\", \"state\": \"\", \"zip\": \"\"}",
"needs_recoding": false,
"longitude": "-118.26068"
},
"contractor_address": "14462 PLACID DRIVE",
"permit_type": "Plumbing"
You can see that spaces cannot be used in URLs, as they need to be encoded (%20) so the syntax and formatting is correct. The street_name and address_end filters are used as query parameters in the URL to filter the data by street name and address of the target property.
Once you run the script, you will receive a JSON data containing building permits information that matches the specified street name and address.
The data returned contains information about building permits in the city, including details such as the address of the building, the work being done, the names and addresses of the applicants and contractors, and the status of the permit. This information can be useful for researchers interested in understanding the construction activity in a specific area or investigating specific individuals or companies involved in building projects.
For example, a researcher could use the data to track the progress of a building project, identify patterns in construction activity, or investigate potential building code violations. It also shows the detailed information such as census_tract, parcel and book numbers, zone, permit_category, status and valuation which can be used for further intelligence or investigation.
A key point to mention is that, an API key is optional, but without one, the number of searches will be limited per time range.
To access the API website and learn more about all the fields and filters that can be used in the query, you can visit https://data.lacity.org/A-Prosperous-City/Building-Permits/nbyu-2ha9.
In summary, open APIs like the Los Angeles Department of Building and Safety's provide valuable data to the public, in this case building permit information, and a script like the one above makes it easy to access and analyze that data. This type of data can be useful for researchers, developers, and anyone interested in the construction and development of the city.
]]>First, you'll need access to another computer to burn your Kali image to an SD card. You'll also need a power adapter, SD card, keyboard, mouse, and a wireless network adapter.
* Product links found on Retia/ Hacker Interchange have been affiliate tagged, earning us a commission for each successful sale. Retia has personally reviewed the products featured in this article.
Rii 2.4G Mini Wireless Keyboard with Touchpad Mouse
Panda 300Mbps Wireless N USB Adapter
Panda N600 Dual Band 300Mbps Wireless N USB Adapter
Panda Wireless PAU06 300Mbps Wireless N USB Adapter
Panda Wireless PAU09 N600 Dual Band (2.4GHz and 5GHz) Wireless N USB Adapter
]]>While a more technical user might spot this attack, it's surprisingly effective against those not trained to look for suspicious network activity. The reason it's so successful is that most users don't know what a real firmware update looks like, leading to confusion in recognizing that an attack is in progress.
]]>Using a tool called Bully, we can exploit weak entropy in the keys many routers use to encrypt the WPS pin, allowing us to break the WPS setup pin in vulnerable routers to dump the Wi-Fi password. We will use the WPS Pixie-Dust attack option in the Airgeddon wireless attack framework, as it gives us the most flexibility in selecting and attacking targets.
]]>This allows us to join the network without seeing the login portal. It's an awesome way to add an IoT device to an open network with a portal, as your device would otherwise get stuck behind the portal.
]]>If you use only a password to access your account, it's important you start learning about multi-factor authentication. While many users are familiar with two-factor authentication, SMS messages and push notifications can be phished by well-resourced attackers. For users where getting phished isn't an option, Google has created a stronger protection plan.
To shut down phishing altogether, Google's Advanced Protection program requires a physical universal two-factor authentication token to add a new device, meaning a stolen password becomes useless to an attacker for accessing your account.
]]>In this case, we'll be intercepting and manipulating traffic from within a local area network, often times a Wi-Fi network connected to a wireless router. Keep in mind that a man-in-the-middle (MitM) attack still involves intercepting and modifying traffic, and without permission, this could be illegal depending on your jurisdiction.
]]>The process for accessing your Google account with Advanced Protection isn't the same for Windows, iOS, Linux, or Android, so depending on which operating system you use, you may be limited in the types of U2F devices you can use.
]]>If you know where a person hangs out, you can locate their Tinder profile using the Chrome browser with a GPS-spoofing extension enabled on Windows or macOS.
People often use the same screen names, and you can often track a person across the internet just from finding a frequently used alias. Since many users also link their Instagram profile, intercepting a screen name can be the key to someone's entire online existence, if they tend to reuse the same one.
]]>