Jump to content

Kas Ob.

Members
  • Content Count

    380
  • Joined

  • Last visited

  • Days Won

    2

Kas Ob. last won the day on June 24

Kas Ob. had the most liked content!

Community Reputation

106 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Kas Ob.

    "Self-updating" terminal services DLL

    I forgot to extend the hard way into longer way, write your own service that does the (2) job, unregister, replace( or just reinstall with new name/path), then register again, give it the required permission, and you should be good to go, this should work on all Windows versions.
  2. Kas Ob.

    "Self-updating" terminal services DLL

    When it comes to DLL loaded by system it need to be stopped first, so here two solution 1) The easy way, if there the required permission for the OS service loaded the DLL then you can restart the OS, but first use the RunOnce registry keys to copy the or replace .., https://docs.microsoft.com/en-us/windows-hardware/drivers/install/runonce-registry-key 2) The harder way make you DLL as EXE and DLL then let the new one unregister the old then register itself as DLL, but to do this you should also make sure that the OS service does has the required permission to run an EXE and install/un install the DLL, as the permission will be applied to the EXE. I used both method successfully when wrote my own firewall to watch the traffic, using socket SPI https://docs.microsoft.com/en-us/windows/win32/winsock/transport-service-providers-2, but that was for Windows XP and Server 2003 and Server 2008, so i am not sure if your current OS will allow you to that, but as you said some brainwave might help. I didn't know that does work with the IDE, spent hell of time in rebuilding, closing the IDE, copy the DLL over, then run the IDE !!!! 🤬
  3. Kas Ob.

    Suggestion for Debug helper Expert

    That did came to my mind, but will be challenging to fit those registers in small part in CPU window, but not exactly only to be shown when the CPU window is activated, it in theory should work when debugger had stopped on a break point to show the CPU registers state and may be the stack with some click to open hex dump window of requested address, same as CPU window, but all not that important as these functionality is working now, the only missing thing is FPU/MMX... registers. Don't waste your time on this now, i will ask you to waste/spare some later when i have something working and useful.
  4. Kas Ob.

    Suggestion for Debug helper Expert

    I failed in the past at many tries to make simple window to dock in the IDE, or even to show correctly, so if you or someone can spare sometime and implement the expert as simple window to pop and having the debugger notifier, then me or anyone else will continue and try to finish it, no need for the functionality or custom drawing that i can do, as long the thread context is provided by the debugger then i think it is doable. Anyway, i was going to do it, but it will take sometime, there are many things i need to learn in the process.
  5. Kas Ob.

    is the site infected?

    If there is security software on your device then most likely it is not serious, just try to clean your own browser form extensions ! those what easily can bypass almost all AV as they are not malicious, just advertising or crypto mining.
  6. The Disassembler windows in Delphi IDE is so basic, with so much limitations making low assembly and memory access investigating so slow, also just recently i found out that Thread Contexts can be accessed using OTA, easily ! But just now it hit me, how easy to add a new window with FPU, MMX, XMM, YMM, ZMM registers, and how much that can help and save time, time wasted switching to external debuggers. So the suggestion is this: Simple windows that can be configured to automatically open when debugging, shows CPU registers, and can hide/show different group of CPU registers like general purposes registers, FPU/MMX registers...etc This window can be extended later to have the ability to change/modify registers, also when this happen the ability to manipulate and use the debug registers Dr0-7 but this will need investigating to see the possibility of using hardware breakpoint and the Delphi debugger compatibility with such breakpoints. One more thing: showing what register value had been changed between two breakpoints will be great, here i am pointing to mimicking how x64dbg behaviour ( https://x64dbg.com/ ), or OllyDbg . Is such expert doable or useful ?
  7. Kas Ob.

    is the site infected?

    What cookies !??? Guys, are you getting cookies ? @Sherlock Have you even wear gloves before inspecting his cookies in pandemic era ? did you smoke pipe near them too ?
  8. Kas Ob.

    Filter Exception causing debugger errors

    Even in my screenshot it is 0, you still can get the address by using IThread.GetOTAThreadContextEx.win64.Rip But this need a refactor to combine the two methods. Anyway the most important thing is that the needed information are there in your hand, thank you and Mahdi, we now can use this useful tool.
  9. Kas Ob.

    Filter Exception causing debugger errors

    @dummzeuch it seems that you fixed the hex problem yesterday, and it is working just fine, now with my semi workaround it does work on each AV separately by address. Now i tried what Mahdi suggested like this function GetExceptionObjectNew(Thread: TThread): TAddress; var PE: PExceptionRecord; ... C := PCardinal(Integer(P) + $18)^; PE := PExceptionRecord(P + $18); {$IFOPT D+} SendDebugWarning('PE = '+IntToHex(UInt64(PE),8)); SendDebugWarning('PE.ExceptionCode = '+IntToHex(PE.ExceptionCode,8)); SendDebugWarning('PE.ExceptionFlags = '+IntToHex(PE.ExceptionFlags,8)); SendDebugWarning('PE.ExceptionAddress = '+IntToHex(UInt64(PE.ExceptionAddress),16)); //SendDebugWarning('PE.ExceptionAddress = '+IntToHex(PE.ExceptionAddress,8)); I := PE.NumberParameters; SendDebugWarning('PE.NumberParameters = '+IntToHex(I,1)); if I > 0 then for I := 0 to PE.NumberParameters - 1 do SendDebugWarning('PE.ExceptionInformation['+IntToStr(I)+'] = '+IntToHex(PE.ExceptionInformation[I],1)); {$ENDIF} { !!! don't optimize me !!! } But used $18 instead of $30 and used the Delphi default Exception record and it is in fact different from the OS somehow, the result of the above is like this Now i believe you can have the exception address with this record, also you can rebuild a message or exception identifier similar to 32bit, the bonus here is not only you have read and write access violation but with that value of 8 you can point the execute on invalid address !, i never saw Delphi report an access violation on execution, now GExperts have it.
  10. Kas Ob.

    Filter Exception causing debugger errors

    I don't have RTL/VCL sources so i have to debug and walk them, if i am not wrong this is how to read access violation according to https://channel9.msdn.com/Shows/Inside/C0000005 and from debugging, i think there is GetExceptionObject in Sysutils that shows how AV message been built, this will help in rebuilding it for 64bit exactly as for 32bit using FDebugEvent.Exception.ExceptionRecord you can read ExceptionAddress for the address instead of reading EIP, while the parameters list ExceptionInformation[0] will hold the operation read,write,execute (the values can be obtained from msdn link above) ExceptionInformation[1] will hold of the invalid address
  11. Kas Ob.

    Filter Exception causing debugger errors

    Looks fixed for the filter to work, but still missing few things, 1) the message '$C0000005' or 'C0000005 ACCESS_VIOLATION' is somehow useless as it combine all AV and this will defeat/limit most of the filter usefulness with this exception, so i suggest a workaround until better solution to read the exception record the right way function DoShowExceptionHooked(Debugger: TDebugger): Boolean; .. GetExceptionName(Debugger, ExceptionName); if (IProcess.GetProcessType = optWin64) and (CompareText(ExceptionName,'$c0000005') = 0) then begin ExceptionName := ExceptionName +'@'+ IntToHex(IThread.GetOTAThreadContextEx.win64.Rip,8); Msg := Msg +' @address '+IntToHex(IThread.GetOTAThreadContextEx.win64.Rip,16); end; Projectname := GxOtaGetCurrentProjectName; and the result will be like this Now we have the address and can separate each AV based on the address of code for 64bit. 2) while (1) add nice feature, i noticed separation of those AV even on 32bit is not working !, that need to be fixed now, as in my example i can't ignore one of the AV and leave the other, even when on 32bit each AV does have unique ExceptionName and Msg per address of the code that raised the AV.
  12. Kas Ob.

    Filter Exception causing debugger errors

    I did not sleep since Wednesday, and i think i am out of mental strength! What was i thinking and how did miss this?!!, IsBadReadPtr is wrong to begin with, and should not be used here as the debugged process is is not the one will be tested against GoodReadPtr. So if the implementation of IOTAProcess is designed to raise an exception then we can do very little about it, but there is still the poking around with OpenProcess then ReadProcessMemory, and to do this we need that handle... and.. long story here.. It is easier to catch the exception with try..except and ditch it. Later will check and try to protect the ReadProcessMemory outside ReadPointer, and make sure the result on exception is 0 for all, in other words there is no other exception raised/escaping to the debnugger.
  13. Kas Ob.

    Filter Exception causing debugger errors

    It seems IsBadReadptr is working fine and it was my bad, this solves the bug for both 32 and 64 function ReadPointer(Process: IOTAProcess; Address: TAddress): TAddress; begin try { read pointer value } Result := 0; {$IFDEF IS_WIN32_ONLY} if not IsBadReadPtr(Pointer(Address), SizeOf(Integer)) then Process.ReadProcessMemory(Address, SizeOf(Integer), Result); {$ELSE} case Process.GetProcessType of {$IF declared(optiOS32)} optiOS32, {$IFEND} {$IF declared(optAndroid)} optAndroid, {$IFEND} {$IF declared(optOSX32)} optOSX32, {$IFEND} optWin32: if not IsBadReadPtr(Pointer(Address), SizeOf(Integer)) then Process.ReadProcessMemory(Address, SizeOf(Integer), Result); {$IF declared(optOSX64)} optOSX64, {$IFEND} {$IF declared(optLinux64)} optLinux64, {$IFEND} {$IF declared(optiOS64)} optiOS64, {$IFEND} {$IF declared(optAndroid64)} optAndroid64, {$IFEND} optWin64: if not IsBadReadPtr(Pointer(Address), SizeOf(Integer)) then Process.ReadProcessMemory(Address, SizeOf(Int64), Result) else raise Exception.Create('Please implement me.'); end; {$ENDIF} except // Debug message end; end; But found a bug in 64 bit with the exception message with wrong address's
  14. Kas Ob.

    Filter Exception causing debugger errors

    I can confirm the bug and its source It is an escaping AV at this line in GX_FilterExceptionsNotification.pas function ReadPointer(Process: IOTAProcess; Address: TAddress): TAddress; begin .. Process.ReadProcessMemory(Address, SizeOf(Integer), Result); // <---- the solution is easy to encapsulate all the content of that function with try..except function ReadPointer(Process: IOTAProcess; Address: TAddress): TAddress; begin try .. except //Log it as nothing need to be done end; end; Though it can be fixed right with the OS API IsBadReadPtr, the idea it should if we have the memory pointer right, but TAddress is UInt64 !
  15. I understand that, just pointing that some OS component evolve for better quality and slower speed. I want to ask this, have you considered GDI and GDIP ? There is an advantage for GDI's over Direct2D and OpenGL, in virtualized system OpenGL might not render to begin with, while Direct2D might be very slow if the hardware acceleration is not enabled.
×