Disclaimer: I am not a medical professional, laymen terms. I collect information for personal consumption below and will keep it updated. Too much noise currently.


  • 26.03.2020: Added Spread and Containment Simulator
  • 27.03.2020: Added tested and proven 3D Prints; Added further national dashboards. Fixed the estimated percentages of asymptomatic infections. Clarified terminology (Symptomatic, Asymptomatic, Infected, Ill). Added "From the horse's mouth" section - on the ground reports.
  • 29.03.2020 : Added details on why the mortality rate is so different from country to country. In Section Statistics.
  • 30.03.2020 : Added Ventilator Pumps Open source designs and information on Disinfecting 3D Prints in the section "What can I do ?" Added interview with Professor Kim Woo-joo from Korea University Guro Hospital in "Videos to watch".
  • 31.03.2020 : Added statistics showing the daily number of cases instead of a logarytmic/cumulative approach in statistics. If you want to see these for your country head over to this dashboard: https://nssac.bii.virginia.edu/covid-19/dashboard/
  • 01.04.2020 : Added COVID-Trends (Thanks to @memgrinder) and CoronaVirus Forecast (Thanks to @GunstickULM) in Statistics.


A striking number of officials can't get their terminology right making some of their statements and statistics void of any meaning hence I will use the following  :
  • SARS-CoV-2 is the name of the particular Coronavirus strain we are seeing now.
  • COVID-19 is the respiratory disease caused by the virus NOT the name of the virus
  • "Infected" = Infected with the virus (Could be symptomatic OR unsymptomatic)
  • "Sick" or "ill" = Infected and suffering from COVID-19 (Symptomatic)
  • Infected does not equal Sick (Symptomatic) 
Problems with the current statistics - a different way to count Infections. Meaningless terminology like counting "healed". Healed from what? COVID-19 ?
Some countries and/or Media only publish cumulative Dashboards. Below you'll find Germany and Luxembourg (both opting for enforced social distancing) - you see indicators that the initiatives work, a flattening of the curve.



3D Prints / "What can I do ?"

From the Horses Mouth

  • NY - 25/03 : https://www.youtube.com/watch?v=bE68xVXf8Kw
    An emergency room doctor in Elmhurst, Queens, gives a rare look inside a hospital at the center of the coronavirus pandemic. “We don’t have the tools that we need.”

Common Symptoms

  • Fever
  • Cough and Respiratory Difficulties
  • Loosing smell or taste <-

Disinfectant DYI:

  • 4 Parts Rubbing Alcohol (Isopropanol) 
  • 1 Part Water
  • 1 Part Citric Acid (smell)
The above kills virii and is nothing else then what is in commercially available disinfectants.

Videos to watch 

A package from Lithuania arrived today that may be interesting for the Infosec Community at large. Arsenijs has finally implemented a theoretical approach to program SD Cards to be temporarily or 
permanently protected from write operations.  Having reliable read-only media can be very usefully in many situations - ranging from offensive to defensive. Implants will no longer suffer from premature SD Card failures, tools like CIRClean can get an additional layer of  tamper-resistance  and forensic operations become cost-effective.

Picture of the SD Card Locker


This device was developed by Karl Lunt back in 2013, then improved by Nephiel in 2014. Arsentijs recently discovered it was never sold or mass-manufactured. 

New in version 2
  • Redesigned the laser-cut case to be thinner, making the "laser-cut case" locker version less bulky. It's also now transparent, except for the middle layer which is transparent orange.
  • Added usage instructions on the bottom of the PCB. 
  • Added a MicroSD slot on the bottom - it allows you to plug a MicroSD card in directly, without using any adapters. 
  • Reinforced the MicroUSB port soldering 
Common Use cases :
  • Make read-only Raspberry Pi SD cards
  • Make virus-resistant LiveCDs (or, rather, LiveSDs) for all your computer maintenance needs
  • Distribute SD cards with promotional materials
  • Forensic research and data recovery (reading from the SD card while preventing all write operations)
  • Test your SD-card-powered products for unexpected behavior (an SD card becoming read-only is a popular failure mode and tends to happen when the card controller detects severe data corruption).
Feature Set of the SD Card Locker

How does it work?

Larger SD cards have a mechanical "write protect" slide switch on the side. However, that switch is useless :
  1. not all readers support it 
  2. the OS can choose to ignore it 
  3. it's not available on  MicroSD cards 
  4. the switch tends to slide accidentally (or fall out of the SD card altogether) when you have no intention of enabling write protection.
The controller chips inside the SD cards (of all sizes, whether full-size or MicroSD) are required by the SD card standard to support a low-level command that locks the card into a read-only mode, preventing any changes - either temporarily (can be switched back to read-write) or even permanently (without a way to ever restore the write capability).

How to order ? 

You can order it from Tindie for only 12USD


  • Look into zRAM (Virtual Swap Compressed in RAM,) to move your swap into RAM Memory, this way you can still swap effectively and even use RAM more efficiently.
  • Use fstab to create directories (Like /etc/log) that only exist in RAM

