ABSTRACT:
With the discovery of new exploit techniques, novel protection mechanisms are needed as well. Mitigations like DEP (Data Execution Prevention) or ASLR (Address Space Layout Randomization) created a significantly more difficult environment for exploitation. Attackers, however, have recently researched new exploitation methods which are capable of bypassing the operating system’s memory mitigations. One of the newest and most popular exploitation techniques to bypass both of the aforementioned security protections is JIT memory spraying, introduced by Dion Blazakis. In this article we will present a short overview of the JIT spraying technique and also novel mitigation methods against this innovative class of attacks. An anti-JIT spraying library was created as part of our shellcode execution prevention system.

DOWNLOAD HERE

MIRROR:
LOCAL MIRROR

PS. You can catch me on twitter (http://twitter.com/PiotrBania) -- however i'm mostly tweeting only about midget car racing.

http://blog.piotrbania.com/2010/09/paper-jit-spraying-and-mitigations.html

From debugging the program I only know that before clicking a link a set of known data isn't in memory (confirmed by memory search) and after clicking it the data is in memory (all the time a different location).

How can I find the code that generates this data?

One of the major problems (which might be important to know) is that it is a .net-Program (which I can't analyze with Reflector because it is obfuscated). So I'm analyzing the assembly generated by .NET (in Olly / Immunity / IDA).

Instruction Tracing or stepping through the code after the click isn't possible because .NET generates to much code to do it in acceptable time.

Hey there!

I have recently came across (well, not entirely by myself... cheers Nahuel!) a fairly (un)common problem related to performing ring0-to-ring3 transitions, after a successful kernel vulnerability exploitation. As I have managed to come up with a bunch of possible solutions, and even write exemplary code for some of these, today I would like to present my thoughts, together with some brief explanation.



Introduction

Before trying to find a reliable solution to the problem, it should be clearly stated first. And so, we are considering a 32-bit Windows NT-family version (one of the supported ones), suffering from a stack-based buffer overflow inside one of the system call handler functions. The attacker is able to overwrite memory placed after a fixed-size buffer, including the stack frame, return address, syscall arguments and anything else reachable from this point. As opposed to the reality, we assume that there is no stack protection (i.e. a cookie) implemented, so the security flaw can lead straight into malicious code execution and system compromise. Furthermore, the overflow is triggered right inside the syscall handler, not a nested function of any kind.

The following ascii picture, presenting the stack layout at the time of the overflow, should give you a better insight of the described scenario:

So, here we are; able to control roughly any value, which could lead us into code execution... a perfect dream for every vulnerability researcher. There is one more requirement, however - we must, by any means, return to user-mode, in order to exit the exploit process in a legitimate way (such as using ExitProcess). So, how do we achieve it, assuming that the original values of the return address, and possibly some of the syscall arguments are lost (due to being overwritten by attacker-supplied data)? Let's find out, what the options are.

KiFastCallEntry and KiServiceExit

Under normal system execution (i.e. when its stability and security don't collapse), each system call handler - such as NtOpenFile - returns to its original caller, the KiFastCallEntry function. This routine, in turn, is a dispatcher most often used upon the sysenter instruction being utilized by ring-3 code (however, it is also used by kernel modules, when taking advantage of system services). After calling an adequate handler from KeServiceDescriptorTable, the dispatcher is supposed to lower the processor privilege level, by returning to where the syscall instruction was triggered.

The latter part of the job is implemented by the KiServiceExit routine, responsible for coming back to the service caller, whatever it is. Interestingly enough, KiFastCallEntry doesn't need to call the exit function, thanks to a specific assembly code layout, designed by the system developers:

As the KiServiceExit implementation directly follows the "end" of KiFastCallEntry, the code execution automatically moves from one routine, into another. This way, no actual call instruction is required, as the smart layout causes KiServiceExit to always execute after returning from the syscall handler. Due to the fact, that by exchanging the original return address with the one pointing at our shellcode, we do not land inside KiServiceExit automatically, anymore. What makes the situation even worse, is the fact that the exit routine is an internal symbol, not publicly exported to other, ring-0 modules.

Considering the above conditions, finding a reliable way of returning into user-mode might appear to be somewhat problematic. The next couple of sections aim to show the bright and dark sides of some possible solutions, which I have been able to think of - if there is something I have apparently missed, please let me know - I will be glad to extend the article with additional material

Obtaining internal kernel symbols

The first, and probably most straight-forward solution one could think of, requires the attacker to recognize the precise version of the kernel image being used, and take advantage of symbols' packages, publicly available on Microsoft servers. An adequate package could be either downloaded at run-time (provided that the attacked machine is connected to internet at the time of the exploitation), or distributed together with the malicious application. A lighter version of the latter option could rely on hard-coding the KiServiceExit function addresses, for every single kernel image version possible.

Advantages: If the exploit was taking advantage of legitimate, Microsoft-supplied symbols or using a static table of supported Windows editions together with the desired kernel addresses, it could achieve a decent level of reliability. If one knows the KiServiceExit memory placement, there isn't much left to be done - just aligning the stack as it would be upon a normal syscall return, and jumping to the routine after the payload completes.

Disadvantages: In case the attacker decided to download a complete ntosknrl.exe symbol file from the web, he could probably put the entire operation at risk, as the the .pdb file being retrieved can be as large as 5MB (or more). The exploit could obviously employ various DKOM-style techniques, in order to hide the connection; this would only work for the local machine, though - how about other computers in the network, and/or devices along the way to the global net? The attacker could be either caught in the first place, or leave significant amounts of proof for the forensics researchers.
If, in turn, the attacker went towards using hardcoded-values, he would be forced to keep his exploit up-to-date, in the context of new system patches being released along the way.

Problems of the above nature are, obviously, not an issue, if the attacker has a relatively small number of targets, and is able to figure out the computers' kernel versions by other means (i.e. having a local account on a given machine would usually help a lot).

Signature scan

Another, well-known way of retrieving the address-of-whatever relies on performing a quick & dirty signature scan of the memory. In this particular case, one would have to scan the entire ntoskrnl.exe image memory area, in search of a previously-extracted signature, unique for the KiServiceExit routine. The signature could (or probably: should) be constructed so that it would work for every operating system out there, or be kept inside a hard-coded table of supported kernel versions (as mentioned in the previous section).

Advantages: The exploit doesn't have to establish any outgoing connections. In fact, it doesn't make use of the internet, at all. Depending on the length and quality of the signature, as well as the numbers of kernel modifications applied by Microsoft, this technique could turn out to be either reliable, or the very opposite. According to the author, it is usually best to consider signature-scanning unreliable, regardless of the conditions. If, however, the attacker proved that the KiServiceExit address can be easily obtained, using a signature valid for all existing systems and is unlikely to change - I would claim such solution to be a relatively good one.

Disadvantages: As far as my experience goes, using constant signatures is rarely a good idea, especially if there are other options to pick. The exploit developer can be never certain that Microsoft doesn't unexpectedly change the kernel code, stack layout, or anything affecting the function assembly being relied on. What is worse, the problem is not only about changing the KiServiceExit contents itself - it is enough that a new byte sequence, matching the existing pattern appears anywhere in the kernel image; and the exploit is fooled. Concluding - not a recommended technique, when it comes to my opinion.

Own KiServiceExit implementation

The next solution to be considered, would require the exploit developer to create his own implementation of the exit routine, rather than keep trying to (non-deterministically) find it's virtual address in memory. This is possible because of the fact that we're executing with the same rights as the kernel itself, and are able to use any privileged instruction it uses. The only problem here could be potentially caused by the complexity of the function - fortunately, it is not the case for KiServiceExit.

Advantages: The major upside of this method, resides in the fact that we are not dependent on virtual addresses of any kind (apart from the actual payload, which might require these). In other words, it is possible to implement one payload epilogue, and use it across numerous system versions, as long as the stack layout (most importantly - the trap frame) doesn't change. According to my observations, the KiServiceExit routine either doesn't change at all, or is changed in minor parts (i.e. single instructions). Even though there might be a few differences between Windows 2000 and Windows Vista; such low-level parts of the system aren't modified in one day. And so, carefully preparing one, separate implementation of the function for each Windows NT-family release (2000, XP, Vista, 7) should be sufficient to keep the reliability on a very high level.

Disadvantages: One actual drawback, which could be pointed out is that the solution is still not as elegant, as it could possibly be. That's due to the fact that the kernel-to-user transition is being performed, using highly undocumented (except for the \ntos\ke\i386\trap.asm file, present inside the Windows Research Kernel package) system behavior and internal offsets. As a consequence, even though it is very likely that someone's implementation of the exit routine will work on any build of a specific Windows version, there is no certainty about it - especially in the context of future Windows versions.

The KeUserModeCallback technique

Last, but not least - the technique that was my first thought, when I started reflecting on the problem. Since the mechanism taken advantage of, in this method, has been already described numerous times (such as the "KeUserModeCallback utilization" section of mxatone's article, or Nynaeve's post), I will only give a brief explanation of its concept.

Under normal conditions, ring-3 code can only interact with the kernel modules via system calls (regular interrupts are mostly deprecated, while call-gates are not used, at all). This basic scheme relies on the fact, that user applications send specific requests, asking the kernel either to perform operations, which require higher processor privileges, or to be supplied with necessary information. A request is made (via theINT 2E or sysenter instruction), kernel dispatches the requests and possibly returns some information - then comes back to user mode (via either iretd or sysexit). Following the above scheme, one could consider system calls to be a specific type of callback functions - whenever an application wants to interact with the system, it calls back an adequate function from the kernel.

As it turns out, the kernel might want to call back into user-mode, as well! More precisely, the standard graphical driver (win32k.sys), needs to use ring-3 routines in numerous situations; in order to send notifications about graphical events going on, or to request some information. In order to meet the requirements, a special interface called user-mode callbacks was developed inside the NT kernel. The interface actually consists of one public, and a few internal kernel routines:

By using the above function, exported by ntoskrnl.exe, the graphical module is able to perform a legitimate ring-0 into ring-3 transition. What happens next, is that some basic information regarding the execution state is stored on the kernel stack, and the execution is passed to the user-mode ntdll.KiUserCallbackDispatcher function, of the following prototype:

The dispatcher is then responsible for forwarding the execution into one of the callback routines (the EDX register contains the ApiNumber parameter):

Seemingly, the user-side dispatch table is pointed to by one of the PEB (Process Environment Block) fields. After the given callback completes its task, it resumes the win32k.sys execution by either using a dedicated interrupt (INT 2D, internally called KiCallbackReturn), or triggering the NtCallbackReturn system call. The question is - how does the above information help us achieve the desired exploitation effect?

Thanks to the fact that KeUserModeCallback is a public symbol, any active module running in kernel-mode can call the function in a fully reliable manner. What is more, we can also hook the KiUserCallbackDispatcher function, or better yet - redirect the dispatch table pointer, residing inside PEB. If we perform the above steps, we become able to trigger our own, fully controlled, kernel-to-user transitions. Thanks to the clever NT kernel, we don't really have to care about what is left on the kernel stack, as it will be gracefully cleaned up, upon the process termination. Below, you can find exemplary code snippets, responsible for accomplishing each stage of the safe kernel-to-user transition:

1. Loading the graphical library - before we decide to touch any of the win32-related PEB fields, we should make sure that the user32.dll library has been previously loaded. This way, we are guaranteed, that both the user- and kernel- parts of the system graphics are correctly initialized for our process.
   
   
   Code:

   ---

   LoadLibraryA("user32.dll");

   ---

2. Replace the original dispatch table pointer, with the one controlled by us.
   
   
   Code:

   ---

   LPVOID GetFSBase(void)
{
  LDT_ENTRY ldt;
  GetThreadSelectorEntry(GetCurrentThread(), GetFS(), &ldt);
  return (LPVOID)(ldt.BaseLow | (ldt.HighWord.Bytes.BaseMid << 16) | (ldt.HighWord.Bytes.BaseHi << 24));
}

(...)

 for( i=0;i<DISPATCH_TABLE_SIZE;i++ )
  DispatchTable[i] = CallbackHandler;

 BYTE* Teb = GetFSBase();
 Teb = *(DWORD*)(Teb+0x18);
 Teb = *(DWORD*)(Teb+0x30);
 *(DWORD*)(Teb+0x2C) = DispatchTable;

   ---

3. Retrieve the nt!KeUserModeCallback address. This step can be achieved, by taking advantage of the PSAPI interface (to retrieve the ImageBase of the kernel image; EnumDeviceDrivers and GetDeviceDriverBaseNameA are of much use), loading the very same image in the context of our application, and performing some simple maths. I have made use of my personal GetKernelProcAddress function this time - implementing this one is left as an exercise to the reader
   
   
   Code:

   ---

   KeUserModeCallback = (typeof(KeUserModeCallback))GetKernelProcAddress("ntoskrnl.exe","KeUserModeCallback");

   ---

4. Trigger the buffer overflow, leading to the Payload() function being executed. Shellcode represents the actual code for elevating user privileges, starting up a reverse shell, or whatever else you can think of.
   
   
   Code:

   ---

   VOID Payload()
{
  ((VOID(*)())Shellcode)();
  KeUserModeCallback(0,0,0,0,0);
}

   ---

5. Catch the user-mode callback inside CallbackHandler(), and gracefully terminate the process.
   
   
   Code:

   ---

   DWORD CallbackHandler()
{
  if(b0f_triggered) ExitProcess();

  NtCallbackReturn(0,0,ERROR_SUCCESS);
  return ERROR_SUCCESS;
}

   ---

6. That's it, we're done!

What should be eventually noted, is that the KeUserModeCallback leads to the KiServiceExit function in the end, as the following call chain shows:

Let's take a closer look at the actual pros and cons of the presented technique.

Advantages: The entire solution basically relies on two steps: calling a public nt!KeUserModeCallback routine after successful exploitation, and "catching" the execution flow at the public ntdll!KiUserCallbackDispatcher function, or at one of the callback handlers, pointed to by the PEB. Seemingly, both steps can be accomplished in a fully reliable way, as long as Microsoft decides to either completely remove one of the utilized functions, or make it an internal symbol. Since such a scenario is highly unlikely, we can safely assume that the technique is, and will be perfect for returning into user-code from difficult situations (such as a seriously damaged stack).

Disadvantages: One, possible disadvantage that comes into my mind, is that replacing the PEB pointer, containing the dispatch table might not be as easy as one might suppose. Due to the fact that high PEB offsets are likely to change between different Windows versions, the attacker should take this fact into consideration when planning a world-wide, cross-version attack. This downside doesn't change anything though, as it is possible to disrupt the execution yet inside the exported KiUserCallbackDispatcher, as mentioned before. If you know about any other drawbacks I am not aware of, please let me know.

Why so serious (about ring-3)?

Looking at the above text, one might wonder, why the problem is stated so that the kernel-to-user transition must take place, when it doesn't have to under normal circumstances. The answer is - because. When it comes to kernel-mode, there are bunches of bunches of possible scenarios, machine states, and other factors which sometimes can be predicted, and sometimes not; returning to user-mode might be the best choice, at times. One should keep in mind, however, that there are ways to terminate the current process from within ring-0 (such as nt!ZwTerminateProcess). Or better yet - once code execution is achieved, the process could simply load a regular rootkit driver (hiding the existence of the process), and remain in the idle state until machine reboot, by infinitely calling nt!ZwYieldExecution.

Conclusion

In this post, I aimed at presenting yet another, interesting scenario related to the kernel exploitation field, with a couple of possible solutions. Even thought situations of the described nature don't tend to happen very often, they do. Besides that, all four techniques are directed towards universality, so they can be used not only when a stack-based buffer overflow takes place, but whatever kind of situation when it is hard, or impossible to resume the original track of kernel code execution. So, that's it... comments are welcome, as always!

Have fun.



http://j00ru.vexillium.org/?p=614

damn, today i did browse some old (jan 2010) downloaded samples..

789981e352460461755325a3c109ee95a7c81c51 *Virtob.si

cmon, they are ready to infect you at high level..
so there is not any normal anti-malware control over net.. :stunned:

http://ad.ghura.pl/rus.php
http://kdert.com/kb2.txt
http://kdert.com/wmp/dmq4.txt

pass: MALWARE

Attached Files

• virtob_si_DLDS.zip (508.5 KB)

I have a VB exe. I used peid to check any encryption and told Microsoft Visual Basic 5.0 / 6.0 encrypt. Now I used many other files on VB and all is working perfect on ollydb the code appears right, I canīt run the exes but i was able to see the code nice and is sufficient to me but now in this new exe is strange appears code like this:

Private Sub OKButton_Click() '11CBBEC
'Data Table: 43454C
Dim As Timer
loc_11CA3A8: LargeBos loc_11CA3AA 'Ignore this
loc_11CA3AA: LargeBos loc_11CA3AF 'Ignore this
loc_11CA3AC: On Error Resume Next
loc_11CA3AF: LargeBos loc_11CA3B7 'Ignore this
loc_11CA3B1: ImpAdLdI2 MemVar_140689C
loc_11CA3B4: BranchF loc_11CAC6E
loc_11CA3B7: LargeBos loc_11CA3C8 'Ignore this
loc_11CA3B9: FLdPr Me
loc_11CA3BC: MemLdI2 global_52
loc_11CA3BF: LitI2_Byte 1
loc_11CA3C1: AddI2
loc_11CA3C2: FLdPr Me
loc_11CA3C5: MemStI2 global_52
loc_11CA3C8: LargeBos loc_11CA405 'Ignore this
loc_11CA3CA: FLdRfVar var_8C
loc_11CA3CD: LitI2_Byte 0
loc_11CA3CF: FLdPrThis
loc_11CA3D0: VCallAd namepassword
loc_11CA49C: NewIfNullPr
loc_11CA49F: = Global.App 'Ignore this
loc_11CA4A4: FLdPr var_88
loc_11CA4A7: = App.Title
loc_11CA4AC: LitVar_Missing var_100
loc_11CA4AF: LitVar_Missing var_C

The code at the top is on VBDecompiler because the procedure i made on other exes where i had success and a perfect code was:

1.-Use Vb decompiler to decode exaclty like VB code is.
2.-Study the code and find what i need to change.
3.-Use ollydbg to write the exe looking the memory positions VB decompiler gave me.

Like i said I used this steps on other exes and all worked for me perfect because vbdecompiler produce me results like this:

loc_00707826: Set var_4C = var_4C
loc_0070782C: var_E0 = var_4C
loc_00707847: 00000000h = namepassword
loc_0070784C: var_E4 = var_4C
loc_00707876: var_15C = var_4C
loc_0070787C: GoTo loc_00707888

How you see the code is pretty perfect an able to understand and ollydbg no problem is paired with vb decompiler 100%.
But on the code at the begin of this page (the strange code) of vb decompiler i canīt find strings nothing and off course ollydb the same. I used the ollydbg 2.0 and OLLY PARCHEADO PARA BUSCAR OEPs and nothing the code is strange like you see too.
How can i decompile that exe? or at least how can i see the real code like the other ones? What kind of code produce the exe i canīt see code like the other ones?.
Thank you

Hi, all
After a long time to reverse oreans vm codes, Now we can restore the oreans VM codes to original x86.
You just need send us the dump file or the original file protected by code virtualizer which comes from oreans VM product. And tell us the address that you want to get the real x86 codes. We can provide you the original x86 codes' hex data and asm info in a few hours.
You can paste the hex data into OllyDBG in oreder to debug it. Also can use IDA pro to analyze it. Analyze VM codes become the same to original x86 instrs.

If you have any question or need help just connect with us.
MsnID: ***********
Email:
blog 1:
blog 2:

And Now we support the test to get your trust.You can complier a vc programm in console module. And must print out "restorevm test" together with other codes
that you want to test.VM the original x86 codes with CV. Send us the VM file, And we will send you the original x86 asm data.

If you have any question pls connect with us
Thanks All.

Hi
i have found a bug during my reversing and i'm not sure it is exploitable i converted the ASM to C code so it would be easier to understand:

memcpy(*DstData, Msg->data, Msg->dataLength);

Msg->data acctual size is only 4 bytes
DstData is maximum size of 256 bytes

what i can control is the Msg->dataLength
i can set a larger value the the Msg->data size.

the exception i get is : "..access to invalid memory.."

is this bug can be somehow exploited via maybe Heap ?

Thanks,
LaBBa.

Some new reading for the unpacker freaks enthusiasts ;)


Packer Analysis Report-Debugging and unpacking the NsPack 3.4 and 3.7 packer

http://www.sans.org/reading_room/whitepapers/malicious/packer-analysis-report-debugging-unpacking-nspack-34-37-packer_33428

Kayaker

I'm checking out an Adobe Reader/Acrobat plugin (foo.api) and I get the problem that neither normal breakpoints nor hardware breakpoints are working.

I've attached the debugger exception output.

On Adobe Acrobat 9.x IDA Pro breakpoints (hardware and non-hardware) work fine if I pass DBG_CONTROL_* to the application. The unlucky thing is that the plugin doesn't support any Adobe (Reader) higher than 7.

Adobe seems to overwrite the BREAKPOINT exception - any ideas/suggestions how to handle the older Adobe Reader/Acrobat?

Attached Images

 

Hi

I have some questions about what is actually possible to enhance in the graphics of an old directx 8 game.

I know enb series does that. From what I understand it replaces the original calls to directx with its own so the game uses custom rendering settings...Am I right ?

I wonder how to do it myself so here is a tut I found : http://forum.cheatengine.org/viewtopic.php?t=161045 What do you think about it ?

What are the limitations of such a method ?
How far is it possible to enhance the graphics of an old game using it ?
How related are the old directx 8 and directx 10 and even directx 11? Is it possible to translate the old classes and functions to the new one so that if you replace the old models and textures of the game by new ones the game engine would handle them the way a directx 11 game would ?

Please explain what is CERTAINLY doable and what is CERTAINLY not.

NB: My knowledge of c++ and directx is null. I only have experience in 3D modelling and web development stuff like PHP so be fair thx

hello all .
im a noob and i would appreciate any help regarding the topic .
as the name states im looking for information on reversing dotnet applications .
i've already found reflector which is a cool application , but there are some hassles which make it hard to see the sourcecode , one is obfuscation .
can anyone provide me or guide me how i can gain some info on de obfuscating an app?
i would be grateful .
and Thank you all in advance .
---------
and by the way i searched couple of times , but couldnt find anything , ( i googled though and found a thread in this forum , but i lost it , couldnt find it again , so thats why i made a new thread for it).

In July I had the honor to speak at the Recon conference in Montreal, Canada. It was my first conference but I really liked the experience. I hope I'll be able to attend it in future.
The presentations were recorded and hopefully will appear on the Recon site soon but for now you can check out the slides (ODP, PDF). I have also uploaded some of the tools I mentioned, most notably various filesystem extractors compiled for Win32 (download).



http://hexblog.com/2010/08/recon_2010_slides.html

Hi,
as mentioned in the topic, I'm currently looking for some information about ProtectDisc. I did a search here, at Exetools, at Arteam's site and at BiW - nothing. I also asked aunt Google - still nothing. Only crappy Warez and such.
When trying to deal with a protected exe or with the ProtecDisc .dll itself, Olly denies to work. So if anyone has any information about this protection...
Thanks a lot in advance.

Regards
darkelf

ABSTRACT

With the discovery of new exploit techniques, new protection mechanisms are needed as well. Mitigations like DEP (Data Execution Prevention) or ASLR (Address Space Layout Randomization) created a significantly more difficult environment for vulnerability exploitation. Attackers, however, have recently developed new exploitation methods which are capable of bypassing the operating system’s security protection mechanisms. In this paper we present a short summary of novel and known mitigation techniques against return-oriented programming (ROP) attacks. The techniques described in this article are related mostly to x86-32 processors and Microsoft Windows operating systems.

PAPER LINK: DOWNLOAD HERE


http://blog.piotrbania.com/2010/08/paper-security-mitigations-for-return.html