Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Newbie too

14 views
Skip to first unread message

Meike Talbach

unread,
Oct 12, 2009, 7:47:28 AM10/12/09
to

Hi,

I'm starting with x86 asm by looking at some programs disassembled with IDA
Pro demo.
I found the following procedure, but I can't get what it actually does.

Anyone has a hint ?

unknown_libname_22 proc near
var_1= byte ptr -1
push ebp
mov ebp, esp
push ecx
mov al, [ebp+var_1]
mov esp, ebp
pop ebp
retn
unknown_libname_22 endp

Thanks,
Meike


Helge Kruse

unread,
Oct 12, 2009, 10:38:29 AM10/12/09
to

Hi Meike,

> I found the following procedure, but I can't get what it actually does.

Well, it doesn't not so much. ;-)

This is the prolog/epilog of a C-function. The prolog saves the EBP register
and sets it as frame pointer to the parameters (and local variables if there
were some of them). The epilog restores ESP and EBP.


push ebp
mov ebp, esp

mov esp, ebp
pop ebp

This does nothing.
push ecx

Here the one and only function arguments is read:
mov al, [ebp+var_1]

The function returns the result in AL.


This should be the compiler output of that function:

char unknown_libname_22(char c)
{
return c;
}

There is a prolog/epilog and a ECX saving that has no effect than consuming
time. This looks like a C compiler output while optimization has been
disabled. The ECX save reminds that ECX is often used as this pointer in C++
code. So this may also be the output of a C++ compiler.

/Helge


"Meike Talbach" <meike....@MUNGED.microcosmotalk.com> wrote in message
news:4ad3174f$0$5086$9a6e...@unlimited.newshosting.com...

Frank Kotler

unread,
Oct 12, 2009, 4:25:09 PM10/12/09
to

Helge Kruse wrote:
> Hi Meike,
>
>> I found the following procedure, but I can't get what it actually does.
> Well, it doesn't not so much. ;-)
>
> This is the prolog/epilog of a C-function. The prolog saves the EBP register
> and sets it as frame pointer to the parameters (and local variables if there
> were some of them). The epilog restores ESP and EBP.
> push ebp
> mov ebp, esp
>
> mov esp, ebp
> pop ebp
>
> This does nothing.
> push ecx
>
> Here the one and only function arguments is read:
> mov al, [ebp+var_1]
>
> The function returns the result in AL.
>
>
> This should be the compiler output of that function:
>
> char unknown_libname_22(char c)
> {
> return c;
> }
>
> There is a prolog/epilog and a ECX saving that has no effect than consuming
> time. This looks like a C compiler output while optimization has been
> disabled. The ECX save reminds that ECX is often used as this pointer in C++
> code. So this may also be the output of a C++ compiler.
>
> /Helge

Nice analysis, Helge... but look closer at this code...

> "Meike Talbach" <meike....@MUNGED.microcosmotalk.com> wrote in message
> news:4ad3174f$0$5086$9a6e...@unlimited.newshosting.com...
>> Hi,
>>
>> I'm starting with x86 asm by looking at some programs disassembled with
>> IDA
>> Pro demo.
>> I found the following procedure, but I can't get what it actually does.
>>
>> Anyone has a hint ?
>>
>> unknown_libname_22 proc near
>> var_1= byte ptr -1
>> push ebp
>> mov ebp, esp
>> push ecx
>> mov al, [ebp+var_1]

If this were "[ebp + 8]", it would "return c", but apparently it's "ebp
- 1]"!!! (or am I misreading IDA's output?) This would return the high
byte of whatever was in ecx, no? If we suppose that ecx is the "this
pointer", return the high byte of that??? Doesn't seem to make much
sense. I like "[ebp + 8]" better, although "return c" doesn't seem very
useful, either. Maybe that's why it won't tell us its name. :)

>> mov esp, ebp
>> pop ebp
>> retn
>> unknown_libname_22 endp
>>
>> Thanks,
>> Meike

Good puzzle, Meike! Is the program you're disassembling "available"? I
can see what I *think* it does, but I can't imagine what it's "for"!