| ]

This is a living post, that will be updated as I release Advisories.


  • 02.01.2020 - Added Initial List of Advisories
  • 09.01.2020 - Added Bitdefender and Kaspersky Advisories
  • 12.01.2020 - Added Bitdefender Advisories
  • 13.02.2020 - Added TZO-011/012 ESET and AVIRA Advisories
  • 14.02.2020 - Added TZO-015 F-Secure Advisory
  • 17.02.2020 - Released TZO-017 Kaspersky
  • 18.02.2020 - Released TZO-018 Bitdefender
  • 20.02.2020 - Released TZO-019 Avira CVE-2020-9320
  • 24.02.2020 - Released TZO-016 F-SECURE CVE-2020-9342
  • 28.02.2020 - Released TZO-023 Avast Generic Bypass
  • 02.03.2020 - Released TZO-020 Quickheal bypass

List of advisories: 

Where can I find more information about this bug class ?
I wrote a post about this bug class in 2009 and in essence, it still holds true. The threat landscape has shifted and so has the technical capabilities : 

Why now ?

10 years ago I took a look at ways to evade AV/DLP Engine detection by using various techniques and released a metric ton of Advisories. 10 years later after multiple CISO type roles, I wanted to deep dive again and see how far (or not) the AV  industry has reacted to this class of vulnerabilities. [1,2]

These types of evasions are now actively being used in offensive operations [3]. To my surprise with a few exceptions most AV Vendors haven't appropriately reacted and in some cases I even found the very same vulnerabilities that were patched and disclosed years ago.

Worse than that is the fact that some vendors that were very collaborative in 2008/2009 have now started to ignore submissions (until I threaten disclosure) or are trying to argue that generically evading AV detection is not a vulnerability although they patched and released advisories before. Go figure.

I had a lot of back and forth on this matter, for instance, one vendor argued that this could not be called a vulnerability because it would not impact Integrity,  Availability or Confidentiality. Another Vendor argued that this cannot pose a "risk" to their customers because of XYZ (assumptions).

Well, I am reporting vulnerabilities within products, not risks. Furthermore, the impact on the customer is highly dependant on how the customer contextually uses the product. Something the vendor has rarely any insight into. Trying to calculate the expected loss for a hundred thousand customers is something we shouldn't be doing when handling vulnerability notifications, however, a shocking amount of vendors are unable to understand the difference between a vulnerability and a risk.

Even more bothersome to me is how the bug bounty platforms have created a distorted Reporter/Vendor relationship and mostly are executed to the detriment of the customers. I am collecting my experiences and plan to write a blog post about this phenomenon in the future.

I am hoping that I can finally help to eradicate this bug class and I don't have to come back to this 10 years from now.

[1] Our presentation at Hack.lu and CansecWest entitled "The Death of AV Defence in Depth?"

[2] It didn't go unnoticed - Past Press Coverage: Washington Post, InfoworldHeise, Security Focus ... etc.

[3] https://www.bleepingcomputer.com/news/security/specially-crafted-zip-files-used-to-bypass-secure-email-gateways/https://www.techradar.com/news/zip-files-are-being-used-to-bypass-security-gateways

| ]

TLS/SSL Audit 09 release
Getting my hands on code again feels good. I updated TLS/SSL Audit to version 0.9. I improved the custom rudimentary core TLS engine, it remains independent of any open-source or commercial TLS Stack (like openssl) and hence allows it to support any cipher-suite or protocol.


TLS/SSL Audit 0.9

Yahoo! - "Wish list"

Yahoo! announced that it will open up email accounts that are inactive since over a year for registration to anyone that applies. Yahoo! is explaining this as a service to give everyone the chance to an Yahoo ID of their choice.

As a lot of organisations and in particular web applications use e-mail addresses as part of authentication and identity management there are a lot of things that can expose Yahoo! e-mail users to potential risks should their de-activated e-mail address be claimed by somebody with bad intentions.

One plain obvious scenario to model against is that e-mail addresses that are publicly known (or can be found out individually) are subject to "theft" by being claimed by third parties. These can then proceed to reset the passwords of their choice.

Since their announcement Yahoo! is trying to retrofit some sort of security control into their process by trying to get the biggest players (Facebook) to implement a new e-mail header for password verification. For that reason Yahoo! pushed an IETF Draft called "Require-Recipient-Valid-Since Header Field".... mid July 2013.

It is not a Question of "IF"

This is merely an attempt at reducing the amount possible damages that will arise by the recently announced move of Yahoo!. There are so many reasons that e-mail addresses can be let dormant but remain important to the owner, especially if used to registration purposes.

It is also not a theoretical matter, password reset functionality is known to be a weak link and stealing identities and stealing e-mail address as the first hop is common. 

It is not a question of whether this new Yahoo! move will be abused, it will be.

A story from the Past