Out of curiosity, I redrew the Supercon Vectorscope badge schematics in KiCad last year. As you might suspect, going from PCB to schematic is opposite to the normal design flow of KiCad and most other PCB design tools. As a result, the schematics and PCB of the Vectorscope project were not really linked. I decided to try it again this year, but with the added goal of making a complete KiCad project. As usual, [Voja] provided a well drawn schematic diagram in PDF and CorelDRAW formats, and a PCB design using Altium’s Circuit Maker format (CSPcbDoc file). And for reference, this year I’m using KiCad v8 versus v7 last year.

Importing into KiCad

This went smoothly. KiCad imports Altium files, as I discovered last year. Converting the graphic lines to traces was easier than before, since the graphical lines are deleted in the conversion process. There was a file organizational quirk, however. I made a new, empty project and imported the Circuit Maker PCB file. It wasn’t obvious at first, but the importing action didn’t make use the new project I had just made. Instead, it created a completely new project in the directory holding the imported Circuit Maker file. This caused a lot of head scratching when I was editing the symbol and footprint library table files, and couldn’t figure out why my edits weren’t being seen by KiCad. I’m not sure what the logic of this is, was an easy fix once you know what’s going on. I simply copied everything from the imported project and pasted it in my new, empty project.

While hardly necessary for this design, you can also import graphics into a KiCad schematic in a similar manner to the PCB editor. First, convert the CorelDRAW file into DXF or SVG — I used InkScape to make an SVG. Next do Import -> Graphics in the Kicad schematic editor. However, you immediately realize that, unlike the PCB editor, the schematic editor doesn’t have any concept of drawing layers. As a work around, you can instead import graphics into a new symbol, and place this symbol on a blank page. I’m not sure how helpful this would be in tracing out schematics in a real world scenario, since I just drew mine from scratch. But it’s worth trying if you have complex schematics.

Note: this didn’t work perfectly, however. For some reason, the text doesn’t survive being imported into KiCad. I attribute this to my poor InkScape skills rather than a shortcoming in KiCad or CorelDRAW. Despite having no text, I put this symbol on its own page in sheet two of the schematic, just for reference to see how it can be done.

Just like last year, the footprints in the Circuit Maker PCB file were imported into KiCad in a seemingly random manner. Some footprints import as expected. Others are imported such that each individual pad is a standalone footprint. This didn’t cause me any problems, since I made all new footprints by modifying standard KiCad ones. But if you wanted to save such a footprint-per-pad part into a single KiCad footprint, it would take a bit more effort to get right.

Recreating Schematics and Parts

After redrawing the schematics, I focused on getting the part footprints sorted out. I did them methodically one by one. The process went as follows for each part:

• Start with the equivalent footprint from a KiCad library
• Duplicate it into a local project library
• Add the text SAO to the footprint name to avoid confusion.
• Position and align the part on the PCB atop the imported footprint
• Note and adjust for any differences — pad size and/or shape, etc.
• Update the part in the project library
• Attach it to the schematic symbols in the usual manner.
• Delete the imported original footprint (can be tricky to select)

Some parts were more interesting than others. For example, the six SAO connectors are placed at various non-obvious angles around the perimeter. I see that [Voja] slipped up once — the angle between connectors 4 and 5 is at a definitely non-oddball angle of 60 degrees.

SAO Angle Difference
#1 326 102 6->1
#2 8 42 1->2
#3 61 53 2->3
#4 118 57 3->4
#5 178 60 4->5
#6 224 46 5->6

With all this complete, the PCB artwork consists of all new footprints but uses the original traces. I needed to tweak a few traces here and there, but hopefully without detracting too much from [Voja]’s style. Speaking of style, for those interested in giving that free-hand look to hand-routed tracks in KiCad, check the options in the Interactive Router Settings menu. Choose the Highlight collisions / Free angle mode and set the PCB grid to a very small value. Free sketch away.

Glitches

