FASM - If file exists - Using GetFileAttributes - INVALID_FILE_ATTRIBUTES value? - winapi

I am using GetFileAttributesA to determine if a file exists or not, in FASM. I know that if the file does not exists the return value will be INVALID_FILE_ATTRIBUTES, but I am not sure how to check for this value.
My Code:
invoke GetFileAttributes,lpFileName
cmp eax,IDK WHAT TO CHECK FOR
je notfound
jne found
invoke ExitProcess,0
Seeing as the compiler does not recognize INVALID_FILE_ATTRIBUTES as a value:
cmp eax,INVALID_FILE_ATTRIBUTES
Will not work.
Does anyone know the value for this constant, so that I can simply enter it manually?
Any help is appreciated. Thanks
After the response from Jens Björnhager, the following is the working code for anyone else interested:
invoke GetFileAttributes,lpFileName
cmp eax,-1
je notfound
jne found
invoke ExitProcess,0
Or Even:
invoke GetFileAttributes,lpFileName
cmp eax,$ffffffff
je notfound
jne found
invoke ExitProcess,0
Thanks again Jens Björnhager!

INVALID_FILE_ATTRIBUTES is defined as -1 ($ffffffff), so check for that.

Instead of using magic numbers in code, you should use properly defined macro INVALID_FILE_ATTRIBUTES. This macro defined in kernel32.inc in INCLUDE folder of fasm installation. You can include this inc file like this
include 'c:\path\to\fasm\INCLUDE\EQUATES\KERNEL32.INC'
or you can add only high level include like
include 'c:\path\to\fasm\INCLUDE\win32a.inc' (or win32w.inc if you use unicode version of winapi)
or if you set include value in Environment section of fasmw.ini just :
include 'win32a.inc'

Related

how to get current running code line and directory name in go [duplicate]

In C/C++ you can use __FILE__ and __LINE__ to get access to the current file and line number.
Does Go provide something similar?
Indeed it does:
http://golang.org/pkg/runtime/#Caller
runtime.Caller can also be used to get the file name/line number of calling functions, too.

WinDbg - getting the address of the last loaded PE into an Alias

I need to get the address of the last loaded PE, into the debugged process, into an Alias / register.
There's no problem to perform this action manually in a WinDbg session, using lm command, and then just to manually copy the address of the loaded module -- but this has to be a part of a WinDbg script.
I can pass the PE's name, full path, pdb path to WinDbg as arguments without a problem. But I doesn't seem to find a way to get the address, without copying it manually, into an Alias.
Maybe there's a way to address the last loaded module's address? (maybe through a specific register, which holds this value)
Maybe the answer is really just that simple: the name of the module is already the address, so there's no additional need to find it out.
0:006> lm m notepad*
Browse full module list
start end module name
011f0000 0145c000 notepad__ (deferred)
0:006> ? notepad__
Evaluate expression: 18808832 = 011f0000
0:006> as lastloaded notepad__
0:006> ? lastloaded
Evaluate expression: 18808832 = 011f0000
If (for whatever reason) you need it as a number, use .printf:
0:006> as /c xx .printf "%d", notepad__
0:006> .echo ${xx}
18808832
0:006> as /c xxh .printf "%x", notepad__
0:006> .echo ${xxh}
11f0000
For me, the problem is rather on the emphasis of "last loaded". How would you figure this out from the list of lm? But since you say that's not a problem for you, I'll not consider this in my answer.

How to correctly create a nim/nimrod windows dll

I want to create a dll from nim code.
But i failed to register some other exports than "NimMainInner".
Even if i try this simple example its not working:
proc Hellow(): cint {.exportc.} =
echo("hello")
return 1
i've compiled it with nim c --app:lib libh4x.nim
and nim c -d:release --app:lib --no_main libh4x.nim
i use Nim Compiler Version 0.11.2 (2015-05-04) [Windows: i386]
to inspect the dll i use dllexp.exe.
I've also tried to load the dll with python ctypes, but none of my exports are shown or are callable. I can see the proc name in the resulting dll with an hexeditor, though.
What have i missed here?
The dynlib pragma was missing. So i changed the definition to:
proc Hellow(): cint {.exportc,dynlib.} =
echo("hello")
result = 1
now it works.
Note: If you use this with pythons ctypes and with function parameters make sure to use ctypes.cdll.LoadLibrary instead of ctypes.windll.LoadLibrary:
Python ctypes argument errors
and to declare the function like this:
proc myinit(procid : int) {.cdecl,exportc,dynlib.} =
discard

