Project name change?

[davidpolverari]

Hello, @merces and @GoGoOtaku! Debian package maintainer for pev here.

I noticed in the last few days that after pev remained archived for a brief stint while waiting for a new maintainer to step in, now the wait is over and development will be resumed in this repository. That's really good news! Congratulations to everyone involved!

I also noticed the repository name change. My question is: will the project be actually renamed? The reason I ask is because if that is the case, I will start making preparations to rename the package in Debian in a seamless way for the users.

Although in Debian we have standardized procedures for doing exactly this kind of change, I would like to point that pev is already well known in a lot of circles, and is referenced in lots of security-related materials (eg: SANS forensics-related courses, Internet tutorials, etc). Thus, a name change could cause some users some confusion about the continuity of the project. Of course that´s not my call to make, but I only wanted to offer another point of view for your consideration. Whatever the decision is, I will keep packaging it in Debian for the foreseeable future.

Regards,

David.

EDIT: btw, could you please clarify what will be the future situation of libpe? Will its code migrate to the same module as pev/readpe and be fully managed here, or will it continue being a git submodule? Thanks in advance for the help!

[GoGoOtaku]

Hello there.

I will be maintaining this project going forward. These are things that were conceptualized before I joined and we talked about when I took over maintenance.

Let me answer something simple first: From this point on libpe will be maintained from within this repository. This is because the releases are very much tightly coupled and in the worst case can lead to compatibility issues. Personally I also did not like how libpe itself did not have versioned releases which would make it harder for possible CVEs to recommend a minimum secure version. Going forward libpe will be versioned along the rest of the repository. Furthermore libpe will not go away and I am not planning on making it an exclusively static element of any executables. Think of it like how elfutils has libelf within the same repository. The source code is already merged into this repository.

Now to the name change. The idea in the long run is to move to a single executable release and for this readpe would be the most recognizable name. I thought this idea was good as it is more in line with Windows usage from what I remember (been a couple years). While I did not communicate this back yet I did think about making the executable react to it's file name so it could be linked under a different name similar to how BusyBox works. For example ln -s readpe pescan would make pescan the same as calling readpe scan. I wanted to look into issues this might cause or if this is a good idea to begin with first tho.

Anyway I do understand your point of pev being a known name and that a name change or single executable thing might not warrant the confusion. While I will put my foot down for libpe being part of this repository as it is mostly important for developers, I am open for communication when it comes to renaming tho. This is something that I would like to hear @merces thoughts on.

No matter what your concerns are good and I will at least add something about the name change to the README before merging #181
Further I am planning on creating a release 0.82 soon that will not have major changes but mostly just include bugfixes and memory leaks that have been fixed. I will also add a deprecation warning to pepack and pedis as pepack seems to have an outdated use case #136 and pedis does not support common CPU extensions like AVX #177 and other easy to use and more powerful tools exist. That way I can get some feedback if those tools are still indispensable to the community.

[davidpolverari]

Let me answer something simple first: From this point on libpe will be maintained from within this repository. This is because the releases are very much tightly coupled and in the worst case can lead to compatibility issues. Personally I also did not like how libpe itself did not have versioned releases which would make it harder for possible CVEs to recommend a minimum secure version. Going forward libpe will be versioned along the rest of the repository.

Thanks for clarifying the situation! It will make it easier to contribute back some patches back to pev/readpe/libpe from the packaging side, too. btw, I was waiting for the project to become active again to send some patches back, and with that clarification, I will work on that soon.

Furthermore libpe will not go away and I am not planning on making it an exclusively static element of any executables. Think of it like how elfutils has libelf within the same repository. The source code is already merged into this repository.

It is good to know about those plans, too. As libpe was not used by any other package before, it was packaged alongside the executables. Knowing those plans, I think it will make sense for me to keep a single source package, but provide two binary Debian packages, one for readpe and the other for libpe.

Now to the name change. The idea in the long run is to move to a single executable release and for this readpe would be the most recognizable name. I thought this idea was good as it is more in line with Windows usage from what I remember (been a couple years). While I did not communicate this back yet I did think about making the executable react to it's file name so it could be linked under a different name similar to how BusyBox works. For example ln -s readpe pescan would make pescan the same as calling readpe scan. I wanted to look into issues this might cause or if this is a good idea to begin with first tho.

I see. It seems that wouldn't cause any problems for existing users.

Anyway I do understand your point of pev being a known name and that a name change or single executable thing might not warrant the confusion. While I will put my foot down for libpe being part of this repository as it is mostly important for developers, I am open for communication when it comes to renaming tho. This is something that I would like to hear @merces thoughts on.

No matter what your concerns are good and I will at least add something about the name change to the README before merging #181 Further I am planning on creating a release 0.82 soon that will not have major changes but mostly just include bugfixes and memory leaks that have been fixed. I will also add a deprecation warning to pepack and pedis as pepack seems to have an outdated use case #136 and pedis does not support common CPU extensions like AVX #177 and other easy to use and more powerful tools exist. That way I can get some feedback if those tools are still indispensable to the community.

Thanks for the consideration. I will try to contribute the Debian patches back in time for the 0.82 release.

[merces]

First of all, I'd like to thank you both. pev was by far the open source project I spent most of my time with and I'm very happy to see things moving forward.

I'd say readpe is the most important program from current pev toolkit, which makes sense as most of the time you just want to parse the PE structure and see how it looks, so I had this old dream of renaming the project with a few reasons in mind:

• pev stands for "pe version". It was originally a single binary to print the PE version number from VS_VERSIONINFO structure, so the name doesn't seem to fit anymore.
• Everything that pev programs do involves reading a PE file, so readpe seem to fit?
• Users would still have a readpe program. Just a more powerful one.
• If we enumerate all features from current pev programs, IMHO we end up with two groups of features: the outdated ones (disassembly, packer scanning, etc) and the ones that readpe could do as a single binary.

So, my suggestion would be to rename it, but @GoGoOtaku will decide of course.

Now let me take advantage that @davidpolverari opened this issue to give my opinion on the features the current toolkit has. Here are my thoughts:

• cpload is a windows-only tool to debug Control Panel Applets (CPL) files, mostly malware. It doesn't even use libpe. I think it should be removed.

• ofs2rva and rva2ofs are rarely needed as any reverse engineering tool can easily do the math they do.

• pedis is a command line disassembler that depends on udis86 library. Besides the additional dependency, it does not have features present in other disassemblers like symbol recognition, flow analysis, etc. One could just use objdump or other GUI tool that does a much better job. I think it should be removed.

• pehash is a good one as it calculates cryptographic hashes and imphash for PE sections and headers. However, it'd be much better if these hashes are printed as part of readpe output.

• pepack is outdated. I think it should be removed. It just can't compete with software like DIE or exeinfope signatures. I don't like the idea of telling the users a PE file is not packed/protected when in fact it is. I think it should be removed.

• peres can parse and extract resources, which is rare in command line tools. I think its features should be merged to readpe too.

• pescan was good when YARA wasn't a thing. I'm not sure if its functionality should be a) removed, b) included in readpe or c) converted to YARA rules. The latter would require more discussion (should readpe depend on libyara?).

• pesec checks security features for a given PE file and parses and exports certificates. Again, a rare feature in PE parsers. I think its functionality should me included in readpe.

• pestr differs from strings command in one thing: it tells the section a string belongs. This is nice to be honest. I think its functionality should be moved to readpe too.

The new readpe

A few modern command line tools use a subcommand concept that's quite easy to use. For example:

Getting help

readpe help

Printing headers

readpe headers <pefile>          # all headers
readpe headers dos <pefile>      # just DOS/MZ header

Strings (pestr functionality)

readpe strings <pefile>            # all strings
readpe strings ascii -s <pefile>   # just ASCII strings, showing what sections they belong
readpe strings unicode <pefile> 

I wonder how cool would be to have this with autocompletion in Debian, for example.

Thanks!

[davidpolverari]

Hi there!

FYI: I have just uploaded readpe 0.82 to Debian Unstable. It might be soon available to development versions of Ubuntu, Kali and others. Key points from the new packaging:

• pev is now a transitional package; and
• package was split into multiple binaries (readpe, libpe1, libpe1-dev and pev [transitional]).

If you were able to test it, your feedback would be much appreciated.

Regards,
David

[GoGoOtaku]

I know this is kind of late but I tested it and found no issue
(with the installation; obviously there are the two issues you already reported on s390x)

[davidpolverari]

I know this is kind of late but I tested it and found no issue (with the installation; obviously there are the two issues you already reported on s390x)

Oh, thanks a lot for testing it. Unfortunately, readpe still didn't enter testing on Debian, as pev wasn't removed from the archive yet. I have already requested for pev's removal, and after that happens, readpe will be on its way to the next Debian stable release 😃.