AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   General (https://forums.alliedmods.net/forumdisplay.php?f=58)
-   -   Idea to find functions in memory (https://forums.alliedmods.net/showthread.php?t=119828)

joaquimandrade 02-25-2010 18:25

Idea to find functions in memory
 
I thought about something to find functions without relying on signature scanning (or at least relying less) but I don't know if it is good (or even can be put) in practice. The idea is creating a tree of functions associated by their relations (how they call each other) and infer addresses given some. For example:

PHP Code:

X()
{
    
Y()
    
Z()


X calls (only) Y and Z. If Y and X are known, Z can be inferred.

By "calls" I mean at least direct calls.
So that this work it must be known where a function ends. I don't know about that but I guess that It can be made. And also a parser of assembly instructions (what exists).

The greater the amount of relations given, the greater the amount of functions inferred.

Also to minimize eventual problems with updates, the parsing of this relations should detect impossible relations when possible.

Arkshine 03-04-2010 06:53

Re: Idea to find functions in memory
 
If somebody know if this could be made, I would also like to know. It probably can make things less OS and modification dependent.

devicenull 03-04-2010 13:32

Re: Idea to find functions in memory
 
One problem with this is a disassembler would need to be included with Sourcemod. That's a fairly major thing to write, and would likely make the server take a lot longer to start up. (IDA takes a few minutes to disassemble the server binary, even longer to analyze it )

Sammy-ROCK! 03-04-2010 13:38

Re: Idea to find functions in memory
 
Besides such a large array would also lag a bit to be accessed.

pRED* 03-04-2010 17:30

Re: Idea to find functions in memory
 
I quite like this idea.

If you wanted to go down the route of building the call graph for the entire binary (as the others have assumed), then you'd want to make sure you cache the result and only rebuild it if the binary has changed.

You could probably write an extension for IDA to build this cache instead of writing your own code for it.

Alternatively you could just write a thin function that takes a function pointer and returns a list of [non-virtual] functions called by it. Then you can use this in situations where you know the result will be meaningful.

I've written a basic CFG parser which can be used to find the end of the function and could output all calls with only a tiny change. It embeds libdisasm which appears to be reasonably lightweight.

Let me know if you want me to dig it out. If the disasm lib turns out to be a bottleneck (unlikely) it wouldn't be hard to write a custom version for your needs.

Something to be aware of are is the massive possible difference between the linux and windows binaries. Calls which appear once in the original code, could appear multiple times in the assembly or not at all, and this would be entirely compiler specific.

tl;dr

joaquimandrade 03-04-2010 19:19

Re: Idea to find functions in memory
 
Quote:

Originally Posted by pRED* (Post 1107562)
I quite like this idea.

If you wanted to go down the route of building the call graph for the entire binary (as the others have assumed), then you'd want to make sure you cache the result and only rebuild it if the binary has changed.

You could probably write an extension for IDA to build this cache instead of writing your own code for it.

Alternatively you could just write a thin function that takes a function pointer and returns a list of [non-virtual] functions called by it. Then you can use this in situations where you know the result will be meaningful.

I've written a basic CFG parser which can be used to find the end of the function and could output all calls with only a tiny change. It embeds libdisasm which appears to be reasonably lightweight.

Let me know if you want me to dig it out. If the disasm lib turns out to be a bottleneck (unlikely) it wouldn't be hard to write a custom version for your needs.

Something to be aware of are is the massive possible difference between the linux and windows binaries. Calls which appear once in the original code, could appear multiple times in the assembly or not at all, and this would be entirely compiler specific.

tl;dr

The number of calls shouldn't be considered, just if it calls or not. When writing the relations, restraints should be applied like:

PHP Code:


{
    
calls
    
{
        
(windows mod a,blinux mod b
        
Z
    
}


Also, and that would need "building the call graph for the entire binary" it should be possible to express the relation function refers string.

Basically, this idea is making into a programmatic way what one does manually normally to find functions.

About implementing it, I think it would be nice for sourcemod to have it but I'm not into it (still in amxmodx). If someone makes it I would gladly try to use it in amxmodx.

About the parser you built If you make it public I would like to see it but more for learning (and maybe use later) since I'm not planning on making this (I was more sharing the idea and hoping that someone with the knowledge did it for sourcemod).

I think that if the idea gets implemented it will be useful. Signature scanning is messy and use it cross-mod or cross-compiler is a pain.

Quote:

then you'd want to make sure you cache the result and only rebuild it if the binary has changed
Yes that would make it ok even if the process took some time to finish.

devicenull 03-04-2010 22:38

Re: Idea to find functions in memory
 
Quote:

Originally Posted by joaquimandrade (Post 1107656)
Yes that would make it ok even if the process took some time to finish.

You would be very surprised as what most server admins would consider ok. Perhaps we could include this with the updater? Servers check for a cached version matching their server binary. If they don't find one, they compute it an submit it?

In my experience, server admins will think there's a problem if their server takes any significant amount of time to restart (anything more then a minute or two)

joaquimandrade 03-04-2010 22:40

Re: Idea to find functions in memory
 
Quote:

Originally Posted by devicenull (Post 1107811)
You would be very surprised as what most server admins would consider ok. Perhaps we could include this with the updater? Servers check for a cached version matching their server binary. If they don't find one, they compute it an submit it?

In my experience, server admins will think there's a problem if their server takes any significant amount of time to restart (anything more then a minute or two)

The process would happen only once per update. I believe it's ok even if it takes minutes. Anyway this is the matter of someone implementing and seeing if its worth and like pred said it can be made without parsing the full library.

About the cache submission (or just retrieval), I guess it would be ok to have one (per library) available to download.

Jamster 03-04-2010 22:54

Re: Idea to find functions in memory
 
Quote:

Originally Posted by devicenull (Post 1107811)
You would be very surprised as what most server admins would consider ok. Perhaps we could include this with the updater? Servers check for a cached version matching their server binary. If they don't find one, they compute it an submit it?

In my experience, server admins will think there's a problem if their server takes any significant amount of time to restart (anything more then a minute or two)

Myself, I would love if this was a core option, disabled by default but then can be enabled for those of us who know what's involved.

This would be a great addition to SM in my opinion.

Fyren 03-05-2010 18:10

Re: Idea to find functions in memory
 
Quote:

Originally Posted by joaquimandrade (Post 1107656)
The number of calls shouldn't be considered, just if it calls or not.

As pred said, there may not be a call at all in the binary for one OS while it may be there in the other, likely due to inlining.

This is an interesting idea, and I've pondered it myself, but I'm way too lazy.


All times are GMT -4. The time now is 07:09.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.