At one time, I thought disassembling compiler output was a good way to
learn asm. After looking at the output from modern compilers, I no
longer think so. It's "good" code, but not very easy to follow. You can
still learn a lot from it, I guess, but some "written in asm" examples
might be easier to start with...

Jeff Duntemann's Third Edition of "Assembly Language Step by Step" is
out(!)...

http://www.duntemann.com/assembly.htm

Best,
Frank

Meike Talbach

unread,
Oct 13, 2009, 5:57:03 AM10/13/09
to

Hi Frank,

> Good puzzle, Meike! Is the program you're disassembling "available"? I
> can see what I *think* it does, but I can't imagine what it's "for"!

I guess this is part of the Microsoft STL. Look here:

; Attributes: library function bp-based frame
; int __cdecl std___Traits_helper__move_s_std__char_traits_char__(void *Dst,
rsize_t DstSize, void *Src, rsize_t MaxCount)
char * __cdecl std::_Traits_helper::move_s<struct
std::char_traits<char>>(char *, unsigned int, char const *, unsigned int)
proc near

var_1= byte ptr -1
Dst= dword ptr 8
DstSize= dword ptr 0Ch
Src= dword ptr 10h
MaxCount= dword ptr 14h

push ebp
mov ebp, esp
push ecx

call unknown_libname_22 ; Microsoft VisualC 2-8/net runtime
mov [ebp+var_1], al
mov al, [ebp+var_1]
push eax
mov ecx, [ebp+MaxCount]
push ecx ; MaxCount
mov edx, [ebp+Src]
push edx ; Src
mov eax, [ebp+DstSize]
push eax ; DstSize
mov ecx, [ebp+Dst]
push ecx ; Dst
call std::_Traits_helper::move_s<std::char_traits<char>>(char *, uint,
char const *, uint, std::_Secure_char_traits_tag)
add esp, 14h


mov esp, ebp
pop ebp
retn

char * __cdecl std::_Traits_helper::move_s<struct
std::char_traits<char>>(char *, unsigned int, char const *, unsigned int)
endp

> At one time, I thought disassembling compiler output was a good way to
> learn asm. After looking at the output from modern compilers, I no
> longer think so. It's "good" code, but not very easy to follow. You can
> still learn a lot from it, I guess, but some "written in asm" examples
> might be easier to start with...
>
> Jeff Duntemann's Third Edition of "Assembly Language Step by Step" is
> out(!)...

I will take a look at it. Thanks

Meike


Helge Kruse

unread,
Oct 14, 2009, 4:19:30 AM10/14/09
to

Frank Kotler schrieb:

>
> Nice analysis, Helge... but look closer at this code...
>
>>> unknown_libname_22 proc near
>>> var_1= byte ptr -1
>>> push ebp
>>> mov ebp, esp
>>> push ecx
>>> mov al, [ebp+var_1]
>
> If this were "[ebp + 8]", it would "return c", but apparently it's "ebp
> - 1]"!!! (or am I misreading IDA's output?) This would return the high
> byte of whatever was in ecx, no? If we suppose that ecx is the "this
> pointer", return the high byte of that??? Doesn't seem to make much
> sense. I like "[ebp + 8]" better, although "return c" doesn't seem very
> useful, either. Maybe that's why it won't tell us its name. :)

You're right, of cause! I just read the plus sign in "[ebp+var_1]" and
did not catched the negative value of var_1.

/Helge

Frank Kotler

unread,
Oct 14, 2009, 11:16:23 AM10/14/09
to

Meike Talbach wrote:
> Hi Frank,
>
>> Good puzzle, Meike! Is the program you're disassembling "available"? I
>> can see what I *think* it does, but I can't imagine what it's "for"!
>
> I guess this is part of the Microsoft STL. Look here:

Mmmm, okay.

> ; Attributes: library function bp-based frame
> ; int __cdecl std___Traits_helper__move_s_std__char_traits_char__(void *Dst,
> rsize_t DstSize, void *Src, rsize_t MaxCount)

(I guess this is the end of the comment, and the beginning of the "proc"
declaration?) Looks like Helge nailed it correctly as C++ - that means
I'm "clueless++". :)

