Push-Ret trick - R2 failed to detect the rest of the code after the ret

[AriEi4]

Hi, One of the most popular techniques for Anti-Disassemble is the Push-Ret Trick. IDA handles it pretty well:

but R2 failed to detect the rest of the code after the ret. When I'm using 'afl' the addresses are relative and I can't get the current address of the code chunks.

Ideas?

[Maijin]

Hello,

Ensure you are using radare2 from git, if you're unsure paste output of r2 -v here. To install radare2 from git, first uninstall your version of radare2 and clean your distro. Then use git clone https://github.com/radare/radare2 && cd radare2 && ./sys/install.sh, verify your version and check if there is no error using r2 -v.

[AriEi4]

I'm using the radare2 from git.

[Maijin]

Ok, can you share the binary or an equivalent binary and can you write some tests in radare2-regression repository of what would be the expected anal/disassembly output ?

[radare]

This can only be done with emulation. The static analysis doesnt relays on emulation (yet) so all those fancy -AAA will not help at all in having better analysis.

The push/ret thing is a very silly trick but cannot be generalized because there can be many more ways to achieve the same in different ways, so emulation is thr way to go.

Use e asm.emu=true and ull see how that ret resolves properly, but you will have to manualy mangle the graph for now because that esil emulation is not yet used for this in the currrent static analysis loop

On 14 Apr 2016, at 08:59, AriEi4 notifications@github.com wrote:

Hi, One of the most popular techniques for Anti-Disassemble is the Push-Ret Trick. IDA handles it pretty well:

but R2 failed to detect the rest of the code after the ret. When I'm using 'afl' the addresses are relative and I can't get the current address of the code chunks.

Ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[AriEi4]

@Maijin Here is the binary - http://www.filedropper.com/virusshare0a3723483e06dcf7e51073972b9d1ef3 (ZeuS Sample)

@radare so actually there is no way to do it automatically, even when the asm.emu=true? And why it cannot be generalized? Whenever there is push to offset and ret, you can assume that there is a function there that need to be analyzed.

[radare]

You can write a script in r2pipe to do this. But the thing of "one instruction type after another of another type" is totally specific. Not generic. In r2land all the stuff we add is generic across all archs. Or at least we try to.. You can also patch the analyzer to do so, its pretty simple. Maybe adding an anal.pushret var to enable this mode would be enough for you. If you provide a sample i can do this, but i dont think this should be enabled by default.

On 14 Apr 2016, at 09:25, AriEi4 notifications@github.com wrote:

@Maijin Here is the binary - http://www.filedropper.com/virusshare0a3723483e06dcf7e51073972b9d1ef3 (ZeuS Sample)

@radare so actually there is no way to do it automatically, even when the asm.emu=true? And why it cannot be generalized? Whenever there is push to offset and ret, you can assume that there is a function there that need to be analyzed.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[Maijin]

That would be super useful !

[radare]

Done in master. Just -e anal.pushret=true

On 14 Apr 2016, at 13:44, Maijin notifications@github.com wrote:

That would be super useful !

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[Maijin]

https://github.com/radare/radare2/commit/7c215189f7b74b64c16673b269f766b666c22b16

[radare]

Pls maijin. Add test and close this thing

On 14 Apr 2016, at 13:44, Maijin notifications@github.com wrote:

That would be super useful !

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[Maijin]

@AriEi4 do you have a clean binary (not malware) that contain this behaviour that we could use in the test suite ?

[AriEi4]

@Maijin Sorry, i have only malware that contains this behavior

[Maijin]

Can you try now? Also, Maybe you can craft one ripping the malware code or crafting it.

[radare]

Just grab those bytes and put them in r2 -. Btw this code just handles push+ret.

If the push is a reg it will not work, all the other ways must be done on top of esil, but at least this will make some windows users happy

On 14 Apr 2016, at 14:59, Maijin notifications@github.com wrote:

Can you try now? Maybe you can craft one ripping the malware code or crafting it.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[AriEi4]

I checked it now and there are few problems after the anal.pushret=true: First, there is a problem in detecting the start address of the code chunks.

Here's the analysis results of r2: | | 0x00419632 1b8b05842243 sbb ecx, dword [ebx + 0x43228405] | | 0x00419638 002b add byte [ebx], ch | | 0x0041963a d08915a3e043 ror byte [ecx + 0x43e0a315], 1 | | 0x00419640 0068bd add byte [eax - 0x43], ch | | 0x00419643 8d4100 lea eax, [ecx] | | 0x00419646 c3 ret

The results from IDA: 00419633 loc_419633: 00419633 mov eax, dword_432284 00419639 sub edx, eax 0041963B mov dword_43E0A3, edx 00419641 push offset loc_418DBD 00419646 retn

The analysis results is wrong, but the cause is probably because r2 start the analysis from 0x00419632 instead of 0x00419633 (as IDA).

So, r2 starts analyzing from the wrong address for some reason. I thing that the problem is that after the push-ret change to JMP, r2 needs to analyze the function in this address (and skip whats between), and not to analyze everything until this function.

Another thing - the 'afl' list still contains relative addresses instead of the current addresses of the code chunks.

Thanks for the help!

[radare]

@rlaemmert wanna check this ? im very busy right now

[rlaemmert]

Yea i will check that. Could you please upload the binary that causes this issue? The one above does not work.

[AriEi4]

@rlaemmert Here is the new link: http://www.filedropper.com/virusshare0a3723483e06dcf7e51073972b9d1ef3

[rlaemmert]

i think that will be a bigger task aaa detects 682 functions aaaa 685 against 66 for idapro

[radare]

I think we have no test in r2r for that. Will be good a have a shareable bin

On 03 May 2016, at 10:35, Rene Laemmert notifications@github.com wrote:

i think that will be a bigger task aaa detects 682 functions aaaa 685 against 66 for idapro

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[XVilka]

Please add a test

[ret2libc]

This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue.

[trufae]

e anal.pushret=true

On 23 Jun 2020, at 12:51, AriEi4 notifications@github.com wrote:

 Hi, One of the most popular techniques for Anti-Disassemble is the Push-Ret Trick. IDA handles it pretty well:

but R2 failed to detect the rest of the code after the ret. When I'm using 'afl' the addresses are relative and I can't get the current address of the code chunks.

Ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.