How to unpack a single EXE file produced by Electron pack? - electron

I have an EXE file which is packed and run by Electron. Now I want to unpack the single EXE file (not asar) to study the source code of this app. But how?
I have tried to unpack this web desktop app (EXE file packed by Electron) by change the extension of this file from exe to zip, 7z and tar. But all failed and indicates that this file is in "PE" format.
Could you please show some ways to unpack this Electron app in a single exe file? Thank you.

You don't unpack an executable file, you decompile it.
AFAIK, you won't get the source code from executable, all you get is machine code that is assembly instructions. There are tools out there which can help you to convert this assembly instructions to readable C code, for example, IDA Pro can do this.
There are lot many other decompilers and debuggers which can help you in this scenario. Like x64 debugger or Olly Debugger.
Trust me, you need a lot many hours to get proficient with these tools before you can actually make sense out of the raw assembly instructions, getting the source code out is a long way ahead.
And out of curiosity, why you wanted the source code of electron executable? All the real implementations for electron app should be inside ASAR packed file (which can be decompressed and then you have all the JavaScript source code). Electron executable is just like a wrapper which runs the JavaScript.
You can check out the electron implementation here.

Hi you can use exeinfope software. This is best ever software you can check programming languages easily

Related

Which Luadist files needed for distribution

I have installed Luadist and created a small program (named abcd.lua which also uses IUP GUI). It runs well with command iuplua.exe abcd.lua I want to give it to some other persons to try. Since Lua may not be installed on their computer, I want to give it to them with Luadist folder. I see that there are a large number of files in Luadist folder (1148 to be exact- tried listing them here but it exceeds character count). They are in following folders:
bin : has large number of exe and dll files.
include: has lauxlib.h luaconf.h lua.h lua.hpp lualib.h
lib: has liblua.dll.a and its extracted folder and a lua folder with large number of subfolders and files
share: also has large number of folders and files.
tmp: only empty cache folder currently
Following files contain 'iup' in their names:
./share/luadist-git/dists/iup-3.6
./share/luadist-git/dists/iup-3.6/dist.info
./share/iup
./share/iup/README
./share/iup/COPYRIGHT
./lib/lua/iupluaimglib.dll
./lib/lua/iuplua.dll
./lib/lua/iuplua_mglplot.dll
./lib/lua/iupluacd.dll
./lib/lua/iupluacontrols.dll
./lib/lua/iupluagl.dll
./lib/lua/iuplua_pplot.dll
./lib/lua/iupluatuio.dll
./lib/lua/iupluaim.dll
./bin/libiuptuio.dll
./bin/libiup_pplot.dll
./bin/iuplua.exe
./bin/iupview.exe
./bin/libiup.dll
./bin/libiupgl.dll
./bin/libiupcd.dll
./bin/libiupim.dll
./bin/libiupimglib.dll
./bin/libiup_mglplot.dll
./bin/libiuplua.dll
./bin/libiupcontrols.dll
Will giving only these file alongwith my program file (abcd.lua) be sufficient, though I think many dll files will also be needed?
Which files or folders can I select to give or do I need to give all files for proper running of my program? Thanks for your help.
In the IUP documentation, each library describes its dependencies. You can start there.
But the answer depends on what modules are you using. If the only "require" you do is "iup", then it is quite simple. You will need the executable, the Lua DLL, the IUP DLL and the IUPLUA DLL.
You have a couple of options:
(1) move the executable to a different folder and start your script. It will fails with an error message about a missing DLL; move the DLL to the folder with the executable and repeat. This should give you a list of the dependencies, assuming the execution will follow all code paths that load external modules.
(2) use the dependency walker to find all dependencies that your executable and its DLLs have. The advantage of this method is that you can execute it without moving any files and it will give you a detailed analysis of the dependencies and how they are resolved on your system.
Keep in mind that you don't need to preserve the same structure that LuaDist has for the dynamic libraries; you can put all the DLLs your script needs next to the executable (and this is likely to be the simplest and the most successful configuration).

How to install Lua GUI in ZBS IDE

I am completely new to programming in Lua outside a sandbox.
I have found a library called Lua GUI that I'd like to use (https://github.com/williamwilling/luagui/). I have still not understood how to quite install the library, and how I even go about using it.
That's part 1 of my question; How can I install Lua GUI(or an library for that matter), and then how do I go about actually using it? By that I mean, is it as simple as writing a program that starts with "require "gui"" and then running it, or is there more to it?
Part 2 of my question is then how do I go about installing it as a package for ZeroBrane Studio IDE, I have no idea at all what the readme file is instructing me to do so I would be grateful if someone could clarify.
If you copy the contents of the src folder in the luagui project to your project directory you should be able to call:
local gui = require("gui")
in your main Lua file and use it that way.

(Delphi 7) I can't run my program executable on non-Delphi PCs?

