ASM routine [Archive] - RCE Messageboard's Regroupment

View Full Version : ASM routine

steel

April 24th, 2008, 22:35

naides

April 25th, 2008, 08:08

Quote:

[Originally Posted by steel;74213]

If anyone can please help me 'translate' this routine to C, or at least guide me towards doing this, it will be greatley appreciated.

Ilfak's new IDA plug-in: Hex-Rays, if you are able to buy it, find it, download it or make it work, supposedly will translate asm into C-like code.

That decompiling it will take you any closer to understand what this code (snippet is an understatement) is doing, that is a whole different story. . .

steel

April 25th, 2008, 14:14

Hi,

Ok, so I followed your advice and was able to get most of it working, I am still having trouble with the following loop:

Code:



005745ED  |> 8A86 A07A5800  /MOV AL,BYTE PTR DS:[ESI+587AA0]

005745F3  |. 50             |PUSH EAX

005745F4  |. E8 37EFFFFF    |CALL app.00573530

005745F9  |. 8B8CBC 0C01000>|MOV ECX,DWORD PTR SS:[ESP+EDI*4+10C]

00574600  |. 51             |PUSH ECX

00574601  |. 50             |PUSH EAX

00574602  |. E8 19F0FFFF    |CALL app.00573620

00574607  |. 50             |PUSH EAX

00574608  |. E8 B3EFFFFF    |CALL app.005735C0

0057460D  |. 8B7CAC 28      |MOV EDI,DWORD PTR SS:[ESP+EBP*4+28]

00574611  |. 50             |PUSH EAX

00574612  |. 8886 A07A5800  |MOV BYTE PTR DS:[ESI+587AA0],AL

00574618  |. E8 13EFFFFF    |CALL app.00573530

0057461D  |. 8B5424 24      |MOV EDX,DWORD PTR SS:[ESP+24]

00574621  |. 8B4C94 7C      |MOV ECX,DWORD PTR SS:[ESP+EDX*4+7C]

00574625  |. 51             |PUSH ECX

00574626  |. 50             |PUSH EAX

00574627  |. E8 F4EFFFFF    |CALL app.00573620

0057462C  |. 50             |PUSH EAX

0057462D  |. E8 8EEFFFFF    |CALL app.005735C0

00574632  |. 8B949C D800000>|MOV EDX,DWORD PTR SS:[ESP+EBX*4+D8]

00574639  |. 50             |PUSH EAX

0057463A  |. 8886 A07A5800  |MOV BYTE PTR DS:[ESI+587AA0],AL

00574640  |. 895424 34      |MOV DWORD PTR SS:[ESP+34],EDX

00574644  |. E8 E7EEFFFF    |CALL app.00573530

00574649  |. 8B4C24 38      |MOV ECX,DWORD PTR SS:[ESP+38]

0057464D  |. 8B948C 7C01000>|MOV EDX,DWORD PTR SS:[ESP+ECX*4+17C]

00574654  |. 52             |PUSH EDX

00574655  |. 50             |PUSH EAX

00574656  |. E8 C5EFFFFF    |CALL app.00573620

0057465B  |. 50             |PUSH EAX

0057465C  |. E8 5FEFFFFF    |CALL app.005735C0

00574661  |. 6A 03          |PUSH 3

00574663  |. 55             |PUSH EBP

00574664  |. 8886 A07A5800  |MOV BYTE PTR DS:[ESI+587AA0],AL

0057466A  |. E8 B1EFFFFF    |CALL app.00573620

0057466F  |. 6A 02          |PUSH 2

00574671  |. 53             |PUSH EBX

00574672  |. 8BE8           |MOV EBP,EAX

00574674  |. E8 A7EFFFFF    |CALL app.00573620

00574679  |. 83C4 40        |ADD ESP,40

0057467C  |. 8BD8           |MOV EBX,EAX

0057467E  |. 8B4424 14      |MOV EAX,DWORD PTR SS:[ESP+14]