is there a way in autoit script to find if current file was included or it is running on its own?

I mean something like get_included_files(); in php or Error().stack; in javascript or $BASH_SOURCE array in bash ?
I've only found in macros ( https://www.autoitscript.com/autoit3/docs/macros.htm ) #ScriptFullPath and #ScriptName.
Check if #ScriptName matches the name of the current script. If it doesn't your script has been included in something else. I use this method to run a unit test if an included script is run as a stand alone script. I add the following code to the end of included_script.au3:
; unit test code
If #ScriptName == "included_script.au3" Then
MsgBox(0, "Unit Test", "Running unit test...", 3)
test()
Exit
EndIf
Func test()
; no test defined
EndFunc
When included in a "main.au3" file, the #ScriptName will be set to "main.au3" and it will not run test().
You can implement the functionality by using a global variable. Say $includeDepth. $includeDepth should be incremented by 1 before any #include and decremented by 1 after it. If $includeDepth is 0, then the code is not running as part of an #include. For example:
Global $includeDepth
$includeDepth+= 1
#include <MyScript1.au3>
#include <MyScript2.au3>
$includeDepth-= 1
; Declarations, functions, and initializations to be run in both "include" and "non-include" modes
If $includeDepth <= 0 Then
; Code for when in "non-include" mode
EndIf
You need to be very consistent in this usage, though. However, as long as library #includes don't include your own scripts (or scripts where this checking is done), there is no need to modify them. From this point of view, it's also not necessary to increment/decrement $includeDepth while including library #includes. However, it doesn't hurt and it reinforces the practice.

Process name missing from GetCommandLine()

I have a problem with the GetCommandLine() API.
It usually returns the executable name followed by a space and arguments. As documentation says, the first token may not have the complete path to the image and blah blah blah.
I never had problems until now that I used CreateProcess with lpApplicationName not NULL.
If I use:
CreateProcess(NULL, "\"c:\\myexe.exe\" param1 param2", ...)
GetCommandLine returns "c:\myexe.exe param1 param2" as expected.
But if I use:
CreateProcess("C:\myexe.exe", "param1 param2")
GetCommandLine returns only "param1 param2".
How do I know if the executable name is given on the command line if another application launches mine?
Also, MFC startup code assumes that the first token on the command line is the executable name and skips it. But if you launch a MFC application with the second CreateProcess API example, MFC's code will skip the first argument.
Not your problem. It's the job of the other application to construct the command line properly. You should simply assume that the first argument is an executable name as expected and skip over it.
I have a workaround which can be helpful in a case like this.
I guess we always be able to check how our module was been started.
In this case we should check first argument.
I will write code because I have some problem with English.
Here two ways:
The first case. we can compare module name with first command line argument.
something like this:
const TCHAR* csCommandLine = ::GetCommandLine();
// Attention!!! the first symbol can be quete
if (*csCommandLine == _T('\"'))
csCommandLine++;
TCHAR sModuleFileName[MAX_PATH];
DWORD dwModuleFileName = ::GetModuleFileName(NULL, sModuleFileName, MAX_PATH);
if (dwModuleFileName && !_tcsncmp(csCommandLine, sModuleFileName, dwModuleFileName)) {
// The command line contains the module name.
}
The second case. we can try to get file attributes for the first command line argument
something like this:
// Attention!!! don't use it case if you are going to pass a file path in command line arguments.
int nArgc;
LPTSTR* szArglist = ::CommandLineToArgvW(::GetCommandLine(), &nArgc);
if (nArgc && ::GetFileAttributes(szArglist[0]) != INVALID_FILE_ATTRIBUTES) {
// The command line contains the module name.
}
::LocalFree(szArglist);
I hope it can be helpful someone.
Regards, Vladimir

Resources