I was trying to run the latest Thaiphoon Burner on Windows 7 and was having no luck. At the time of this guide, the Thaiphoon Burner version was 17.4.1.2 build 0902 Final.

When trying to launch, the first message was:

The kernel mode driver of Thaiphoon Burner is blocked from being installed by Windows operating system or antivirus software. This exception may also occur if you do not have sufficient administrative privileges.

In this case the error message was not relevant, because Windows 7 was a fresh install without a 3rd party antivirus. I was also using the system Administrator account.

After Thaiphoon Burner loaded, a second error message was shown:

Thaiphoon Burner has not detected any SPD EEPROM device! The most possible reasons for this is an unspoported SMBus Controller, your antivirus software or the latest Windows 11 operating system with enabled Smart App Control that blocks Thaiphoon’s drive from being installed.

If this is a permanent error, please disable your antivirus software or refer to the READFIRST.txt file to get more information on this issue.

I reviewed the READFIRST.txt but it did not contain anything about Windows 7, so it was a bit of a dead end.

The next step was to try disabling Windows Defender real-time protection as well as User Account Control.  However, the result was the same.

Then at some point, Windows provided the biggest clue with a message from the Program Compatibility Assistant:

Windows requires a digitally signed driver

A recently installed program tried to install an unsigned driver. This version of Windowws requires all drivers to have a valid digital signature. The driver is unavailable and the program that uses this driver might not work correctly. Uninstall the program or device that uses this driver and check the publisher’s support website to get a digitally signed driver.

Driver: MICSYS IO driver
Service: Thaiphoon Burner Low-level Access Driver
Publisher: MICSYS Technology CO., LTd
Location: C:\Windows\SysWOW64\drivers\TbsbIo64.sys

The solution was to disable the requirement for digitally signed drivers. The steps:

1. Reboot
2. Before the Windows logo, press F8
3. Choose the option for: Disable Driver Signature Enforcement

Once Windows boots with this option enabled, Thaiphoon Burner should now load successfully. Keep in mind this is a temporary solution until the next time the system is restarted.

You might find yourself in a situation where you have an old motherboard based on a phoenixBIOS chip, and you desire to update the BIOS to the latest version.

In this example, I had a Supermicro X7DWE-O.  The motherboard is quite old and BIOS downloads are no longer available. Visiting the Supermicro website below, you are greeted with a message:  The product is archived and no longer in production. Please go to our BIOS List to locate your product BIOS/BMC Firmware/Bundled Software.

https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X7DWE/BIOS

I was able to acquire the BIOS .bin / .rom file (i.e., X7DWE0.B19). However, after entering the BIOS setup on the motherboard I found it had no built in update system.  I also had no DOS flash utility for Phoenix BIOS.

I came across several Supermicro FAQs for motherboards such X7DA8, X7DWA, X7QC3, X7SBE and X7SB4 that mentioned a Phoenix BIOS and related functions:

https://www.supermicro.com/support/faqs/faq.cfm?faq=760

https://www.supermicro.com/support/faqs/faq.cfm?faq=5039

https://www.supermicro.org.cn/support/faqs/faq.cfm?faq=5860

https://www.supermicro.com/support/faqs/faq.cfm?faq=11444

https://www.supermicro.com/support/faqs/faq.cfm?faq=12512

The steps I used to flash the BIOS:

1. Create a USB bootable DOS disk (I prefer FreeDOS) using Rufus
2. Download the phflash utility
   https://www.mediafire.com/?1b2zr67o1y5v4gr
3. From that download, find and copy phflash16.exe to the bootable disk
4. Use the disk to boot into DOS
5. To update the BIOS, use the command phflash16.exe <filename>. For example:

   phflash16.exe X7DWE0.B19

6. Proceed with the directions shown to flash.

If using Microsoft Authenticator, you may receive the following error message when trying to remove an account:

You need to disable backup to delete <account>.

This can happen if you are trying to delete the account that is also acting as the Recovery Account for authenticator backups.  To resolve, go into the Microsoft Authenticator settings.  Find the section titled Backup, then disable backup.  For example, on iOS this will be via iCloud Backup.

It will then ask whether you want to delete your backup:  You will no longer be able to recover your accounts.

Click OK. You will receive confirmation that Backup successfully deleted with a Cancel button.

Go back to the main Authenticator screen. You will now be able to delete the account from Microsoft Authenticator.

One case study involved an Ubuntu 20.04 (Focal Fossa) system that was protected with Fail2fan.  However the server was also protected with Cloudflare, so there was some work needed to get the remote IP of the attacker (this topic was covered in another post). If you try to ban the offender’s real IP (not the Cloudflare IP) with that configuration, you may receive messages in the fail2ban.log that look similar to the below:

