Wednesday, 9 April 2014

Still a alive - Update


I have not posted anything for a while, but I am going to be posting from now. I apologize for the long delay, I did not really get around to posting any interesting topics recently however I plan on also writing few blogs regarding security soon or later.

Nevertheless, I am going to be writing about physics, cosmology as well after people requested me to write few blogs pertaining about physics and space.

Anyway, in security I will be covering:

- Theories of Anti-Virus development (Heuristics)
- How DDoS works
- Theory of Network analysis
- Self-Protection mechanisms

I also have a long list of planned topics to cover in future:

- AI (Non-Game based)
- Encryptions
- Science of Sci-Fi
- Simulation Programming

That being said, stay tuned.

Sunday, 5 January 2014

Global Remote Detour: KiFastSystemCall


I am not planning on explaining my code too much but rather give code, which is more or less straightforward in terms of the functions used and the simple logic.

Unlike the previous remote detour given I am not really creating a running thread as that will just be too slow and unneeded work.

There are 2 functions needed for the global injection: Provider(void) & Injector(DWORD Pid)
The function Provider(void) is responsible for providing each process's PID to the Injector function, then the Injector function will:

  1. Open the PID via a call to OpenProcess
  2. Using the handle it will suspend the process, ready for injection
  3. It will then write the callback into the process memory space
  4. Then will create a char array of machine code (JMP ---) then will annotate the remote callback address on to the char array.
  5. The char array will be then written on KiFastSystemCall address, 
We have detoured KiFastSystemCall, the uses of such detours are endless:

  • Self-Protection
  • Proactive AV scanning
  • Complete Control over system
  • Helpful Debugging Information
The Code Metrics:

Line Count:  105 Lines
Size: 3.05 KB (3,125 bytes)

Stay Tuned,

Saturday, 30 November 2013

Detoruing x64 System Call Stub: X86SwitchTo64BitMode


It's been a while since I posted anything, anyway now that I am here I am going to be giving a detour for: X86SwitchTo64BitMode.

X86SwthTo64BitMode is the deepest call before everything switches into 64 bit mode and other inaccessible DLL files. Additionally X86SwitchTo64BitMode can be detoured fairly easily unlike KiFastSystemCall, a usual JMP would do the job especially because we don't care if we overwrite instructions because we are not jumping back to the original instruction.

The Code is more or less pretty straightforward for any Windows savvy users.

Link: X86SwitchTo64BitMode.cpp

As said before, this code can be easily incorporated into a Global detour, additionally you may find this suitable to incorporate into your projects with credits to - Code Empire.


Wednesday, 13 November 2013

Security: Process Injection & detouring


I will be posting on how to inject into foreign processes then place a detour on specific API's, our example being MessageBoxA however this technique can be adapted to any API detour with slight change. Some useful API calls to detour would be:
- NtOpenProcess
- NtTerminateProcess
- NtQueryDirectoryFile
- NtQuerySystemInformation 

more exotic API's include:

- TurboDispatchJumpAddressStart
- KiFastSystemCall
- X86SwitchTo64BitMode
- Wow64SystemServiceEx
- CpuSimulate

As you may guess, there is again both malicious and positive purposes. It is always beneficial to understand these things, especially in case these task raise up.

The injection is modified slightly from the Mozilla Firefox post which was posted last month. I could have placed a detour directly on the API address using few easy workarounds however I simply created a entire thread which places the detour, just to show it as a Proof-Of-Concept code to newbie security analysts & security developers.

The code follows:

  • Open the process with flag set to PROCESS_ALL_ACCESS however this can be reduced to bare minimum
  • Create and fill a _CODE structure ready to be added as a parameter to our injected thread
  • Then allocate all the space needed for the processes which include - Thread, Parameter
  • Create the remote thread
The explanation above shows the procedure to inject code into foreign process but the thread performs something more or less the most important part of the program:
  • Use the _CODE structure then store the appropriate members in specific typedefs to be called
  • Calls MessageBoxA with parameters being set to those given from the _CODE structure
  • Finally patches MessageBoxA to redirect the control to a callback 
  • Additionally the thread also patches the callback to ensure the callback returns the control back to original 
Now I will elaborate on the job of the callback:
  • The callback reinstates the lost bytes of the original instructions 
  • Jumps back to original MessageBoxA  
  • Returns 
You would get a good idea on how it works, however for those who still have no clue here is the download:

Until Next Time,

Thursday, 31 October 2013

Security: Social Engineering using UAC


Today, we will be exploiting the UAC Architecture - for developers wanting to become savvy on Windows, UAC is a abbreviation for User Account Control it is designed to allow individual processes to run in various Account Levels, additionally it protects the host from malicious software from gaining higher privileges without consent.
However Microsoft while developing UAC, and perform bug checks they forgot to notice Windows Command Preprocessor, functionality which defeats the purpose of Command Prompt.

