.exe import error: Specified length extends beyond file bytes length

Describe the bug

I’m attempting to import an old Win95 game into Ghidra for disassembly, but Ghidra throws an error when importing the portable executable file into a project.

To Reproduce

1. Go to ‘File/Import’
2. Select ‘TM2.EXE’
3. Import the file with default settings in the import menu
4. See error

Expected behavior

Ghidra should successfully import/process the file and allow its disassembly.

Attachments

Error importing file: TM2.EXE
java.lang.IndexOutOfBoundsException: Specified length extends beyond file bytes length
	at ghidra.program.database.mem.MemoryMapDB.checkFileBytesRange(MemoryMapDB.java:589)
	at ghidra.program.database.mem.MemoryMapDB.createInitializedBlock(MemoryMapDB.java:552)
	at ghidra.app.util.MemoryBlockUtils.createInitializedBlock(MemoryBlockUtils.java:225)
	at ghidra.app.util.opinion.PeLoader.processMemoryBlocks(PeLoader.java:657)
	at ghidra.app.util.opinion.PeLoader.load(PeLoader.java:121)
	at ghidra.app.util.opinion.AbstractLibrarySupportLoader.doLoad(AbstractLibrarySupportLoader.java:346)
	at ghidra.app.util.opinion.AbstractLibrarySupportLoader.loadProgram(AbstractLibrarySupportLoader.java:83)
	at ghidra.app.util.opinion.AbstractProgramLoader.load(AbstractProgramLoader.java:112)
	at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:401)
	at ghidra.plugin.importer.ImporterDialog.lambda$okCallback$7(ImporterDialog.java:351)
	at ghidra.util.task.TaskLauncher$1.run(TaskLauncher.java:90)
	at ghidra.util.task.Task.monitoredRun(Task.java:126)
	at ghidra.util.task.TaskRunner.lambda$startTaskThread$1(TaskRunner.java:94)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

---------------------------------------------------
Build Date: 2020-Feb-12 1149 EST
Ghidra Version: 9.1.2
Java Home: /usr/lib/jvm/java-11-openjdk-amd64
JVM Version: Private Build 11.0.5
OS: Linux 5.1.16-050116-generic amd64

I know there were previous issues with the same problem on different files, so I’ve enclosed a hexdump of the first 0x400 bytes of the EXE file’s header:

00000000  4d 5a 80 00 01 00 00 00  04 00 00 00 ff ff 00 00  |MZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 70 00 00 00  |............p...|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 74 68  |........!..L.!th|
00000050  69 73 20 69 73 20 61 20  57 69 6e 64 6f 77 73 20  |is is a Windows |
00000060  39 35 20 65 78 65 63 75  74 61 62 6c 65 0d 0a 24  |95 executable..$|
00000070  50 45 00 00 4c 01 06 00  38 38 5a 34 00 00 00 00  |PE..L...88Z4....|
00000080  00 00 00 00 e0 00 82 81  0b 01 02 12 00 1a 0c 00  |................|
00000090  00 aa 00 00 00 c4 79 00  ac 48 0c 00 00 00 01 00  |......y..H......|
000000a0  00 00 0e 00 00 00 40 00  00 00 01 00 00 02 00 00  |......@.........|
000000b0  01 00 0b 00 00 00 00 00  04 00 00 00 00 00 00 00  |................|
000000c0  00 00 a1 00 00 04 00 00  00 00 00 00 02 00 00 00  |................|
000000d0  00 50 00 00 00 50 00 00  00 20 00 00 00 10 00 00  |.P...P... ......|
000000e0  00 00 00 00 10 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 89 00 ff 15 00 00  00 00 8b 00 00 d0 15 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 8a 00 ac c3 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000160  00 00 00 00 00 00 00 00  42 45 47 54 45 58 54 00  |........BEGTEXT.|
00000170  00 00 00 00 00 00 01 00  00 1a 0c 00 00 04 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 20 00 00 60  |............ ..`|
00000190  44 47 52 4f 55 50 00 00  00 00 00 00 00 00 0e 00  |DGROUP..........|
000001a0  00 aa 00 00 00 1e 0c 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 40 00 00 c0  2e 62 73 73 00 00 00 00  |....@....bss....|
000001c0  00 00 00 00 00 00 0f 00  00 c4 79 00 00 00 00 00  |..........y.....|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 80 00 00 c0  |................|
000001e0  2e 69 64 61 74 61 00 00  00 00 00 00 00 00 89 00  |.idata..........|
000001f0  00 16 00 00 00 c8 0c 00  00 00 00 00 00 00 00 00  |................|
00000200  00 00 00 00 40 00 00 c0  2e 72 65 6c 6f 63 00 00  |....@....reloc..|
00000210  00 00 00 00 00 00 8a 00  00 c4 00 00 00 de 0c 00  |................|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 42  |............@..B|
00000230  2e 72 73 72 63 00 00 00  00 00 00 00 00 00 8b 00  |.rsrc...........|
00000240  00 d0 15 00 00 a2 0d 00  00 00 00 00 00 00 00 00  |................|
00000250  00 00 00 00 40 00 00 40  00 00 00 00 00 00 00 00  |....@..@........|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

The file is 2,322,944 bytes in size according to my file explorer.

Environment (please complete the following information):

• OS: Linux Mint 19.2 (kernel version 5.1.16)
• Java Version: OpenJDK 11
• Ghidra Version: 9.1.2

Additional context

This is an old Win95 game I’m trying to reverse engineer, so there should be no obfuscation or anything.

Let me know if any more information is needed! Thanks.

[patope]

I have same problem with an another late 90’s game. I investigated this and found that PeLoader tries to load .bss section as initialized block. Patch below resolved my problem.

diff --git a/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/PeLoader.java b/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/PeLoader.java
index ae17ad4..dad720e 100644
--- a/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/PeLoader.java
+++ b/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/PeLoader.java
@@ -641,8 +641,9 @@
 					SectionFlags.IMAGE_SCN_MEM_EXECUTE.getMask()) != 0x0);
 
 				int rawDataSize = sections[i].getSizeOfRawData();
+				int pointerToRawData = sections[i].getPointerToRawData();
 				virtualSize = sections[i].getVirtualSize();
-				if (rawDataSize != 0) {
+				if (rawDataSize != 0 && pointerToRawData > 0) {
 					int dataSize =
 						((rawDataSize > virtualSize && virtualSize > 0) || rawDataSize < 0)
 								? virtualSize

[ryanmkurtz]

Duplicate of #2496.