java.lang.NumberFormatException: For input string: "0x4000000000"

[yanan-sjh]

Describe the bug

I tried to load a trace file generated by afl-qemu-trace in AFL++, but it failed. Here is the detailed error message:

java.lang.NumberFormatException: For input string: "0x4000000000"
java.lang.AssertionError: java.lang.NumberFormatException: For input string: "0x4000000000"
at cartographer.CoverageFile.(CoverageFile.java:137)
at cartographer.CartographerPlugin$2.lambda$actionPerformed$0(CartographerPlugin.java:296)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at cartographer.CartographerPlugin$2.actionPerformed(CartographerPlugin.java:291)
at docking.DockingActionProxy.actionPerformed(DockingActionProxy.java:47)
at docking.MenuBarMenuHandler.lambda$processMenuAction$0(MenuBarMenuHandler.java:60)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.NumberFormatException: For input string: "0x4000000000"
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
at java.base/java.lang.Integer.parseInt(Integer.java:668)
at java.base/java.lang.Integer.parseInt(Integer.java:786)
at cartographer.CoverageFile.parseDrCovFile(CoverageFile.java:197)
at cartographer.CoverageFile.(CoverageFile.java:101)
... 18 more

---

Build Date: 2024-Apr-10 1518 EDT
Ghidra Version: 11.0.3
Java Home: E:\Study\Java\jdk-17
JVM Version: Oracle Corporation 17.0.11
OS: Windows 11 10.0 amd64

Screenshots

[DragonsAshes]

Hello, I've the same bug, did you find a solution ?

[aus10pv]

Hi @yanan-sjh and @DragonsAshes,

Cartographer only supports loading coverage files in DRCOV and EZCOV formats at this time. I'll look into adding support for AFL coverage files in the future.

[DragonsAshes]

Hi @aus10pv From my side, the exception is triggered by adding a coverage file generated by LibAFL. It is supposed to generate coverage file using drcov format.
So you think the problem comes from libafl side when generating coverage file ?

[aus10pv]

I wasn't aware that AFL generated DRCOV files, but that does seem to be the case looking at their qemu_mode readme. Looking closer at drcov.c, it seems that AFL produces coverage files in DRCOV version 2 format, which has the base offset in the 2nd column.

Thank you for the clarification. This is definitely an oversight on my part, and I'll work on implementing DRCOV version 2 support.

[datalocaltmp]

I've create a pull request that addresses this problem - #8 ; it changes the modules to use a long to represent the base rather than an int (which is what you're failing on) as well as adds suppport for all DRCov formats (except DRCov v1 which is missing necessary fields).

If you want to use this extension for Ghidra 11.1 - build and install the version from the pull request (@aus10pv happy to make adjustments to the pull request as you see fit!). Unfortunately I have removed the module base being added in Cartographer and instead opted for some very light manual work. This version requires you adjust your image base address in Ghidra - to do so run the following in the Python scripting window (Window > Python):

currentProgram.setImageBase(currentProgram.getImageBase().getNewAddress(0x0), True)

If you load a coverage file after this adjustment you should see the highlighting apply - hope that helps, cheers!

---

Pre-base adjustment Memory Map:

Adjusting the base with the Python scripting window:

Post-base adjustment Memory Map: