Ghidra headless analyzer - node.js

I am trying to decompile nodejs bytecode using ghidra, and there is this specific plugin which decompiles the the nodejs bytecode. How can I install that plugin using ghidra headless method?
And another question I have is, after analysing the nodejs bytecode it generated a .rep folder, which I am not sure what to do about now, as I thought it will be giving me the source code after analysis.
Thanks in advance :)

Installing a plugin in Ghidra via GUI is just an unzip with extra checks. Headless install is described in the doc at https://ghidra-sre.org/InstallationGuide.html#GhidraExtensionNotes
To install an extension in these cases, simply extract the desired Ghidra extension archive file(s) to the /Ghidra/Extensions directory. For example, on Linux or macOS:
Set current directory to the Ghidra installed-extensions directory: cd <GhidraInstallDir>/Ghidra/Extensions
Extract desired extension archive file(s) to the current directory:
unzip /path/to/<extension>.zip
The extension(s) will be installed the next time Ghidra is started.
How to dump the source code will depend on the plugin you are using, without a link it's hard to tell. I guess it just allows disassembling NodeJS bytecode, so you have to use the regular Ghidra APIs or scripts to dump disassembly?

Related

How to properly install Ghostscript under Linux as shared library

The link on this page (https://www.ghostscript.com/download.html) for Linux x64, gets you a .tgz with an executable binary.
However, while trying to use this binary as an .so, (after renaming it into libgs.so and putting into appropriate place) via Ghost4J, I invariably get errors as follows:
java.lang.UnsatisfiedLinkError: /tmp/jna-100923095/jna3513656669313044092.tmp: cannot dynamically load executable
Once I install the Ghostscript via apt-get install ghostscript, the same code runs fine (as it now loads an .so from /usr/lib/x86_64-linux-gnu/libgs.so.9.22)
Question: which minimal set of files should I put to some folder, so that I could link to Ghostscript dynamic library (.so) successfully, without Ghostscript being installed on the machine/container?
UPD: under Windows, this seems to be possible, the /bin folder of the installation contains both DLL and EXE files; if I put that .dll file into a win32-x86-64 folder under resources, it is being picked up by JNA (via Ghost4j) and Ghostscript instance works fine, even once I remove the "official" installation). I would like to have same behaviour (i.e. self-sufficient, self-containing JAR file) for Linux as well.
Well, I ended up building the shared object myself, using Ubuntu 18.04 installed as WSL 1 distribution, following the guidelines from here: https://www.ghostscript.com/doc/current/Make.htm#Shared_object
These were the exact commands:
./configure --without-luratech --with-system-libtiff --with-drivers=PCLXL
make so
and then, in the sobin folder, you have libgs.so, that works as expected. But sad it's not possible to download it from the official site.

Packing node webkit application

I'm new to node webkit and I'm confused about the packaging steps. I just compressed the whole files including the webkit files to make package.zip file. I just copied it to another machine and unzipped it. The nw executable file is not executable there. Its not doing anything when I clicked on it. My concern is
Will the user be able to use the package by just double clicking on the package provided. Or should he need to unzip the package and execute ?
What are the steps to be followed to package the app ?
It's explained here https://github.com/nwjs/nw.js/wiki/How-to-package-and-distribute-your-apps
There is special tool to make packages: https://github.com/mllrsohn/node-webkit-builder
And here how I do in my project https://github.com/Paxa/postbird/blob/master/Rakefile

How do I deploy Node.js applications as a single executable file? [duplicate]

