Re: [NEW] security/ghidra
On Sat, Jun 22, 2019 at 10:26:11PM -0400, Lawrence Teo wrote:
> On Fri, Jun 21, 2019 at 01:48:59AM -0600, Anthony J. Bentley wrote:
> > Lawrence Teo writes:
> > > I used SUBST_CMD to substitute WRKDIR in GHelpBuilder.java, and
> > > accidentally included the substituted value in my diff when I
> > > regenerated patches.
> > >
> > > I have fixed it in this latest diff. Could you please test if it works
> > > for you?
> >
> > Thanks, ghidra and the decompiler work fine now.
>
> Great to hear that it works!
>
> > If any patches are pulled from GitHub, please add a comment with the
> > commit or a link to the pull request.
> >
> > ok bentley@
>
> Thanks for the ok and feedback. I have created a new diff where I have
> added the link to the GitHub pull request as a comment to all the patch
> files that were created/adapted from that pull request. There are no
> changes apart from adding those comments.
>
> Remi, are you ok with this going in?
Here's an updated diff so that it will apply after sthen@'s
PERMIT_PACKAGE_CDROM -> PERMIT_PACKAGE sweep. There are no other
changes.
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile12 Jul 2019 20:49:02 - 1.4
+++ Makefile14 Jul 2019 03:04:19 -
@@ -6,9 +6,13 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -19,30 +23,113 @@ MAINTAINER = Remi Pointel https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
+MASTER_SITES2 =https://repo.maven.apache.org/maven2/
EXTRACT_SUFX = .zip
+ST4_VER = 4.1
+HAMCREST_VER = 1.3
+JAVACC_VER = 5.0
+JMOCKIT_VER = 1.44
+JSON_SIMPLE_VER = 1.1.1
+JUNIT_VER =4.12
+YAJSW_VER =12.12
+
+JAR_DISTFILES += ST4{org/antlr/ST4/${ST4_VER}/ST4}-${ST4_VER}.jar
+JAR_DISTFILES +=
hamcrest{org/hamcrest/hamcrest-all/${HAMCREST_VER}/hamcrest}-all-${HAMCREST_VER}.jar
+JAR_DISTFILES +=
javacc{net/java/dev/javacc/javacc/${JAVACC_VER}/javacc}-${JAVACC_VER}.jar
+JAR_DISTFILES +=
jmockit{org/jmockit/jmockit/${JMOCKIT_VER}/jmockit}-${JMOCKIT_VER}.jar
+JAR_DISTFILES +=
json-simple{com/googlecode/json-simple/json-simple/${JSON_SIMPLE_VER}/json-simple}-${JSON_SIMPLE_VER}.jar
+JAR_DISTFILES += junit{junit/junit/${JUNIT_VER}/junit}-${JUNIT_VER}.jar
+
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =archivers/unzip \
+ devel/bison \
+ java/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS += GHIDRA_DATE VERSION WRKDIR
+
+JAR_DIRS +=Features-FileFormats
+JAR_DIRS +=Features-Python
+JAR_DIRS +=Framework-Docking
+JAR_DIRS +=Framework-FileSystem
+JAR_DIRS +=Framework-Generic
+JAR_DIRS +=Framework-Graph
+JAR_DIRS +=Framework-Project
+JAR_DIRS +=Framework-SoftwareModeling
post-extract:
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/ghidraRun
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/ghidraRun
+ @perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/support/launch.sh
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
+ @perl -pi -e 's,(application.version)=.*,\1=${VERSION},' \
+ ${WRKSRC}/Ghidra/application.properties
+
+# Steps derived from:
+# https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
+pre-build:
+ cp ${FILESDIR}/repos.gradle ${WRKDIR}
+ ${SUBST_CMD} ${WRKDIR}/repos.gradle \
+
${WRKSRC}/Ghidra/Framework/Help/src/main/java/help/GHelpBuilder.java
+ mkdir ${WRKDIR}/{flatRepo,gradle,home}
+.for dir in ${JAR_DIRS}
+ unzip -j ${DISTDIR}/ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}.zip \
+
Re: [NEW] security/ghidra
On Fri, Jun 21, 2019 at 01:48:59AM -0600, Anthony J. Bentley wrote:
> Lawrence Teo writes:
> > I used SUBST_CMD to substitute WRKDIR in GHelpBuilder.java, and
> > accidentally included the substituted value in my diff when I
> > regenerated patches.
> >
> > I have fixed it in this latest diff. Could you please test if it works
> > for you?
>
> Thanks, ghidra and the decompiler work fine now.
Great to hear that it works!
> If any patches are pulled from GitHub, please add a comment with the
> commit or a link to the pull request.
>
> ok bentley@
Thanks for the ok and feedback. I have created a new diff where I have
added the link to the GitHub pull request as a comment to all the patch
files that were created/adapted from that pull request. There are no
changes apart from adding those comments.
Remi, are you ok with this going in?
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile23 Jun 2019 01:08:36 -
@@ -6,9 +6,13 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +21,115 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
+
+WANTLIB += c m stdc++
-MASTER_SITES = ${HOMEPAGE}
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
+MASTER_SITES2 =https://repo.maven.apache.org/maven2/
EXTRACT_SUFX = .zip
+ST4_VER = 4.1
+HAMCREST_VER = 1.3
+JAVACC_VER = 5.0
+JMOCKIT_VER = 1.44
+JSON_SIMPLE_VER = 1.1.1
+JUNIT_VER =4.12
+YAJSW_VER =12.12
+
+JAR_DISTFILES += ST4{org/antlr/ST4/${ST4_VER}/ST4}-${ST4_VER}.jar
+JAR_DISTFILES +=
hamcrest{org/hamcrest/hamcrest-all/${HAMCREST_VER}/hamcrest}-all-${HAMCREST_VER}.jar
+JAR_DISTFILES +=
javacc{net/java/dev/javacc/javacc/${JAVACC_VER}/javacc}-${JAVACC_VER}.jar
+JAR_DISTFILES +=
jmockit{org/jmockit/jmockit/${JMOCKIT_VER}/jmockit}-${JMOCKIT_VER}.jar
+JAR_DISTFILES +=
json-simple{com/googlecode/json-simple/json-simple/${JSON_SIMPLE_VER}/json-simple}-${JSON_SIMPLE_VER}.jar
+JAR_DISTFILES += junit{junit/junit/${JUNIT_VER}/junit}-${JUNIT_VER}.jar
+
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =archivers/unzip \
+ devel/bison \
+ java/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS += GHIDRA_DATE VERSION WRKDIR
+
+JAR_DIRS +=Features-FileFormats
+JAR_DIRS +=Features-Python
+JAR_DIRS +=Framework-Docking
+JAR_DIRS +=Framework-FileSystem
+JAR_DIRS +=Framework-Generic
+JAR_DIRS +=Framework-Graph
+JAR_DIRS +=Framework-Project
+JAR_DIRS +=Framework-SoftwareModeling
post-extract:
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/ghidraRun
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/ghidraRun
+ @perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/support/launch.sh
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
+ @perl -pi -e 's,(application.version)=.*,\1=${VERSION},' \
+ ${WRKSRC}/Ghidra/application.properties
+
+# Steps derived from:
+# https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
+pre-build:
+ cp ${FILESDIR}/repos.gradle ${WRKDIR}
+ ${SUBST_CMD} ${WRKDIR}/repos.gradle \
+
${WRKSRC}/Ghidra/Framework/Help/src/main/java/help/GHelpBuilder.java
+ mkdir ${WRKDIR}/{flatRepo,gradle,home}
+.for dir in ${JAR_DIRS}
+ unzip -j
Re: [NEW] security/ghidra
Hi Lawrence, Lawrence Teo writes: > I used SUBST_CMD to substitute WRKDIR in GHelpBuilder.java, and > accidentally included the substituted value in my diff when I > regenerated patches. > > I have fixed it in this latest diff. Could you please test if it works > for you? Thanks, ghidra and the decompiler work fine now. If any patches are pulled from GitHub, please add a comment with the commit or a link to the pull request. ok bentley@
Re: [NEW] security/ghidra
On Thu, Jun 20, 2019 at 04:22:28AM -0600, Anthony J. Bentley wrote:
> Lawrence Teo writes:
> > Here's an updated diff that makes the port fetch all the dependent
> > .jar files prior to building.
> >
> > I also used gradle's --offline flag which explicitly tells gradle to
> > "Execute the build without accessing network resources".
> >
> > Could you please try this diff to see if it resolves your issue?
>
> Thanks. That issue seems to be resolved, but I'm seeing another build
> failure:
>
> > Task :Base:buildHelp FAILED
> Exception in thread "main" ghidra.util.exception.AssertException: Failed to
> create user settings directory:
> /usr/ports/pobj/ghidra-9.0.4/home/.ghidra/.ghidra-9.0.4
> at ghidra.framework.Application.initialize(Application.java:78)
> at
> ghidra.framework.Application.initializeApplication(Application.java:114)
> at help.GHelpBuilder.main(GHelpBuilder.java:73)
>
> FAILURE: Build failed with an exception.
Oops! Sorry, that was a mistake on my part.
I used SUBST_CMD to substitute WRKDIR in GHelpBuilder.java, and
accidentally included the substituted value in my diff when I
regenerated patches.
I have fixed it in this latest diff. Could you please test if it works
for you?
Thanks,
Lawrence
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile20 Jun 2019 23:15:33 -
@@ -6,9 +6,13 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +21,115 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
+
+WANTLIB += c m stdc++
-MASTER_SITES = ${HOMEPAGE}
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
+MASTER_SITES2 =https://repo.maven.apache.org/maven2/
EXTRACT_SUFX = .zip
+ST4_VER = 4.1
+HAMCREST_VER = 1.3
+JAVACC_VER = 5.0
+JMOCKIT_VER = 1.44
+JSON_SIMPLE_VER = 1.1.1
+JUNIT_VER =4.12
+YAJSW_VER =12.12
+
+JAR_DISTFILES += ST4{org/antlr/ST4/${ST4_VER}/ST4}-${ST4_VER}.jar
+JAR_DISTFILES +=
hamcrest{org/hamcrest/hamcrest-all/${HAMCREST_VER}/hamcrest}-all-${HAMCREST_VER}.jar
+JAR_DISTFILES +=
javacc{net/java/dev/javacc/javacc/${JAVACC_VER}/javacc}-${JAVACC_VER}.jar
+JAR_DISTFILES +=
jmockit{org/jmockit/jmockit/${JMOCKIT_VER}/jmockit}-${JMOCKIT_VER}.jar
+JAR_DISTFILES +=
json-simple{com/googlecode/json-simple/json-simple/${JSON_SIMPLE_VER}/json-simple}-${JSON_SIMPLE_VER}.jar
+JAR_DISTFILES += junit{junit/junit/${JUNIT_VER}/junit}-${JUNIT_VER}.jar
+
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =archivers/unzip \
+ devel/bison \
+ java/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS += GHIDRA_DATE VERSION WRKDIR
+
+JAR_DIRS +=Features-FileFormats
+JAR_DIRS +=Features-Python
+JAR_DIRS +=Framework-Docking
+JAR_DIRS +=Framework-FileSystem
+JAR_DIRS +=Framework-Generic
+JAR_DIRS +=Framework-Graph
+JAR_DIRS +=Framework-Project
+JAR_DIRS +=Framework-SoftwareModeling
post-extract:
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/ghidraRun
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/ghidraRun
+ @perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/support/launch.sh
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
+ @perl -pi -e 's,(application.version)=.*,\1=${VERSION},' \
+ ${WRKSRC}/Ghidra/application.properties
+
+# Steps derived
Re: [NEW] security/ghidra
Hi Lawrence, Lawrence Teo writes: > Here's an updated diff that makes the port fetch all the dependent > .jar files prior to building. > > I also used gradle's --offline flag which explicitly tells gradle to > "Execute the build without accessing network resources". > > Could you please try this diff to see if it resolves your issue? Thanks. That issue seems to be resolved, but I'm seeing another build failure: > Task :Base:buildHelp FAILED Exception in thread "main" ghidra.util.exception.AssertException: Failed to create user settings directory: /usr/ports/pobj/ghidra-9.0.4/home/.ghidra/.ghidra-9.0.4 at ghidra.framework.Application.initialize(Application.java:78) at ghidra.framework.Application.initializeApplication(Application.java:114) at help.GHelpBuilder.main(GHelpBuilder.java:73) FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':Base:buildHelp'. > Process 'command '/usr/local/jdk-11/bin/java'' finished with non-zero exit > value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 42s 13 actionable tasks: 13 executed *** Error 1 in . (Makefile:118 'do-build')
Re: [NEW] security/ghidra
On Mon, Jun 17, 2019 at 08:10:45PM -0600, Anthony J. Bentley wrote:
> Lawrence Teo writes:
> > Here is an updated diff now that Gradle has been imported.
>
> It doesn't build for me.
Hi Anthony,
Thanks for testing! I checked your build log and found that the Ghidra
build process tries to fetch dependent files on demand while building.
I was able to replicate your build failure when I tried building the
port as _pbuild.
Here's an updated diff that makes the port fetch all the dependent
.jar files prior to building.
I also used gradle's --offline flag which explicitly tells gradle to
"Execute the build without accessing network resources".
Could you please try this diff to see if it resolves your issue?
Thank you,
Lawrence
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile20 Jun 2019 01:40:09 -
@@ -6,9 +6,13 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +21,115 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
+
+WANTLIB += c m stdc++
-MASTER_SITES = ${HOMEPAGE}
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
+MASTER_SITES2 =https://repo.maven.apache.org/maven2/
EXTRACT_SUFX = .zip
+ST4_VER = 4.1
+HAMCREST_VER = 1.3
+JAVACC_VER = 5.0
+JMOCKIT_VER = 1.44
+JSON_SIMPLE_VER = 1.1.1
+JUNIT_VER =4.12
+YAJSW_VER =12.12
+
+JAR_DISTFILES += ST4{org/antlr/ST4/${ST4_VER}/ST4}-${ST4_VER}.jar
+JAR_DISTFILES +=
hamcrest{org/hamcrest/hamcrest-all/${HAMCREST_VER}/hamcrest}-all-${HAMCREST_VER}.jar
+JAR_DISTFILES +=
javacc{net/java/dev/javacc/javacc/${JAVACC_VER}/javacc}-${JAVACC_VER}.jar
+JAR_DISTFILES +=
jmockit{org/jmockit/jmockit/${JMOCKIT_VER}/jmockit}-${JMOCKIT_VER}.jar
+JAR_DISTFILES +=
json-simple{com/googlecode/json-simple/json-simple/${JSON_SIMPLE_VER}/json-simple}-${JSON_SIMPLE_VER}.jar
+JAR_DISTFILES += junit{junit/junit/${JUNIT_VER}/junit}-${JUNIT_VER}.jar
+
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =archivers/unzip \
+ devel/bison \
+ java/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS += GHIDRA_DATE VERSION WRKDIR
+
+JAR_DIRS +=Features-FileFormats
+JAR_DIRS +=Features-Python
+JAR_DIRS +=Framework-Docking
+JAR_DIRS +=Framework-FileSystem
+JAR_DIRS +=Framework-Generic
+JAR_DIRS +=Framework-Graph
+JAR_DIRS +=Framework-Project
+JAR_DIRS +=Framework-SoftwareModeling
post-extract:
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/ghidraRun
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/ghidraRun
+ @perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
@perl -pi -e 's,#!/bin/bash,#!${LOCALBASE}/bin/bash,' \
- ${WRKSRC}/support/launch.sh
+ ${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh
+ @perl -pi -e 's,(application.version)=.*,\1=${VERSION},' \
+ ${WRKSRC}/Ghidra/application.properties
+
+# Steps derived from:
+# https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
+pre-build:
+ cp ${FILESDIR}/repos.gradle ${WRKDIR}
+ ${SUBST_CMD} ${WRKDIR}/repos.gradle \
+
${WRKSRC}/Ghidra/Framework/Help/src/main/java/help/GHelpBuilder.java
+ mkdir ${WRKDIR}/{flatRepo,gradle,home}
+.for dir in ${JAR_DIRS}
+ unzip -j ${DISTDIR}/ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}.zip \
+ -d ${WRKDIR}/flatRepo \
+
Re: [NEW] security/ghidra
Hi Lawrence, Thanks for working on this. Lawrence Teo writes: > Here is an updated diff now that Gradle has been imported. It doesn't build for me. cd /ptmp/pobj/ghidra-9.0.4/ghidra-Ghidra_9.0.4_build && /usr/bin/env -i PO= RTSDIR=3D"/ptmp/ports" LIBTOOL=3D"/usr/bin/libtool" CCACHE_DIR=3D/ptmp/po= bj/.ccache PATH=3D'/ptmp/pobj/ghidra-9.0.4/bin:/usr/bin:/bin:/usr/sbin:/s= bin:/usr/local/bin:/usr/X11R6/bin' PREFIX=3D'/usr/local' LOCALBASE=3D'/us= r/local' X11BASE=3D'/usr/X11R6' CFLAGS=3D'-O2 -pipe -g' TRUEPREFIX=3D'/u= sr/local' DESTDIR=3D'' HOME=3D'/ghidra-9.0.4_writes_to_HOME' COMPILER_VER= SION=3Dclang PICFLAG=3D"-fpic" BINGRP=3Dbin BINOWN=3Droot BINMODE=3D755 = NONBINMODE=3D644 DIRMODE=3D755 INSTALL_COPY=3D-c INSTALL_STRIP=3D MANGR= P=3Dbin MANOWN=3Droot MANMODE=3D644 BSD_INSTALL_PROGRAM=3D"/ptmp/pobj/ghid= ra-9.0.4/bin/install -c -m 755" BSD_INSTALL_SCRIPT=3D"/ptmp/pobj/ghidra-= 9.0.4/bin/install -c -m 755" BSD_INSTALL_DATA=3D"/ptmp/pobj/ghidra-9.0.4/= bin/install -c -m 644" BSD_INSTALL_MAN=3D"/ptmp/pobj/ghidra-9.0.4/bin/ins= tall -c -m 644" BSD_INSTALL_PROGRAM_DIR=3D"/ptmp/pobj/ghidra-9.0.4/bin/in= stall -d -m 755" BSD_INSTALL_SCRIPT_DIR=3D"/ptmp/pobj/ghidra-9.0.4/bin/in= stall -d -m 755" BSD_INSTALL_DATA_DIR=3D"/ptmp/pobj/ghidra-9.0.4/bin/inst= all -d -m 755" BSD_INSTALL_MAN_DIR=3D"/ptmp/pobj/ghidra-9.0.4/bin/install= -d -m 755" gradle -g /ptmp/pobj/ghidra-9.0.4/gradle --no-daemon -I /ptmp= /pobj/ghidra-9.0.4/repos.gradle yajswDevUnpack Welcome to Gradle 5.4.1! Here are the highlights of this release: - Run builds with JDK12 - New API for Incremental Tasks - Updates to native projects, including Swift 5 support For more details see https://docs.gradle.org/5.4.1/release-notes.html To honour the JVM settings for this build a new JVM will be forked. Please= consider using the daemon: https://docs.gradle.org/5.4.1/userguide/gradle= _daemon.html. Daemon will be stopped at the end of the build stopping after processing FAILURE: Build failed with an exception. * Where: Build file '/ptmp/pobj/ghidra-9.0.4/ghidra-Ghidra_9.0.4_build/Ghidra/Featu= res/Python/build.gradle' line: 28 * What went wrong: A problem occurred evaluating project ':Python'. > Could not resolve all files for configuration ':Python:jython'. > Could not resolve org.python:jython-standalone:2.7.1. Required by: project :Python > Could not resolve org.python:jython-standalone:2.7.1. > Could not get resource 'https://repo.maven.apache.org/maven2/or= g/python/jython-standalone/2.7.1/jython-standalone-2.7.1.pom'. > Could not GET 'https://repo.maven.apache.org/maven2/org/pyth= on/jython-standalone/2.7.1/jython-standalone-2.7.1.pom'. > repo.maven.apache.org: no address associated with name > Could not resolve org.python:jython-standalone:2.7.1. > Could not get resource 'https://jcenter.bintray.com/org/python/= jython-standalone/2.7.1/jython-standalone-2.7.1.pom'. > Could not GET 'https://jcenter.bintray.com/org/python/jython= -standalone/2.7.1/jython-standalone-2.7.1.pom'. > jcenter.bintray.com: no address associated with name * Try: Run with --stacktrace option to get the stack trace. Run with --info or --= debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 1m 34s *** Error 1 in . (Makefile:85 'pre-build') -- = Anthony J. Bentley
Re: [NEW] security/ghidra
On Sat, Jun 15, 2019 at 09:26:18PM +0200, Remi Pointel wrote:
> On 6/15/19 4:56 PM, Lawrence Teo wrote:
> > On Tue, May 14, 2019 at 07:59:57PM +0200, Remi Pointel wrote:
> > > On 5/14/19 7:48 PM, Jeremy O'Brien wrote:
> > > > On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote:
> > > > > Jeremy O'Brien writes:
> > > > > > I noticed this port was committed today. I have to
> > > > > > ask, did you actually try to use it? In its current
> > > > > > state, (sans my above changes), there is no decompiler
> > > > > > nor symbol demangler. This might have been OK to omit,
> > > > > > except for the fact that you will get a "Could not
> > > > > > find decompiler executable decompile" popup every
> > > > > > single time you click anywhere in the disassembly pane,
> > > > > > which makes this port unusable.
> > > > >
> > > > > Indeed they are very annoying. I agree the port is not
> > > > > "finished." But I've used Ghidra to do some minor work despite that,
> > > > > so
> > > > > I'm happy to see it in. Revising the port to add the native tools
> > > > > would
> > > > > be very welcome though.
> > > > >
> > > > >
> > > >
> > > > If you're willing to compile it yourself, my MR here:
> > > > https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the
> > > > native components build perfectly in OpenBSD. Just follow the ghidra
> > > > DevGuide.md instructions after applying the patch. I also have my
> > > > personal build here (but that of course requires that you trust a
> > > > stranger on the internet):
> > > > https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip
> > > > if you don't feel like compiling but want the "full" ghidra experience.
> > > > I do like that the current ghidra port requires no compilation, as the
> > > > compilation process is a bit heavy-handed and takes some time to
> > > > complete, but I personally would prefer to see a fully-working port
> > > > over a fast-installing one.
> > > >
> > >
> > > Thank you for feedback, I will try your patch to build ghidra and I will
> > > let
> > > you know.
> > > If you are motivated, you can send a diff that applies on the ghidra port
> > > to
> > > integrate your work.
> > >
> > > Cheers,
> > >
> > > Remi.
> > >
> >
> > Here's my attempt to update Ghidra to add a native decompiler for
> > OpenBSD. I created the patches based on Jeremy's pull request and used
> > https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
> > to figure out the build steps.
> >
> > I also did the following to make it build and conform to OpenBSD port
> > conventions:
> >
> > 1. Ghidra is built using Gradle so I have attached a new port for
> > devel/gradle 5.4.1.
> >
> > 2. DevGuide.md says they built Ghidra with Gradle 5.0 but I was able to
> > build it successfully with Gradle 5.4.1.
> >
> > 3. To prevent the build process from touching $HOME, I made gradle use
> > ${WRKDIR}/gradle as its home and also modified GHelpBuilder.java
> > (the program that builds help files during build) to log to ${WRKDIR}
> > instead of $HOME/.ghidra.
> >
> > 4. One of the Gradle scripts (ip.gradle) scans the Ghidra source tree so
> > I had to explicitly tell it to exclude *.orig and *.beforesubst.
> >
> > 5. The port has to be built with a high `ulimit -d` (I set it to
> > `ulimit -Hd` which on my system is 33554432).
> >
> > Using the resulting package I was able to decompile programs without
> > encountering the "Could not find decompiler executable decompile" popup.
> >
> > Tests/reviews/feedback welcome! :)
>
> Hi,
>
> quickly tested and sounds good to me, thanks a lot for your work.
>
> Cheers,
>
> Remi.
Remi, thank you for testing!
Here is an updated diff now that Gradle has been imported.
The only change is the BUILD_DEPENDS for Gradle which I've changed from
devel/gradle to java/gradle.
ok?
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile17 Jun 2019 00:58:58 -
@@ -6,9 +6,14 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+YAJSW_VER =12.12
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +22,85 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
-MASTER_SITES = ${HOMEPAGE}
+WANTLIB += c m stdc++
+
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
Re: [NEW] security/ghidra
Thank you Stuart! I have imported java/gradle with your tweak.
On Sun, Jun 16, 2019 at 11:12:09AM +0100, Stuart Henderson wrote:
> Oh, maybe worth considering putting it in java/ instead of devel/.
>
> --
> Sent from a phone, apologies for poor formatting.
>
> On 16 June 2019 10:47:15 Stuart Henderson wrote:
>
> > Here's a small tweak for gradle, then it's ok with me to import.
> >
> > diff --git a/Makefile b/Makefile
> > index 06e0699..e4e5daf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2,9 +2,8 @@
> >
> > COMMENT = build automation tool
> >
> > -V =5.4.1
> > -DISTNAME = gradle-${V}-bin
> > -PKGNAME = gradle-${V}
> > +DISTNAME = gradle-5.4.1
> > +EXTRACT_SUFX = -bin.zip
> >
> > CATEGORIES =devel
> >
> > @@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes
> >
> > MASTER_SITES = https://services.gradle.org/distributions/
> >
> > -EXTRACT_SUFX = .zip
> > -
> > MODULES = java
> > MODJAVA_VER = 1.8+
> >
> > NO_BUILD = Yes
> > NO_TEST = Yes
> >
> > -WRKDIST = ${WRKDIR}/gradle-${V}
> > -WRKSRC = ${WRKDIST}
> > -
> > RUN_DEPENDS = java/javaPathHelper
> >
> > do-install:
Re: [NEW] security/ghidra
On Sun, Jun 16, 2019 at 11:12:09AM +0100, Stuart Henderson wrote: > Oh, maybe worth considering putting it in java/ instead of devel/. I agree. OK kn with that.
Re: [NEW] security/ghidra
Oh, maybe worth considering putting it in java/ instead of devel/.
--
Sent from a phone, apologies for poor formatting.
On 16 June 2019 10:47:15 Stuart Henderson wrote:
Here's a small tweak for gradle, then it's ok with me to import.
diff --git a/Makefile b/Makefile
index 06e0699..e4e5daf 100644
--- a/Makefile
+++ b/Makefile
@@ -2,9 +2,8 @@
COMMENT = build automation tool
-V =5.4.1
-DISTNAME = gradle-${V}-bin
-PKGNAME = gradle-${V}
+DISTNAME = gradle-5.4.1
+EXTRACT_SUFX = -bin.zip
CATEGORIES =devel
@@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes
MASTER_SITES = https://services.gradle.org/distributions/
-EXTRACT_SUFX = .zip
-
MODULES = java
MODJAVA_VER = 1.8+
NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/gradle-${V}
-WRKSRC = ${WRKDIST}
-
RUN_DEPENDS = java/javaPathHelper
do-install:
Re: [NEW] security/ghidra
Here's a small tweak for gradle, then it's ok with me to import.
diff --git a/Makefile b/Makefile
index 06e0699..e4e5daf 100644
--- a/Makefile
+++ b/Makefile
@@ -2,9 +2,8 @@
COMMENT = build automation tool
-V =5.4.1
-DISTNAME = gradle-${V}-bin
-PKGNAME = gradle-${V}
+DISTNAME = gradle-5.4.1
+EXTRACT_SUFX = -bin.zip
CATEGORIES = devel
@@ -15,17 +14,12 @@ PERMIT_PACKAGE =Yes
MASTER_SITES = https://services.gradle.org/distributions/
-EXTRACT_SUFX = .zip
-
MODULES = java
MODJAVA_VER = 1.8+
NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/gradle-${V}
-WRKSRC = ${WRKDIST}
-
RUN_DEPENDS = java/javaPathHelper
do-install:
Re: [NEW] security/ghidra
On 6/15/19 4:56 PM, Lawrence Teo wrote:
On Tue, May 14, 2019 at 07:59:57PM +0200, Remi Pointel wrote:
On 5/14/19 7:48 PM, Jeremy O'Brien wrote:
On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote:
Jeremy O'Brien writes:
I noticed this port was committed today. I have to
ask, did you actually try to use it? In its current
state, (sans my above changes), there is no decompiler
nor symbol demangler. This might have been OK to omit,
except for the fact that you will get a "Could not
find decompiler executable decompile" popup every
single time you click anywhere in the disassembly pane,
which makes this port unusable.
Indeed they are very annoying. I agree the port is not
"finished." But I've used Ghidra to do some minor work despite that, so
I'm happy to see it in. Revising the port to add the native tools would
be very welcome though.
If you're willing to compile it yourself, my MR here:
https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the native components
build perfectly in OpenBSD. Just follow the ghidra DevGuide.md instructions after
applying the patch. I also have my personal build here (but that of course requires that
you trust a stranger on the internet):
https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip if you don't feel
like compiling but want the "full" ghidra experience. I do like that the
current ghidra port requires no compilation, as the compilation process is a bit
heavy-handed and takes some time to complete, but I personally would prefer to see a
fully-working port over a fast-installing one.
Thank you for feedback, I will try your patch to build ghidra and I will let
you know.
If you are motivated, you can send a diff that applies on the ghidra port to
integrate your work.
Cheers,
Remi.
Here's my attempt to update Ghidra to add a native decompiler for
OpenBSD. I created the patches based on Jeremy's pull request and used
https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
to figure out the build steps.
I also did the following to make it build and conform to OpenBSD port
conventions:
1. Ghidra is built using Gradle so I have attached a new port for
devel/gradle 5.4.1.
2. DevGuide.md says they built Ghidra with Gradle 5.0 but I was able to
build it successfully with Gradle 5.4.1.
3. To prevent the build process from touching $HOME, I made gradle use
${WRKDIR}/gradle as its home and also modified GHelpBuilder.java
(the program that builds help files during build) to log to ${WRKDIR}
instead of $HOME/.ghidra.
4. One of the Gradle scripts (ip.gradle) scans the Ghidra source tree so
I had to explicitly tell it to exclude *.orig and *.beforesubst.
5. The port has to be built with a high `ulimit -d` (I set it to
`ulimit -Hd` which on my system is 33554432).
Using the resulting package I was able to decompile programs without
encountering the "Could not find decompiler executable decompile" popup.
Tests/reviews/feedback welcome! :)
Hi,
quickly tested and sounds good to me, thanks a lot for your work.
Cheers,
Remi.
Re: [NEW] security/ghidra
On Tue, May 14, 2019 at 07:59:57PM +0200, Remi Pointel wrote:
> On 5/14/19 7:48 PM, Jeremy O'Brien wrote:
> > On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote:
> > > Jeremy O'Brien writes:
> > > > I noticed this port was committed today. I have to
> > > > ask, did you actually try to use it? In its current
> > > > state, (sans my above changes), there is no decompiler
> > > > nor symbol demangler. This might have been OK to omit,
> > > > except for the fact that you will get a "Could not
> > > > find decompiler executable decompile" popup every
> > > > single time you click anywhere in the disassembly pane,
> > > > which makes this port unusable.
> > >
> > > Indeed they are very annoying. I agree the port is not
> > > "finished." But I've used Ghidra to do some minor work despite that, so
> > > I'm happy to see it in. Revising the port to add the native tools would
> > > be very welcome though.
> > >
> > >
> >
> > If you're willing to compile it yourself, my MR here:
> > https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the native
> > components build perfectly in OpenBSD. Just follow the ghidra DevGuide.md
> > instructions after applying the patch. I also have my personal build here
> > (but that of course requires that you trust a stranger on the internet):
> > https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip if
> > you don't feel like compiling but want the "full" ghidra experience. I do
> > like that the current ghidra port requires no compilation, as the
> > compilation process is a bit heavy-handed and takes some time to complete,
> > but I personally would prefer to see a fully-working port over a
> > fast-installing one.
> >
>
> Thank you for feedback, I will try your patch to build ghidra and I will let
> you know.
> If you are motivated, you can send a diff that applies on the ghidra port to
> integrate your work.
>
> Cheers,
>
> Remi.
>
Here's my attempt to update Ghidra to add a native decompiler for
OpenBSD. I created the patches based on Jeremy's pull request and used
https://github.com/NationalSecurityAgency/ghidra/blob/master/DevGuide.md
to figure out the build steps.
I also did the following to make it build and conform to OpenBSD port
conventions:
1. Ghidra is built using Gradle so I have attached a new port for
devel/gradle 5.4.1.
2. DevGuide.md says they built Ghidra with Gradle 5.0 but I was able to
build it successfully with Gradle 5.4.1.
3. To prevent the build process from touching $HOME, I made gradle use
${WRKDIR}/gradle as its home and also modified GHelpBuilder.java
(the program that builds help files during build) to log to ${WRKDIR}
instead of $HOME/.ghidra.
4. One of the Gradle scripts (ip.gradle) scans the Ghidra source tree so
I had to explicitly tell it to exclude *.orig and *.beforesubst.
5. The port has to be built with a high `ulimit -d` (I set it to
`ulimit -Hd` which on my system is 33554432).
Using the resulting package I was able to decompile programs without
encountering the "Could not find decompiler executable decompile" popup.
Tests/reviews/feedback welcome! :)
Thanks,
Lawrence
gradle-5.4.1.tar.gz
Description: application/tar-gz
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile11 Jun 2019 00:38:36 - 1.3
+++ Makefile15 Jun 2019 01:20:42 -
@@ -6,9 +6,14 @@ ONLY_FOR_ARCHS = amd64
COMMENT = software reverse engineering (SRE) framework
VERSION = 9.0.4
-REVISION = 0
-DISTNAME = ghidra_9.0.4_PUBLIC_20190516
-PKGNAME = ghidra-${VERSION}
+GHIDRA_DATE = 20190516
+YAJSW_VER =12.12
+REVISION = 1
+
+GH_ACCOUNT = NationalSecurityAgency
+GH_PROJECT = ghidra
+GH_TAGNAME = Ghidra_${VERSION}_build
+DISTNAME = ghidra-${VERSION}
CATEGORIES = security
@@ -17,32 +22,85 @@ HOMEPAGE = https://www.ghidra-sre.org/
MAINTAINER = Remi Pointel
# Apache v2
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE = Yes
-MASTER_SITES = ${HOMEPAGE}
+WANTLIB += c m stdc++
+
+MASTER_SITES0 =${HOMEPAGE}
+MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
EXTRACT_SUFX = .zip
+DISTFILES =${DISTNAME}.tar.gz
+DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
+DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
+
+EXTRACT_ONLY = ${DISTNAME}.tar.gz
+
MODULES = java
MODJAVA_VER = 11+
+BUILD_DEPENDS =devel/bison \
+ devel/gradle \
+ shells/bash
+
RUN_DEPENDS = shells/bash \
java/javaPathHelper
-NO_BUILD = Yes
NO_TEST = Yes
-WRKDIST = ${WRKDIR}/${PKGNAME:S/-/_/}
+SUBST_VARS
Re: [NEW] security/ghidra
On 5/14/19 7:48 PM, Jeremy O'Brien wrote: On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote: Jeremy O'Brien writes: I noticed this port was committed today. I have to ask, did you actually try to use it? In its current state, (sans my above changes), there is no decompiler nor symbol demangler. This might have been OK to omit, except for the fact that you will get a "Could not find decompiler executable decompile" popup every single time you click anywhere in the disassembly pane, which makes this port unusable. Indeed they are very annoying. I agree the port is not "finished." But I've used Ghidra to do some minor work despite that, so I'm happy to see it in. Revising the port to add the native tools would be very welcome though. If you're willing to compile it yourself, my MR here: https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the native components build perfectly in OpenBSD. Just follow the ghidra DevGuide.md instructions after applying the patch. I also have my personal build here (but that of course requires that you trust a stranger on the internet): https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip if you don't feel like compiling but want the "full" ghidra experience. I do like that the current ghidra port requires no compilation, as the compilation process is a bit heavy-handed and takes some time to complete, but I personally would prefer to see a fully-working port over a fast-installing one. Thank you for feedback, I will try your patch to build ghidra and I will let you know. If you are motivated, you can send a diff that applies on the ghidra port to integrate your work. Cheers, Remi.
Re: [NEW] security/ghidra
On Tue, May 14, 2019, at 12:43, Anthony J. Bentley wrote: > Jeremy O'Brien writes: > > I noticed this port was committed today. I have to > > ask, did you actually try to use it? In its current > > state, (sans my above changes), there is no decompiler > > nor symbol demangler. This might have been OK to omit, > > except for the fact that you will get a "Could not > > find decompiler executable decompile" popup every > > single time you click anywhere in the disassembly pane, > > which makes this port unusable. > > Indeed they are very annoying. I agree the port is not > "finished." But I've used Ghidra to do some minor work despite that, so > I'm happy to see it in. Revising the port to add the native tools would > be very welcome though. > > If you're willing to compile it yourself, my MR here: https://github.com/NationalSecurityAgency/ghidra/pull/490 makes the native components build perfectly in OpenBSD. Just follow the ghidra DevGuide.md instructions after applying the patch. I also have my personal build here (but that of course requires that you trust a stranger on the internet): https://pintobyte.com/tmp/ghidra_9.1-DEV_PUBLIC_20190513_openbsd64.zip if you don't feel like compiling but want the "full" ghidra experience. I do like that the current ghidra port requires no compilation, as the compilation process is a bit heavy-handed and takes some time to complete, but I personally would prefer to see a fully-working port over a fast-installing one.
Re: [NEW] security/ghidra
Jeremy O'Brien writes: > I noticed this port was committed today. I have to > ask, did you actually try to use it? In its current > state, (sans my above changes), there is no decompiler > nor symbol demangler. This might have been OK to omit, > except for the fact that you will get a "Could not > find decompiler executable decompile" popup every > single time you click anywhere in the disassembly pane, > which makes this port unusable. Indeed they are very annoying. I agree the port is not "finished." But I've used Ghidra to do some minor work despite that, so I'm happy to see it in. Revising the port to add the native tools would be very welcome though.
Re: [NEW] security/ghidra
On Fri, Apr 26, 2019, at 10:39, Jeremy O'Brien wrote: > On 2019/04/26 07:44, Remi Pointel wrote: > > Hi, > > > > attached is the port of ghidra: a software reverse engineering (SRE) > > framework. > > > > > > $ pkg_info ghidra > > Information for inst:ghidra-9.0.2 > > > > Comment: > > software reverse engineering (SRE) framework > > > > Description: > > hidra is a software reverse engineering (SRE) framework created and > > maintained > > by the National Security Agency Research Directorate. This framework > > includes a > > suite of full-featured, high-end software analysis tools that enable users > > to > > analyze compiled code on a variety of platforms. Capabilities include > > disassembly, assembly, decompilation, graphing, and scripting, along with > > hundreds of other features. Ghidra supports a wide variety of processor > > instruction sets and executable formats and can be run in both > > user-interactive > > and automated modes. Users may also develop their own Ghidra plug-in > > components > > and/or scripts using Java or Python. > > > > Maintainer: Remi Pointel > > > > WWW: https://www.ghidra-sre.org/ > > > > > > Ok? > > > > Cheers, > > > > Remi. > > Nice. You may be interested in my (pending) MR to ghidra which also > adds support for compiling the native components (decompiler, > demangler): > > https://github.com/NationalSecurityAgency/ghidra/pull/490 > > I noticed this port was committed today. I have to ask, did you actually try to use it? In its current state, (sans my above changes), there is no decompiler nor symbol demangler. This might have been OK to omit, except for the fact that you will get a "Could not find decompiler executable decompile" popup every single time you click anywhere in the disassembly pane, which makes this port unusable. See below screenshot: https://pintobyte.com/tmp/ghidra_decompiler_error.png
Re: [NEW] security/ghidra
On 2019/04/26 07:44, Remi Pointel wrote: > Hi, > > attached is the port of ghidra: a software reverse engineering (SRE) > framework. > > > $ pkg_info ghidra > Information for inst:ghidra-9.0.2 > > Comment: > software reverse engineering (SRE) framework > > Description: > hidra is a software reverse engineering (SRE) framework created and > maintained > by the National Security Agency Research Directorate. This framework > includes a > suite of full-featured, high-end software analysis tools that enable users > to > analyze compiled code on a variety of platforms. Capabilities include > disassembly, assembly, decompilation, graphing, and scripting, along with > hundreds of other features. Ghidra supports a wide variety of processor > instruction sets and executable formats and can be run in both > user-interactive > and automated modes. Users may also develop their own Ghidra plug-in > components > and/or scripts using Java or Python. > > Maintainer: Remi Pointel > > WWW: https://www.ghidra-sre.org/ > > > Ok? > > Cheers, > > Remi. Nice. You may be interested in my (pending) MR to ghidra which also adds support for compiling the native components (decompiler, demangler): https://github.com/NationalSecurityAgency/ghidra/pull/490
Re: [NEW] security/ghidra
On 2019/04/26 07:44, Remi Pointel wrote:
> Hi,
>
> attached is the port of ghidra: a software reverse engineering (SRE)
> framework.
>
>
> $ pkg_info ghidra
> Information for inst:ghidra-9.0.2
>
> Comment:
> software reverse engineering (SRE) framework
>
> Description:
> hidra is a software reverse engineering (SRE) framework created and
> maintained
> by the National Security Agency Research Directorate. This framework
> includes a
> suite of full-featured, high-end software analysis tools that enable users
> to
> analyze compiled code on a variety of platforms. Capabilities include
> disassembly, assembly, decompilation, graphing, and scripting, along with
> hundreds of other features. Ghidra supports a wide variety of processor
> instruction sets and executable formats and can be run in both
> user-interactive
> and automated modes. Users may also develop their own Ghidra plug-in
> components
> and/or scripts using Java or Python.
>
> Maintainer: Remi Pointel
>
> WWW: https://www.ghidra-sre.org/
>
>
> Ok?
>
> Cheers,
>
> Remi.
Missing RUN_DEPENDS on javaPathHelper, and first char of DESCR is
missing ("hidra" not "Ghidra" - also the lines in DESCR are quite long
and mixed lengths - it looks nicer after running through fmt.
The bundled jython only has amd64 components for OpenBSD, so it's
quite likely that this wants ONLY_FOR_ARCHS=amd64.
Otherwise OK.