fail2ban.observer INFO [jail] Found x.x.x.x, bad
fail2ban.actions NOTICE [jail] x.x.x.x already banned

You should also see the ban in iptables:

sudo iptables -L

However with the bans in place, the offending IP can still access the resource. The root cause is because the attack is originating from Cloudflare.

The solution is to ban and unban attacker’s remote IPs using Cloudflare’s API for their firewall.  Fail2ban has a built in actions.d/cloudflare.conf to help with that.   However with the Fail2ban version (0.11.1) available in Ubuntu 20.04 , the action file included was not completely functional, especially on the unban side.  The trick is  replace it (or use an action local file) using the latest action file on GitHub:

https://github.com/fail2ban/fail2ban/blob/master/config/action.d/cloudflare.conf

Duplicate the latest action file, then:

1. Populate cftoken with your Global API key from Cloudflare
2. Populate cfuser with the email address of your Cloudflare account.

Save the new action file (e.g., cloudflare.conf or cloudflare.local).  Before proceeding further, flush out any old bans that may be present in Fail2ban from previous attempts at banning, doing one or more of the following:

sudo fail2ban-client set JAILNAME unbanip x.x.x.x

Once complete, the next step is to update your jail to have the following line (NOTE – if your action file is not called cloudflare.conf or cloudflare.local, change it below accordingly):
action = cloudflare

Save the jail and then reload Fail2ban:

sudo service fail2ban reload

Test to see if the banning works. You can monitor fail2ban in real time using the command:

sudo tail -f /var/log/fail2ban.log

As of today, you can view and manage bans in your Cloudflare account at Websites -> “Your-Site” -> Security -> WAF -> Tools.  Any bans that come in through the API will have a note “Fail2Ban JAILNAME”  under the IP address.

On Ubuntu 20.04 (Focal Fossa) running PHP 8.2, you may run into an issue after installing the latest phpMyAdmin (5.2.1) using the PPA (ppa:phpmyadmin/ppa).

When you try to log in to phpMyAdmin, you will get the following message:

 Error: Unknown named parameter $$dbi

I first found discussion about the issue on Stack Overflow, but neither solutions would result in staying on the PPA:
https://stackoverflow.com/questions/76213404/error-unknown-named-parameter-dbi-in-phpmyadmin-5-2-1

However the issue has been identified by the development team:
https://github.com/phpmyadmin/phpmyadmin/issues/16968
https://github.com/phpmyadmin/phpmyadmin/wiki/DebianUbuntu#known-issues
https://github.com/phpmyadmin/phpmyadmin/issues/18498
https://github.com/symfony/symfony/commit/8e34978e4e2c4bf7dac97e44e904368c4cfb54f8

The quick steps to fix the problem:

1. Edit the file (nano, vi, etc.)

   /usr/share/php/Symfony/Component/DependencyInjection/ContainerBuilder.php

2. Change this line

   $service = null === $r->getConstructor() ? $r->newInstance() : $r->newInstanceArgs($arguments);

   to look as follows:

   $service = null === $r->getConstructor() ? $r->newInstance() : $r->newInstanceArgs(array_values($arguments));

3. Save and close the file.  Refresh the browser (or try to log in again) and you should now have a working phpMyAdmin instance.

If you have a Sprint branded Blackberry phone (in this case a Bold 9930 running OS 7.1) that has an old phone number (MDN) on it, you may find that the number remains even after performing a Security Wipe of the data from the device. However, you can remove easily remove it with a device reset using these steps:

1. From the home screen, press the Send key.
2. Dial ##72786.
3. Tap Continue (Call ##72786)
4. You will receive a prompt: SCRTN will change to factory default value for DSS
5. Choose Continue
6. You will receive another prompt: SCRTN Successful. The device will now reset to apply the necessary changes
7. Click OK
8. The device will restart and the old phone number will have been removed.

On a Blackberry (in this case a Bold 9930 running Blackberry OS 7.1), you can check for forced encryption on the device by going to: Options -> Security -> Encryption.

There you will see a lock symbol illuminated for Device Memory and possibly Media Card as well.

Under Options -> Security -> Password, you may also have some options forced.

You can view all of the policies that are being forced on the device (typically on a company phone) by going to Options -> Security -> Security Status Information -> View IT Policy button.

You may have already tried to remove encryption by wiping the phone via Options -> Security -> Security Wipe. While this may remove data on the device and memory card, it doesn’t remove the IT policies (such as password, encryption, etc.).

To fully reset the phone, you will need to use the Blackberry Desktop Software.  As of 2023 the software carries the same name as the original, but has been repurposed for Blackberry VPN service (https://www.blackberry.com/content/dam/blackberry-com/Documents/pdf/desktop/br-desktop.pdf).   Blackberry phones are no longer supported by the version of the software that is available for download. (https://www.blackberry.com/us/en/support/downloads/notice).

Fortunately, you can still acquire the software that works on either Windows or Mac using the Internet Archive project.  A version of Blackberry Desktop that supports Blackberry OS 7.1 and earlier is available. Software is also available for Blackberry 10 OS (Blackberry Link and Blackberry Blend).

https://archive.org/details/blackberry-desktop-software_202112

You can check the model of phone and also the version of Blackberry OS running on the device by going to Options -> Device -> About Device Versions.   Download the appropriate software from the link above.

For a Bold 9930 you’ll need BlackBerry Desktop software for BlackBerry 7.1 OS and earlier.  

If running Windows 10, use the link above to download:
Desktop Software v7.1.0 B42 (Multilanguage)
710_b042_multilanguage.exe

If on Mac OS, download:
BlackBerry Mac Desktop Software v2.4.0.18 (Mac OS)
BlackBerry Desktop Software.dmg

Once installed, connect the device to the computer (in this case using a micro USB cable) and launch the software.  Verify the phone is detected.   In the top right of the software there is a box with a question mark inside of it.  Click it, then choose -> Support resources -> Support tools.  There you will have the option to Reset to Factory Settings.  Click the Reset button.

If it gets interrupted or you receive an error related to the Application Loader, simply repeat the steps.

Once complete, the device should be free of any forced policies.

If you are having trouble getting Q-Flash Plus to work, below are some tips:

1. Use a dedicated USB disk, freshly formatted using FAT32 with Windows explorer.  I’ve read some tutorials that said smaller size thumb drives are better but I had no issues with a Microcenter 32GB flash drive.
2. Copy the latest BIOS file to the root of a flash drive. Make sure you can view file extensions in Windows explorer.   The original BIOS filename should end in a period and 3 digits, (e.g., A520MS2H.15e).    Rename it to GIGABYTE.BIN
3. Connect the flash drive to the correct USB port on the Gigabyte motherboard. The port should be uniquely labeled on the rear I/O shield, such as “BIOS” or “Q-FLASH PLUS”.
4. Attach the 24 pin ATX and 8 Pin CPU cables from the power supply. An installed CPU, GPU and/or memory are optional.
5. Press and release (not hold down) the QFLASH_PLUS button on the motherboard (do not use the regular power button).
6. You should see activity on your flash drive.  If activity stops and the Q-Flash LED does not illuminate, then try steps 2 and 3 again using a different flash drive.
7. When the LED stops, the flash is complete. Remove the flash drive and power cycle the system.

At the very end of an upgrade from version 5 to version 6 of OMV, I received the error

Updating workbench configuration files ...
Restarting engine daemon ...
Errors were encountered while processing:
grub-pc
W: --force-yes is deprecated, use one of the options starting with --allow instead.
E: Sub-process /usr/bin/dpkg returned an error code (1)

To finish the install, the solution is to simply run this command:

sudo dpkg --configure -a

I had an unclean shutdown of OMV and when it restarted, all of the shares were no longer accessible.

Also when rebooting OMV, you may see a console message related to “a start job is running for /dev/disk/by-label/your-volume-name” that takes many seconds before it will proceed.

Logging into the OMV GUI, the array was completely gone (under RAID Management).  The file system also had a status of “Missing” (under File Systems).

Here are the steps used to restore the array

1. Log in to the OMV console and run the command below to get the name of the array (e.g., md0) and a list of drives contained within it (e.g., sda, sdb, etc.).

   cat /proc/mdstat

2. Using the name of the array from above (e.g., md0), run this command to get the list of drives that are contained within the array (e.g., /dev/sda, /dev/sdb, etc.)

   mdadm --detail /dev/md0

3. Stop the array

   mdadm --stop /dev/md0

4. Try to manually assemble the array, replacing the letters in the brackets with a list of the last letter of each device (e.g., a, b, etc.)

   mdadm /dev/md0 --assemble /dev/sd[ab]

5. If everything is fine, you should see only a message from mdadm that the array has been started with the specified number of drives.
6. If you receive a message that a device is busy – skipping, then power off the machine completely. Power on and repeat steps 2-4 (be sure to confirm whether any drive letters changed).
7. In the GUI, confirm the array is appearing under RAID Management. It should have a State of clean, resyncing (pending)
   
8. Go to File Systems, select the device that represents the array. Click the Mount button.
9. If everything is fine, then after a short time the file system should change status to “Online” and the shares will become accessible again.
10. Go back to RAID Management and confirm the State of the array is now clean, resyncing.