Jump to content

Search the Community

Showing results for tags 'kifastsystemcall'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

Found 1 result

  1. Usually I don't post things like this, but because KiFastSystemCall hooking only works on x86 systems and doesn't work on Windows 8 or above, it no longer has much use in malware. There are also multiple public implementations for this method, just not very elegant, which I hope to correct. If you haven't read my previous article about this topic, or need a refresher, you can find it here. Performing a System Call KiFastSystemCall has a very strange calling convention (if you can call it that). Each native function (Ex: NtCreateFile) corresponds to a function with the same name in the SSDT. In order to make the transition from user mode to kernel mode, the instruction "sysenter" is used. I don't want to go into great detail on how the sysenter instruction actually enters kernel mode, as that would take up the entire page, but I'll explain the basics: The SSDT is an array of addresses for each native function. The number you see being moved into the eax register is known as its ordinal, and is the position within the SSDT where that functions address is located. When the sysenter instruction is executed the kernel reads the ordinal from eax and uses it to call the corresponding function in the SSDT, before returning execution to usemode. Something important to note is that the native function simply calls KiFastSystemCall and doesn't even set up a stack frame, meaning the address of the first parameter can only be accessed using [esp+8], so we can't just hook KiFastSystemCall with a C function, as this matches no standard calling convention (which is what makes the method so tricky to implement). Dispatching Calls Since the last article I've improved on the dispatching method, which now has two purposes: Determining which native function made the call to KiFastSystemCall, so we can properly handle it. Setting up the stack in such a way that we can access the parameters using plain C. Dispatching Normally we'd hook each individual function we want to intercept with a single handler (proxy), but all native functions call KiFastSystemCall, so we need to think differently. As I explained earlier, the SSDT is an array of addresses and the ordinal (which is in eax when KiFastSystemCall is invoked), corresponds to the position of that function's address within the SSDT. Using this knowledge we can do the same: We create an array of addresses for the the proxy functions and use the ordinal to locate the correct handler using the ordinal in eax. For our SSDT each entry will be 8 bytes, so the handler needs to be placed at our_ssdt[2*ordinal] (in order to get the ordinal for a native function we just read 4 bytes starting at the 2nd byte of the function). You're probably wondering why each entry for our SSDT is 8 bytes, instead of 4; this is because in order to set up the stack before calling the proxy, we need to know how many parameters were passed to KiFastSystemCall (we store the proxy address as the first 4 bytes and the number of parameter as the rest). Preparing the Stack When KiFastSystemCall is invoked, there are two return addresses between the stack pointer and the function parameters (the return from KiFastSystemCall to the native function and the return from the native function). In order to call the proxy function we will get the number of parameter for the function from our_ssdt[2*ordinal+4] and push them to the stack again, in stdcall format (the proxy function is responsible for removing them from the stack). The last thing that is pushed to the stack before we call the proxy is the eax register (the ordinal), we will need this later if we wish to call the original, non hooked, version of KiFastSystemCall. The Code FstHook - This is my own C library which allows a program to easily hook any number of native function using a single hook on KiFastSystemCall. https://github.com/MalwareTech/FstHook/ Source
×
×
  • Create New...