/* ========================================== File: frontend\shortcodes\series-shortcode.php ========================================== */ Uncategorized Archives - Gabriel Gonzalez - Cyber Security https://www.gabrielcybersecurity.com/category/uncategorized/ Blending Embedded Security and Development Wed, 22 Apr 2026 21:27:25 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.4 https://i0.wp.com/www.gabrielcybersecurity.com/wp-content/uploads/2024/09/cropped-Logo-Gchip.png?fit=32%2C32&ssl=1 Uncategorized Archives - Gabriel Gonzalez - Cyber Security https://www.gabrielcybersecurity.com/category/uncategorized/ 32 32 228045498 QRNGabri – Quantum RNG https://www.gabrielcybersecurity.com/qrngabri-quantum-rng/?utm_source=rss&utm_medium=rss&utm_campaign=qrngabri-quantum-rng Wed, 22 Apr 2026 21:27:23 +0000 https://www.gabrielcybersecurity.com/?p=258 I’ve built a real Quantum Random Number Generator, and it’s now live. http://www.gabrielcybersecurity.com/QRNG A QRNG is different from a conventional pseudo-random number generator because it does not rely on a deterministic algorithm or an initial seed. Instead, it uses a physical process whose outcome is fundamentally unpredictable. In this case, I used the alpha decay […]

The post QRNGabri – Quantum RNG appeared first on Gabriel Gonzalez - Cyber Security.

]]>
I’ve built a real Quantum Random Number Generator, and it’s now live.

http://www.gabrielcybersecurity.com/QRNG

A QRNG is different from a conventional pseudo-random number generator because it does not rely on a deterministic algorithm or an initial seed. Instead, it uses a physical process whose outcome is fundamentally unpredictable. In this case, I used the alpha decay of Radon-222 as the entropy source. Radioactive decay is a quantum phenomenon: while the statistical behavior of a large number of atoms can be modeled, the exact instant at which a particular nucleus decays cannot be predicted in advance. That makes it a valid source of true randomness.

The approach I took was to use a RadonEye detector to observe decay-related pulse activity and an ESP32-S3 to retrieve that data over BLE. From those pulse counts, the system derives entropy using a Slow-Clock LSB Extraction method. In practical terms, I sample the detector state at fixed intervals, look at the change in pulse count between accepted measurements, and use the least significant bit of that delta as the raw entropy bit. Those bits are then accumulated into random values and sent to the backend, where they can be stored, visualized, and analyzed.

The main drawback of this design is speed. The current setup produces entropy very slowly, at roughly one bit every 10 minutes, which means generating a 16-bit random value takes close to 3 hours. That is obviously not suitable for high-throughput applications, but speed was never the goal here. The interesting part is that the output is tied directly to a real quantum process rather than to a software construction that only simulates randomness.

The system has only been running for about half a day so far, so the observed bias has not had enough time to settle toward a long-term value yet, but the early behavior looks encouraging. The bias currently displayed is the raw bias from the extracted bitstream itself. I have not applied any additional debiasing or whitening technique to the displayed value, so what is shown reflects the direct output of the Slow-Clock LSB Extraction stage.

The post QRNGabri – Quantum RNG appeared first on Gabriel Gonzalez - Cyber Security.

]]>
258
Reverse Engineering Mask ROM https://www.gabrielcybersecurity.com/reverse-engineering-mask-rom/?utm_source=rss&utm_medium=rss&utm_campaign=reverse-engineering-mask-rom Tue, 10 Mar 2026 09:39:05 +0000 https://www.gabrielcybersecurity.com/?p=252 Progressing a bit more on the #Silicon #RE side, I came across the structure used for manufacturing ROM (from the same paper as last time) and how it can affect #reverse #engineering. 1. Types of technology There are four main types of technology, as seen in the first image, depending on how a bit is […]

The post Reverse Engineering Mask ROM appeared first on Gabriel Gonzalez - Cyber Security.

]]>
Progressing a bit more on the #Silicon #RE side, I came across the structure used for manufacturing ROM (from the same paper as last time) and how it can affect #reverse #engineering.

1. Types of technology

There are four main types of technology, as seen in the first image, depending on how a bit is represented:

Active-Layer, Contact-Layer, Metal-Layer and Implant Programming ROMs.

The first three of them (Active-Layer, Contact-Layer, Metal-Layer) all share the fact that a physical construction is used to represent a bit:

Active-Layer: transistor present or absent

Contact-Layer: presence or absence of a contact connecting the cell

Metal-Layer: metal connection (short circuit) present or absent