I used two photos of the actual board to check when something wasn’t clear. One such puzzle was the 3-pad SMT solder ball jumper. This was shown on the schematic and on the fully assembled PCB, but it was not in the Circuit Maker design files. I assumed that the schematics and photos were the truth, and the PCB artwork was a previous revision. There is a chance that I got it backwards, but it’s an easy to fix if so. Adding the missing jumper took a bit of guesswork regarding the new and adjusted traces, because they were hard to see and/or underneath parts in the photo. This redrawn design may differ slightly in appearance but not in functionality.

DRC checks took a little more iterating than usual, and at one point I did something to break the edge cuts layer. The irregular features on this PCB didn’t help matters, but I eventually got everything cleaned up.

I had some trouble sometimes assigning nets to the traces. If I was lucky, putting the KiCad footprint on top of the traces assigned them their net names. Other times, I had traces which I had to manually assign to a net. This operation seemed to work sporatically, and I couldn’t figure out why. I was missing a mode that I remember from another decade in a PCB tool, maybe PCAD?, where you would first click on a net. Then you just clicked on any number of other items to stitch them into the net. In KiCad it is not that simple, but understandable given the less-frequent need for this functionality.

You may notice the thru hole leads on the 3D render are way too long. Manufacturers provide 3D files describing the part as they are shipped, which reasonably includes the long leads. They are only trimmed at installation. The virtual technician inside KiCad’s 3D viewer works at inhuman speeds, but has had limited training. She can install or remove all through hold or SMT parts on the board, in the blink of an eye. She can reposition eight lamps and change the background color in mere seconds. These are tasks that would occupy a human technician for hours. But she doesn’t know how to trim the leads off of thru hole parts. Maybe that will come in future versions.

Project Libraries

I like to extract all symbols, part footprints, and 3D files into separate project libraries when the design wraps up. KiCad experts will point out that for several versions now this is not necessary. All (or most) of this information is now stored in the design files, alghouth with one exception — the 3D files. Even so, I still feel safer making these project libraries, probably because I understand the process.

KiCad can now do this with a built-in function. See the Export -> Symbols to New Library and Export -> Footprints to New Library in the schematic and PCB editors, respectively. These actions give you the option to additionally change all references in the design to use this new library. This didn’t work completely for me, for reasons unclear. Eventually I just manually edited the sch and pcb file and fixed the library names with a search and replace operation.

Hint: When configuring project libraries in KiCad, I always give them a nickname that begins with a dot. For example, .badge24 or .stumbler. This always puts project libraries at the top of the long list of libraries, and it makes it easier to do manual search and replaces in the design files if needed.

What about 3D files, you say? That isn’t built into KiCad, but have no fear. [Mitja Nemec] has you covered with the Archive 3D Models KiCad plugin. It was trivial to activate and use in KiCad’s Plugin and Content Manager.

All Done

In the end, the design passed all DRCs, and I could run Update PCB from Schematic... without errors. I went out on a limb and immediately placed an order for five PCBs, hoping I hadn’t overlooked something. But it’s only US$9.00 risk. They are on the way from China as I type this.

All the files can be found in this GitHub repo. If you find any errors, raise an issue there. I have not done this procedure for any of the SAO petals, but when I do, I will place a link in the repository.
Schematics showing jumper

Introduction

In May 2020, Bitdefender released a white paper containing a detailed analysis of Mandrake, a sophisticated Android cyber-espionage platform, which had been active in the wild for at least four years.

In April 2024, we discovered a suspicious sample that appeared to be a new version of Mandrake. Ensuing analysis revealed as many as five Mandrake applications, which had been available on Google Play from 2022 to 2024 with more than 32,000 installs in total, while staying undetected by any other vendor. The new samples included new layers of obfuscation and evasion techniques, such as moving malicious functionality to obfuscated native libraries, using certificate pinning for C2 communications, and performing a wide array of tests to check if Mandrake was running on a rooted device or in an emulated environment.

Our findings, in a nutshell, were as follows.

• After a two-year break, the Mandrake Android spyware returned to Google Play and lay low for two years.
• The threat actors have moved the core malicious functionality to native libraries obfuscated with OLLVM.
• Communication with command-and-control servers (C2) uses certificate pinning to prevent capture of SSL traffic.
• Mandrake is equipped with a diverse arsenal of sandbox evasion and anti-analysis techniques.

