/* ==========================================
File: frontend\shortcodes\series-shortcode.php
========================================== */
The post QRNGabri – Quantum RNG appeared first on Gabriel Gonzalez - Cyber Security.
]]>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.
]]>The post Reverse Engineering Mask ROM appeared first on Gabriel Gonzalez - Cyber Security.
]]>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

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.
]]>The post Exploring USB Commands appeared first on Gabriel Gonzalez - Cyber Security.
]]>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.
]]>The post IDA Pro String Heuristics appeared first on Gabriel Gonzalez - Cyber Security.
]]>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:

The post IDA Pro String Heuristics appeared first on Gabriel Gonzalez - Cyber Security.
]]>The post Filtering strings output appeared first on Gabriel Gonzalez - Cyber Security.
]]>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.
The post Filtering strings output appeared first on Gabriel Gonzalez - Cyber Security.
]]>The post Converting code in IDA with a simple script appeared first on Gabriel Gonzalez - Cyber Security.
]]>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.
]]>The post How Attackers Can Target Your VSAT from Any Ground-Level Angle appeared first on Gabriel Gonzalez - Cyber Security.
]]>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:
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.
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.
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.
]]>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.
]]>