2. Which one is harder to Reverse Engineer?

So, according to the information provided in the paper and the images included, second image, these constructions allow to “easily” read the bitstream using an optical microscope.

On the other hand, implant programming ROMs use different doping levels to turn on or off a transitors; during manufacturing additional dopants are selectively introduced to change the electrical behavior of each cell

So, from a #Reverse #Engineering point of view, implant-based systems are harder to analyze, since optical microscopy alone is typically not sufficient to distinguish the cells.

Original paper: https://www.researchgate.net/publication/301317714_A_Survey_on_Chip_to_System_Reverse_Engineering

The post Reverse Engineering Mask ROM appeared first on Gabriel Gonzalez - Cyber Security.

]]>
252
Exploring USB Commands https://www.gabrielcybersecurity.com/exploring-usb-commands/?utm_source=rss&utm_medium=rss&utm_campaign=exploring-usb-commands Fri, 19 Dec 2025 10:05:58 +0000 https://www.gabrielcybersecurity.com/?p=247 If you’ve ever had to explore the interfaces of a USB-enabled device, you know how opaque and undocumented many of them can be. While working on this problem, I put together a small tool I now routinely use to discover commands and better understand how these devices behave. Like most tools born out of real […]

The post Exploring USB Commands appeared first on Gabriel Gonzalez - Cyber Security.

]]>
If you’ve ever had to explore the interfaces of a USB-enabled device, you know how opaque and undocumented many of them can be. While working on this problem, I put together a small tool I now routinely use to discover commands and better understand how these devices behave.

Like most tools born out of real needs, this one is very much a work in progress. So far, I’ve focused on what has proven most useful in practice: brute-force and random command scanning, solid logging, and structured exploration of anything that looks like a valid or interesting command.

To make experimentation safer and more effective, the tool also supports adding known command prefixes and filtering out patterns that tend to trigger unwanted or disruptive behavior on the device.

If you’re interested in USB protocol exploration, reverse engineering, or device fuzzing, you can find the project here:

https://github.com/ggonzalez/CyberSecurity-KnowledgeBase/tree/main/USBScanner

The post Exploring USB Commands appeared first on Gabriel Gonzalez - Cyber Security.

]]>
247
IDA Pro String Heuristics https://www.gabrielcybersecurity.com/ida-pro-string-heuristics/?utm_source=rss&utm_medium=rss&utm_campaign=ida-pro-string-heuristics Fri, 12 Dec 2025 09:43:38 +0000 https://www.gabrielcybersecurity.com/?p=244 Lately I’ve been refining a set of heuristics to cut through the noise when dealing with extracted strings during reverse engineering. Anyone who’s spent enough time staring at an endless list of meaningless bytes knows how quickly your attention drifts. By filtering out the junk up front—using chi-square checks, pattern detection, and a couple of […]

The post IDA Pro String Heuristics appeared first on Gabriel Gonzalez - Cyber Security.

]]>
Lately I’ve been refining a set of heuristics to cut through the noise when dealing with extracted strings during reverse engineering. Anyone who’s spent enough time staring at an endless list of meaningless bytes knows how quickly your attention drifts. By filtering out the junk up front—using chi-square checks, pattern detection, and a couple of lightweight sanity rules—you can surface the strings that actually matter. It’s a small quality-of-life improvement, but one that pays off every time you load a binary.

To push this a bit further, I wrapped those heuristics into an IDA Python script that automatically flags interesting strings for you. Instead of manually scanning through IDA’s string list and squinting at every suspicious entry, the script walks the entire set and marks anything that fits the “useful” profile. It’s a simple idea, but it trims down the friction in early-stage reversing and keeps the focus on what’s relevant. No magic—just a bit of automation around something we all end up doing anyway.

If you want to try it, the script is available here:


https://github.com/ggonzalez/CyberSecurity-KnowledgeBase/blob/main/ReverseEngineering/IDA/set_strings.py

The post IDA Pro String Heuristics appeared first on Gabriel Gonzalez - Cyber Security.

]]>
244
Filtering strings output https://www.gabrielcybersecurity.com/filtering-strings-output/?utm_source=rss&utm_medium=rss&utm_campaign=filtering-strings-output Fri, 05 Dec 2025 11:15:27 +0000 https://www.gabrielcybersecurity.com/?p=242 Tired of scrolling through endless walls of garbage when running strings on a binary? Same here. When you’re doing quick triage before diving into reverse engineering, most of what strings spits out is just useless noise — random bytes that happen to form printable characters but don’t mean anything. To make my life easier, I […]

