profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/nneonneo/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Robert Xiao nneonneo University of British Columbia Vancouver, BC, Canada https://robertxiao.ca HCI researcher, CTF player.

nneonneo/2048-ai 919

AI for the 2048 game

nneonneo/eqgrp-free-file 162

Free sampling of files from the purported Equation Group hack.

nneonneo/ffsend 119

Python client for Firefox Send

nneonneo/direct-handtracking 29

DIRECT - Depth IR Enhanced Contact Tracking

FIGLAB/FastAccel 27

Fast (4 kHz) accelerometer sampling for the LG G Watch.

nneonneo/doublethink 21

Doublethink challenge from DEF CON 2018

nneonneo/fixedint 16

Fixed-width integers for Python

FIGLAB/FastAccel-kernel 5

Custom LG G Watch kernel supporting high-speed accelerometer sampling. See https://github.com/FIGLAB/FastAccel for more details.

nneonneo/bgrep 5

Binary grep with support for sophisticated regexes and grep(1)-like usage

nneonneo/FF-Remote-Control 4

An extension for Firefox that allows one to remote control FF with TCP sockets

PR opened cesena/ghidra2dwarf

Handle Unicode in decompiler output

The decompiler output can legitimately contain Unicode (e.g. Unicode strings). Currently, the script will crash with an error like this:

Traceback (most recent call last):
  File "ghidra2dwarf.py", line 512, in <module>
    write_source()
  File "ghidra2dwarf.py", line 343, in write_source
    src.write("\n".join(decomp_lines))
UnicodeEncodeError: 'ascii' codec can't encode character u'\uefbe' in position 14630: ordinal not in range(128)

This fix makes the output UTF-8, which solves this issue for all valid Unicode characters.

+1 -1

0 comment

1 changed file

pr created time in 4 days

push eventnneonneo/ghidra2dwarf

Robert Xiao

commit sha 13145331c5313ac381e2d1bed681c215deeda2a1

Handle Unicode in decompiler output

view details

push time in 4 days

push eventnneonneo/Il2CppInspector

Katy Coe

commit sha 84a3530556de894742c9d250f2387214f15f129f

PS: Fix two regressions with Unity version wildcards

view details

Katy Coe

commit sha b327fdf341b0241acb4a8c0751f9265015d72c21

C#: Fix indexer name corruption if length was not 4 characters

view details

Katy Coe

commit sha deba3035fccee5b8cebeec22f8a8c49337c6b47e

GUI: Add Select all/none buttons to namespace tree selector

view details

Katy Coe

commit sha 64c7310e2861e48124caa19d014b9db595929970

C++: Add il2cppi_to_string() helpers Refactor other helper names to il2cppi_*

view details

Katy Coe

commit sha d81cf7fef6f56cd9c32db1a9ca3b6c82e1cd5a67

C++: Write IL2CPP metadata version to appdata/il2cpp-metadata-version.h

view details

Katy Coe

commit sha 2c5e34c72442c734608e44c91074d3eef822491b

C++: Output *__TypeInfo double-indirected to avoid having to call init_il2cpp() repeatedly

view details

Katy Coe

commit sha 605734a0206b7425176eb9a85d0ae7cea03e6c56

C++: Add il2cppi_is_initialized() API to scaffolding

view details

Katy Coe

commit sha a548fbb4f6f6e6a415f2717b79fea6c786201ac8

C++: Disable C4359 for 32-bit scaffolding

view details

Katy Coe

commit sha 4a2cc55cb6df4e3bfbc8be1baa5e7d0d62aa5f77