> char * __cdecl std::_Traits_helper::move_s<struct
> std::char_traits<char>>(char *, unsigned int, char const *, unsigned int)
> proc near
>
> var_1= byte ptr -1

Again, a local variable at -1. I would "expect" a single local variable
to be at -4, even if it's a single byte - nicer alignment. Doesn't make
much difference, I guess...

> Dst= dword ptr 8
> DstSize= dword ptr 0Ch
> Src= dword ptr 10h
> MaxCount= dword ptr 14h

These numbers are offsets "up the stack" from ebp. Perfectly "normal".

> push ebp
> mov ebp, esp

"Normal" prolog...

> push ecx

This does not appear to be for the purpose of preserving caller's ecx,
nor as a parameter to "unknown" ("unknown" uses ecx, but doesn't fetch
it off the stack). I think it's just a way of doing "sub esp, 4" to make
room for the local variable. I think...

> call unknown_libname_22 ; Microsoft VisualC 2-8/net runtime

We looked at this before. As near as I can see, it's the equivalent of:

mov eax, ecx
shr eax, 24

Well, not exactly - upper bits of eax are unchanged by "unknown", as are
flags... But we get whatever was the high byte of ecx into al.

> mov [ebp+var_1], al

Save it to our local variable

> mov al, [ebp+var_1]

And get it back. (not much use...)

> push eax

Now this appears to be a "hidden parameter" to the function we're about
to call. (I understand C++ has such things)

> mov ecx, [ebp+MaxCount]
> push ecx ; MaxCount
> mov edx, [ebp+Src]
> push edx ; Src
> mov eax, [ebp+DstSize]
> push eax ; DstSize
> mov ecx, [ebp+Dst]
> push ecx ; Dst

"re-push" the parameters we were called with, and call...

> call std::_Traits_helper::move_s<std::char_traits<char>>(char *, uint,
> char const *, uint, std::_Secure_char_traits_tag)

Okay, I guess the name of the "mystery parameter" is
"std::_Secure_char_traits_tag". I guess that would make the name of
"unknown_libname_22", "get_..."? No idea what it means.

> add esp, 14h

Remove 5 parameters from stack - the 4 we were passed (dest, size, src,
maxcount) plus that strange thing we got from "unknown". This doesn't
clean up the "push ecx" we did to make room for the local variable. That
is (as "usual") cleaned up by the "normal" epilog:

> mov esp, ebp
> pop ebp
> retn
> char * __cdecl std::_Traits_helper::move_s<struct
> std::char_traits<char>>(char *, unsigned int, char const *, unsigned int)
> endp

I don't know if this is any help to you, Meike. I don't know how "new"
you "be". If you're "brand new", this may not have been the easiest
place to start (but if it's what you're interested in, gotta look at it
eventually...). If you need a more detailed explanation of how "normal"
passing of parameters on the stack is done, just ask.

Best,
Frank

Tim Roberts

unread,
Oct 16, 2009, 4:06:11 AM10/16/09
to

Helge Kruse <Helge.Kru...@MUNGED.microcosmotalk.com> wrote:
>
>You're right, of cause! I just read the plus sign in "[ebp+var_1]" and
>did not catched the negative value of var_1.

I shouldn't do this -- I know I will regret it so I will apologize in
advance -- but it bothers me when someone apparently accidentally misuses
an idiom or an adage, because non-native speakers pick up the wrong usages
without realizing they are wrong.

The phrase is "of course", not "of cause".
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

Helge Kruse

unread,
Oct 16, 2009, 7:41:21 AM10/16/09
to

"Tim Roberts" <ti...@MUNGED.microcosmotalk.com> wrote in message
news:4ad82972$0$5665$9a6e...@unlimited.newshosting.com...


> I shouldn't do this -- I know I will regret it so I will apologize in
> advance -- but it bothers me when someone apparently accidentally misuses
> an idiom or an adage, because non-native speakers pick up the wrong usages
> without realizing they are wrong.
>
> The phrase is "of course", not "of cause".


It's ok to answer and you shouldn't regret. I am a non-native speaker,
that's why I misspelled it. But I hope I've learned it now. ;-)

Thanks,
Helge


0 new messages