Kaspersky products detect this threat as
HEUR:Trojan-Spy.AndroidOS.Mandrake.*.

Technical details

Background

The original Mandrake campaign with its two major infection waves, in 2016–2017 and 2018–2020, was analyzed by Bitdefender in May 2020. After the Bitdefender report was published, we discovered one more sample associated with the campaign, which was still available on Google Play.

The Mandrake application from the previous campaign on Google Play

In April 2024, we found a suspicious sample that turned out to be a new version of Mandrake. The main distinguishing feature of the new Mandrake variant was layers of obfuscation designed to bypass Google Play checks and hamper analysis. We discovered five applications containing Mandrake, with more than 32,000 total downloads. All these were published on Google Play in 2022 and remained available for at least a year. The newest app was last updated on March 15, 2024 and removed from Google Play later that month. As at July 2024, none of the apps had been detected as malware by any vendor, according to VirusTotal.

Mandrake samples on VirusTotal

Applications

Mandrake applications on Google Play

We were not able to get the APK file for
com.brnmth.mtrx, but given the developer and publication date, we assume with high confidence that it contained Mandrake spyware.

Application icons

Malware implant

The focus of this report is an application named AirFS, which was offered on Google Play for two years and last updated on March 15, 2024. It had the biggest number of downloads: more than 30,000. The malware was disguised as a file sharing app.

AirFS on Google Play

According to reviews, several users noticed that the app did not work or stole data from their devices.

Application reviews

Infection chain

Like the previous versions of Mandrake described by Bitdefender, applications in the latest campaign work in stages: dropper, loader and core. Unlike the previous campaign where the malicious logic of the first stage (dropper) was found in the application DEX file, the new versions hide all the first-stage malicious activity inside the native library
libopencv_dnn.so, which is harder to analyze and detect than DEX files. This library exports functions to decrypt the next stage (loader) from the assets/raw folder.

Contents of the main APK file

Interestingly, the sample
com.shrp.sght has only two stages, where the loader and core capabilities are combined into one APK file, which the dropper decrypts from its assets.
While in the past Mandrake campaigns we saw different branches (“oxide”, “briar”, “ricinus”, “darkmatter”), the current campaign is related to the “ricinus” branch. The second- and third-stage files are named “ricinus_airfs_3.4.0.9.apk”, “ricinus_dropper_core_airfs_3.4.1.9.apk”, “ricinus_amber_3.3.8.2.apk” and so on.

When the application starts, it loads the native library:

Loading the native library

To make detection harder, the first-stage native library is heavily obfuscated with the OLLVM obfuscator. Its main goal is to decrypt and load the second stage, named “loader“. After unpacking, decrypting and loading into memory the second-stage DEX file, the code calls the method
dex_load and executes the second stage. In this method, the second-stage native library path is added to the class loader, and the second-stage main activity and service start. The application then shows a notification that asks for permission to draw overlays.
When the main service starts, the second-stage native library
libopencv_java3.so is loaded, and the certificate for C2 communications, which is placed in the second-stage assets folder, is decrypted. The treat actors used an IP address for C2 communications, and if the connection could not be established, the malware tried to connect to more domains. After successfully connecting, the app sends information about the device, including the installed applications, mobile network, IP address and unique device ID, to the C2. If the threat actors find their target relevant on the strength of that data, they respond with a command to download and run the “core” component of Mandrake. The app then downloads, decrypts and executes the third stage (core), which contains the main malware functionality.

Second-stage commands:

Third stage commands:

When Mandrake receives a
start_v command, the service starts and loads the specified URL in an application-owned webview with a custom JavaScript interface, which the application uses to manipulate the web page it loads.
While the page is loading, the application establishes a websocket connection and starts taking screenshots of the page at regular intervals, while encoding them to base64 strings and sending these to the C2 server. The attackers can use additional commands to adjust the frame rate and quality. The threat actors call this “vnc_stream”. At the same time, the C2 server can send back control commands that make application execute actions, such as swipe to a given coordinate, change the webview size and resolution, switch between the desktop and mobile page display modes, enable or disable JavaScript execution, change the User Agent, import or export cookies, go back and forward, refresh the loaded page, zoom the loaded page and so on.