As you know Windows Command Preprocessor has extremely rich parameter usage, which can be exploited in order to run a different program but UAC shows that the program is trusted:

*** The Username is blurred out, for obvious reasons ***

 The above UAC is the default UAC which pops up, this UAC is also set to the highest level to show it works effectively on the most harshest\secure PC's.
While this look completely trustable, you can see the real-trick when we click on the "Show details" expander control located bottom-left.
Once we click that the true identity is shown:

As you may observed, only when we press "Show details" expander control located bottom-left we can see the true identity of this UAC alert, however majority of the time 80-90% of the Users tend to never click on show details especially if the UAC has a trusted software wanting elevation.

To show even more, if we press publishers, it shows Certificate is OK, many may think this is about the Malware but the certificate is CMD.exe's therefore we have performed Social Engineering Attack.
We can easily perform this via a simple call to ShellExecuteExA\W, with the lpVerb set to - "runas" and lpFile set to - location of Cmd.exe however to start our Malware as well we can use lpParameters to elevate our Malware like so - /c start %Malware Path%.
This technique will not only reduce huge amount of code and effort but is useful when deploying untrusted applications in the sense that it does not contain any digital signatures.
Source code:

As you may see I have not included entire source file such as headers as those can be added upon easily.


UAC is pretty secure itself such as prevents buffer overflows (to a certain extent of course) and such similar attacks however, it need more stricter settings by maybe show a label suggesting a parameter is added or showing additional details by default rather than giving user a choice.

As for the current UAC, it can still be "hacked" via a code injection into UAC when it pops up to hide the "show details" tab  therefore evading prying eyes even further.

Stay Tuned,

Monday, 28 October 2013

Project Delta Game Development


Unlike previous posts, this is nothing related to Security Field - I have been working on  Game tirelessly for few months now and I have yet to even start releasing the game as I still need to implement stronger AI, Bigger map, Higher Graphic Resolution, More Levels & more!
Those who are interested in the game storyline and game concepts:

" As the tension is rising between US and Soviets, CIA has uncovered a dangerous plan by the KGB to invade the US. 
KGB has set up Sleeper agents across the US states and even set Missile Launch Centres on the Moon.
You and your team, team of deadly assassins and soldiers must prevent nefarious plan from taking place. 

Wage War against your foes in Frontiers of Space, Moon and Mariana Trench... 
Play as iconic historical figures - Neil Armstrong, John F Kennedy.

Get Ready For War!"

Those who liked the game storyline, I am going to be publishing this for FREE!
A screenshot of the Game:


This level, is when the player is in Cuba.


Security: Blocking DLL Injections


Today - we will be discussing about Injections and prevention of Injections, malware in generally notorious for stealing vital information from Softwares - This causes concern for most Developers working in the Security and Financial Industry as in these field, safeguarding customer data is a very important goal.

Malware(s) perform DLL Injection into the target, the DLL loaded would be a malicious DLL which would steal personal information, the generic malware authors tend to use LoadLibrary and WriteProcessMemory in a combination in order to successfully load a DLL into the Processes memory space, although this many Security Developers and Financial Developers simply detour LoadLibrary and expect the Application to be safe, however a simple call to a lower level function would bypass your layered protection, thus breaching the security.
However if we wanted to block the injection, without ourselves injection then performing a system-wide patch - we can use a LDR function which is function used to load DLL onto our Application, placing a nasty detour on that function would completely safeguard us against many User-Level Malware including Citadel.

The "magic" function is called LdrLoadDll, after we detour this function - we will be able to block many Injector(s) example  - WinInject.

Let's Get Coding, First we will start by the function responsible for patching LdrLoadDll:

As you see, we are not doing any special detouring method but the usual jmp method, I did not re-protect the memory address space as you can do anything more like add your own code\replace code.

Next we will be covering the Callback, the callback itself is more or less, simple filtering mechanism however you can customize the mechanism to your own liking:

As you may have noticed the callback simply blocks all DLL locations\names in the C: drive however if the DLL's exist in System32, we cannot block it. All this does is allow trusted DLL to load, but this can be bypassed if a Malware sets its DLL in System32:

The code above is quite straightforward so, not much to explain apart from the LdrAddress variable is a global variable therefore, you cannot see the variable.
These are only real\important piece of code as you may know as all main does is call the Install detour functions and thats all - from then on the callback handles it all.

The code, as I could not fit it into a single screenshot, I am going to give the code in a *.cpp file:

Next, time I will be covering how to block Code\Process Injections.

Until Next Time,