I was making a Delphi application, and wanted to test it on another PC to see if everything was working properly. I compiled and built the executable file, of course and I transfered all of the files from the Project folder to the other PC. When I launched the .exe file on the PC, nothing would happen. I then ticked the "Build with runtime packages" option in Project Options:
This made the .exe go from around 300 KBs to around 30 KBs, but now, instead of being able to launch the application on another (non-Delphi) PC, that PC got an error saying it was missing various files required to open the .exe .
I sent the same thing to various friends and all reported the same problem.
My application is a rather simple lottery prototype application, so I don't understand why I'm having trouble opening it on other PCs. Are there other special options I need to enable for this to work?
When you use runtime packages, you need to distribute those packages. These are the .bpl files that your program links to. It will be a subset of the packages listed in the runtime packages edit box in your screenshot. You should just list the packages that you use.
The net result of doing this is that the total amount that you will have to distribute is much greater than a single monolithic executable. Because in a monolithic executable the unused code can be stripped. If you want to minimize the size of your program, and make life simple, do not use runtime packages.
It would be worthwhile reading Embarcadero's documentation:
Working with Packages and Components
Solve the first problem.
Using Runtime Packages will not solve the problem of your EXE not running on certain PC's. All it does is increase the complexity of deploying your application (as you have found).
Unless you need Runtime Packages for other, specific reasons, then you are far, far better off NOT using them, especially if you do not understand them (which based on the way you describe having discovered them does appear to be the case, if we're being honest).
Concentrate on finding out why your application does not run as a single, stand-alone EXE.
With all of the problems involving runtime packages your EXE is currently not even reaching the point of running your application code, and this may be where your original problem lies. Which means that once you have solved all the issues created by Runtime Packages, you will stil be left with an EXE which does not run. i.e. your original problem.
What does your application do when it starts ? Does it attempt to load files from any specific locations ? What are those locations ? What are the files ? Are you using any third party libraries which may expect DLL's to be present or other external files ? Are you trying to read or write settings to the registry or any external files (INI files etc).
What is the OS you are trying to run on ? This can be a very significant question for applications compiled with older Delphi versions. Have you tried configuring the EXE to run in Compatibility Mode for older versions of Windows ? (something that you do in Windows itself, not when compiling the EXE).
These are the questions you should be focussing on. Not runtime packages.
Gday,
A small tool that's been around for a while to help you with this is Dependency Walker. You can find it at http://www.dependencywalker.com. It's helped me out on more than one occasion. This will tell you what files (usually BPLs as stated in the other responses) need to be sent with your EXE.
Also look at NSIS to create a simple installer, and put your EXE and supporting BPLs and any other files in the same directory.

Is it possible to embed and run exe file in a Delphi executable app?

Resource files (.RES) accept any kind of binary files but if it is an exe file how can I run it?
You would have to extract it as a file to disk and execute it.
Although you don't have to extract it to disk, as Cosmin Prund says in a comment, if you don't it requires a lot of hard work.
http://sites.google.com/site/delphibasics/home/delphibasicssnippets/memoryexecutionunit-winxpwinvistawin7
Take a look at this memory execution unit.It allows you to execute an exe from memory without dumping it on disk.
Yes it is possible. There is a Delphi library to do this somewhere on the web, but I cannot for the life of me remember what it's called. It allows you to execute a normal exe file no-matter where it is in memory. So you can load it into a stream, or just embed it in a resource.
I realize that my reply is a bit depressing since i dont remember the name of the library, but at least you now know that it can be done. If you google around for "execute PE exe from memory" and "Delphi" then I'm sure you will find it.
You might want to take a look at Orean's XBundler: http://www.oreans.com/xbundler.php
I use their licensing product (WinLicense) and have been very happy with the product, their support, responsiveness and updates.
In fact, I'm about to buy XBundler so I can ship a dll securely embedded in my exe.
Tom

Delphi app calling cobol app -> error

We need to get data out of an older accounting system. We have received a dll that gives us access to the data we need. It includes a type library that we have imported.
If we run our test application from the same directory as the accounting system, everything works fine. If we try to run our application from a different directory, we get the following error:
Dynamically Bound RTS
Runtime DLL 'OOPS', version 3.1, entry point oops
not recorded in registry, not found or incompatible with requirements
of dynamically bound COBOL program. Dynamic binding of RTS requires:
Runtime DLL 'OOLSM', at least Version 3.1
Can anybody provide some helpful information on this?
Are we supposed to have some kind of cobol runtime in our directory? Or in the path? Or registered in the registry?
Thanks,
-Vegar
Updates:
Setting the system %path% to include the path to the accounting system seems to do the trick. Including it as a user variable did not have the same effect for some reason.
What Cobol are you using?
I had done this for year with Microfocus NetExpress 3.1, and all works just fine.
I write COBOL DLL to access COBOL data files, and also write Delphi DLL to add new features to old COBOL systens.
And yes, I use to set the runtime path, that is environment variable called COBDIR, there are others,but usually %PATH% and %COBDIR%is enough.
If you give more detais about what COBOL compiler are you using, and how is the dll interface that you are calling, will me ore easy to help you.
And maybe "Dependence Walker" can help you to identify what run time files are missing, if it is.
http://www.dependencywalker.com/
If it works from the accounting app's directory, but not a different one, the first thing I'd try is adding that directory to your path.
Unless it is already loaded into memory, Windows looks for DLL's that a program is requesting in every location listed in its PATH environment variable, and also in the directory the application is located within.

Resources