What is the state of the library? about libpeconv HOT 4 CLOSED

I'm glad to hear you like the idea, yeah, you can customize the error function however you like, add more function parameters or even have multiple error functions conditionally called by single ShowError variadic macro depending on macro parameters and depending on if UNICODE is defined and call separate error functions.

Since you answered my initial questions I'm going to close this issue and let you design error handling to your liking.
Whish you all the best!

from libpeconv.

Hi @metablaster !
Thank you for your interest in libpeconv!
Sorry for the late response, I am pretty busy nowadays.
Answering your questions:

1. At this point libpeconv is getting pretty mature. I use it in several projects, such as PE-sieve, so it is being tested in real life scenarios. Also I had a contributor who did tests including fuzzing, which resulted in few improvements. I also have written tests in the repository, that are deployed on every build, preventing from commits that will cause regression. Yet, I am planning to improve the coverage, and possibly add continuous fuzzing.
2. Yes, I am planning to add some features, for example adding new sections to an existing PE with the help of libpeconv. And maybe adding a new. more flexible API for loading a PE into an existing buffer (so far the loading function is responsible for buffer allocation, which is then returned). Those are just few examples that are coming to my mind right now. I am always open to suggestions from the users, so there is a possibility that I will add something more.
3. Yes. I am planning to add an option to build the library with or without error logging (and also varying verbosity of the logging: INFO/WARNING/DEBUG, etc). This will be enabled/disabled basing on the CMake option. What do you think?

I will probably add more information about it in the project Wiki, and link to it from the README.
Please let me know if you have any more questions. I hope you will enjoy using it.
Have a nice day!

from libpeconv.

Thank you for answering my questions! glad to hear libpeconv is stable and close to future complete.

Error logging granularity (info, warning, debug) would be good addition but I was referring to something else.
For example if you use some Windows API that produces NTSTATUS or Win32 error code then with the help of
FormatMessage API the error code can be formatted to string and in addition with the help of macros it's possible
to pin it to exact source file and line number.

Here is sample pseudo code for you to better explain what I mean, it works for both ANSI and UNICODE,
you decide if it would be useful:

#include <cwchar>
#include <cstring>
#include <string>
#include <Windows.h>

#ifdef UNICODE

// Always appended L
#define EXPAND_WIDE_INNER(x) L ## x
#define EXPAND_WIDE(x) EXPAND_WIDE_INNER(x)

// File name only instead of full path wide version
#define FILE_NAME \
	(std::wcsrchr(EXPAND_WIDE(__FILE__), L'\\') ? \
	std::wcsrchr(EXPAND_WIDE(__FILE__), L'\\') + 1 : \
	EXPAND_WIDE(__FILE__))

// Wide string function name
#define FUNC_NAME __FUNCTIONW__

#else
// Needed this workaround because msvc is not compliant
#define EXPAND(x) x

// File name only instead of full path ANSI version
#define FILE_NAME \
	(std::strrchr(__FILE__, '\\') ? \
	std::strrchr(__FILE__, '\\') + 1 : __FILE__)

// ANSI string function name
#define FUNC_NAME __FUNCTION__

#endif

// Boilerplate macro
#define ERROR_INFO FILE_NAME, FUNC_NAME, __LINE__

// Format error code function (error_code is either NTSTATUS or Win32 error code)
std::wstring FormatErrorMessageW(const DWORD& error_code, DWORD& dwChars, bool ntstatus)
{
	constexpr short msg_buff_size = 512;
	wchar_t message[msg_buff_size];

	if (ntstatus)
	{
		// Format NTSTATUS error code
		dwChars = FormatMessageW(
			FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_IGNORE_INSERTS,
			GetModuleHandleW(L"ntdll"),
			error_code,
			MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),
			message,
			msg_buff_size,
			nullptr);
	}
	else
	{
		// Format Win32 error code
		dwChars = FormatMessageW(
			FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
			nullptr,
			error_code,
			MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),
			message,
			msg_buff_size,
			nullptr);
	}

	return message;
}
// Error function sample
void ShowErrorW(PCWSTR file_name, PCWSTR func_name, int line)
{
	const DWORD error_code = GetLastError();

	DWORD dwChars = 0;
	auto message = FormatErrorMessageW(error_code, dwChars, false);

	// TODO: Use file_name, func_name, line and message variables to construct
	// error message and print it in the console
}

// How to call ShowErrorW function
#define ShowError(...) ShowErrorW(__VA_ARGS__);

Here is sample call to system API and how error handling is currently implemented by libpeconv:

// Sample call to API that produces system error is currently handled as follows
void test()
{
	if (CreateProcessA(/**/) == FALSE)
	{
		std::cerr << "[ERROR] CreateProcess failed, Error = " << std::hex << GetLastError() << "\n";
	}
}

With the help of error formatting this error message can be now replaced with simple macro:

// Can now be replaced with formatted error code
void test()
{
	if (CreateProcessA(/**/) == FALSE)
	{
                // Print formatted error code, source file and line where it occured
		ShowError(ERROR_INFO);
	}
}

The end result in the console is that the following sample error message:

[ERROR] CreateProcess failed, Error = 0x3043405

Is replaced with formatted message and additional info such as source file and line:

Source file: SomeFile.cpp
Function: test
Line: 1028
ErrorType: NTSTATUS
Message: The exact error message is printed here

You might or might not find this useful, I'm just giving a sample code to demonstrate what I mean,
if you would like to perhaps see a more advanced use case with more error information handled feel free to take a look into
my experimental repo here which makes use of this method to format and report errors.

This is what I meant by improving error reporting, because I think formatted error message and source line is more descriptive than error code and custom message.
But the biggest advantage of all is that you don't have write error messages everywhere since system will format codes on it's own and you can customize additional error information in a single place, in the error function.

But again, it's just a suggestion.

from libpeconv.

Thanks for the suggestion! It's a good idea, and I will add something similar. I will prefer to have a single error reported in one line, so maybe something like this:

[ERROR] NTSTATUS at SomeFile.cpp test : 1028 : The exact error message is printed here

from libpeconv.