The post Filtering strings output appeared first on Gabriel Gonzalez - Cyber Security.

]]>
Tired of scrolling through endless walls of garbage when running strings on a binary? Same here. When you’re doing quick triage before diving into reverse engineering, most of what strings spits out is just useless noise — random bytes that happen to form printable characters but don’t mean anything.

To make my life easier, I put together a small set of heuristics (chi-square, simple pattern checks, dictionary matching, etc.) to detect only the strings that actually look like meaningful C text. The idea is to surface the good stuff and hide the junk so you can focus on what matters instead of wasting time scrolling.

Usage is dead simple:





strings firmware.img | python3 ~/bin/strings_english.py

This filters most of the annoying random output and keeps the strings that are likely relevant for analysis. There are two small files involved: the Python script itself, and a lightweight dictionary that helps catch common identifiers like strstr.

https://github.com/ggonzalez/CyberSecurity-KnowledgeBase/blob/main/ReverseEngineering/strings_english.py

https://github.com/ggonzalez/CyberSecurity-KnowledgeBase/blob/main/ReverseEngineering/words_alpha.txt

The post Filtering strings output appeared first on Gabriel Gonzalez - Cyber Security.

]]>
242
Converting code in IDA with a simple script https://www.gabrielcybersecurity.com/converting-code-in-ida-with-a-simple-script/?utm_source=rss&utm_medium=rss&utm_campaign=converting-code-in-ida-with-a-simple-script Thu, 23 Oct 2025 08:40:49 +0000 https://www.gabrielcybersecurity.com/?p=232 The below code is a very efficient and simple way of converting chunks of Bytes to code. This becomes specially handy when analyzing large binaries, specially firmware. The script first asks for the start and end addresses (these are both auto-filled based on the selected address on the disassembly vie and the last address of […]

The post Converting code in IDA with a simple script appeared first on Gabriel Gonzalez - Cyber Security.

]]>
The below code is a very efficient and simple way of converting chunks of Bytes to code. This becomes specially handy when analyzing large binaries, specially firmware.

The script first asks for the start and end addresses (these are both auto-filled based on the selected address on the disassembly vie and the last address of the code segment).

The it automagically starts creating functions and if there are locations where it can’t, it will display the address in the console so by double-clicking it you can go to that address and analyze whether it’s a function or maybe it’s a bunch of data that needs to be manually analyzed.

import ida_kernwin
import idautils
import idaapi
import idc


def make_functions_in_range(start_ea, end_ea):
    ea = start_ea
    failed_addrs = []

    while ea < end_ea:
        if idc.is_unknown(idc.get_full_flags(ea)):
            func_start = ea
            

            res = idc.add_func(func_start)
            print("res", res)

            if not res or idc.get_func_name(func_start) == '':
                failed_addrs.append(func_start)

            ea = idc.next_head(func_start, end_ea)

        else:
            ea += 1

    if failed_addrs:
        print("Could not create function at:")
        for a in failed_addrs:
            tmp = idc.get_wide_word(a)
            # Skip some bytes which are not functions.
            if tmp != 0xBF00:
                print("  - {0:X}".format(a))

    return failed_addrs


def main():
    start = ida_kernwin.ask_addr(get_screen_ea(), "Start address:")
    if start is None:
        return

    end = ida_kernwin.ask_addr(idc.get_segm_end(start), "End address:")
    if end is None:
        return

    failed = make_functions_in_range(start, end)

if __name__ == "__main__":
    main()

The post Converting code in IDA with a simple script appeared first on Gabriel Gonzalez - Cyber Security.

]]>
232
How Attackers Can Target Your VSAT from Any Ground-Level Angle https://www.gabrielcybersecurity.com/how-attackers-can-hijack-your-vsat-from-any-ground-level-angle/?utm_source=rss&utm_medium=rss&utm_campaign=how-attackers-can-hijack-your-vsat-from-any-ground-level-angle Tue, 22 Apr 2025 10:36:43 +0000 https://www.gabrielcybersecurity.com/?p=225 For the last 20 years I have been closely working in the SATCOM industry both helping develop prototypes and securing the most critical systems out there so I am pretty interested in research topics in this area. The recent work by Bisping et al. presents several interesting attack vectors against commercial VSAT satellite modems. The presented […]

The post How Attackers Can Target Your VSAT from Any Ground-Level Angle appeared first on Gabriel Gonzalez - Cyber Security.

]]>
For the last 20 years I have been closely working in the SATCOM industry both helping develop prototypes and securing the most critical systems out there so I am pretty interested in research topics in this area.

