do you know where I can find Windows Low Level Assembly examples programs?
I have some exemples using macros (NASM, MASM) but I want pure assembly, in order I can build a shellcode later.
Thanks a lot guys!
This tutorial might be usefull for you: winamtut
Also this topic in MASM forum is great too.
If your architeture is x64 so try this link too.
And finally if you're interested in some theory, maybe this link could be nice.
Doing Windows GUI stuff in assembly language is a lot of work. This is why the examples you've found use macros - it takes away some of the pain.
If you really want pure assembly language, a great way is to ask your compiler. Write some C code to call CreateWindow or whatever, and then generate an assembly listing from the compiler (or step through it with a debugger).
If by "pure assembly" you mean "not done as a macro or library" then this is what you have to do:
download the masm32 package
check through the copius amount of samples, there will be many using CreateWindow or CreateWindowEx
start your own program
link in windows.h
use the invoke macro to call CreateWindow or CreateWindowEx
if you don't want to use invoke then just push the parameters onto the stack and call the functions directly - as this is what invoke does for you anyway
You can also get lots of help using the MASM package from the masm forum.
The best way to really (and quickly) learn win32 assembly is to decompile simple win32 programs. You could download lena's reversing tutorials from tutsforyou.com. Alternative you could tryout the reverse me's from osix.net - they have some pretty straight forward programs for you to reverse, and the best part is you get to see the masm32 sourcecode after completing the level.
tools: ollydbg, masm32 etc.
books: win32 assembler coding by Goppit, the arteam's PE compendium, intel developers handbook
hxxp://osix.net
hxxp://tuts4you.com/download.php?list.17
hxxp://www.intel.com/products/processor/manuals/
I'm not very pleased with your "in order I can build a shellcode later." - it's stuff like that which gives assembly a bad name.
I'd suggesty you take a look at FASM instead of MASM, though, since it's "closer to the metal", and directly supports binary output.
For learning to build shellcode I would suggest creating a very simple c program that does what you want the shellcode to do and than disassemble that using IDA or Immunity (or whatever debugger / dissasembler that you are familiar with). Than you can see what the instructions are that are being used.
I would also recommend the following books:
Hacking: The Art of Exploitation (2nd Edition)
The Shellcoder's Handbook
Related
I'm writing a 32-bit assembly program with MASM and the Irvine32 library, and am trying to save the contents currently written in the console window to a buffer. As far as my research on the topic has told me, (and please correct me if I'm wrong), I need the ReadConsoleOutputCharacter Win32 API function for this. However, when invoking it, I get told that the symbol is undefined. In the same program, invoking another function like WriteConsole works.
To investigate, I checked the Smallwin.inc file that comes with the Irvine library, and for some reason, the function isn't prototyped in there. It's strange because the function is listed in Table 11-2 of the book, the book explicitly says that all Win32 functions are supported by the Irvine library, and Smallwin.inc even prototyped the Write counterpart of this very function! I can't seem to find an answer as to why the function isn't included. Could someone help me figure out how I can use this function, maybe by adding the appropriate prototype to Smallwin.inc or including something else within the Irvine library?
I'm coding on Visual Studio Community 2019, using the Irvine32 library. If there's anything else I should add to my question please let me know.
Thanks in advance!
assembly programming in Emacs how to?
I want Emacs to do following things
1. assembling
2. run the just before made program inside Emacs
3. debugging with watching flags and registers as like ollydbg or softice
4. decompile executable file for see what assembly codes are made by c
but I don't know how to do this
could somebody let me know ?
Which operating system (and machine architecture) are you using? I think that's quite essential information for questions about assembly programming.
I'll try to answer your four points anyway:
Just run your assembler (e.g. as) from M-x compile.
Run it from a shell buffer or from shell-command (bound to M-!).
Emacs' built-in graphical debugging support is started with M-x gdb. You may have to look for some external debugger support package if GDB is not suitable for your purposes.
For disassembling object code, I'd use GDB. But I think if you have the C sources, it would be better to compile them with the -S flag to see the assembly code emitted by the compiler instead of what can be reconstructed from the machine code.
Since you mention SoftICE, I'm assuming you're on windows.
(Good old times, by the way. If anybody ever used SoftICE on windows 9x, he/she will know what I mean :)
I don't use Emacs, but here's how to get started:
Get the tools you need to assemble your program (ie: at least, the assembler and the linker). On windows, the MASM package comes with everything you need : http://www.masm32.com/
Figure out wich commands you need to compile a simple hello world.
Configure Emacs so that it runs the above commands for you
I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
I'm writing a compiler that converts source code (written in a small imperative programming language) to Intel AT&T 32-bit assembler.
I tend to spend a lot of time debugging, because of nasty offset-mistakes etc. in the generated code, and I would like to know if anyone knows of a tool to "walk through" the generated assembler code step-by-step, visualizing what's on the stack etc.
I use Ubuntu Linux as my development platform, and I'm comfortable with the terminal -- a GUI-program would be nice though. Does it exist? Or is there a good reason it doesn't (maybe the problem isn't so straightforward..?)
If you have good ideas for approaching debugging tasks in assembly code, I'll be glad to hear from you!
I like EDB (Evan's Debugger) on Linux. It has a nice, easy-to-use, QT4-based GUI. Its developer's goal is to make it similar to OllyDbg. And it's being actively maintained:
EDB on FreshMeat
I'm pretty sure it's installable through Synaptic on Ubuntu as well. Enjoy!
Is the end result of the compile process something that you can actually execute, and therefore examine in a debugger? If so the Data Display Debugger (ddd) might be useful.
My experience with debuggers such as Olly and EDB is quite sparse, so I wasn't able to solve my problem with those. I ended up
scattering calls around to a Debug function in the source code, nailing down bad register values
letting the compiler output HTML-formatted code with useful metadata for different iterations in the liveness analysis etc.
I have a desktop program I downloaded and installed. It runs from an .exe file.
Is there some way from the .exe file to tell what programming language was used to write the program?
Are there any tools are available to help with this?
What languages can be determined and which ones cannot?
Okay here are two of the sort of things I'm looking for:
Tips to Determine Whether an App is Written in Delphi or Not
This "IsDelphi" program by Bruce McGee will find all applications built with Delphi, Delphi for .Net or C++ Builder that are on your hard drive.
I use WinDowse (a small freeware utility written in Delphi) to spy the windows of the program.. for example if you look at the "Class" TabSheet you can discover the "Class" Name of the control..
For example:
TFormXX, TEditYY, TPanelZZZ for delphi apps
WindowsForms10.XXXX.yyy, for .NET apps
wxWindowsXXX for wxWindows apps
AfxWndXX for MFC/VC++ apps (I think)
I think this is the fastest way (although not the most accurate) to find information about apps..
I understand your curiosity.
You can identify Delphi and C++ Builder apps and their SKU by looking for a couple of specific resources that the linker adds. Specifically RC Data\DVCLAL and RC DATA\PACKAGEINFO. The XN Resource Editor makes this a lot easier, but it might choke on compressed EXEs.
EXE compressors complicate things a little. They can hide or scramble the contents of the resources. Programs compressed with UPX are easy to identify with a HEX editor because the first 2 sections in the PE header are named UPX0 and UPX1. You can use the app to decompress these.
Applications compiled with .Net aren't difficult to detect. Recent versions of Delphi even include an IsAssembly function, or you could do a little spelunking in the PE header. Check out the IsManaged function in IsDelphi.
Telling which .Net language was used is trickier. By default, VB.Net includes a reference to Microsoft.VisualBasic, and VCL.Net apps included Borland specific references. However, VCL.Net is defunct in favour of Delphi Prism, and you can add a reference to the VB assembly to any managed language.
I haven't looked at some of the apps that use signatures to identify the the compiler, so I don't know how well they work.
I hope this helps.
First, look to see what run time libraries it loads. A C program won't normally load Visual Basic's library.
Also, examine the executable for telltale strings. In most executables, this is near the end. If the program uses string constants, there might be a clue in how they are stored.
A good disassembler, plus of course an excellent understanding of the underlying CPU architecture, can often help you identify the runtime libraries that are in play. Unless the exe has been carefully "stripped" of symbols and/or otherwise masked, the names of symbols seen in runtime libraries will often provide you with programming-language hints, because different languages' standards specify different names, and vendors of compilers and accompanying runtime libraries usually respect those standards pretty closely.
Of course, you won't get there without knowledge of the various possible languages and their library standards -- and if the code's author was intent to mask the information, that's not too hard for them to do, either.
If you have available a large set of samples from known compilers, I should think this would be an excellent application for machine learning. I believe so-called "supervised learning" is relevant here. Unfortunately I know next to nothing about the topic—only that I have heard some impressive results presented at conferences.
You might dig through the proceedings of the Working Conference on Reverse Engineering to see if anyone else is interested in this problem.
Assuming this is an application for Windows...
Does Reflector recognize it as a .NET assembly? Then it's MSIL, 99% either VB or C#, but you'll likely never know which, nor does it matter.
Does it need an intrepreter (like Java?)? Then it's Java (or whatever the interpreter is.)
Check what runtime DLLs it requires.
Does it require the VB runtime dlls? Congratulations, VB from VisualStudio 6.0 or earlier.
Does it require the Delphi dlls? Congratulations, Delphi.
Did you make it this far? C/C++. Assume C++ unless it requires msys or cygwin dlls, in which case C has maybe a 25% chance.
Congratulations, this should come out correct for the vast majority of Windows software. This probably doesn't actually help you though, as a lot of the same things can be done in all of these languages.
IDA Pro Free (http://www.hex-rays.com/idapro/idadownfreeware.htm) may be helpful. Even if you don't understand assembly language, if you load the EXE into IDA Pro then its initial progress output might (if there are any telltale signs) include its best guess as to which compiler was used.
Start with various options to dumpbin. The symbol names, if not carefully erased, will give you all kinds of hints as to whether it is C, C++, CLR, or something else.
Other tools use signatures to identify the compiler used to create the executable, like PEiD, CFF Explorer and others.
They normally scan the entry point of the executable vs the signature.
Signature Explorer from CFF Explorer can give you an understanding of how one signature is constructed.
It looks like the VC++ linker from V6 up adds a signature to the PE header which youcan parse.
i suggest PEiD (freeware, closed source). Has all of Delphi for Win32 signatures, also can tell you which was packer used (if any).