Recently I discovered that .exe files sometimes still hold their source code (readable code).
I opened an exe in IDA and it told me it was written in .NET and I could see the source code opening the exe with a .NET decompiling program (DNspy).
Soon after I made an exe from a python script using pyinstaller. And similarly but with another program I was able to retrieve the original code from only the exe.
But opening the exe with IDA did not give me any indication that it was written in python/ build with pyinstaller. So I wonder if there is a program/tool/method that could detect how an exe was generated (maybe by looking at some magic bytes or something) ? Generally I would like to know for an exe if I can retrieve the source code.
Related
I Use code in vb.net to run EXE file (EXE From node.js) it open normally but not create output I use this code
System.Diagnostics.Process.Start("D:\app5-win.exe")
but when I run the exe file without vb.net it created output normally
so i'don't know what wrong
I use Windows 10 and an .exe program (in-house code written by a colleague) that imports data from .txt files. Since 99% of my use of .txt files are for this program, I've changed the default Windows program so that this .exe file is run automatically when opening a .txt file. If I need to access the .txt file directly, or use it for another purpose, I right-click and choose "edit."
I'm now writing a program of my own (using Octave 4.4.1), which also uses .txt files that sometimes need to be opened/edited, but if I use "open(filename)" in my Octave script, of course it just opens the .exe file. I can open the .txt file from there, but I'd like to skip this middle step, since the aforementioned .exe program is not intended to be used in this process, and there are other users of my code that don't have the .exe program installed.
Is there a way to duplicate the right-click/edit feature in Windows within Octave code? "edit(filename)" opens the file in the native Octave editor, which is technically viable, but not exactly a desirable scenario. I've also tried changing the default Octave editor to Notepad, and I've tried Notepad++ as well, but I have had absolutely no luck, even with significant effort, of making Octave use an external default editor of any kind (even when I remove the .exe program as the default for .txt files). Thanks in advance for any advice you can offer.
You can send command-line commands from Octave using the system() function.
For example, to open the file in notepad, you could do
[status, output] = system("notepad <path_to_text_file>.txt");
If notepad isn't in your system path, you will have to add it to or use the full path to the notepad executable
Or, if you want to use Notepad++, add it to your system path and then do
[status, output] = system("notepad++ <path_to_text_file>.txt");
I have made a small (8 MB) program into a MAC executable (.app?)
It works great if I share it using a thumbstick, but if I try to upload it to google drive and then download it it doesn't work. By this I mean It first tells me that It is an unidentified source (this seems reasonable)
But then if I click "open"
It opens as a text file with junk data:
If I try to force it to open on the terminal, how the other program opens, it just shows the heartbeat thing that MACs do when opening a file, but never opens anything.
It is certifiably the same exact file. Same size, same name, same goobldygoop if I open both of them as text files instead of executables.
I am really confused, the only thing I can think of is the "signature" that apple uses is lost when it is compressed into a zip, but I'm probably totally off base.
The code uses python 3.7, pyinstaller, pynput, and selenium.
I am using MAC OS Catalina to write and make into an EXE, then another Catalina to try to run the program.
EDIT: Clarify what doesn't work means
Please help.
I found the answer, simply zip the file from my mac and send it that way!
Yay!
I am new to python and need to compile it into .exe version. My question is when a py script is compiled into .exe does it mean it cant decode anymore?
Our goal is make python scripts safe when deploying to client servers as we dont want them to get our source code using the .exe.
No - a compiled piece of code is compiled into another language (byte code) - you can not actually read the source code.
Do have a look at this though...
A savvy user who has this .exe version could extract the .pyc (byte code) and then break that down using a python decompiler like Uncompyle to get it pretty much back to source code. Thus there is a way (and a chance) of the python source code (close to it) getting extracting from your .exe version.
I did a very simple program in C for linux a few months ago to read data from a socket and write it to disk. Now I want to run it on Windows, so I installed cygwin and everything worked fine.
The problem appears in windows when my program is writing the data to a file and, at the same time, I try to open that file with another tool. It complains and doesn't open the file because it is opened by other process.
After googleing, I have read that to avoid that, in windows, you have to create the file with SHARE_FILE_READ and SHARE_FILE_WRITE flags, but the problem is that my program is written in C for linux and I just use a standard open syscall..
Is there any way to tell cygwin to add that shared modes to the file that my program is opening?
The issue is that both processes which open the file must do so with compatible sharing modes in order to succeed. Cygwin is opening the file with the correct sharing mode, but the other program is not.
For all files which are not special device files for tape drives, Cygwin opens them by calling NtCreateFile with a sharing mode of FILE_SHARE_VALID_FLAGS (equivalent to FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE)—see the implementation of fhandler_base::open() in fhandler.cc, which is what fopen(), open() etc. all use under the hood.
You need to convince your other program to open the file with the correct sharing mode; if it uses a sharing mode of 0 (no sharing), then it doesn't matter how Cygwin opens the file—the program will always get a sharing violation in that case.