When Mandrake receives a
start_i command, it loads a URL in a webview, but instead of initiating a “VNC” stream, the C2 server starts recording the screen and saving the record to a file. The recording process is similar to the “VNC” scenario, but screenshots are saved to a video file. Also in this mode, the application waits until the user enters their credentials on the web page and then collects cookies from the webview.
The
start_a command allows running automated actions in the context of the current page, such as swipe, click, etc. If this is the case, Mandrake downloads automation scenarios from the URL specified in the command options. In this mode, the screen is also recorded.
Screen recordings can be uploaded to the C2 with the
upload_i or upload_d commands.
The main goals of Mandrake are to steal the user’s credentials, and download and execute next-stage malicious applications.

Data decryption methods

Data encryption and decryption logic is similar across different Mandrake stages. In this section, we will describe the second-stage data decryption methods.

The second-stage native library
libopencv_java3.so contains AES-encrypted C2 domains, and keys for configuration data and payload decryption. Encrypted strings are mixed with plain text strings.
To get the length of the string, Mandrake XORs the first three bytes of the encrypted array, then uses the first two bytes of the array as keys for custom XOR encoding.

Strings decryption algorithm

The key and IV for decrypting AES-encrypted data are encoded in the same way, with part of the data additionally XORed with constants.

AES key decryption

Mandrake uses the OpenSSL library for AES decryption, albeit in quite a strange way. The encrypted file is divided into 16-byte blocks, each of these decrypted with AES-CFB128.

The encrypted certificate for C2 communication is located in the
assets/raw folder of the second stage as a file named cart.raw, which is decrypted using the same algorithm.

Installing next-stage applications

When Mandrake gets an
apk command from the C2, it downloads a new separate APK file with an additional module and shows the user a notification that looks like something they would receive from Google Play. The user clicking the notification initiates the installation process.
Android 13 introduced the “Restricted Settings” feature, which prohibits sideloaded applications from directly requesting dangerous permissions. To bypass this feature, Mandrake processes the installation with a “session-based” package installer.

Installing additional applications

Sandbox evasion techniques and environment checks

While the main goal of Mandrake remains unchanged from past campaigns, the code complexity and quantity of the emulation checks have significantly increased in recent versions to prevent the code from being executed in environments operated by malware analysts. However, we were able to bypass these restrictions and discovered the changes described below.

The versions of the malware discovered earlier contained only a basic emulation check routine.

Emulator checks in an older Mandrake version

In the new version, we discovered more checks.

To start with, the threat actors added Frida detection. When the application starts, it loads the first-stage native library
libopencv_dnn.so. The init_array section of this library contains the Frida detector function call. The threat actors used the DetectFrida method. First, it computes the CRC of all libraries, then it starts a Frida detect thread. Every five seconds, it checks that libraries in memory have not been changed. Additionally, it checks for Frida presence by looking for specific thread and pipe names used by Frida. So, when an analyst tries to use Frida against the application, execution is terminated. Even if you use a custom build of Frida and try to hook a function in the native library, the app detects the code change and terminates.
Next, after collecting device information to make a request for the next stage, the application checks the environment to find out if the device is rooted and if there are analyst tools installed. Unlike some other threat actors who seek to take advantage of root access, Mandrake developers consider a rooted device dangerous, as average users, their targets, do not typically root their phones. First, Mandrake tries to find a su binary, a SuperUser.apk, Busybox or Xposed framework, and Magisk and Saurik Substrate files. Then it checks if the system partition is mounted as read-only. Next, it checks if development settings and ADB are enabled. And finally, it checks for the presence of a Google account and Google Play application on the device.

C2 communication

All C2 communications are maintained via the native part of the applications, using an OpenSSL static compiled library.