C++: Handle C and C++ versions of enum type definitions correctly (#62)

view details

Katy Coe

commit sha d26b2d91a8bf95638f1a372adc7009e83d17942f

C++: Types with enum fields will be output in a way that preserves alignment (#62)

view details

Katy Coe

commit sha 973c368deabbc4d90c93037ebcd6006dc79bf645

C++: Fix incorrect Debug x86 .sln config (#66)

view details

Katy Coe

commit sha 4261b5b2d1f4201e67bfbaf1ea71826b55050192

Handle split APK packages + CLI support

view details

Katy Coe

commit sha 98bd12e76d4027dee4e6ded1176583bb79945a0c

MachO: Accept file types other than MH_EXECUTE (#67)

view details

Katy Coe

commit sha 49ec360f29746b5bb46bb47197373f288acce144

Don't attempt to map VA to read 0-length arrays (#67)

view details

Katy Coe

commit sha e384ec226ede9b07c3788c25445f6c6d4517ec63

GUI: Support split APKs

view details

Katy Coe

commit sha 0b97a78a8d49c09545642377c58110a10684d42d

GUI: Improve progress updates

view details

Katy Coe

commit sha 8e00e47ccdc3606796e37f84d5db40280d5a1939

C#: Fix regression in indexer name output

view details

Katy Coe

commit sha e511b99dec663209bbc82f5e69740827896880fd

Model: UnmangledBaseName / CSharpSafeName refactoring (#70)

view details

Katy Coe

commit sha 8d015c82711d9af55516ba9b37ef9208688348e7

C#: Sanitize field and event names (#70)

view details

Katy Coe

commit sha fcbfc652044358ae4273c8be2bd065142608bff8

C#: Sanitize type names (#70)

view details

push time in 7 days

pull request commentrust-lang/rust

Avoid spurious "previous iteration of loop" errors

@rustbot label: +A-diagnostics +D-papercut

nneonneo

comment created time in 8 days

pull request commentrust-lang/rust

Avoid spurious "previous iteration of loop" errors

@rustbot +A-diagnostics +D-papercut

nneonneo

comment created time in 8 days

Pull request review commentdjkaty/Il2CppInspector

add declared type namespace to json

 public class JSONMetadata             writer.WriteString("dotNetSignature", method.ToString().ToEscapedString());         } +        private void writeDeclaredTypeNamespace(MethodBase method) {+            writer.WriteString("declared_type_namespace", method.DeclaringType.Namespace);

Best to keep camelCase for the JSON keys for consistency: declaringTypeNamespace

Mythra

comment created time in 12 days

PullRequestReviewEvent

issue commentNationalSecurityAgency/ghidra

Ghidra decompiler crashes when Pcode injection returns an empty array

@toshipiazza Your crash appears to be different; it's caused by this bit of code in Ghidra/Features/Decompiler/src/decompile/cpp/funcdata_op.cc:

void Funcdata::opSetOpcode(PcodeOp *op,OpCode opc)

{
#ifdef OPACTION_DEBUG
  if (opactdbg_active)
    debugModCheck(op);
#endif
  obank.changeOpcode(op, glb->inst[opc] );
}

In this case, it looks like glb->inst[opc] is NULL (probably because it's an undefined opcode?) which results in a null pointer dereference inside PcodeOpBank::changeOpcode (specifically, inside PcodeOp::setOpcode when it attempts to call t_op->getFlags()).

nneonneo

comment created time in 13 days

issue commentNationalSecurityAgency/ghidra

Ghidra decompiler crashes when Pcode injection returns an empty array

Traced the crash to this bit of code in Ghidra/Features/Decompiler/src/decompile/cpp/flow.cc in FlowInfo::doInjection:

  PcodeOp *lastop = xrefControlFlow(iter,startbasic,isfallthru,fc);

  if (startbasic) {		// If the inject code does NOT fall thru
    iter = op->getInsertIter();
    ++iter;			// Mark next op after the call
    if (iter != obank.endDead())
      data.opMarkStartBasic(*iter); // as start of basic block
  }

  if (payload->isIncidentalCopy())
    obank.markIncidentalCopy(firstop, lastop);
  obank.moveSequenceDead(firstop,lastop,op); // Move the injection to right after the call

xrefControlFlow is allowed to return NULL if there are no ops at all, but doInjection does not check that lastop is NULL before passing it to moveSequenceDead; moveSequenceDead immediately accesses lastop->insertiter and segfaults. Should be an easy fix: add a suitable null check to this function. Unfortunately, I am not sure what parts should be guarded with that check.

nneonneo

comment created time in 13 days

push eventnneonneo/rust

Guillaume Gomez

commit sha fbaa4a2a176731538093d2d951d340c47181ab08

Rollup merge of #88109 - inquisitivecrystal:env-docs, r=m-ou-se Fix environment variable getter docs `@RalfJung` pointed out a number of errors and suboptimal choices I made in my documentation for #86183. This PR should (hopefully) fix the problems they've identified.

view details

Guillaume Gomez

commit sha 75c6a9190d5b9793e3cadf5c81b8aa962d4455e7

Rollup merge of #88111 - GuillaumeGomez:background-color-jump-to-def, r=jhpratt Add background-color on clickable definitions in source code Someone suggested to add a decoration on clickable elements in the source code pages: ![Screenshot from 2021-08-17 14-49-39](https://user-images.githubusercontent.com/3050060/129728911-def74f9e-50e2-40d2-b512-e23f1b3d0409.png) ![Screenshot from 2021-08-17 14-49-47](https://user-images.githubusercontent.com/3050060/129728925-14aec500-82ff-4336-955a-4173c769deeb.png) ![Screenshot from 2021-08-17 14-49-52](https://user-images.githubusercontent.com/3050060/129728927-a8a89d7a-e837-4ff5-b094-35be23629d14.png) The idea is to not disturb the reading while telling the reader "you can click on this one", which is why it's not a text decoration. What do you think `@rust-lang/rustdoc` ? r? `@Nemo157`

view details

Guillaume Gomez

commit sha e2271cd42228af817bfbda684b93b7ab20f29f8e

Rollup merge of #88129 - willcrichton:expose-graphviz-modules, r=ecstatic-morse Fix dataflow graphviz bug, make dataflow graphviz modules public I'm working on a rustc plugin that uses the dataflow framework for MIR analysis. I've found the graphviz utilities extremely helpful for debugging. However, I had to fork the compiler to expose them since they're currently private. I would appreciate if they could be made public so I can build against a nightly instead of a custom fork. Specifically, this PR: * Makes public the `rustc_mir::dataflow::framework::graphviz` module. * Makes public the `rustc_mir::util::pretty::write_mir_fn` function. Here's a concrete example of how I'm using the graphviz module: https://github.com/willcrichton/flowistry/blob/97b843b8b06b4004fbb79b5fcfca3e33c7143bc0/src/slicing/mod.rs#L186-L203 Additionally, this PR fixes a small bug in the diff code that incorrectly shows the updated object as the old object. r? `@ecstatic-morse`

view details

Guillaume Gomez

commit sha 9bbb57c6ab4d0693b42e6a050ba9ddf8b857a804

Rollup merge of #88136 - spastorino:fix-test-directory, r=oli-obk Move private_unused.rs test to impl-trait This test was added to fix this issue #55124 which is about impl traits but not related with type alias impl traits. r? `@oli-obk` `@bors` rollup=always

view details

Ellen

commit sha 0d9ea425798d6cb412fc2d85bb409eddee1d4eed

add tests

view details

Vadim Petrochenkov

commit sha 1fdea560d2b756d1372aa7a8db52aec3a0b94f0b

rustc_privacy: Replace `HirId`s and `DefId`s with `LocalDefId`s where possible

view details

bors

commit sha 6d300391ede6de79469670957b508072d132a2a0

Auto merge of #87818 - GuillaumeGomez:anchors-display-rustdoc, r=camelid Fix anchors display in rustdoc Fixes https://github.com/rust-lang/rust/issues/87611 (it simplifies the positioning and fix the background). ![Screenshot from 2021-08-06 16-47-03](https://user-images.githubusercontent.com/3050060/128531105-61d1c21f-4a4d-4d68-aedf-9bfe0332f8ae.png) ![Screenshot from 2021-08-06 16-47-10](https://user-images.githubusercontent.com/3050060/128531109-b2ea8065-10b0-4400-9507-322122e42e78.png) ![Screenshot from 2021-08-06 16-47-14](https://user-images.githubusercontent.com/3050060/128531111-8a17cbdb-29e8-4baa-a0d6-81aa4f6ac6ed.png) r? `@camelid`

view details

bors

commit sha ad1eaffc7e24f497e969c47f400ad20ae383f9aa

Auto merge of #88143 - GuillaumeGomez:rollup-sgh318f, r=GuillaumeGomez Rollup of 10 pull requests Successful merges: - #87818 (Fix anchors display in rustdoc) - #87983 (Use more accurate spans when proposing adding lifetime to item) - #88012 (Change WASI's `RawFd` from `u32` to `c_int` (`i32`).) - #88031 (Make `BuildHasher` object safe) - #88036 (Fix dead code warning when inline const is used in pattern) - #88082 (Take into account jobs number for rustdoc GUI tests) - #88109 (Fix environment variable getter docs) - #88111 (Add background-color on clickable definitions in source code) - #88129 (Fix dataflow graphviz bug, make dataflow graphviz modules public) - #88136 (Move private_unused.rs test to impl-trait) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

view details

Joshua Nelson

commit sha 18f0f242e18349f89716a30a74d56003d01a6af2

Give precedence to `html_root_url` over `--extern-html-root-url` by default, but add a way to opt-in to the previous behavior ## What is an HTML root url? It tells rustdoc where it should link when documentation for a crate is not available locally; for example, when a crate is a dependency of a crate documented with `cargo doc --no-deps`. ## What is the difference between `html_root_url` and `--extern-html-root-url`? Both of these tell rustdoc what the HTML root should be set to. `doc(html_root_url)` is set by the crate author, while `--extern-html-root-url` is set by the person documenting the crate. These are often different. For example, docs.rs uses `--extern-html-root-url https://docs.rs/crate-name/version` to ensure all crates have documentation, even if `html_root_url` is not set. Conversely, crates such as Rocket set `doc(html_root_url = "https://api.rocket.rs")`, because they prefer users to view the documentation on their own site. Crates also set `html_root_url` to ensure they have documentation when building locally when offline. This is unfortunate to require, because it's more work from the library author. It also makes it impossible to distinguish between crates that want to be viewed on a different site (e.g. Rocket) and crates that just want documentation to be visible offline at all (e.g. Tokio). I have authored a separate change to the API guidelines to no longer recommend doing this: https://github.com/rust-lang/api-guidelines/pull/230. ## Why change the default? In the past, docs.rs has been the main user of `--extern-html-root-url`. However, it's useful for other projects as well. In particular, Cargo wants to pass it by default when running `--no-deps` (https://github.com/rust-lang/cargo/issues/8296). Unfortunately, for these other use cases, the priority order is inverted. They want to give *precedence* to the URL the crate picks, and only fall back to the `--extern-html-root` if no `html_root_url` is present. That allows passing `--extern-html-root` unconditionally, without having to parse the source code to see what attributes are present. For docs.rs, however, we still want to keep the old behavior, so that all links on docs.rs stay on the site.

view details

bors

commit sha 4968a8bbd19cea8713aabff9b1575ec60e208670

Auto merge of #87986 - Aaron1011:incr-double-panic, r=estebank Prevent double panic when handling incremental fingerprint mismatch When an incremental fingerprint mismatch occurs, we debug-print our `DepNode` and query result. Unfortunately, the debug printing process may cause us to run additional queries, which can result in a re-entrant fingerprint mismatch error. To avoid a double panic, this commit adds a thread-local variable to detect re-entrant calls.

view details

Michael Watzko

commit sha 8049230852676cda16fe4fb443b4e2b99be87cf8

Saturate negative division

view details

Michael Watzko

commit sha 742d450783cb9c9e7faef0f2dc3f09c72f7ff217

Add and use saturating_div instead of impl inside Saturating

view details

Jakub Beránek

commit sha ccd550ee565436b4c9b7f987c19bd3a9111714f1

[rustdoc] Wrap code blocks in <code> tag

view details

Michael Watzko

commit sha 6bb3acab74f9cf4bf3d3b81f0805416cd7b3ee20

Add doctests to and fix saturating_div for signed integer types

view details

Michael Watzko

commit sha a0e61e278057ffa3a6ca1d39fe04bf1569d3cf40

Add saturating_div to unsigned integer types

view details

Michael Watzko

commit sha 5ca6993307c926f1eb1e536bf957620685b31b00

Simplify Div impl for Saturating by using saturating_div

view details

bors

commit sha a9ab2e55395013de116340e4cbfa0bb0263bb658

Auto merge of #88002 - hermitcore:unbox-mutex, r=dtolnay Unbox mutexes, condvars and rwlocks on hermit [RustyHermit](https://github.com/hermitcore/rusty-hermit) provides now movable synchronization primitives and we are able to unbox mutexes and condvars.

view details

Michael Watzko

commit sha 2b5970f993a091ad51624cdbfefee7dd97f65682

Simplify saturating_div

view details

Hirochika Matsumoto

commit sha 8b4e7a47925710db50940cc53638b2b82a308948

Update .mailmap

view details

bors

commit sha 20e92344bc46011de7d8deda2fb49c54ed2a6435

Auto merge of #88023 - devnexen:fbsd_arm64, r=nagisa freebsd arm64 add supported sanitizers.

view details

push time in 13 days

pull request commentrust-lang/rust

Avoid spurious "previous iteration of loop" errors

@estebank (or @wesleywiser, etc.): Could I get some feedback on this PR?

nneonneo

comment created time in 13 days

push eventnneonneo/Il2CppVersions

Jeremy Pritts

commit sha 8c1584905e292ddbfad3abe90a67c3c280d79af4

add new unity versions

view details

Robert Xiao

commit sha a13d233abee83a01210e8cdc9ed0e7cf62572e49

Merge pull request #18 from ds5678/August2021UnityVersions August Unity Versions

view details

push time in 16 days

PR merged nneonneo/Il2CppVersions

August Unity Versions

This pull request adds the Header and API files from the following Unity Versions:

  • 2019.4.30f1
  • 2020.3.16f1
  • 2020.3.17f1
  • 2021.1.17f1
  • 2021.1.18f1
  • 2021.1.19f1
+16015 -12

0 comment

16 changed files

ds5678

pr closed time in 16 days

issue openedNationalSecurityAgency/ghidra

Window focus ordering is broken under macOS

Describe the bug Pressing Cmd+Backquote (Cmd+`) to cycle between windows within Ghidra produces unpredictable or incorrect results, compared with basically any other application.

To Reproduce Steps to reproduce the behavior:

  1. Open Ghidra without a project open
  2. Create a new non-shared project
  3. Without importing anything, open a (blank) CodeBrowser
  4. Click on the project window to focus it
  5. Open another (blank) CodeBrowser
  6. Repeatedly press Cmd+Backquote to "Move focus to the next window" (this is a macOS shortcut; it may vary based on keyboard locale)

Expected behavior The three open windows, "CodeBrowser", "CodeBrowser (2)", and "Ghidra: project" are cycled in some consistent order, for example:

  1. CodeBrowser
  2. CodeBrowser (2)
  3. Project
  4. repeat the cycle

Observed behavior The actual order in which the windows are cycled appears to vary, but the following sequence has been observed:

  1. CodeBrowser
  2. Project
  3. CodeBrowser
  4. CodeBrowser (2)
  5. Project
  6. CodeBrowser (2)
  7. repeat the cycle

Oddly enough, pressing Cmd+Shift+Backquote to cycle windows in the reverse direction works as expected:

  1. CodeBrowser (2)
  2. CodeBrowser
  3. Project
  4. repeat the cycle

Environment (please complete the following information):

  • OS: macOS 11.4
  • Java Version: 11.0.2
  • Ghidra Version: 10.0.2
  • Ghidra Origin: official GitHub release

created time in 17 days

startedgarrettgu10/ghidra-wasm-plugin

started time in 19 days

push eventnneonneo/ghidra-skeleton-language

Robert Xiao

commit sha 474e4ed405418e84b9e593badd1ca933b410894b

Update comments

view details

push time in 19 days

issue openedNationalSecurityAgency/ghidra

Ghidra decompiler incorrectly decompiles jump to instruction containing a Pcode injection

Describe the bug Jumping to an instruction that contains a Pcode callother causes incorrect decompilation, even if the injected Pcode does not affect any relevant registers.

To Reproduce Steps to reproduce the behavior:

  1. Install this skeleton language module, which contains a custom Pcode injection library: https://github.com/nneonneo/ghidra-skeleton-language (see #3389, which uses the same language and library)
  2. Create a new project
  3. Import test/prog1.skeleton - it should automatically load using the Skeleton loader
  4. Open the program and run the default analyses
  5. Open function1 in the decompiler

Expected behavior The correct logic for this function is as follows:

int function1(int param_1)

{
  if (param_1 != 0) {
    if (param_1 == 1) {
      param_1 = 8;
    }
    else {
      param_1 = 3;
    }
  }
  return param_1;
}

Observed behavior The function is instead decompiled to the following:

int function1(int param_1)

{
  if (param_1 != 0) {
    param_1 = 3;
  }
  return param_1;
}

Screenshots Incorrect decompilation:

Screen Shot 2021-09-03 at 12 49 13 AM

Correct decompilation (obtained by commenting out simpleCallOther(); in the slaspec):

Screen Shot 2021-09-03 at 12 50 14 AM

Attachments If applicable, please attach any files that caused problems or log files generated by the software.

Environment (please complete the following information):

  • OS: macOS 11.4
  • Java Version: 11.0.2
  • Ghidra Version: 10.0.2
  • Ghidra Origin: official GitHub release

Additional context The code and language have been significantly simplified from a real test-case, in which Ghidra decompiles a function containing only forward jumps to the following:

undefined4 func(int param1)
{
  if (param1 == 0) {
    return 8;
  }
  do {
  } while( true );
}

I wasn't able to reproduce this exact behaviour in the minimization, but it's probably the same bug since this incorrect decompilation also goes away when I comment out the Pcode injection operations, or have the injections only output NOPs.

The offending Pcode injection class:

public class InjectPayloadSkeletonSimple extends InjectPayloadCallother {

	public InjectPayloadSkeletonSimple(String sourceName) {
		super(sourceName);
	}

	@Override
	public PcodeOp[] getPcode(Program program, InjectContext con) {
		PcodeOpEmitter ops = new PcodeOpEmitter(program, con.baseAddr);

		Address reg1Address = program.getRegister("sp").getAddress();
		Address reg2Address = program.getRegister("r1").getAddress();
		ops.emitCopy(reg1Address, reg2Address, 4);

		return ops.getPcodeOps();
	}
}

Unlike #3389, this is not so straightforward to work around if Pcode injections are required for the opcode to work correctly.

created time in 19 days

issue openedNationalSecurityAgency/ghidra

Ghidra decompiler crashes when Pcode injection returns an empty array

Describe the bug Returning an empty array from a Pcode injection causes the decompiler to crash.

To Reproduce Steps to reproduce the behavior:

  1. Install this skeleton language module, which contains a custom Pcode injection library: https://github.com/nneonneo/ghidra-skeleton-language
  2. Create a new project
  3. Import test/prog1.skeleton - it should automatically load using the Skeleton loader
  4. Open the program and run the default analyses
  5. Open function2 in the decompiler

Expected behavior The function does nothing; therefore, the decompilation should resemble

void function0()
{
  return;
}

Observed behavior The decompiler dies and the following message is shown in the decompiler pane:

Exception while decompiling 12000000: Decompiler process died

No other debugging information is present in the logs.

Screenshots Screen Shot 2021-09-03 at 12 44 15 AM

Attachments If applicable, please attach any files that caused problems or log files generated by the software.

Environment (please complete the following information):

  • OS: macOS 11.4
  • Java Version: 11.0.2
  • Ghidra Version: 10.0.2
  • Ghidra Origin: official GitHub release

Additional context The offending Pcode injection class:

public class InjectPayloadSkeletonEmpty extends InjectPayloadCallother {

	public InjectPayloadSkeletonEmpty(String sourceName) {
		super(sourceName);
	}

	@Override
	public PcodeOp[] getPcode(Program program, InjectContext con) {
		return new PcodeOp[0];
	}
}

This issue is fairly easily worked around by always returning at least one PcodeOp, but since there is no explicit NOP PcodeOp, you have to invent one (e.g. r0 = COPY r0).

created time in 19 days

create barnchnneonneo/ghidra-skeleton-language

branch : main

created branch time in 19 days

created repositorynneonneo/ghidra-skeleton-language

Skeleton language module for Ghidra

created time in 19 days

issue commentNationalSecurityAgency/ghidra

PcodeSyntaxTree.getPcodeOps(Address addr) iterator returns pcode operations in an invalid order.

I think I can confirm - I'm seeing the same issue with even very simple programs, and it's affecting some work I'm doing. Steps to reproduce:

  1. Import the attached macOS binary and run auto-analysis (the binary is int main(int argc, char **argv) { printf("%d\n", 42 + argc); })

simple.zip

  1. Run the following Python code (in the interpreter is fine):
from __future__ import print_function
import ghidra.app.script.GhidraScript
from ghidra.util.task import ConsoleTaskMonitor
from ghidra.app.decompiler import DecompileOptions, DecompInterface

func = getGlobalFunctions("entry")[0]
options = DecompileOptions()
monitor = ConsoleTaskMonitor()
ifc = DecompInterface()
ifc.setOptions(options)
ifc.openProgram(getCurrentProgram())
ifc.setSimplificationStyle("decompile")
res = ifc.decompileFunction(func, 60, monitor)
hf = res.getHighFunction()
for op in hf.pcodeOps:
    print(op)

This prints out the following:

(register, 0x0, 4) INT_ADD (register, 0x38, 4) , (const, 0x2a, 4)
(register, 0x30, 8) INT_ZEXT (register, 0x0, 4)
 ---  CALL (ram, 0x100003f92, 8) , (unique, 0x10000031, 8) , (register, 0x30, 8)
(unique, 0x10000031, 8) COPY (const, 0x100003fb2, 8)
(register, 0x0, 8) COPY (const, 0x0, 8)
 ---  RETURN (const, 0x0, 8) , (register, 0x0, 8)

These are obviously out of order: the CALL precedes the COPY which fills in the first argument to printf. Both the CALL and COPY are at address 0x100003f80, but the COPY is order 2, while the CALL is order 3, so the COPY should precede the CALL.

wburton-intel

comment created time in 19 days

issue commentNationalSecurityAgency/ghidra

Unhandled relocation type 286 (0x11e) / R_AARCH64_LDST64_ABS_LO12_NC

Based on https://github.com/llvm-mirror/lld/blob/master/ELF/Arch/AArch64.cpp#L371, I think it will have to be >> 3, not >> 2. Otherwise, it should behave the same as R_AARCH64_LDST32_ABS_LO12_NC.

Ralim

comment created time in 19 days

pull request commentcesena/ghidra2dwarf

macOS support, fix #9, function parameters

Fantastic! I pulled the new changes and tested with macOS Ghidra - works like a charm.

nneonneo

comment created time in 25 days

pull request commentcesena/ghidra2dwarf

macOS support, fix #9, function parameters

Thank you! I understand the concern about the untrusted binary - makes sense. I am looking forward to the rewrite - this project is immensely useful in its current state already.

nneonneo

comment created time in a month

push eventnneonneo/ghidra2dwarf

Robert Xiao

commit sha 8a9a6b89db467016198739a570bf4cdfbffe8c1f

Handle failed decompilation gracefully. The decompiler might fail on certain functions for any number of reasons, and they may not even be functions that matter for debugging purposes. Handle this situation gracefully by outputting an error comment to the decompiled source and skipping line number generation.

view details

Robert Xiao

commit sha 17d5328d593dda8dfb8d240da74ee59fd5488d15

Print output paths on completion

view details

push time in a month

PR opened garrettgu10/ghidra-wasm-plugin

Load data segments

This enables proper analysis of memory references, etc. The code for loading the offset expression is hacky, and in a future commit I'll refactor it to use a reusable expression parser (so we can eventually handle globals, element tables, and other features).

+82 -7

0 comment

5 changed files

pr created time in a month

push eventnneonneo/ghidra-wasm-plugin

Robert Xiao

commit sha d13f3be45cf9bec620522094d0874cce698576db

Load data segments to mem0. This enables proper analysis of memory constants, etc. The code for loading the offset expression is hacky, and in a future commit I'll refactor it to use a reusable expression parser (so we can eventually handle globals, element tables, and other features).

view details

push time in a month

fork nneonneo/ghidra-wasm-plugin

Ghidra Wasm plugin with disassembly and decompilation support

fork in a month

pull request commentDUOLabs333/Photopea-Offline

Add some missing files and fonts

I’d suggest not to, actually: there’s a lot of directories on the website and having them all clutter the root may be confusing. Plus, I think it’s better to keep the website content separate from the bits that are specific to this project, like the updater and README. I wouldn’t be opposed to renaming the directory though, e.g. to “www” or “html”.

It’s simple enough to launch the web server at the correct root: python3 -m http.server --directory www.photopea.com 8887 will do it (Python 3.7+).

nneonneo

comment created time in a month

pull request commentDUOLabs333/Photopea-Offline

Add some missing files and fonts

Oh, I didn't even see that. That would have made extracting fonts much easier. Could you revert the deletion of the README though?

It looks like the relevant comment in DBS.js was actually added very recently, so I don't blame you for missing it :)

nneonneo

comment created time in a month