mirror/ghidra
1
0
Fork 0
mirror of https://github.com/NationalSecurityAgency/ghidra.git synced 2026-09-28 17:11:11 -09:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/Ghidra_12.2'

Browse Source
This commit is contained in:
Ryan Kurtz
2026-09-11 11:11:53 -04:00
parent 130ea476f4 a9cfc37b4c
commit 3064b743f6
4 changed files with 76 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

125
Ghidra/Configurations/Public_Release/src/global/docs/WhatsNew.md
View File

@@ -29,9 +29,10 @@ Ghidra 12.2 is fully backward compatible with project data from previous release
and data type archives which are created or modified in 12.2 may not be usable by an earlier Ghidra
version.
**IMPORTANT:** Jython support is not supported by default but is included with the release as an extension.
An extra step is required to install it. If you have Ghidra Jython scripts, you must either install the
Jython Extension, convert your scripts to Python and run with PyGhidra, or convert your scripts to JAVA.
**IMPORTANT:** Jython support is not supported by default but is included with the release as an
extension. An extra step is required to install it. If you have Ghidra Jython scripts, you must
either install the Jython Extension, convert your scripts to Python and run with PyGhidra, or
convert your scripts to JAVA.
**IMPORTANT:** Ghidra 12.2 requires, at minimum, JDK 25 to run.
@@ -64,66 +65,62 @@ provides better results.
**NOTE:** Ghidra Server: The Ghidra 12.2 server is compatible with older Ghidra 11.3.2 clients and
later, although the presence of any newer link-files within a repository may not be handled properly
by client versions prior to 12.0, which lack support for the newer storage format. Ghidra 12.1 clients
require Ghidra Server version 12.1/12.0.5 or newer compatible version.
by client versions prior to 12.0, which lack support for the newer storage format. Ghidra 12.1
clients require Ghidra Server version 12.1/12.0.5 or newer compatible version.
**NOTE:** Ghidra Server: Due to security fixes made to Ghidra and the Ghidra Server it is highly
recommended that older installation versions be updated to this latest release. To ensure compatibility,
older client version of Ghidra should also be upgraded.
recommended that older installation versions be updated to this latest release. To ensure
compatibility, older client version of Ghidra should also be upgraded.
## Security Related Fixes
### TLS/SSL Client/Server Changes
Ghidra Server and BSim PostgreSQL Server deployments now highly encourage the use of a CA-signed
server certificate. In addition, Ghidra clients will now enforce server-authentication
for all SSL/TLS connections. This was previously not the case with earlier versions of Ghidra.
This server-authentication also applies to accessing servers accessed via the loopback/localhost
interface, although the property `ghidra.disable.loopback.server.authentication` can be set `true` in
`support/launch.properties` file to disable such local server authentication for testing.
interface, although the property `ghidra.disable.loopback.server.authentication` can be set `true`
in `support/launch.properties` file to disable such local server authentication for testing.
A suitable keystore must be obtained from a CA signing-authority or a self-signed certificate file may
be generated but is not preferred. If needed, the new `server/certTool` command provided with Ghidra
may be used to assist with the keystore request and generation.
A suitable keystore must be obtained from a CA signing-authority or a self-signed certificate file
may be generated but is not preferred. If needed, the new `server/certTool` command provided with
Ghidra may be used to assist with the keystore request and generation.
Each client must ensure that trusted certificates are added to an appropriate trust store.
Ghidra clients now support the use of OS managed certificate trust stores as well as default trust stores
supplied with the Java installation. For Windows and macOS, the system provided `User Certificate
Manager` may be launched from the Ghidra projct window (Edit -> Manage Certificates...). For Unix/Linux
the property `ghidra.unix.default.cacerts` may be optionally specified in `support/launch.properties` to
identify a directory path where unencrypted PEM or DER trusted certificate files may be added. In the case of a
server which uses a self-signed certificate, that certificate would need to be added by each client as a trusted
certificate. Otherwise, all the CA certificates in the server's CA-chain should be added if not already
present.
Ghidra clients now support the use of OS managed certificate trust stores as well as default trust
stores supplied with the Java installation. For Windows and macOS, the system provided
`User Certificate Manager` may be launched from the Ghidra projct window
(Edit -> Manage Certificates...). For Unix/Linux the property `ghidra.unix.default.cacerts` may be
optionally specified in `support/launch.properties` to identify a directory path where unencrypted
PEM or DER trusted certificate files may be added. In the case of a server which uses a self-signed
certificate, that certificate would need to be added by each client as a trusted certificate.
Otherwise, all the CA certificates in the server's CA-chain should be added if not already present.
#### Ghidra Server
If the `server/server.conf` file does not specify a `ghidra.keystore` the server will continue to
auto-generate a temporary self-signed server certificate. However, when this occurs the server will
now only listen for loopback connections on the localhost interface. If remote connections are
required, a proper keystore must be specified. If local access only is acceptable, a Ghidra client
may set the `ghidra.disable.loopback.server.authentication=true` property in the
`support/launch.properties` file with caution. Otherwise, a keystore must be generated.
If the `server/server.conf` file does not specify a `ghidra.keystore` the server will continue to auto-generate
a temporary self-signed server certificate. However, when this occurs the server will now only listen
for loopback connections on the localhost interface. If remote connections are required, a proper
keystore must be specified. If local access only is acceptable, a Ghidra client may set the
`ghidra.disable.loopback.server.authentication=true` property in the `support/launch.properties` file with caution.
Otherwise, a keystore must be generated.
See `server/svrREADME.md or server/svrREADME.html for more details.
See `server/svrREADME.md` or `server/svrREADME.html` for more details.
#### BSim PostgreSQL Server
A BSim PostgreSQL data directory that was configured with a previous version of Ghidra will
not have any new constraints other than client connections now performing server
authentication. If using a self-signed certificate it will need to be added to client
trust stores or a properly signed server certificate/keystore obtained.
A BSim PostgreSQL data directory that was configured with a previous version of Ghidra will not have
any new constraints other than client connections now performing server authentication. If using a
self-signed certificate it will need to be added to client trust stores or a properly signed server
certificate/keystore obtained.
New BSim PostgreSQL deployments should specify a server keystore when initialized. If a keystore
is not specified, the server will use an auto-generated self-signed certificate which will need to
be added to client trust stores. When either a keystore is not specified, or the `trust` authentication
mode is used (`--auth=trust`), the server will be configured to listen to loopback connections on the
localhost interface only.
be added to client trust stores. When either a keystore is not specified, or the `trust`
authentication mode is used (`--auth=trust`), the server will be configured to listen to loopback
connections on the localhost interface only.
See Ghidra GUI Help Content related to BSim Database Configuration and `bsim_ctl` for more details.
### Ghidra Client - Server Allow List
Ghidra client-side applications will now impose the use of a __Server Allow List__ mechanism to
help mitigate unintended server access. This mechanism is currently used to restrict:
@@ -131,30 +128,56 @@ help mitigate unintended server access. This mechanism is currently used to res
will cause that server to be implicitly added to the __Server Allow List__, and
- Clicking on URL links (e.g., http/https) within Ghidra listing comment annotations.
See analyzeHeadlessREADME.md for information related to use of __analyzeHeadless__ and the new
See `analyzeHeadlessREADME.md` for information related to use of __analyzeHeadless__ and the new
__support/updateServerAllowList__ command which can be used to manage the __Server Allow List__
entries.
## BSim PostgreSQL Deployment and Control (bsim_ctl)
Extensive changes have been made to the BSim PostgreSQL control script. New `bsim_ctl` commands
have been added for initializing and reconfiguring a server deployment (`init`, `configure`). Once
a deployment is configured, the following commands are used to manage its state: `start`, `stop`, and
`restart`. In addition, the ability to install as a Linux Service has been added using the commands
`install-service` and `uninstall-service`. A new command `listusers` has also been added to aid with
user management.
a deployment is configured, the following commands are used to manage its state: `start`, `stop`,
and `restart`. In addition, the ability to install as a Linux Service has been added using the
commands `install-service` and `uninstall-service`. A new command `listusers` has also been added to
aid with user management.
When initializing or configuring a PostgreSQL server, `password` authentication mode is now the default
if the `--auth` option is not specified. This differs from previous releases which defaulted to `trust`
authentication. In general, use of `trust` authentication should be avoided.
When initializing or configuring a PostgreSQL server, `password` authentication mode is now the
default if the `--auth` option is not specified. This differs from previous releases which
defaulted to `trust` authentication. In general, use of `trust` authentication should be avoided.
## JDK 25
Ghidra now requires JDK 25 or later to run. Developing against JDK 25 has enabled the use of several
new language features. Some of the new features that Ghidra script and extension developers may now
use are outlined below:
- [Foreign Function & Memory API](https://openjdk.org/jeps/454)
- [Unnamed Variables & Patterns](https://openjdk.org/jeps/456)
- [Markdown Documentation Comments](https://openjdk.org/jeps/467)
- [Class-File API](https://openjdk.org/jeps/484)
- [Stream Gatherers](https://openjdk.org/jeps/485)
- [Scoped Values](https://openjdk.org/jeps/506)
- [Flexible Constructor Bodies](https://openjdk.org/jeps/513)
## Beta support for "Timeless Debugging"
We've completed several enhancements to the Debugger to better support "timeless" or "time-travel"
debugging. This includes a native tool, based on Intel PIN, to capture execution traces in a format
based on TENET. This format has a corresponding importer to load it into Ghidra's Debugger for
further analysis. Three new UI components are included to aide in that analysis:
1. A breakpoint timeline, which displays hits for each breakpoint, color coded by kind (Execute,
Read, Write). Clicking a colored box navigates to the snapshot of the hit.
2. A dynamic call tree, which displays the execution history as a series of function calls, each
subroutine displayed as a child of its run-time parent. Call, Returns, and Tail Calls are
displayed, as observed. Clicking an item navigates to the snapshot of the observed call or
return.
3. A variable viewer, which tabulates all local variables known to the Listing and Decompiler along
with their storage, values, types, and typed-values.
... To Be Continued ...
These views can also be used with live Debugger targets, but with some caveats.
- To record a trace using PIN, see `Ghidra/Debug/Debugger-importers/data/TenetPlusPlus_PinTool`
- To enable the UI components, use **File → Configure** from the Debugger tool and open the
Experimental category.
- To import the Trace, use **File → Import** from the Debugger tool. You must first import the
program image in the usual fashion, if you have not already. When importing the Trace, click
Options and associate it with the image.
## Additional Bug Fixes and Enhancements
Numerous other new features, improvements, and bug fixes are fully listed in the

1
Ghidra/Features/Base/src/main/java/ghidra/app/util/headless/UpdateServerAllowList.java
View File

@@ -122,7 +122,6 @@ public class UpdateServerAllowList implements GhidraLaunchable {
catch (Exception e) {
Msg.error("Exception processing Allow List updates", e);
}
System.out.println("Done");
}
private static void usage(String[] args) {

2
Ghidra/Framework/Project/src/main/java/ghidra/framework/main/EditActionManager.java
View File

@@ -117,7 +117,7 @@ class EditActionManager {
.menuPath(ToolConstants.MENU_EDIT, "Clear Server Allow List...")
.helpLocation(new HelpLocation("FrontEndPlugin", "Clear_Server_Allow_List"))
.onAction(c -> clearServerAllowList())
.enabledWhen(c -> DefaultKeyManagerFactory.getKeyStore() != null)
.enabledWhen(c -> !UrlAllowListManager.getAccessMap().isEmpty())
.enabled(true)
.build();
tool.addAction(clearServerAllowList);

2
README.md
View File

@@ -27,7 +27,7 @@ of how you might be impacted.
## Install
To install an official pre-built multi-platform Ghidra release:
* Install [JDK 21 64-bit][jdk]
* Install [JDK 25 64-bit][jdk]
* Download a Ghidra [release file][releases]
- **NOTE:** The official multi-platform release file is named
`ghidra_<version>_<release>_<date>.zip` which can be found under the "Assets" drop-down.