Open Zerotistic opened 4 weeks ago
I've got two more last week.
chatroom:
0x004051a0 - handle_send_message_command
0x00405d30 - handle_connection
0x00405660 - handle_logged_in_connection
bagua:
0x0000adc2 - deploy_soldiers
0x00010c2a - adjust_deployment
(As a side note, because of the conditions it feels like new result_* are created each time, which just makes it harder to read)
I noticed something interesting when merging variable, though I'm not entirely sure since I was quite tired at the time (maybe it just refreshed and I thought it cleaned up?). There was a case where the code became notably cleaner after heavily merging variables, but I didn't document where and can't locate it now.
This made me question my initial assumption about conditions not being optimized. Perhaps the issue isn't with the optimization itself, but rather with Binja creating new variables too aggressively?
We can see it in SmsRouterSvc.dll
-Windows::Sms::Common::CSmsUtil::GetXmlDocument
: Binja treats each instance of mov rcx, [rbp+arg_18]
as a new variable, rather than reusing the same one. Could this aggressive variable creation somehow be affecting condition optimization?
Binaries and bndb: chatroom.zip bagua.zip
Binja shows the following: (example taken from SmsRouterSvc.dll at 0x18002994c -
CSmsMessageXmlHelper::GetBroadcastMessageXml
)(As a side note, because of the conditions it feels like new
result_*
are created each time, which just makes it harder to read) When it could be optimized into something like:More examples from the same binary (SmsRouterSvc.dll): 0x18000fd10 -
Windows::Sms::Common::CSmsUtil::GetXmlDocument
0x1800286ec -CSmsMessageXmlHelper::GetStatusMessageXml
0x180048484 -GetDeliverMessageXml
(specifically around 0x1800488bd) (^ most references toWindows::Sms::Common::CSmsUtil::GetXmlDocument
seems to have the same pattern, and so if conditions)As #3527 was closed a bit ago, I am opening this one. Below is the dll. SmsRouterSvc.dll.zip This was tested on 4.2.6298-dev