manual_exception_handling

KO | EN

gitlite — search

#javascript #python #hacktoberfest #react #typescript #golang #deep-learning #docker #macos #windows #vue #awesome-list #pytorch #ios

manual_exception_handling

(★ 76)

Handling C++ & __try exceptions without the need of built-in handlers.

manual_exception_handling 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# manual_exception_handling
 this handles exceptions inside the module its specified to manage without needing previous handlers for the exception
	a good use case would be using this inside a manually mapped module

IMPORTANT
	as a manually mapped module, if you remain inside a module that already has exception handling you will have to
	run memory::remove_inverted_func_table() with the parameter being the base address of the module with exception handling in order
	to allow you to get exception handling

WHY THIS WORKS - __try & __except
	reversed by BlackBone's dev DarthTon he found that by placing your module inside the global LdrpInvertedFunctionTable you can obtain
	exception handling without having to handle it inside VEH, however i made sure this was the case by placing VEH that would go through
	the handlers of the module told to be handled by memory::enable_exceptions and determine if there is a handler for the exception
	being sent to the VEH

i took hints from the ehdata.h file and some basic memory research to see how gathering all the necessary information for the loop
	to be successful, heres a simple breakdown of what it does:

exception_table[i] -> unwind_info -> frame_count & exception_data_ptr -> (exception address inside handler) && (is a Exception HANDLER or a Unhandled HANDLER) ->
	frames[ii] -> exception_frame_offset -> exception_frame & frame_start_offset & frame_end_offset -> (exception address inside frame) ->
	SetLastError & jmp to exception_frame

WHY THIS WORKS - c++
	this wasn't very reversed or looked into by people but without the extra details ill just go directly into why this works
	i place an IAT (Import Address Table) hook on RaiseException which is called to handle c++ exceptions, the function that does is called
	__CxxThrowException and can be found under the symbols for any compiled module, this function is called with the same exception that
	can be used to identify c++ exceptions in the VEH and this exception code can be found under the definition EH_EXCEPTION_NUMBER which is
	inside ehdata.h

by using this i can go through the call stack of RaiseException and, making sure to check the callstack is for the most recent exception, i
	can see if any of the functions in the callstack have a handler by going through the exception_table, after checking if there is a handler
	i then call the language_handler discovered by looking for the function entry via RtlLookupFunctionEntry as well as RtlVirtualUnwind
	after all of this is done i call the language handler to make sure it does get called and handles the exception properly, even if the c++
	exception handling code fails

call_stack[i] -> exception_table[ii] -> unwind_info -> (exception address inside handler) && (is a Exception HANDLER or a Unhandled HANDLER) ->
	function_entry & handler_data & establisher_frame & language_handler -> return language_handler(necessary data)

FINAL NOTES
	this should work for any exceptions inside the current module, but this is untested to work with exceptions coming from exterior modules that should be handled
	inside this module, ex. calling a function that triggers __except and should be handled inside the current module

manual_exception_handling

manual_exception_handling 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

manual_exception_handling

manual_exception_handling 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README