I'm trying to create helloworld C program for windows. I need target executable to be COFF file for some security-related project. Do I use cl.exe? Do I use fasm?
Edit: not necessirily compile on windows, anything goes as long as I can run binary on windows.
Edit2: anything goes as long as I can run binary on windows or load as dynamic library.
You would use nasm.
period#D5DZ5WT2 ~/src/metasploit-framework $ nasm -f coff -o obj-intel.o dlexec.asm
period#D5DZ5WT2 ~/src/metasploit-framework $ file -s obj-intel.o
obj-intel.o: Intel 80386 COFF object file, no line number info, not stripped, 1 section, symbol offset=0x16f, 26 symbols
(That was done on WSL the windows subsystem for linux, but you should be able to do the same with cygwin or a native win binary for nasm).
https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/
Related
I found every process running on my computer has .exe extension on task manager.
Someone said that batch file (.bat) and bytecode (maybe .class) are also executable program, but I think they are just a file running by other executable program (.bat - cmd.exe, .class - JVM, .cpl - rundll32.exe) according to what I saw on task manager
Is ".exe" the only extension of executable programs in Windows OS?
If you're talking about executing commands then all the extensions in the %PATHEXT% environment variable can be run without specifying the extension. For example *.bat, *.vbs... are all "executable" in that sense
> echo %pathext%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
If it's about binary executables then Windows doesn't care about the extension of executable files. It just checks the format and if it's a supported binary format then it'll be run. Modern Windows uses PE format which starts with the MZ magic number so if you create a *.TXT file with MZ at the beginning and run it in cmd then it'll actually be treated as an executable file. In fact many files in the System32 folder like *.SCR, *.CPL... are also PE files and still run when we double click on them. And even *.COM files in modern Windows apps are also PE files. The *.COM extension is only for differentiating with another *.EXE of the same app, but with priority in running because *.COM is put before *.EXE in %PATHEXT% by default as can be seen above:
What would be the reason for WinSCP using a ".com" instead of ".exe"?
Executables in Visual Studio: devenv.com/devenv.exe
Windows 10 wsl (not wsl-2) even supports running Linux ELF executables directly and they of course doesn't have any extension by default. Since wsl-2 the file is run inside the VM instead of directly under Windows kernel like in wsl
Depending on Windows version it may support many more executable formats. The complete list is
Raw binary instructions in old *.com format
NE *.exe format
PE *.exe format
MZ *.exe format
ELF format
And they don't depend on the extension either except for the raw *.COM file
I'm compiling a program on windows using cmake and clang-cl with flags /Zi and /DEBUG:FULL. I can step through the program using VS code and it shows function names in the call stack.
However, when I try to disassemble with llvm-objdump, I get the whole .txt as a single block, no function names whatsoever. I want to check the disassembly of a single function but llvm-objdump says failed to disassemble missing function <name>. How can I make llvm-objdump recognize the exe symbols.
P.S. I'm familiar with linux and ELF but not really with EXE format, that's why I'm using clang instead of msvc.
Hello guys I am writing an operating system in Assembly 16 bit NASM windows 10 64 bit (to be specific) and compiled it to 2 binary .bin files:
kernel.bin
boot.bin
as you may guess boot.bin loads kernel.bin and makes a filesystem, thats all ok. but the problem is that I need to test it on a real machine to test how the hardware reacts instead of only virtual! so I got floppys (3.5" 1.44MB) it is more than enough but I tried to write the bootloader (boot.bin) to sector 0 of a floppy with a floppy-usb-drive (drive and floppys are working how they should!) I use the following steps for putting the OS on a floppy in cmd:
format A:
nasm -f bin kernel.asm -o KERNEL.BIN`
copy KERNEL.BIN A:\KERNEL.BIN
debug boot.bin
w 100 0 0 1
q
it boots... but not correct: it says this:
Please remove all media... press any key to reboot...`
and it reboots to windows 10
QUESTION
how can I fix this? I now use dosbox and debug.exe in dosbox (debug.exe from windows 7 x32), like: I copy the kernel and burn the loader but it actually WORKS! and loads my OS!
It's quite likely that your system is EFI or uEFI rather than traditional BIOS, especially if it's been made in the last four or five years. You can check the system configuration at boot (Go into BIOS or EFI config) and enable legacy boot mode.
It is also possible that your antivirus software is interfering with you writing to a bootsector silently. Check those logs and make sure that your command line is being run as an administrator.
I'm having some trouble getting NASM to work at the moment. I have to get it installed for a subject that I'm doing at college. I have Windows 8.1 Pro 64-bit installed. I managed to get NASM installed by downloading the latest version.
Our first task is just to copy the code to a Hello World program and get it running. Here's the code below:
bits 16
org 0x100 ; Start the program at offset 100h
jmp main ; Jump to main program
message: db 'Hello World', 0ah, 0dh, '$'
main: mov dx, message ; Start address of message
mov ah, 09 ; Prepare for screen display
int 21h ; DOS interrupt 21h
int 20h ; Terminate program
So I saved that as prog1.asm and used a batch script that our lecturers gave us to compile it. The batch script is this:
nasm -f bin %1.asm -o %1.com -l %1.lst
When I type in as prog1.asm into cmd it compiles without error, although as soon as I type in prog1 to run the program I get the following error in the cmd window:
This version of C:\Users\########\AppData\Local\nasm\prog1.com is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.
I don't know what to do really and no matter what I try or Google, nothing seems to give me a straight answer or a proper solution.
The program you've built is a DOS program - it won't run directly in Windows (you might be able to run it in compability mode in Windows XP/9x, but certainly not on your 64-bit edition of Windows 8.1).
You'll need to run your program in some sort of emulator that can handle DOS programs. Probably the most popular one is DOSBox.
If you choose DOSBox you can use a 3rd party front-end to configure things. Or you can just start up DOSBox, then at DOSBox's prompt type:
mount c: <the directory where prog1.com is located>
c:
prog1
I had the same issue with the same exercise.
I have Windows 7 64bit.
My solution was this:
Downloaded and Installed DosBox
Downloaded 16bit version of NASM from:
http://prdownloads.sourceforge.net/nasm/nsm09838.zip?download
(other versions of NASM gave me weird errors)
Unzipped NASM to c:\nasm16
Using notepad, created prog1.asm file (with containing code) in c:\nasm16\
Copied the "as.bat" file into c:\nasm16\
Ran DosBox, and in Dosbox ran command:
mount c c:\nasm16
Open mounted drive with command:
c:\
ran command:
as prog1
And it worked hooraa! :)
In GNU/Linux System there exists a command, named file, which determines the file type.
Is there any similar command/tool in Windows?
In particular, I want to check if a .lib file is compiled to 32 or 64 bits.
There is no function like out-of-the-box. Still, You can use Cygwin to use it's unix version.
There is also free http://mark0.net/soft-trid-e.html tool.