I am working on a compiler for a small (toy) language that produces 16-bit com-files, which are executable in Windows XP. However, in more modern releases of Windows com-files are executable only with the help of tools such as DosBox. I would like my compiler to produce exe-files that can be executed directly in Windows 10.
As I understand it, the exe-file needs a header that instructs the system of how to execute it. My idea is to simply add the header at the beginning of the com-file to extend it into an exe-file. I wonder if anyone can recommend an appropriate tutorial that describes how exe-files works. More specifically, I am looking for a tutorial of how to build the smallest possible working exe-file.
I also wonder if there is a difference between exe-files for 32-bit or 64-bit Windows?
Best Regards,
Stefan
You can download description exe format here. You need pecoff.docx file.
Also you may look on this old but detailed doc here.
Related
I have some crucial data written decades ago by an ancient 16bit DOS application.
There are no docs, no source, and no information about the author. Just the 16 bit exe.
I guess it's time for me to learn how to decompile stuff, since it seems the only way to restore file format.
I've tried OllyDbg, it looks really great, but it can't 16 bit.
So, is there a disassembler/debugger capable of working with such executables?
Thanks.
UPD: I know DOSbox, the app runs in it all right. The problem is, I don't need to run it, I need to understand the file format in which it writes data. Or maybe I don't know something about DOSbox and it can run as a debugger/decompiler as well? Or do you mean starting some old 16bit DOS debugger/decompiler in DOSbox? The latter sounds like an idea, but could you please name a decent DOS debugger, then?
disassembling tool:
use IDA Freeware https://www.hex-rays.com/products/ida/support/download_freeware.shtml
you won't find any better tool for reversing - even for old dos programs :)
most other tools are only capable of doing disassembling for 32bit and don't reach in any way the analyze features of IDA - its the gold standard tool of reverse engineering
debugger:
dosbox got its own builtin debugger (reachable through the "debug" command on command line)
but you need to build your own version of dosbox with activated debugger (oder better heavy-debug) see: http://www.vogons.org/viewtopic.php?t=3944
or if you got a ida licence with the sdk there is an dosbox<->ida-debugger plugin available
currently linux only https://github.com/wjp/idados
file format:
do you know what the file contains (what do you want from the file)
very complex information or "just" some lists of values?
maybe its better to start here with an hex-editor (http://mh-nexus.de/de/hxd/) and known result-values to compare
what program uses the data currently (or only the program itself)? maybe its possible to understand how the data is read in this program?
program itself:
how large is the exe?
console program or a big super gfx power app?
real 16bit or 32bit with dos-extender?
a single exe or overlays(dos-dlls)?
can you give access to the executable?
your turn
You're looking for IDA. It's the de-facto disassembler for pretty much anything.
You can get more help on this at https://reverseengineering.stackexchange.com/
You do not necessarily need to disassemble a program in order to figure out the format in which it writes data.
Perhaps you can do differential analysis on it. Change some inputs to the program, have it write the data, and watch how the file changes.
I have some vintage hardware devices here which can dump their NVRAM settings over MIDI in a binary format (in one case, a single SysEx message with a binary blob in it). If I wanted to know what the format is, I'd make small, systematic changes to the settings, and perform dumps, then see what bits in the binary data are changing.
You really are probably best off attacking the data, rather than the program.
Dosbox is probably a thing to try.
You might also look at http://hte.sourceforge.net/ .
I have downloaded spotify API and am trying to build the example code using libspotify on Windows. The build environment seems to apply only for Mac/Linux world (atleast the Makefile seems to suggest that and there are no Visual Studio project files). Any one has any luck in building the sample code on Windows ?
Even the basic stub example uses pthreads which is not available on windows. Since all their examples assume a POSIX compliant OS (which windows is not) I'm afraid you will not be able to build them on windows (natively). If you want try then take a look at Cygwin.
However, you can still use the include header file and the provided dll/lib to link against and develop applications. The library calls made in the examples are still valid - just not the examples themselves.
I've got a working proprietary application (windows exe) and would like to know which particular toolkit was used to make it. The reason is that I like the widgets it uses and seek to use same library in my project (to buy it if it's proprietary as well).
Just use Process Explorer to see what DLLs the application has loaded. That will be your widget set. Sort the results by folder to roughly group them by manufacturer. You may need to examine the properties of the DLLs for more detailed info as well.
If the library is statically linked you may have to do some deep looking around, maybe you'll get lucky and find a string saying the name of the library or a class/function in it. You can use OllyDbg for this to view strings loaded at runtime, or something like the linux command strings to look through statically, although that wont work if the program decodes itself at startup. If that doesn't work, you'd have to come up with a list of libraries that do what the one you are looking at does, and find some artifacts in the binary that are common between the two. Anyways, better to check the dlls first like Paul Sasik said.
You can use PEiD to identify the compiler, which can be a hint aswel. PEiD also has a nice process explorer.
For instance, Google Chrome uses C:\WINDOWS\SYSTEM32\IEFRAME.DLL :-) Nice isn't it?
(Don't trust it 100%. For instance, my own compiler has the "Morphine 1.2 - 1.3 -> rootkit" description, which I find quite awkward: that's a packer/compiler trace obfuscator.)
I want a small (< 30MB) standalone Windows executable (a single file) that creates a window which asks the user for the location of a directory and then launches a different program in that directory.
This executable has to run on XP, Vista, Server 2003, and Server 2008 versions of Windows in 32-bits and 64 bits on x86-64 architecture as well as Itanium chips.
It would be spectacular if we only had to build it once in order to run it on all these platforms, but that is not a requirement. This is for a proprietary system, so GPL code is off-limits.
What is the fastest way to put this together?
These are some things I'm looking into, so if you have info about their viability, I'm all about it:
Perl/Tk using perl2exe to get the binary.
Ruby with wxruby
Learn MFC programming and do it the right way like everybody else.
What about a WSH script? It won't be an exe, right, but to ask for a folder I don't see the need for an exe file, much less a 30Mb one...
A 1Kb script, save it as whatever name you like with vbs extension and run it. This, in case it's not clear, asks you for a folder name and then runs calc.exe from the system32 subdirectory. You can of course do a lot better than this in 2 or 4 Kb.
Set WshShell = WScript.CreateObject("WScript.Shell")
win = InputBox("Please type your Windows folder location.")
If Right(win,1) <> "\" Then
win = win & "\"
End If
WshShell.Run win & "system32\calc.exe"
To add a Folder Browser dialog instead of an InputBox, check this out.
Clear benefits are:
Simplicity (well, VB is ugly, but you can use JScript if you prefer), no need to compile it!
Compatibility, works on every windows machine I have available (from 98 onwards)
I'd use .NET and WinForms. The idea of scripted solution is appealing, but in practice I often find you end up jumping through hoops to do anything beyond the basic case and still don't have the flexibility to do everything you want.
Quickest way on Windows for a lightweight and fast GUI? One word.. Delphi! It lacks the 64 bit support for now but then FreePascal would come to the rescue.
Having a small stand-alone application and developing it quickly are, I'm sorry to say, usually conflicting requirements.
To be honest, given how incredibly simple the application is, I would write it in C with direct Win32 calls: one call to SHBrowseForFolder() to get the directory, and one to ShellExecuteEx() to run the program. Even MFC is far too heavy-weight for such a modest application. Set the C runtime to be statically linked and you should be able to keep the size of the stand-alone executable to less than 100k. A decent Windows C coder should be able to knock that up in less than an hour, assuming you have one to hand.
Python with either wxWidgets or Tkinter should be able to do this with almost no effort at all. Runs on everything, and py2exe will get you a standalone executable.
Tcl/tk is one solution. You can have a single file executable (including custom images, dlls, etc) using something called a "starpack" -- a virtual filesystem that is both tcl interpreter and application code. I think it would weigh in at maybe a couple megabytes.
From your specifications it would take me personally maybe 15 minutes to get a first working version.
Tcl/Tk has a BSD license.
For all of its flaws, Visual Basic has historically been great for super-simple apps like this.
I agree with the Tcl/Tk answer above. For more information about the starpack that he refers to, see: http://www.equi4.com/tclkit/ it's a Tcl/Tk interpreter available for various OS's all in about 1MB. In the past there apparently has been concerned about the look and feel of Tcl/Tk UI's, but this has been addressed by a new framework named "Tile" that supports the native look and feel of the user's OS.
For a quick and dirty GUI program like you said, you can use an AutoIt script. You can even compile to an exe.
For an GUI example of AutoIt, you can check my stdout redirect script in a previous answer here
wxWidgets; it's cross platform, free, open source and easy to learn
You could do this in MFC and have an executable in under 100k. In general, if you want to keep the size of your executables down, you can use UPX to perform exe compression. If you want an example, take a look at uTorrent. It's a full featured BitTorrent app in less than 300k of executable.
I use HTA (HTML Application) for quick-and-dirty form & script applications. See Microsoft's HTA Developers Center for details and examples. This basically uses HTML for the form, and any HTML-accessible scripting language for the script. Normal browser security is bypassed so that you can get at almost all OS internals. The above site also contains links to several tools that nearly automate the scripting part for you.
PyQt works really well for this. Binaries for Windows here:
http://www.riverbankcomputing.co.uk/software/pyqt/download
A good book here:
http://www.amazon.com/Programming-Python-Prentice-Software-Development/dp/0132354187/ref=sr_1_1?ie=UTF8&qid=1295369454&sr=8-1
And you can freeze these using various methods if you need exe(s).
Similar to what Vinko Vrsalovic said, you can use a HTA application. It is as easy as building a webpage with windows scripting host functionality. I have built a few utilities with jscript and it is really easy and quick
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx
These responses are unbelievable.
Visual Studio Forms editor lets you draw out WinForms and autogenerates the boilerplate GUI code (which is a pain in the ass at best for most other languages and toolkits). Then you can use C# or any other .NET language. .NET has stock widgets for file pickers. I could write that script in 20 minutes and it will run on every one of your target platforms for free. Draw out the GUI, drag-n-drop a file picker, fill out maybe two hooks to do the "launch a different file than they wanted" thing, done.
I suggest Autohotkey (AHK) or Autoit. Both support win95+ (with caveats for certain functions). They can be compiled into small .exe without external dependency (besides native DLL's).
Pros:
small size
easy to write code
useful for simple - complex operations
can create GUI easily
Cons:
learning curve (as syntax is unusual)
30MB is pretty huge!
Qt (C++) may be the best choice. It is portable, quick to develop and relatively fast to run. With UPX (Ultimate Packer for eXecutables) your program will be 10M+.
Qt (Python) is OK too, but will be slower.
If you want it less than 1M and/or you want it quick, you can write it in C with win32 api, or use Delphi.
For certain programs nothing beats the command line. Unfortunately, I have never seen good documentation or examples on how to write console applications that go beyond "Hello World". I'm interested in making console apps like Vim or Emacs. Well not exactly like Vim or Emacs but one that takes over the entire command prompt while it is in use and then after you exit it leaves no trace behind. I know that on Unix there is the curses library but for Windows? ...
PDCurses works on Win32.
I found List of Console Functions on msdn, PDCurses, and The Console Module.
You can certainly write that kind of application with Delphi, which has reasonable commandline support. People often overlook that Delphi can build any kind of Windows executable, not just GUI apps.
I don't know off-hand if the free 'Turbo' edition of Delphi has anything cobbled into it to PREVENT you from using it to build console apps - I would have thought it would be fine for this kind of thing.
There is a small but good tutorial on using C++ for the Windows console at www.benryves.com/tutorials/?t=winconsole&c=all going as far as coding a simple painting program.
You could also try Free Pascal. It is a free ((L)GPL) Object Pascal compiler which is compatible with the Delphi-compiler. It has an console-based IDE, which proves that you can make very good console-applications with it, and which you can use as an example.
If you want to use a graphical IDE to build your console-application, you can download the Lazarus IDE.
As a bonus your application will run on Windows (32/64 bit), Linux, Mac OS X, FreeBSD, Solaris etc...
In Windows or DOS, I used the conio library from Borland. It's very old but fine enough for a beginner like me.
As Robsoft says Delphi would be a good start. There is Turbo Delphi (Pascal based) or Turbo C++ both free editions.
web site here.
http://www.turboexplorer.com/
Check out some of the mono libs. They have a great one to parse command line arguments but can't remember the namespace.
Miguel just posted some terminal code as well.
For ncurses-like library/framework on Windows, I'll highly suggest to get your hand dirty with PDCurses.
If you trying/using C#, there's Curses-Sharp.
This is the best tool for it I've ever seen!!
1) Create any application using VB6 IDE
2) Convert it to Console Application, using THIS!