To prevent network traffic sniffing, Mandrake uses an encrypted certificate, decrypted from the
assets/raw folder, to secure C2 communications. The client needs to be verified by this certificate, so an attempt to capture SSL traffic results in a handshake failure and a breakdown in communications. Still, any packets sent to the C2 are saved locally for additional AES encryption, so we are able to look at message content. Mandrake uses a custom JSON-like serialization format, the same as in previous campaigns.
Example of a C2 request:
node #1
{
uid "a1c445f10336076b";
request "1000";
data_1 "32|3.1.1|HWLYO-L6735|26202|de||ricinus_airfs_3.4.0.9|0|0|0||0|0|0|0|Europe/Berlin||180|2|1|41|115|0|0|0|0|loader|0|0|secure_environment||0|0|1|0||0|85.214.132.126|0|1|38.6.10-21 [0] [PR] 585796312|0|0|0|0|0|";
data_2 "loader";
dt 1715178379;
next #2;
}
node #2
{
uid "a1c445f10336076b";
request "1010";
data_1 "ricinus_airfs_3.4.0.9";
data_2 "";
dt 1715178377;
next #3;
}
node #3
{
uid "a1c445f10336076b";
request "1003";
data_1 "com.airft.ftrnsfr\n\ncom.android.calendar\n\[redacted]\ncom.android.stk\n\n";
data_2 "";
dt 1715178378;
next NULL;
}
Example of a C2 response:
node #1
{
response "a1c445f10336076b";
command "1035";
data_1 "";
data_2 "";
dt "0";
next #2;
}
node #2
{
response "a1c445f10336076b";
command "1022";
data_1 "20";
data_2 "1";
dt "0";
next #3;
}
node #3
{
response "a1c445f10336076b";
command "1027";
data_1 "1";
data_2 "";
dt "0";
next #4;
}
node #4
{
response "a1c445f10336076b";
command "1010";
data_1 "ricinus_dropper_core_airfs_3.4.1.9.apk";
data_2 "60";
dt "0";
next NULL;
}
Mandrake uses opcodes from 1000 to 1058. The same opcode can represent different actions depending on whether it is used for a request or a response. See below for examples of this.

• Request opcode 1000: send device information;
• Request opcode 1003: send list of installed applications;
• Request opcode 1010: send information about the component;
• Response opcode 1002: set contact rate (client-server communication);
• Response opcode 1010: install next-stage APK;
• Response opcode 1011: abort next-stage install;
• Response opcode 1022: request user to allow app to run in background;
• Response opcode 1023: abort request to allow app to run in background;
• Response opcode 1027: change application icon to default or Wi-Fi service icon.

Attribution

Considering the similarities between the current campaign and the previous one, and the fact that the C2 domains are registered in Russia, we assume with high confidence that the threat actor is the same as stated in the Bitdefender’s report.

Victims

The malicious applications on Google Play were available in a wide range of countries. Most of the downloads were from Canada, Germany, Italy, Mexico, Spain, Peru and the UK.

Conclusions

The Mandrake spyware is evolving dynamically, improving its methods of concealment, sandbox evasion and bypassing new defense mechanisms. After the applications of the first campaign stayed undetected for four years, the current campaign lurked in the shadows for two years, while still available for download on Google Play. This highlights the threat actors’ formidable skills, and also that stricter controls for applications before being published in the markets only translate into more sophisticated, harder-to-detect threats sneaking into official app marketplaces.

Indicators of Compromise

File Hashes
141f09c5d8a7af85dde2b7bfe2c89477
1b579842077e0ec75346685ffd689d6e
202b5c0591e1ae09f9021e6aaf5e8a8b
31ae39a7abeea3901a681f847199ed88
33fdfbb1acdc226eb177eb42f3d22db4
3837a06039682ced414a9a7bec7de1ef
3c2c9c6ca906ea6c6d993efd0f2dc40e
494687795592106574edfcdcef27729e
5d77f2f59aade2d1656eb7506bd02cc9
79f8be1e5c050446927d4e4facff279c
7f1805ec0187ddb54a55eabe3e2396f5
8523262a411e4d8db2079ddac8424a98
8dcbed733f5abf9bc5a574de71a3ad53
95d3e26071506c6695a3760b97c91d75
984b336454282e7a0fb62d55edfb890a
a18a0457d0d4833add2dc6eac1b0b323
b4acfaeada60f41f6925628c824bb35e
cb302167c8458e395337771c81d5be62
da1108674eb3f77df2fee10d116cc685
e165cda25ef49c02ed94ab524fafa938
eb595fbcf24f94c329ac0e6ba63fe984
f0ae0c43aca3a474098bd5ca403c3fca