00574682  |. 6A 01          |PUSH 1

00574684  |. 50             |PUSH EAX

00574685  |. E8 96EFFFFF    |CALL app.00573620

0057468A  |. 83C4 08        |ADD ESP,8

0057468D  |. 46             |INC ESI

0057468E  |. 83FE 05        |CMP ESI,5

00574691  |. 894424 14      |MOV DWORD PTR SS:[ESP+14],EAX

00574695  |.^0F8C 52FFFFFF  \JL app.005745ED

For these operations :
MOV ECX,DWORD PTR SS:[ESP+EDI*4+10C]
00574600 |. 51 |PUSH ECX
00574601 |. 50 |PUSH EAX
00574602 |. E8 19F0FFFF |CALL app.00573620

Hex-Rays gives me :
v58 = sub_10003620(v57, *(&v66 + v3));

which doesn't make sense. I've traced through, step by step I understand what the application is doing, but I'm not sure how to do it. Any help is greatly appreciated.

Thanks

naides

April 25th, 2008, 16:35

Quote:

[Originally Posted by steel;74223]
Disclaimers: 1. Hex-Rays sometimes screws up and produces non nonsensical code. 2: some of the action is taking place somewhere else in the code, You and Hex-Rays can see it, I cannot

The code is getting ready to call the function app.00573620 in the Olly list,
IDA?HexRays list : sub_10003620.

The second parameter of sub_10003620 is : *(&v66 + v3), a dereferenced pointer to and structure based on and pointed at by ESP+10C, which would be variable 66 (V66). EDI holds the variable displacement V3 in pointer arithmetics. (That is why is multiplied by 4). The result of this dereferenced pointer is pre-load into ECX.

The first parameter, v57 Somewhat, automagically got loaded in EAX. When???? Perhaps is the return value of function app.00573530???

I don't see how and when EAX got loaded with the variable 57 (V57) in this huge function. unless Hex overlooks call 00573530 and pretends that [ESI+587AA0] still holds the value of V57. dunno.

For these operations :
MOV ECX,DWORD PTR SS:[ESP+EDI*4+10C]
00574600 |. 51 |PUSH ECX
00574601 |. 50 |PUSH EAX
00574602 |. E8 19F0FFFF |CALL app.00573620

Hex-Rays gives me :
v58 = sub_10003620(v57, *(&v66 + v3));

which doesn't make sense. I've traced through, step by step I understand what the application is doing, but I'm not sure how to do it. Any help is greatly appreciated.

Thanks

Or, I am babbling

steel

April 25th, 2008, 16:48

Hi,

My bad for not listing more code:

here is the loop generated by Hex-Rays

Code:



 v10 = 0;

  do

  {

    LOBYTE(result) = Str2[v10];

    v57 = sub_10003530(result);

    v58 = sub_10003620(v57, *(&v66 + v3));

    LOBYTE(v59) = sub_100035C0(v58);

    v3 = *(&v86 + v5);

    Str2[v10] = v59;

    v60 = sub_10003530(v59);

    v61 = sub_10003620(v60, *(&v106 + v166));

    LOBYTE(v62) = sub_100035C0(v61);

    v63 = *(&v126 + v7);

    Str2[v10] = v62;

    v166 = v63;

    v64 = sub_10003530(v62);

    v65 = sub_10003620(v64, *(&v141 + v167));

    Str2[v10] = sub_100035C0(v65);

    v5 = sub_10003620(v5, 3);

    v7 = sub_10003620(v7, 2);

    result = sub_10003620(v167, 1);

    ++v10;

    v167 = result;

  }

  while ( v10 < 5 );

  byte_10017AA5 = 0;

  return result;

}

