Radare2: Correlate registry reference to function.

[MariasStory]

HI,
Shouldn't this call be detected as/correlated to SendMessageA?

I see this kind of calls to registry often and it is an unnecessary work to search for the function assignment.

[radare]

can you share a binary/sample test script to reproduce the case? so we can have a look to the issue?

relating ebx to its original value can only be done with esil, and this is what you get in the comment at right... but i cant see it completely because you chopped the image

[MariasStory]

Hi @radare,
Get the complete strings:

To get this result I used:

e anal.searchstringrefs=true
e asm.emu=true
aap
aaaa

Binary

[radare]

we can enhacne asm.emu and asm.emustr to resolve the flag at the value of each register change, this will solve the problem

On 24 Nov 2016, at 12:43, MariasStory [e-mail] wrote:

Hi @radare https://github.com/radare,
Get the complete strings:
https://cloud.githubusercontent.com/assets/6576335/20597279/07e87544-b243-11e6-92e5-569c6f784bd9.png
To get this result I used:
aeim;e anal.searchstringrefs=true;e asm.emu=true; aap; aaaa
Binary: https://www.hybrid-analysis.com/sample/26757bbde17d6c32b48b388b7a73195a5c67d5ec897afabc36a170870c824938?environmentId=100 https://www.hybrid-analysis.com/sample/26757bbde17d6c32b48b388b7a73195a5c67d5ec897afabc36a170870c824938?environmentId=100
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6256#issuecomment-262757430, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-luZxs-5P1q4nlDkgdvAl73iQHyetks5rBXhegaJpZM4K7jMG.

[MariasStory]

Sounds good.
BZW: I would be interested to see your approach on reversing this binary with r2. Kind of a real word reversing challenge. Just to make sure that I am not missing some cool tricks. ;-)

[radare]

can you provide a link that doesnt requires login or wtf procedures to get the bin?

On 24 Nov 2016, at 12:43, MariasStory [e-mail] wrote:

Hi @radare https://github.com/radare,
Get the complete strings:
https://cloud.githubusercontent.com/assets/6576335/20597279/07e87544-b243-11e6-92e5-569c6f784bd9.png
To get this result I used:
aeim;e anal.searchstringrefs=true;e asm.emu=true; aap; aaaa
Binary: https://www.hybrid-analysis.com/sample/26757bbde17d6c32b48b388b7a73195a5c67d5ec897afabc36a170870c824938?environmentId=100 https://www.hybrid-analysis.com/sample/26757bbde17d6c32b48b388b7a73195a5c67d5ec897afabc36a170870c824938?environmentId=100
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6256#issuecomment-262757430, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-luZxs-5P1q4nlDkgdvAl73iQHyetks5rBXhegaJpZM4K7jMG.

[Maijin]

26757bbde17d6c32b48b388b7a73195a5c67d5ec897afabc36a170870c824938.zip

Here you go, zip password (infected)

[MariasStory]

Thanks @Maijin ;-)

[radare]

uhm, its not that easy.. be reference reads the dword in that address instead of refering the address.

So i dont see a way to know which address ebx was read from directly from asm.emu… and i dont like the idea of storing source pointers for each reference… any better proposal? if not you should write an r2pipe script to do that

On 24 Nov 2016, at 13:32, MariasStory [e-mail] wrote:

Thanks @Maijin https://github.com/Maijin ;-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6256#issuecomment-262766064, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lk-uwc1P6seQIQq9gtUJr3EXgr4Qks5rBYPCgaJpZM4K7jMG.

[Maijin]

[radare]

i dont see why IDA considers mov ebx, [foo] to be the same as mov ebx, foo…. this is a plain wrong assumption. the representation is IDA is wrong, but people get used to their notations and complain when using other tools.

if you emulate or debug this code you’ll see that EBX is not pointing to SendMessageA.

On 24 Nov 2016, at 15:09, Maijin [e-mail] wrote:

https://cloud.githubusercontent.com/assets/1408600/20601250/ee98802e-b257-11e6-8c87-0661c0fc7e1e.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6256#issuecomment-262784572, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-liO58qT8Hk-xDTdhtHeYxXHuq7HRks5rBZqBgaJpZM4K7jMG.

[Maijin]

Debugged

[Maijin]

[radare]

as i said, 0x76cd613E is outside the addressspace of this binary. OLLY resolves the correct address because it loads the symbols of the library, and it works because EBX contains the address defined by the windows linker at load time. So the easiest solution to this problem is to make RBin create flags pointing to the destination targets of each reloc entry at load time but this can bring some false assumptions in case the linker replaces those values at runtime…

On 24 Nov 2016, at 16:01, Maijin [e-mail] wrote:

https://cloud.githubusercontent.com/assets/1408600/20602819/32fd80e6-b25f-11e6-8811-ccf069d0df63.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6256#issuecomment-262795231, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-llqC619b3K-GlV-u3-ekme9aPZYjks5rBabAgaJpZM4K7jMG.

[MariasStory]

When the move to the registry is on the screen, it work:

When the move to the registry is out of the screen it does not work:

Anyway, thanks for the fast (partial) solution. ;-)