Domains and IPs
45.142.122[.]12
ricinus[.]ru
ricinus-ca[.]ru
ricinus-cb[.]ru
ricinus-cc[.]ru
ricinus[.]su
toxicodendron[.]ru

securelist.com/mandrake-apps-r…

Few types of accidents speak as much to the imagination as those involving nuclear fission. From the unimaginable horrors of the nuclear bombs on Nagasaki and Hiroshima, to the fever-pitch reporting about the accidents at Three Mile Island, Chernobyl and Fukushima, all of these have resulted in many descriptions and visualizations which are merely imaginative flights of fancy, with no connection to physical reality. Due to radiation being invisible with the naked eye and the interpretation of radiation measurements in popular media generally restricted to the harrowing noise from a Geiger counter, the reality of nuclear power accidents in said media has become diluted and often replaced with half-truths and outright lies that feed strongly into fear, uncertainty, and doubt.

Why is it that people are drawn more to nuclear accidents than a disaster like that at Bhopal? What is it that makes the one nuclear bomb on Hiroshima so much more interesting than the firebombing of Tokyo or the flattening of Dresden? Why do we fear nuclear power more than dam failures and the heavy toll of air pollution? If we honestly look at nuclear accidents, it’s clear that invariably the panic afterwards did more damage than the event itself. One might postulate that this is partially due to the sensationalist vibe created around these events, and largely due to a poorly informed public when it comes to topics like nuclear fission and radiation. A situation which is worsened by harmful government policies pertaining to things like disaster response, often inspired by scientifically discredited theories like the Linear No-Threshold (LNT) model which killed so many in the USSR and Japan.

In light of a likely restart of Unit 1 of the Three Mile Island nuclear plant in the near future, it might behoove us to wonder what we might learn from the world’s worst commercial nuclear power disasters. All from the difficult perspective of a world where ideology and hidden agendas do not play a role, as we ask ourselves whether we really should fear the atom.

The TMI PR Disaster

Three Mile Island, including the training center and access road. (Credit: Groupmesa, Wikimedia)
What truly happened at the Three Mile Island (TMI) nuclear plant’s #2 reactor on March 28 of 1979? The technical explanation is that the main feedwater pumps in the secondary, non-nuclear, coolant loop failed, which led to a shutdown of the reactor as a whole. As a pressurized water reactor (PWR), the primary coolant loop is pressurized, the levels of which began to increase due to the failed secondary coolant loop and loss of cooling capacity. This triggered a pressure relief valve, which should have closed again when pressure normalized, but due to a technical malfunction it remained open.

The resulting open valve led to a loss-of-coolant situation in the primary coolant loop that went unnoticed in the control room. Due to missing and conflicting information, the operators undertook improper actions that ultimately led to the core overheating and the fuel rods partially melting. During this process, some radioactive gases escaped via the relief valve into the environment surrounding the plant, mostly xenon and krypton isotopes. The effect of this on the local population was estimated to be at most 1.4 millirem (14 µSv), effectively half of a chest X-ray and a fraction of the average annual natural background levels in the US of 3,100 µSv, or ~1% of the local background radiation.

Ultimately, the #2 reactor was quite damaged, and it was decided to decommission it rather than try to repair the damage. Reactor #1 operated uneventfully until 2019 until it was shut down for economic reasons. The lessons learned from the 1979 accident were pivotal for nuclear safety in the US, and is a big part of why for the past decades, nuclear power in the US has been among the safest sources of power.

Objectively considered, the 1979 TMI accident was a big financial loss for the plant owner and investors, but no physical injuries or worse occurred. The real harm of TMI came not from the accident itself, but from the bungled interaction with the press by the people in charge of the accident response. This is excellently detailed in a documentary created by Kyle Hill, who also contrasts the real accident with the imaginary accident dreamed up in the 4-part Netflix series Meltdown: Three Mile Island.

youtube.com/embed/cL9PsCLJpAA?…

