You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is one of the highly needed features and makes HyperDbg users able to write scripts that can use Microsoft symbols, drivers, and applications symbols.
The current symbol parser of HyperDbg has functions to fulfill the casting requirements, however for making things as simple as possible, I made a function that gets the symbol name (e.g., a structure name), and a field of a structure and then returns whether the following field is a pointer or a structure, sizeof the structure or the field, and offset of the field from the top of the structure.
(Note that, the above functionality is available in the symbol parser but to make testing of the script engine simpler for the initial design, it is written like this).
What needed to be implemented?
The 'sizeof' operator. This operator is really useful for debugging, and reverse engineering. If we could manage the script engine to support the 'sizeof' operator, it would enhance the script engine.
The cast operator. Generally, as HyperDbg's script engine doesn't have any types, we could use the casting characters. Assume the following structures:
A suggested grammar for handling casts is like this (feel free to discuss and change the casting grammar if it seems not suitable, but this is what came to my mind):
As a result, HyperDbg's script engine should use the above function and support these statements (note that the value of the test cases is commented at the next line):
my_var = cast<PSTUPID_STRUCT2>(@rcx)->Sina32;
// my_var = 0x32
my_var = cast<PSTUPID_STRUCT2>(@rcx)->Sina64;
// my_var = 0x64
my_var = cast<PSTUPID_STRUCT2>(@rcx)->AghaaSina;
// my_var = 0x55
my_var = cast<PSTUPID_STRUCT2>(@rcx).Unknownnnnnn;
// Error because Unknownnnnnn not found
my_var = cast<PSTUPID_STRUCT2>(@rcx)->Unknownnnnnn;
// Error because Unknownnnnnn not found
my_var = cast<PSTUPID_STRUCT2>(@rcx).Sina32;
// Error because PSTUPID_STRUCT2 is pointer, should use '->'
my_var = cast<PSTUPID_STRUCT2>(*@rcx).Sina32;
// Error because PSTUPID_STRUCT2 is pointer, should use '->'
my_var = cast<STUPID_STRUCT2>(*@rcx).Sina32;
// my_var = 0x32
my_var = cast<STUPID_STRUCT2>(*@rcx).Sina64;
// my_var = 0x64
my_var = cast<STUPID_STRUCT2>(*@rcx).AghaaSina;
// my_var = 0x55
my_var = cast<STUPID_STRUCT2>(*@rcx).UnicodeStr->MaximumLength;
// my_var = 0x40
my_var = cast<PSTUPID_STRUCT2>(@rcx)->UnicodeStr->MaximumLength;
// my_var = 0x40
my_var = cast<PSTUPID_STRUCT2>(@rcx)->StupidStruct1->Flag32;
// my_var = 0x3232
my_var = cast<PSTUPID_STRUCT2>(@rcx)->StupidStruct1->Flag64;
// my_var = 0x6464
my_var = cast<STUPID_STRUCT2>(*@rcx).StupidStruct1->StringValue->MaximumLength;
// my_var = 0x3c
printf("Result is : %ws\n", cast<PSTUPID_STRUCT2>(@rcx)->UnicodeStr->Buffer );
// Result is : Goodbye I'm at stupid struct 2!"
printf("Result is : %ws\n", cast<PSTUPID_STRUCT2>(@rcx)->StupidStruct1->StringValue->Buffer );
// Result is : Goodbye I'm at stupid struct 2!"
Please note that the only thing that matters in the script engine is the offsets. The symbol parser doesn't need to parse anything in the kernel (VMX-root mode) because everything is parsed in the user-mode parser and once the offsets are determined, the results of dereferences and other offsets will be sent to VMX-root mode.
Feel free to discuss this feature and possible modifications to it.
The text was updated successfully, but these errors were encountered:
@xmaple555 If you find free time, it would be best if you could help us with this, but if it needs too much work or if it's too hard to be done, no worries, I'll find another way. 🙂
@xmaple555 If you find free time, it would be best if you could help us with this, but if it needs too much work or if it's too hard to be done, no worries, I'll find another way. 🙂
It is not difficult to add type for variables in the script engine. I can make the script engine more like c language, but I will fix the current bugs first.
Sure, if it can handle the types, that would be great and make the implementation cleaner since we won't have to use the 'cast' keyword anymore. Let me know once anything needs to be done on my side.
HyperDbg welcomes contributions from everyone, but as @xmaple555 is actively working on the script engine development, please make sure to coordinate with him to avoid overlapping efforts.
This is one of the highly needed features and makes HyperDbg users able to write scripts that can use Microsoft symbols, drivers, and applications symbols.
Previously I created the following file in the symbol parser:
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/symbol-parser/code/casting.cpp
The current symbol parser of HyperDbg has functions to fulfill the casting requirements, however for making things as simple as possible, I made a function that gets the symbol name (e.g., a structure name), and a field of a structure and then returns whether the following field is a pointer or a structure, sizeof the structure or the field, and offset of the field from the top of the structure.
This is the link to this function:
HyperDbg/hyperdbg/symbol-parser/code/casting.cpp
Line 72 in fac10fd
(Note that, the above functionality is available in the symbol parser but to make testing of the script engine simpler for the initial design, it is written like this).
What needed to be implemented?
The '
sizeof
' operator. This operator is really useful for debugging, and reverse engineering. If we could manage the script engine to support the 'sizeof' operator, it would enhance the script engine.The cast operator. Generally, as HyperDbg's script engine doesn't have any types, we could use the casting characters. Assume the following structures:
These structures are compiled with the following offsets:
A suggested grammar for handling casts is like this (feel free to discuss and change the casting grammar if it seems not suitable, but this is what came to my mind):
As a result, HyperDbg's script engine should use the above function and support these statements (note that the value of the test cases is commented at the next line):
Please note that the only thing that matters in the script engine is the offsets. The symbol parser doesn't need to parse anything in the kernel (VMX-root mode) because everything is parsed in the user-mode parser and once the offsets are determined, the results of dereferences and other offsets will be sent to VMX-root mode.
Feel free to discuss this feature and possible modifications to it.
The text was updated successfully, but these errors were encountered: