Built artifacts crash upon start on Windows

[nikitalita]

Thanks for updating this utility, I had been trying to edit an award bios and the old version did not work.

Unfortunately, I cannot get this to run at all on Windows. After copying the exes to their respective lib directories:

The 32-bit version crashes with this:

The 64-bit version just silently dies; can't get it to output any logs or other info.

[nikitalita]

For the 32-bit build, dependency walker suggests that libgcc_s_sjlj-1.dll and libstdc++-6.dll being missing is the problem:

seems that other people are running into this problem: https://github.com/libusb/libusb/issues/1049

The suggested solution is to use -static-libgcc -static-libstdc++ when building.

[nikitalita]

As a temporary workaround, I copied those DLLs from the ubuntu ming64-w64 package into the libs dir and now it runs.

However, when loading a BIOS file, it now silently crashes without an error message.

[KOLANICH]

As a temporary workaround, I copied those DLLs from the ubuntu ming64-w64 package into the libs dir and now it runs. The suggested solution is to use -static-libgcc -static-libstdc++ when building.

Yes, it intended that you either have to copy these files or add the flags to run a program standalonely. It is a well-known procedure for everyone using MinGW standard library, one usually learns it after compiling one's first program using it. I have not coded any of the solutions into CMake scripts because the steps are easy enough to do yourself and the decision what exactly must be done is up to the packager. I.e. if you are creating a Conda or a MSYS2 package, all that you need to do is to write the right dependencies, and then no unneeded bloat.

A common approach for Windows programs is that every software product has a copy of most of third-party shared libs in an own dir, it is not very good and causes bloat. There are exceptions though. For its own compiler, Visual Studio, MS supplies redistributable packages software vendors just link to and tell a user to download it and install (or more common no, just to bundle an instaler and run it within installation process). Though some software projects still prefer to vendorize the dlls from them instead. Other exceptions are VISA and OpenCL dlls that are usually installed with drivers.

For MinGW there is no such a thing, because different versions of MinGW have a bit different standard libraries. I.e. if one installs Anaconda and adds in PATH, he ends up with some MinGW redists being in PATH, and it has caused an issue for me once.

The proper solution for this problem would be to encode the compatibility of MinGW redistributables into their file names and manage them via a systemwide package manager. There are not so many package managers and repos for Windows, but there is MSYS2, it uses pacman from Arch, and there is Conda.

However, when loading a BIOS file, it now silently crashes without an error message.

The tool has memory safety issues and can open properly not every BIOS. For example it can crash if the file format is a bit different from the one the software expects.

Also you can try to disable some hardening flags. Open cmake-gui and clear everything from the variables starting with HARDENING_, and then rebuild.

To verify the tool works somehow you can try it on some ancient bioses. I. e. a BIOS from an ASUSTek motherboard from 2001 year. BIOSes from MSI motherboards of the same olso work.

The tool just scans for LHA signatures within the file, then unpacks the blobs into memory. If you only want to unpack BIOS modules, you can use binwalk with the same or even better success.

Also, please make sure that the file with the bios is unpacked from the archive motherboard vendors usually supply it in. Also make sure the BIOS is AWARD/Phoenix-based, not AMI-based.

My initial goal for fixing the building of this tool was ... to have it just built. For me it is mostly needed for studying how it works (I wanted to rewrite it into python in a form of a library and also figure out how the info about loading the modules into memory and their order of execution is stored).

[KOLANICH]

Also, there is no need to fork this repo if you are not going to contribute. I rewrite the history often (because there is no value in preserving mine history), usually when I update the Boilerplate submodule.

[nikitalita]

As a temporary workaround, I copied those DLLs from the ubuntu ming64-w64 package into the libs dir and now it runs. The suggested solution is to use -static-libgcc -static-libstdc++ when building.

Yes, it intended that you either have to copy these files or add the flags to run a program standalonely. It is a well-known procedure for everyone using MinGW standard library, one usually learns it after compiling one's first program using it. I have not coded any of the solutions into CMake scripts because the steps are easy enough to do yourself and the decision what exactly must be done is up to the packager. I.e. if you are creating a Conda or a MSYS2 package, all that you need to do is to write the right dependencies, and then no unneeded bloat.

That isn't the case here. That particular libgcc dll is no longer distributed in MSYS, so there's no real way for windows users to get this. After a half-hour of searching around, I had to just install the mingw-w64 package on an ubuntu system and then copy the DLLs. So, you're going to have to distribute those dlls in the build artifact, or use the static flags.

[KOLANICH]

I had to just install the mingw-w64 package on an ubuntu system and then copy the DLLs.

In fact you have other options:

1. the most obvious and the most recommended one is to install MinGW and build from source. If you are on Windows, MSYS2 is probably the best option.
2. one can download the packages manually and then unpack. 7z does that, but there is an issue. Ubuntu uses zstd compression, so you need a special version of 7zip supporting it, here it is: https://github.com/mcmilk/7-Zip-zstd . You can also use the package from Debian, it uses LZMA and its source is pretty the same as the Ubuntu one's.
3. It is likely that any other dll of the same vesion and exception model will fit, so you can also try to get the libs from other sources, i.e. Fedora.

[nikitalita]

Is it really your intent to make your users either build this from source (which is very much not straight-forward and involves other repositories), or go and hunt for these DLLs? really?

[KOLANICH]

What's your use case?

Do you just want to replace a CPU microcode table or logos? Then it's you better for you to use the original CBROM.

This tool is unofficial and was created by a guy who has no affiliation to Award and no access to their docs or source code. The tool can be doing something wrong and make your PC unstartable to the point you will need a second PC and a flasher (if you don't have a second PC, it is likely you can use your rooted smartphone with a USB host for that, you need a USB flasher supported by flashrom and NDK, then you can try to build flashrom for your phone).

So for any risk-bearing operations I'd have used the original tools by Award. I consider this tool as suitable for research purposes only by now. And the ones doing research in bios hacking are already programmers and likely already have the build tools.