As anti-nuclear groups swooped in on Three Mile Island to amplify their messaging, and panicked citizens as far as hundreds of kilometers away worried about having to evacuate and potential nuclear fallout, or even the plant somehow turning into a nuclear bomb, the federal and local official response was weak and incompetent, further adding to the narrative of a terrible disaster unfolding with unwitting officials unable to prevent the apocalyptic events that would inevitably follow.

The TMI accident didn’t kill or harm anyone, of course. Despite it being assigned an INES 5 rating, it was inarguably less severe than the non-commercial accident at the SL-1 reactor, which killed three and caused massive contamination, albeit in a more remote location. SL-1’s accident was assigned INES 4 on this logarithmic scale. If anything, the only enduring legacy of the TMI Unit 2 accident was the toxic fallout of the PR disaster that still contaminates discourse on nuclear power to this day.

Substituted Soviet Reality

The New Safe Confinement in final position over reactor 4 at Chernobyl Nuclear Power Plant.
The one nuclear disaster that looms above all is of course that of Chernobyl, or rather the Chernobyl Nuclear Power Plant (ChNPP, today the Chornobyl NPP) with its accompanying city of Pripyat. The city of Chernobyl, now Chornobyl, is located some distance from ChNPP in the Chornobyl Exclusion Zone, and unlike Pripyat was not fully abandoned after the events of April 26, 1986 when a complete lack of safety culture in the 1980s USSR combined with a sketchy turbine spin-up experiment using residual core heat culminated in what in hindsight was a very much preventable accident.

With Soviet leadership choosing to override any engineering concerns and technical issues that might be inconvenient to the USSR narrative, issues with the RBMK reactor design were classified as state secrets already years before the ChNPP Unit 4 accident. This left plant staff both uninformed and untrained about what was to come. Yet despite of the horrors of the immediate aftermath of the ChNPP Unit 4 reactor’s steam explosion, graphite fire and subsequent radioactive cloud, the worst harm was caused by the denial by Soviet authorities that anything was wrong, which resulted in delayed evacuations, the lack of distribution of iodine tablets to prevent harm from radioactive iodine-131 isotope, and the consumption of radiologically contaminated milk and other foodstuffs in the surrounding area rather than these being destroyed.

Yet despite the RBMK reactor design as at ChNPP being at best a sketchy hybrid military/commercial reactor, the world’s unquestioned worst nuclear accident led to only a few dozen attributable deaths, mostly among the first responders who were fighting the raging graphite fire in the exposed core when radiation levels from short-lived isotopes like iodine-131 were at their highest. Cases of thyroid cancer likely increased due to the exposure to iodine-131, but it’s hard to quantify exact numbers here, especially amidst the statistical noise of forced evacuations and the resulting stress and substance abuse, as well as the breakup of the USSR only a few years later.

As a comparison, in the US, parts of the populace got regularly exposed to iodine-131 during the 1940s through the 1960s courtesy of nuclear weapons testing, but despite a lack of precautions at the time a causal effect is elusive.

Sadly, when HBO chose to make a series about the ChNPP nuclear accident, it leaned heavily into the sensationalist angle, with many analyses showing just how it plays it fast and loose with the truth to create a more exciting narrative. Despite what the series claims, there was no surge in birth defects, only elective abortions, and no surge in cancer cases.

Today, many people remain jumpy about anything to do with ‘Chernobyl’, leading to panicked headlines in 2021 about a ‘neutron surge’ at the ChNPP, which likely was just due to the New Safe Confinement (NSC) structure above the #4 reactor blocking rainwater intrusion. As water is a neutron moderator, this consequently is merely a logical and totally expected result.

Similarly, when during the 2022 invasion of Ukraine Russian forces rolled heavy equipment into the Chornobyl Exclusion Zone (CEZ), there was again panicked reporting about ‘elevated gamma radiation levels’. Although occupying forces destroyed much of the forensic evidence including much of the sensor network, it’s likely that the high gamma readings observed on the public radiation monitoring dashboard were spoofed or at least invalid values, rather than actual readings.

Ultimately, the CEZ was a thriving tourist attraction until the Russian invasion, with no radiological hazard if you take basic precautions in the worst affected areas. Back in 2019 discussions were already underway to reduce the size of the CEZ due to decreasing background radiation levels. Rather than a monument to the hazards of nuclear power, ChNPP is a testament to its safety even when used by a totalitarian regime whose idea of ‘safety culture’ involves the KGB and vanishings of those lacking in loyalty.

