I am writing a simple rootkit (just to learn how the kernel works ;)) that is hooking the filldir function in the kernel.
I am using the inline hook method - writing a JMP opcode in the beginning of the function.
the function looks like -
struct sym_hook *sa;
unsigned char o_code[HIJACK_SIZE], n_code[HIJACK_SIZE];
unsigned long o_cr0;
// mov rax, $addr; jmp rax
memcpy(n_code, "\x48\xb8\x00\x00\x00\x00\x00\x00\x00\x00\xff\xe0", HIJACK_SIZE);
*(unsigned long *)&n_code[2] = (unsigned long)new;
printk("Hooking function 0x%p with 0x%p\n", target, new);
memcpy(o_code, target, HIJACK_SIZE);
write_cr0(read_cr0() & (~ 0x10000));
memcpy(target, n_code, HIJACK_SIZE);
write_cr0(read_cr0() | 0x10000);
While compiling and testing on Ubuntu 16.04 (kernel 4.15) everything works just fine, but when using Ubuntu 19.10 (Kernel 5.3) - I get a crash every-time I insmod.
the crash is because of permissions when writing to protected memory - that means (I think so) that the write protection disabling line is not working (write_cr0(read_cr0() & (~ 0x10000));).
I didn't found any documentation explaining why it's not working on the new Kernel version, is it really a related to the kernel version? or I am doing something wrong ? My guess is that there was added some new protection method in the new version and the 'old' protection disabling is not working any more ...
also, if it's really kernel version issue, is there a way to disable that protection in the new kernel version?
btw, tried also disabling using this code -
unsigned long cr0 = read_cr0();
clear_bit(16, &cr0);
asm volatile("mov %0,%%cr0" : "+r"(cr0), "+m"(__force_order));
Here is an example program that illustrates my problem, it can be compiled using FlatAssembler without using a linker:
format PE console
entry start
include 'win32a.inc'
section '.text' code executable
start:
mov dword [esp],_output1
call [printf]
mov dword [esp+4],first
mov dword [esp],_input
call [scanf]
mov dword [esp],_output2
call [printf]
mov dword [esp+4],second
mov dword [esp],_input
call [scanf]
finit
fld dword [first]
fabs
fld dword [second]
fxch
fld1
fxch
fyl2x
fldl2e
fdivp st1,st0
fmulp st1,st0
fldl2e
fmulp st1,st0
fld1
fscale
fxch
fld1
fxch
fprem
f2xm1
faddp st1,st0
fmulp st1,st0
fstp dword [result]
fld dword [result]
fst qword [esp+4]
mov dword [esp],_output
call [printf]
invoke system,_pause
invoke exit,0
_output1 db "Enter the first number: ",0
_output2 db "Enter the second number: ",0
_input db "%f",0
_pause db "PAUSE",0
_output db "The first number to the power of the second number is: %f.",10,0
section '.rdata' readable writable
result dd ?
first dd ?
second dd ?
section '.idata' data readable import
library msvcrt,'msvcrt.dll'
import msvcrt,printf,'printf',system,'system',exit,'exit',scanf,'scanf'
So, the expected output is, of course, something like this:
Enter the first number: -2.5
Enter the second number: -2
The first number to the power of the second number is: 0.16
And that's the output I indeed get if I run that program on Windows 10. However, if I try to run that program on WINE on Oracle Linux, the output I get is:
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 2
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 2
wine: Bad EXE format for Z:\home\teo.samarzija\Documents\Assembly\debug.exe.
Any idea what's going on?
I've done a little research, and I can't find any reference confirming that _printf and _scanf are even implemented in WINE's MSVCRT. However, I am not sure that's the problem, and, if it is a problem, that that's the only problem.
However, if I try to run that program on WINE on Oracle Linux, the
output I get is:
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 2
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 2
wine: Bad EXE format for Z:\home\teo.samarzija\Documents\Assembly\debug.exe.
A "Bad EXE format" error is something different entirely. It doesn't imply that the problem is a missing imported function. The loader never got that far. It wasn't even able to read your binary. This is very likely caused by a bitness mismatch. For example, trying to run a 64-bit application on a 32-bit system.
Aside from this problem, it is worth pointing out that your attempted use of C runtime library functions is inherently non-portable. It might work, if Wine (or whatever other runtime environment) provides a function with an identical signature, but it very likely won't.
I suppose I should further clarify, since calling a standard C runtime library function "non-portable" may raise a few eyebrows. These functions are portable at the source-code level, but not at the binary level. Even without the added complexity of Wine, the C runtime library functions are non-portable, as Microsoft's CRT is versioned—you have to link to the appropriate version and have that DLL available at runtime, or your application will not work.
This exact problem is why Windows provides wrappers for these standard functions as part of the basic platform API, which is universally available. If you want to be fully portable to all implementations of the Win32 environment, and you aren't linking in your own copy of the C runtime library, then you should call these functions instead.
The Win32 version of the sprintf function is wsprintf. It has the same interface as sprintf, so you can call it the same way, as a drop-in replacement. In fact, although you shouldn't rely on this, it is implemented by Windows as a simple wrapper around the sprintf version provided by the local copy of the C runtime libraries.
If you want a version to which you can pass an argument list (a la vsprintf), then you can call wvsprintf.
Note that, unlike most of the Windows API functions, these functions use the __cdecl calling convention, not the __stdcall calling convention. Make sure that you are adhering to that in your assembly code. In short, that means passing arguments from right-to-left and cleaning up the stack at the call site.
Microsoft has, however, deprecated these functions, as they aren't entirely safe (buffer overflows and etc. are possible). As replacements, they offer the functions in the StrSafe.h header. These functions come in two variants: those which take a count of bytes (Cb) and those which take a count of characters (Cch). The relevant ones to this discussion would be either StringCbPrintfA or StringCchPrintfA. These are trickier to use from assembly language, however, because they're meant to be used inline by simply including the StrSafe.h header file. You can use them in library form, but then you'll need to pass the corresponding StrSafe.lib stubs to the linker. Note that linking to this library means your application will only run on Windows XP with SP2 or later.
This gets you halfway there. You are actually trying to call printf, rather than sprintf. The gap, of course, is getting the formatted string written to the console. Once you have the formatted string (generated by wsprintf, StringCchPrintfA, or whatever), that can be accomplished by calling the WriteConsole function, which is the Win32 API for writing output to the console window. If you want STDOUT, then you need to open that handle first with GetStdHandle(STD_OUTPUT_HANDLE).
Anyway, I got the answer:
https://www.linuxquestions.org/questions/linux-general-1/can%27t-install-wine-on-64-bit-oracle-linux-4175655895/page2.html#post6012838
In short, on 64-bit Oracle Linux, WINE needs to be compiled from source to work properly.
After upgrade app from Clarion 9.1 to Clarion 10 and after first build an error acquiring.
Error: Unresolved External SHGetFolderPathA in EFOCUS.obj. I include efocus.clw in solution. Efocus.clw and efocus.inc are in C10 folder.
Help me please
I dont use the enhanced focus feature, but a couple of things might help:
SHGetFolderPathA is deprecated but should still be around since its in Shell32.dll. Its possible SV eliminated it from their lib in lieu of the replacement call (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx ), but I doubt it. Even so, you could make your own lib using the DLL and Libmaker.exe (which is shipped in \c10\bin).
It may be simpler than this. Delete the clw and obj from your app folder (or sub-folder where the .RED directs them) and recompile.
My application has minSdk at 15 and targetSdk at 20. I need a support library because my application uses the PageViewer view.
Reading the documentation I read that the support library vx is designed to be used on the API level x. I think that the version's number x should be between 15 and 20.
How should I choose that number?
Secondly, using android studio I have to add the following line in a file named build.grandle, for using the support library v4.
compile 'com.android.support:support-v4:20.0.0'
What is the meaning of the suffix 20.0.0?
The support libraries have different revisions/versions. You can check more info here
Adding this part in your gradle file:
compile 'com.android.support:support-v4:20.0.0'
you are telling gradle to get the support-library-v4 with revision 20.0.0.
About which version you should use. If you compiling with api20, you can use the revision 20.
Suppose that I have a 64 and a 32 bit version of a certain library (VC++, VS2013)
(I would really appreciate it if this fact would not draw away attention from the question itself)
Now, Suppose that I have a project that is also compiled under the two latter platforms
Is there a way in which I can make the IDE/linker use the 32 bit version of the library when compiling the project under the 32 bit platform,
and of course, using the 64 bit library when compiling under the 64 bit version
Thanks in advance
Eyal Perry
Recall that all project settings are per configuration/platform pair. When working with Project Properties dialog, pay attention to Configuration and Platform drop-downs at the top.
So, under Linker > Input > Additional Dependencies, simply mention 32-bit LIB file for Win32 platform, and 64-bit LIB for Win64 platform.
You need not to include your library name twice (or as many time your platform or config), as it will be same. Additional lib directory needs to be changed.
Properties->(Select configuration="All Configuration" platform="All Platforms")->Linker->Input->Additional Dependencies->(Include your lib name - which will be same, for x32, x64, release, debug...)
What you really want to change is additional library path! as below:
Properties->(Select configuration="release or debug " platform="win32")->Linker->General->Additional library Directories->Provide here win32 lib directory.
Repeat this for platform x64 givign respective directory.