I've only seen examples for VB.NET. But I need to do this on VB6. Does anyone have examples or can do this?
How can I see temperature of CPU using VB.NET with Open Hardware Monitor DLL
Can someone edit the code from VB.NET in VB6?
I realized that there are no built-in WinAPI functions for temperature and many uses a third-party dynamic library for this - OpenHardwareMonitorLib.dll . Where can I find all the functions of this library to use in VB6? In addition, the library was created in C# for .NET and 99.9% won't work on VB6! Perhaps there is another way to get the real temperature?
WMI - I don't consider it, because either it doesn't work, or it displays identical parameters
"wmic /namespace:\root\wmi PATH MSAcpi_ThermalZoneTemperature get Current Temperature"
PS: I think until someone writes a ready-made library for use(With a description of the functions), so these questions will appear to many in the future!
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!
I've written some high level interpreters and a simple byte code compiler and interpreter and I want to start making a powerful intermediate language for my small operating system.
It has its own API just like windows does, and the only thing which prevents me of starting this project is to know how these specific API calls (for example the win32 forms api) are being made on the assembly level.
Is there a way to see the assembly output of not optimized c code for example and look how exatly the calls are being made? Or any sources on the WWW?
Thanks in advance
Having C documentation for the API, and knowing the calling convention / ABI, should be enough to create asm that uses it. There's no "magic" needed (no inline syscall instructions or anything like that).
Much of the Win32 API is implemented in user-space DLLs, so API calls are no different from other library function calls. (i.e. an indirect CALL with a function pointer, if I recall correctly).
Often the library function implementation will involve a syscall to interact with the kernel (or for 32-bit code, maybe an int or sysenter, I'm not sure), but this interface is not documented and is not stable across different Windows versions.
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
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).