| View previous topic :: View next topic |
| Author |
Message |
BanMe
Master Cheater
![]() Reputation: 0
Joined: 29 Nov 2005
Posts: 375
Location: Farmington NH, USA
|
 Posted: Mon Feb 02, 2009 4:51 pm Post subject: Context.Eip always = 7c90eb94(KiFastSystemCallRet)??? |
 |
|
here is the chunk of code..
im pretty sure this shouldnt be happening..
should i set the single step trap flag to obtain EIP?
should i save process commandline, kill process and then restart with CreateProcess(suspended) get thread start addresses and then singlestep them all ?
i would greatly appreciate any help on this subject as this is the Basis for my ThreadFollow scheme that will integrate into CE adding a disasm window for each thread and hopefully(Stack Information that is stored and can be veiwed to see what else a function is used for to help in the discovery and ease of use of hacks)
kinda like a disambly flowchart with extensible information.. i plan this so that CE can load such info about a process and then match that info up with existing threads...
| Code: |
void StartThreadContextSnap(HANDLE hThread)
{
CONTEXT Context = {0};
char Buffer[255]= {0};
Context.ContextFlags = CONTEXT_FULL;
if(CECT.SuspendThread(hThread) != -1)
{
if(CECT.GetThreadContext(hThread,&Context) != 0)
{
//Exported.ShowMessage("Got Thread Context");
_itoa(Context.Eip,Buffer,16);
Exported.ShowMessage(Buffer);
memset((void*)&Buffer,0,sizeof(Buffer));
CECT.ResumeThread(hThread);
return;
}
}
Exported.ShowMessage("Failed Getting Context");
return;
}
BOOL PoolForTargetThreads(ULONG ProcessId)
{
THREADENTRY32 te32;
HANDLE hSnap,hThread;
te32.dwSize = sizeof(THREADENTRY32);
hSnap = CECT.CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD,ProcessId);
if(hSnap != INVALID_HANDLE_VALUE)
{
if(CECT.Thread32First(hSnap,&te32) != FALSE)
{
do
{
if(te32.th32OwnerProcessID == ProcessId)
{
hThread = CheckThreadHandleInList(te32.th32ThreadID);
if(hThread != INVALID_HANDLE_VALUE)
{
//Exported.ShowMessage("Thread Found");
StartThreadContextSnap(hThread);
}
}
}while(CECT.Thread32Next(hSnap,&te32) != FALSE);
return TRUE;
}
}
return FALSE;
}
|
regards BanMe
|
|
| Back to top |
|
 |
DoomsDay
Grandmaster Cheater
 Reputation: 0
Joined: 06 Jan 2007
Posts: 768
Location: %HomePath%
|
| Posted: Tue Feb 03, 2009 4:10 am Post subject: |
|
|
| Normally when an application is waiting for an input\event, you would land on KiFastSystemCallRet. Did you try to debug an application that is just looping without using WinAPI?
|
|
| Back to top |
|
|
BanMe
Master Cheater
![]() Reputation: 0
Joined: 29 Nov 2005
Posts: 375
Location: Farmington NH, USA
|
| Posted: Tue Feb 03, 2009 11:34 am Post subject: |
|
|
tried on notepad,explorer,CE, spoolsrv, and a few others all to same effect..
also tried removing hooks placed on NtOpenThread and this also had no effect to the outcome...
what u suggest
| Code: |
if(!WaitInputIdle())
{
//code to get context of thread
}
|
doesnt work either..
thank you for your reply
regards BanMe
|
|
| Back to top |
|
|
DoomsDay
Grandmaster Cheater
Reputation: 0
Joined: 06 Jan 2007
Posts: 768
Location: %HomePath%
|
| Posted: Tue Feb 03, 2009 4:53 pm Post subject: |
|
|
What I meant was that it should be tested on a simple application which will loop forever(to see if there is an actual problem):
| Code: | int main()
{
while(0);//should not lead to KiFastSystemCallRet
reutrn 1;//should never be executed
} |
The issue is that suspendthread is only working for user mode execution; hence you would break at the first user-mode piece of code being executed - which would normally be at KiFastSystemCallRet if the process is passing control back from kernel mode.
|
|
| Back to top |
|
|
BanMe
Master Cheater
![]() Reputation: 0
Joined: 29 Nov 2005
Posts: 375
Location: Farmington NH, USA
|
| Posted: Tue Feb 03, 2009 5:27 pm Post subject: |
|
|
yes it works in this case..
but it all others it doesnt work..
so im going to add a DebugEventHandler to my plugin, which i was trying to avoid a multi-layer plugin..but i guess this is how it has to be..
regards BanMe
|
|
| Back to top |
|
|
Dark Byte
Site Admin
 Reputation: 474
Joined: 09 May 2003
Posts: 25931
Location: The netherlands
|
| Posted: Wed Feb 04, 2009 12:51 am Post subject: |
|
|
well, at a normal single step debug event you can also manually query all threads, at least one thread will contain a non KiFastSystemCallRet eip (unless the user places a breakpoint right at that spot...) because the process is then frozen.
but the best way to figure out when such an event has actually happened is a DebugEventHandler event
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
BanMe
Master Cheater
![]() Reputation: 0
Joined: 29 Nov 2005
Posts: 375
Location: Farmington NH, USA
|
| Posted: Wed Feb 04, 2009 9:57 am Post subject: |
|
|
In the case your describe where 1 thread is gonna be in KiFastSystemCallRet shouldnt edx be the return address? or is that still stored in esp+4?
thanks for your reply 
regards BanMe
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