Japanese Unsafety Culture

When in March of 2011 a massive tsunami slammed into the coast of Fukushima prefecture after the 9.0 level Touhoku earthquake, it led to 19,759 deaths, 6,242 injured and 2,553 people missing but presumed killed and vanished with the water back into the ocean. There also were multiple meltdowns at the Fukushima Daiichi nuclear power plant, after the tsunami’s water bypassed the inadequate tsunami defenses and submerged the basement which held the emergency generators.

The reactors all shut down as soon as the earthquake occurred, but required power for their cooling pumps. As external power was cut off and their emergency generators drowned in the basement, the first responders simply had to plug in the backup external power. Unfortunately, this procedure had never been practiced, they could not establish the physical connection, and the cores overheated, resulting in them melting and the corium solidifying in the core catchers. That’s when the lack of hydrogen vents in the spent fuel pools at the top of the buildings resulted in hydrogen – generated by the steam in the spent fuel pools reacting with the zirconium cladding – finding an ignition source and blowing off multiple roofs, spreading parts of the fuel rods on the plant’s terrain.

Some lighter radioactive isotopes were scattered further away from the plant, but ultimately nobody died or suffered injuries from radiation. Despite this, a large exclusion zone was established and thousands of people were evacuated for what turned out to be years. Government reports since 2011 have noted rampant mental health issues among these evacuees, as well as high rates of substance abuse and suicides. Meanwhile many questions have been raised about whether most of the evacuations and the in-progress top soil removal was ever needed.

youtube.com/embed/Z4YsXeX8c7M?…

Multiple cracks were found in the concrete of the plant, which allow for seawater to seep into the reactor buildings. This water consequently has to be pumped out before it is treated with ALPS (Advanced Liquid Processing System), which can remove all radioactive isotopes except tritium, as this is just a form of hydrogen and thus effectively impossible to easily segregate from hydrogen and deuterium.

The treated water has been released back into the ocean, which has led to much international outrage. This despite that the tritium levels in the treated and diluted water (as released) are lower than those of any nuclear plant operating today, and lower than the naturally produced tritium levels from the Earth’s atmosphere.

youtube.com/embed/UwFoOVyB40s?…

Ultimately, it was the botched evacuation and disaster response, per the 2012 Diet report, that led to hundreds if not thousands of needless deaths. The flawed messaging around Fukushima Daiichi brings to mind the PR disaster around TMI Unit 2, with anti-nuclear groups hijacking the conversation and drowning any sensible communication that could have occurred with stress-inducing FUD when a calm and objective approach was needed. Unsurprisingly, the biggest outcome for Japan was the complete restructuring of its nuclear safety model, with the newly formed NRA, based on the US’s NRC, turning a whole new leaf in Japanese safety culture.

Today, many of the nuclear reactors that were shutdown after the 3/11 event are now either already back online, or are in the process of getting the last safety upgrades needed before receiving an operating license from the NRA. Despite middling enthusiasm for nuclear power in Japan, there’s an increase in support along with a move towards new reactor construction.

Radiophobia

Radiophobia is defined as an irrational or excessive fear of ionizing radiation. It leads people to overestimate the health implications of radiation, suspect the presence of radiation where there is none, like microwaved food, and easily miss actual sources of radiation, such as taking an airplane flight, having a granite counter top, the presence of radon gas in the basement, inhaling cigarette smoke, or frequenting certain Brazilian beaches.

The TMI Unit 1 reactor restarting should be met with joy, as it means more reliable (95+% capacity factor) low-carbon electricity and well-paying jobs. The country to have suffered the worst nuclear disaster in history – Ukraine – is finishing construction on two nuclear plants today, and will be constructing many more. Japan is coming to terms with the reality of nuclear power, as it grapples with the economic cost of importing the LNG and coal that have kept its economy going since 2011.

If there is one thing that we can learn from nuclear accidents in this Atomic Age, it is that the fear of the atom has done more harm than respect for it. We can only hope that more people will learn this lesson.