My issue isn't with anything but the pointer arithmetic. In assembly, there is awareness of where the memory for the next value is allocated ( I am talking about the second parameter passed to sub_10003620 ) that's why we can add an offset to it and get the next value ) but the way hex-rays decompiled it, each was an individual integer. This would only be possibly if we were dealing with an array. Would it be likely that hex-rays was unable to recognize the creating of an array of integers and instead defined invididual variables? if that is the case, would it be possible to point me in the right direction regarding what's going on inside the loop with the array, and based on the beginning of the function, SUB ESP, 198.. an idea of what the structure of the array would look like ?

Thanks

naides

April 25th, 2008, 23:19

I think I understand where the confusion may be:

There is not an ordered, one to one correspondence, left to right linear correspondence between
[ESP+EDI*4+10C]
and
*(&v66 + v3))

I don't pretend to know it either, decompiling is a shaky terrain. But, remember that addition is associative, commutative, and that disassembly has some rules in the order of representation that do not directly translate into decompiling language.

Meaning, in a disassembled expression that includes registers and direct constants, the registers (ESP, EDI) are written first, to the left of the expression, then the constants 10C at the end. On the other hand, Hex-rays reorders it to fit its interpretation: ESP+10C, a stack variable, is named v66, EDI*4 a register representing V3, a structure offset, goes next.

I propose you do some experimentation:

Change the code of this instruction:
MOV ECX,DWORD PTR SS:[ESP+EDI*4+10C]

to

MOV ECX,DWORD PTR SS:[ESP+10C]
in the original file code, then disassemble and decompile. . .

the resulting code may not run or produce some weird results, but IDA and Hex-rays should analyze it it just fine.

Find out what the construct [ESP+10C] decompiles into C- pseudocode. My bet, v66. ( besides some dereferencing stuff)

By trial and error you may figure out what the ASM representation of V66 ends up being. . .

After reading your answer more carefully:
I agree that Hex Rays may have missed an array created in the stack, and instead is referencing to a huge collection of individual DWORD variables (v14 to v67). A complicating issue is that this is a ESP based stack frame. But the theoretical Base of such array is not defined:
The constant added to ESP varies wildly from 28 to 17C in this code snippet, and the extra displacement (EDI*4) is often the result of a previous operation.

The only real way to really figure this out is to watch it operate live with the debugger, keeping track of the actual contents of the stack

steel

April 27th, 2008, 20:03

Thanks naides,

I figured It out, and was able to write what I need. I was correct in thinking it was an array, and it made things a lot easier!

naides

April 27th, 2008, 20:16

Now you got me curious:

What and where was the array?

steel

April 28th, 2008, 12:06

this is what the loop ended up looking like (it can be simplified a great deal, but this serves the purpose of doing what is needed)

Code:



for(int i = 0;  i < 5; i++)

	{

		result = Str2[I];

		int eax26 = sub_10003530(result);

		int eax27 = sub_10003620(eax26, integers[sum1 + 66]);

		int eax28 = sub_100035C0(eax27);

		Str2[I] = eax28;

		sum1 = integers[sum2 + 6];

		int eax29 = sub_10003530(eax28);

		int eax30 = sub_10003620(eax29,integers[integers[4]+26]);

		int eax31 = sub_100035C0(eax30);

		Str2[I] = eax31;

		integers[4] = integers[sum4+46];

		int eax32 = sub_10003530(eax31);

		int eax33 = sub_10003620(eax32, integers[integers[5] + 86]);

		int eax34 = sub_100035C0(eax33);

		Str2[I] = eax34;

		sum2 = sub_10003620(sum2, 3);

		sum4 = sub_10003620(sum4, 2);

		integers[5] = sub_10003620(integers[5], 1);

	}

where integers is the loong array full of ints defined in the very beginning.

When the memory was being allocatd for the array, I found the base at 0012E944, and since the stack pointer, ESP is being wound/unwound as we make the calls to the cdecl functions, I also kept track of the offset it would be from the original base. It keeps on changing, but near the end of the loop:
00574679 |. 83C4 40 |ADD ESP,40

it resets itself to the origin. So the array offsets are consistently the same, varying by the values used in sum1, sum2 and the integers array.