The recent work by Bisping et al. presents several interesting attack vectors against commercial VSAT satellite modems. The presented software vulnerabilities alone are great, but I want to personally highlight the demonstrated ability to inject spoofed IP traffic into the modem from unexpected angles relative to the dish. This opens a new path for attack satellite modems from the ground which can be use to target individual assets without any involvement with the head end system or using the satellite as a delivery method.

Before exploring the physical part of the research a brief mention to the issues found and a bit of context:

VSAT Basics

A VSAT (Very Small Aperture Terminal) is a compact satellite earth station composed of an outdoor transceiver and an indoor interface that connects users (e.g., PCs) to a central hub via a satellite in a star topology. All user traffic is relayed through the hub, which manages network operations. Modern VSATs, typically 1.2–3 m dishes operating in C‑, Ku‑, and increasingly Ka‑bands, now support multimegabit bi‑directional data, voice, and video services for enterprise and government applications.

Key Vulnerabilities Identified

  • Malicious Firmware Update: The unauthenticated update mechanism allows arbitrary firmware to be delivered and (CRC permitting) installed.
  • Remote Admin Shell: A buffer‑overflow in the update‑signalization parser yields root shell execution over the air.

Although these software and protocol weaknesses are serious, the real surprise lies in the physical‑layer results—specifically, how off‑axis signal injection can happen from virtually any angle.

Off‑Axis Signal Injection: Angles of Attack

Parabolic VSAT antennas are optimized to receive signals from directly overhead, side‑lobes and back‑lobes still capture off‑axis RF energy. By measuring signal‑to‑noise ratio (SNR) and “acceptance” of injected packets, the study found that in a realworld test with sufficient SDR+BUC power (~9.5 dBm), every angle became viable for injection.

Fig 1. Packet‑injection success rate vs. vertical attack angle (multipath corridor).

These findings underscore that angle‑of‑arrival cannot be relied upon as a sole security boundary, an attacker with an off-the-shelf SDR setup and line of sight to the antenna can breach the link from virtually any direction and exploit vulnerabilities that otherwise would have been only be possible to exploit compromise the head-end system or using the satellite as a delivery channel making the attack easier to detect.

The post How Attackers Can Target Your VSAT from Any Ground-Level Angle appeared first on Gabriel Gonzalez - Cyber Security.

]]>
225
Fault Injection III: Connecting the MAXIM4619 https://www.gabrielcybersecurity.com/fault-injection-iii-connecting-the-maxim4619/?utm_source=rss&utm_medium=rss&utm_campaign=fault-injection-iii-connecting-the-maxim4619 Wed, 12 Mar 2025 23:10:48 +0000 https://www.gabrielcybersecurity.com/?p=219 In my previous post, I detailed some tests into fault injection techniques on the nRF52 family experimenting with crowbar circuits, and ultimately being surprised by the effects of an analog CMOS switch, the MAXIM4619. After observing its higher overvoltage and ringing effects compared to a traditional crowbar circuit, many of you reached out asking how […]

The post Fault Injection III: Connecting the MAXIM4619 appeared first on Gabriel Gonzalez - Cyber Security.

]]>

In my previous post, I detailed some tests into fault injection techniques on the nRF52 family experimenting with crowbar circuits, and ultimately being surprised by the effects of an analog CMOS switch, the MAXIM4619. After observing its higher overvoltage and ringing effects compared to a traditional crowbar circuit, many of you reached out asking how to properly connect the MAXIM4619 in your setups.

The diagram on the left, taken from the datasheet, shows how each pin connects to the various analog CMOS switches implemented by the IC. In addition to the obvious Vcc and GND connections, the diagram displays three different switches, one enable signal used in conjunction with three switch signals labeled A, B, and C.

Each switch has three different connection points: an output (Y, Z, or X) and two additional connections (X0 and X1 for the X switch, Y0 and Y1 for the Y switch, and Z0 and Z1 for the Z switch).

For this example, we will choose the switch in the upper right corner, which consists of X0, X1, X and A.

We will connect the glitching trigger from the ESP32 to the A signal, so each time we want to inject a glitch, it will switch from one position. We also need to Enable all the switches, for that the ENABLE Signal needs to be set to GND.

Then, we will connect X1 to GND, which will create a short to ground when the trigger is injected.

X0 will be left floating, as we do not want any signal going into our glitching point when it is not needed.

Below is a picture showing what this looks like in real life. I hope this helps everyone!

The post Fault Injection III: Connecting the MAXIM4619 appeared first on Gabriel Gonzalez - Cyber Security.

]]>
219