Can someone please explain me what is a Pseudo Variable and what exactly is the first parameter to the function WinMain below??
GetStartupInfo(&StartupInfo);
int nMainRetVal = WinMain((HINSTANCE)&__ImageBase, NULL, pszCommandLineAnsi,
(StartupInfo.dwFlags & STARTF_USESHOWWINDOW)
? StartupInfo.wShowWindow : SW_SHOWDEFAULT);
Also what does the following statement do??
extern "C" const IMAGE_DOS_HEADER __ImageBase;
The first parameter of WinMain is a so-called "application instance handle". This thing originated from the ancient Windows 3.x times, where it denoted the handle to the running instance of the application. But starting from Win32 (Windows 9x/NT) this parameter is the base address of the executable module mapping in the process virtual address space.
So, what you see is the image base address __ImageBase, which is cast to HINSTANCE to meet the WinMain signature.
Now, __ImageBase - I guess it's a build-time-generated structure that resides exactly at the image starting address.
And, I'm not certain what is a "Pseudo Variable". But perhaps this is exactly __ImageBase.
__ImageBase is the "current module's HINSTANCE from a static library". This is a so called pseudovariable which the linker provides. This pseudovariable is the address where the module has been loaded in memory. Using this pseudovariable you can directly access the mapped image from memory and address its content.
Related
I want to print real physical address that is stored in a variable of type phys_addr_t. Now I'm doing something like this:
phys_addr_t paddr;
...
paddr = virt_to_phys(some_virt_addr);
pr_info("%pa", &paddr);
...
As for documentation:
Physical addresses types ``phys_addr_t``
========================================
::
%pa[p] 0x01234567 or 0x0123456789abcdef
For printing a ``phys_addr_t`` type (and its derivatives, such as
``resource_size_t``) which can vary based on build options, regardless of
the width of the CPU data path. Passed by reference.
but I'm a bit confused about Passed by reference, because it is already something like reference. So my actual questions are:
How to correctly print phys_addr_t using printk?
What does Passed by reference mean here?
What does the [p] postfix of %pa[p] mean?
If my example is not correct or inefficient, please show me how it should be.
You are doing it correctly:
phys_addr_t paddr = 0x1234;
printk(KERN_INFO "%pa\n", &paddr);
// Result: 0x0000000000001234
"Pass by reference" means to pass a pointer to the physical address you want to print (&paddr) instead of directly passing its value (paddr).
The [p] suffix in the documentation means that the last p is optional. You can use %pa or %pap. The final p is not necessary and also doesn't change the output format (as you can see from the source here).
We have a kernel module using filename_lookup call which is not exported anymore in RHEL8 Kernel 4.18. But found another system call exported in /proc/kallsyms, which is filename_lookup.part.64
What is filename_lookup.part.64 ? Can I call it in our code using the address exported in /proc/kallsyms?
I am not able to find any documentation on filename_lookup.part.64.
Is it safe to use this kind of undocumented APIs?
struct filename filename = { .name = name };
struct nameidata nd;
filename_lookup(AT_FDCWD, &filename, LOOKUP_PARENT, &nd);
I am looking to find the calls that can be used to replace the above in the absence of filename_lookup()
Regarding your question
What is filename_lookup.part.64 ? Can I call it in our code using the
address exported in /proc/kallsyms?
as can be read at here, it is the original filename_lookup function without some parts that the compiler optimized and set them inline, so its not safe.
As said earlier #user3248278, would be easier to use the wrappers such as kern_path or user_path_at_empty.
Filename_lookup is now wrapped with various APIs, which are exported, for example -
*int kern_path(const char *name, unsigned int flags, struct path path) - for getting inodes in kernels.
You can easily search in elixir for filename_lookup and you can find the wrappers.
Related to but not equivalent to DLL Get Symbols From Its Parent (Loader)
Is there a way to convince the Windows loader to resolve a particular symbol referenced by A.dll from either the loading executable or an intermediate dll without specifying the file to resolve symbols from in A.dll?
It's pretty obvious how to do it if the loading .exe has a known name, but if it isn't ...
Here's a good reason why you'd actually want to do this: https://www.gnu.org/software/libc/manual/html_node/Replacing-malloc.html
If this can be done, a good answer would say how to do it some way or another.
I'm half-expecting the answer is it can't be done. In that case, a good answer would show why this is impossible. "The build tools don't support this." is a bad answer.
when we use import we need exactly indicate module name and function name. and we can not use complex algorithms. also for exe not exist well known alias which we can use in place exactly exe name. for compare: in case get GetModuleHandle we can use NULL for get handle to the file used to create the calling process (.exe file). but in case LoadLibraryExW we can not use 0 or empty string (L"") or some another alias for say - we want handle to exe. when loader load our module - he read dll name from IMAGE_IMPORT_DESCRIPTOR and try found or load module with this name first by low level, private, core of LoadLibraryExW. here need exactly name. or load fail. as result use import - not a solution here, if we dont know exe name at build time
possible variant - resolve functions pointers yourself at runtime. here we can get exe HMODULE by GetModuleHandle(0). also if need we can search function not only in exe but somewhere else. can implement any search algorithm.
here exist several ways. for concrete example let we need get pointer to function with signature:
void WINAPI fn(int i);
we can declare pointer to this function and resolve it in runtime
void (WINAPI *fn)(int);
*(void**)&fn = GetProcAddress(GetModuleHandleW(0), "fn");
say on DLL_PROCESS_ATTACH
a slightly different solution (although at the binary level it is completely equivalent) declare function with __declspec(dllimport) attribute. this is for CL.EXE (more known as MSVC) compiler only. so
__declspec(dllimport) void fn(int i);
in this case CL yourself generate pointer to function with name __imp_ ## __FUNCDNAME__ name. so by fact the same as in first variant, when we declare pointer yourself. only difference in syntax and.. symbol name. it will be look like __imp_?fn2##YAXH#Z. problem here that __imp_?fn2##YAXH#Z not valid name for c/c++ - we can not direct assign value to it from c/c++. even if we declare function with extern "C" - function name will be containing # symbol (illegal for c++) for __stdcall and __fastcall functions, for x86. also name will be different for different platforms (x86, x64, etc). for access such names - need or use external asm file (for asm ? and # symbols valid in name) or use /alternatename linker option - for set alias for such name and access symbol via it. say like
__pragma(comment(linker, "/alternatename:__imp_?fn##YAXH#Z=__imp_fn"))
and init via
*(void**)&__imp_fn = GetProcAddress(GetModuleHandle(0), "fn");
another option use __declspec(dllimport) in function declarations + add import library, where all __imp___FUNCDNAME__ (such __imp_?fn2##YAXH#Z) is defined. (even if we have not such library we can easy create it yourself - all what need - correct function declarations with empty implementation). and after we add such import lib to linker input - add /DELAYLOAD:dllname where dllname - exactly name from import lib. sense that this dllname will(can) be not match to exe - all what need - it must be unique. and we need yourself handle delayload (called when we first time call fn). for implement delayload we need implement
extern "C" FARPROC WINAPI __delayLoadHelper2(
PCImgDelayDescr pidd,
FARPROC * ppfnIATEntry
);
we can implement it yourself, or add delayimp.lib to our project. here (in delayimp.lib) the delayLoadHelper2 and implemented. however we must customize this process (default implementation(look in /include/DelayHlp.cpp) will be use LoadLibraryExA with dllname which is not excepted in our case - otherwise we can be simply use import as is). so we need mandatory implement __pfnDliNotifyHook2:
for example:
FARPROC WINAPI MyDliHook(
unsigned dliNotify,
PDelayLoadInfo pdli
)
{
switch (dliNotify)
{
case dliNotePreLoadLibrary:
if (!strcmp(pdli->szDll, "unique_exe_alias"))
{
return (FARPROC)GetModuleHandle(0);
}
}
return 0;
}
const PfnDliHook __pfnDliNotifyHook2 = MyDliHook;
we can look for dliNotePreLoadLibrary notification and instead default LoadLibraryEx(dli.szDll, NULL, 0); use GetModuleHandle(0); for get base of exe.
the "unique_exe_alias" (which linker got from import library) here play role not real exe name, which is unknown, but unique tag(alias) for exe
On Linux, when linking I can specify any virtual address for a section:
ld -Ttext 0x10000000 -Tdata 0x20000000 foo.o -o foo
But I don't see such option for Windows' link.exe.
Is it possible to specify PE section start addresses somehow?
MinGW ld can put the sections at arbitrary addresses. Dumpbin and disassemblers can handle it without problem.
But it seems Windows does not accept anything but the default address: if you try to set it to a different value Windows will say "not a valid Win32 application".
The base address must be 0x400000 or 0x1000000.
And the .text section must be at 0x401000 or 0x1001000.
Also it seems no gaps allowed between the sections. If I try to place the .data section to 0x403000 instead of 0x402000, then Windows is unable to load it...
(I maybe wrong, or mingw ld is buggy...)
When using GCC, this page explains how to define variables at absolute addresses (including mentioning the section in which they should reside) : https://mcuoneclipse.com/2012/11/01/defining-variables-at-absolute-addresses-with-gcc/
The idea I use here is to put the variable with a special section
name, and then place it in the linker file at an absolute address.
unsigned char __attribute__((section (".myBufSection"))) buf[128]
__attribute__ ((aligned (512)));
With this, my variable will be put into a section named
‘.myBufSection’, and it will be aligned on a 512 address boundary.
The next step is to place that section at an address in the linker file.
SECTIONS
{
/* placing my named section at given address: */
.myBufBlock 0x20000000 :
{
KEEP(*(.myBufSection)) /* keep my variable even if not referenced */
} > m_data
/* other placements follow here... */
}
PS: Another method is mentioned in How can I declare a variable at an absolute address with GCC?
PS 2: Another related (alas unanswered) question is this : How to place a variable at a given absolute address in memory (with Visual C++)
How do I programmatically trigger Flip 3D on Windows Vista and 7?
Is there an API for this and if so, what is it called and where can I find the relevant functions? (I need a specific answer, eg a web link to the actual functions, not something generic like "Oh, it's in DirectX.")
On a related node, I have a Logitech mouse that has a "Document Flip" button that invokes Flip 3D (and then I can press up/down keys to page through the results.) I am curious if they are using an official Windows API or if there is some low level hackery going on.
you need to run a function from dwmapi
Sadly there is no proper funktion name only the ord-number 105
You can try this by executing %WinDir%\System32\rundll32.exe dwmapi #105 from Run-dialog or cmd.
edit
ive found out the Windows' API GetProcAddress Function accepts ord-numbers (the 105) as second parameter as well as proper name
lpProcName [in]
The function or variable name, or the function's ordinal value. If this parameter is an ordinal value, it must be in the low-order word; the high-order word must be zero.
so use this code
typedef vois (__cdecl *FlipProc)();
HINSTANCE hDwmApi = LoadLibrary(TEXT("dwmapi.dll"));
FlipProcAdd = (FlipProc) GetProcAddress(hDwmApi, (LPCSTR)105);
(FlipProcAdd)();