This question already has answers here:
How to make exe files from a node.js app?
(20 answers)
Closed 7 years ago.
Supposed I have written a Node.js application, and I now would like to distribute it. Of course, I want to make it easy for the user, hence I do not want him to install Node.js, run npm install and then manually type node app.js.
What I'd prefer was a single executable file, e.g. an .exe file on Windows.
How could I approach this?
I am aware of this thread, anyway this is only about Windows. How could I achieve this in a platform-independent manner? Any ideas? Best practices? ...?
The perfect solution was a "compiler" I can give a source folder to. The source folder contains the app itself in various .js files, the node_modules folder and some metadata, such as the package.json. The output should be binaries for various platforms, such as Windows, OS X and Linux.
Oh, and what's important: I do not want to make any changes to the source code, so calls to require with relative paths should still work, even if this relative path is now inside the packaged app.
Any ideas?
PS: I do not want the user to install Node.js independently, it should be included inside the executable as well.
Meanwhile I have found the (for me) perfect solution: nexe, which creates a single executable from a Node.js application including all of its modules.
It's the next best thing to an ideal solution.
First, we're talking about packaging a Node.js app for workshops, demos, etc. where it can be handy to have an app "just running" without the need for the end user to care about installation and dependencies.
You can try the following setup:
Get your apps source code
npm install all dependencies (via package.json) to the local node_modules directory. It is important to perform this step on each platform you want to support separately, in case of binary dependencies.
Copy the Node.js binary – node.exe on Windows, (probably) /usr/local/bin/node on OS X/Linux to your project's root folder. On OS X/Linux you can find the location of the Node.js binary with which node.
For Windows:
Create a self extracting archive, 7zip_extra supports a way to execute a command right after extraction, see: http://www.msfn.org/board/topic/39048-how-to-make-a-7-zip-switchless-installer/.
For OS X/Linux:
You can use tools like makeself or unzipsfx (I don't know if this is compiled with CHEAP_SFX_AUTORUN defined by default).
These tools will extract the archive to a temporary directory, execute the given command (e.g. node app.js) and remove all files when finished.
Not to beat a dead horse, but the solution you're describing sounds a lot like Node-Webkit.
From the Git Page:
node-webkit is an app runtime based on Chromium and node.js. You can write native apps in HTML and JavaScript with node-webkit. It also lets you call Node.js modules directly from the DOM and enables a new way of writing native applications with all Web technologies.
These instructions specifically detail the creation of a single file app that a user can execute, and this portion describes the external dependencies.
I'm not sure if it's the exact solution, but it seems pretty close.
Hope it helps!
JXcore will allow you to turn any nodejs application into a single executable, including all dependencies, in either Windows, Linux, or Mac OS X.
Here is a link to the installer:
https://github.com/jxcore/jxcore-release
And here is a link to how to set it up:
http://jxcore.com/turn-node-applications-into-executables/
It is very easy to use and I have tested it in both Windows 8.1 and Ubuntu 14.04.
FYI: JXcore is a fork of NodeJS so it is 100% NodeJS compatible, with some extra features.
In addition to nexe, browserify can be used to bundle up all your dependencies as a single .js file. This does not bundle the actual node executable, just handles the javascript side. It too does not handle native modules. The command line options for pure node compilation would be browserify --output bundle.js --bare --dg false input.js.
There are a number of steps you have to go through to create an installer and it varies for each Operating System. For Example:
on Mac OS X you need to create a .pkg, there are instructions on how to do that here: https://coolaj86.com/articles/how-to-create-an-osx-pkg-installer.html
on Ubuntu Linux you need to create a .deb, there are instruction on how to do that here: https://coolaj86.com/articles/how-to-create-a-debian-installer.html
on Microsoft Windows you need to create a .exe or .msi, there are instruction on how do that using the innosetup installer here: https://coolaj86.com/articles/how-to-create-an-innosetup-installer.html
You could create a git repo and setup a link to the node git repo as a dependency. Then any user who clones the repo could also install node.
#git submodule [--quiet] add [-b branch] [-f|--force]
git submodule add /var/Node-repo.git common
You could easily package a script up to automatically clone the git repo you have hosted somewhere and "install" from one that one script file.
#!/bin/sh
#clone git repo
git clone your-repo.git

What is the development package for lua 5.1.4?

My machine has lua-5.1.4 installed (from source) but does not have lua.pc. What is the development package to download for lua 5.1.4?
I am new to this myself, so please bear with me while I explain what is 'lua.pc'. If you think some of the information here is incorrect, please make full use of the edit button.
lua.pc or any file with pc for an extension is a file that goes into either /usr/local/lib/pkgconfig/ or /usr/lib/pkgconfig directories. It is a text file containing different fields such as Description etc., information that is used by the make install process. The default installation of lua does not install the lua.pc file. That is because it is the 'normal' package. However, the development package contains this file. The development package creates additional dynamic links (for shared libraries etc.) that are needed during installation of other software where these shared libraries may be dependencies. For more information, read here and here.
Update: lua.pc is present in the etc/ folder within the source tarball.
The lua.pc is in the source tarbal, in the etc folder

Building a Win32 DLL from a Linux library source

I'm trying to build a Win32 DLL from an audio-DSP related Linux library (http://breakfastquay.com/rubberband/). There are makefiles and config scripts for Linux, but no help for Windows. The author provides a Win32 binary of a sample app using the library, and I see a number of "#ifdef MSVC" and "#ifdef WIN32" scattered around, so I don't think I'm starting completely from scratch but I'm stuck nevertheless.
As my programming knowledge in either platform is rather limited, I'd appreciate any help.
First of all, what is the right way to get started here? Visual Studio? Cygwin? Initially I started off creating a Win32 DLL project in Visual Studio, adding the source files, thinking about adding a .def file, etc, but at some point I felt like this was going nowhere.
As for Cygwin, this was the first time using it, and I don't even know if this is the sort of thing that Cygwin is designed for. Is it?
On Cygwin, I ran ./configure and got stuck at something like this:
"checking for SRC... configure: error: Package requirements (samplerate) were not met: No package 'samplerate' found"
After looking through the log, it appears that pkg-config is looking for samplerate.pc. How do I handle packages in Windows? libsamplerate is just an open source library, and I have source and a DLL for this. But I'm not sure how to use them to satisfy the dependency requirements for librubberband (which is what I'm trying to build)
I'm completely lost at this point and if anyone can give me a nudge in the right direction... and, is there an easier way to do this?
Many thanks in advance.
If you're still stuck on this I can throw a little light.
You may have to build everything from sources (or have the libraries installed in your environment). You're using Cygwin, I would recommend MinGW and MSYS too, but sometimes it's just not possible to use this combination to build the program or library.
So if using Cygwin, first ensure that you have a proper environment installed. This is that you have the correct development headers installed.
Then download libsndfile. Extract the sources to a directory and from the Cygwin bash shell navigate to that directory. There perform:
./configure
make
make install prefix=/cygdrive/c/cygwin
Notice that I use a prefix, that prefix should point to the directory Cygwin is installed in order to correctly install the libraries (the same happens to MinGW and MSYS, the prefix should point to the MinGW installation directory). Maybe using the usr directory in the prefix works too, I've never tried it.
Now download FFTW, as it will be needed for libsamplerate and rubberband. Same procedure as with libsndfile: extract, configure, make & make install using the prefix. Now copy the header files of FFTW (in the example they'd be in /cygdrive/c/cygwin/include) to the include directory in the usr directory (in the example /cygdrive/c/cygwin/usr/include).
Next SRC (libsamplerate), same procedure.
Then the Vamp plugin SDK. In order to compile the it you may need to edit the file src\vamp-hostsdk\PluginLoader.cpp, deleting RTLD_LOCAL from a dlopen() call (it's safe, it's already the default behaviour).
Also, you may need to install it by hand (in my experiences it didn't like the prefix). Or set the environmental variable PKG_CONFIG_PATH pointing to the paths of pkgconfig, e.g.:
set PKG_CONFIG_PATH=/cygdrive/c/cygwin/lib/pkgconfig:/usr/local/lib/pkgconfig
Now, create a file called ladspa.h in the include directory with the contents of the LADSPA header
Finally, configure and build rubberband, it should find everything it needs.
To build in MSYS using MinGW follow the same procedure, using the according prefix. Using Visual Studio is another alternative, but you may need to use some of the pre-built libraries (for example for libsndfile) as building Linux libraries natively in Windows may be complicated or even impossible (without hacking the source code) in VS.
Anyway, the autor of rubberband provides binaries; I think you should consider use them instead of going through all of this.
Linux to w32 is mostly a tricky thing.
For each of your dependencies, download the source and:
./configure
make
sudo make install
Also, I recommend you to use MinGW + msys in place of CygWin (as the latter produces executables that depend on its libraries). However in your situtation, use the VS approach -- 't will save you a lot of time.

Resources