reversing a dll

[fir]

if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)

i wonder if it is realatively easy to read (probably by some disasemmbly) the number and size (and maybe partial type like if pointer or not) of arguments that those functions take

could someone put some light on it?

[Chris M. Thomasson]

On 3/22/2017 11:59 PM, fir wrote:
> if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
>

Have you ever gave:

http://www.dependencywalker.com

a try ;^)

[Christian Gollwitzer]

Am 23.03.17 um 07:59 schrieb fir:

This information is not stored within the DLL typically, you will need
the header file. Only if you got debug information, then the full
signature is stored there. Since you are talking about DLL and EXE,
assuming Windows 64 bit, you can find the calling conventions here:

https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention

Some arguments are passed in the registers, only if it is too much they
are passed via the stack. The return from the procedure can give you a
hint if it pops something off the stack, but otherwise you'll need to
read and understand the assembly code of the function.

BTW: Since this is all platform specific and independent of the
programming language, it is off topic here in clc++.

Christian

[fir]

i know that.. (assume more 32 bit btw..) .. the question is if this this disasembly would be hard or easy (and how exactly it would be) as it is some kind of pattern that repeats same in each case you maybe not need whole analysis but something more simple.. (im not so much into it to know it just right away)

[Alf P. Steinbach]

On 23-Mar-17 7:59 AM, fir wrote:
> if you got a dll it is easy to read its export and import names (i
> use total commander plugin to see it), (this means that reversing dll
> is easier than reversing exe)

There are a great many tools that do provide you with such lists: GNU's
objdump etc., Microsoft dumpbin, Borland's (whoever has it now) tdump,
Matt Pietrek's dump facility (pdump? I don't remember), etc. etc.

> i wonder if it is realatively easy to read (probably by some
> disasemmbly) the number and size (and maybe partial type like if
> pointer or not) of arguments that those functions take

That depends.

I think that often the total size is encoded in the name mangling. That
mangling depends on the compiler used, though.

More portably, /some/ DLLs provide a type library, and Windows provides
APIs to read type libraries, plus the OLE/COM object viewer tool. After
all that's what the type libraries are for, to provide this information.
But they're intended for scripting languages.

> could someone put some light on it?

As someone else mentioned, this has nothing to do with C++ as such,
except that if you want to invest unreasonably much work into code to
read type libraries then C++ is The Thing™, and it has nothing to do
with some earlier discussion in this group, so it's really off-topic.


Cheers!,

- Alf

[Christian Gollwitzer]

Am 23.03.17 um 09:12 schrieb fir:

>>
Some arguments are passed in the registers, only if it is too much they
>> are passed via the stack. The return from the procedure can give
>> you a hint if it pops something off the stack, but otherwise you'll
>> need to read and understand the assembly code of the function.
>>

> i know that.. (assume more 32 bit btw..) .. the question is if this
> this disasembly would be hard or easy (and how exactly it would be)
> as it is some kind of pattern that repeats same in each case you
> maybe not need whole analysis but something more simple.. (im not so
> much into it to know it just right away)

So you want to write an automated code analyser which gives you the
number / type of parameters? This is most probably not possible. In 16
bit, it would be partly possible, because 16 bit x86 passes everything
on the stack. The return from the procedure cleans up the stack, so "ret
20" tells you that there are 5 16bit words as parameters. But for 32bit
and 64bit you are out of luck because the parameters are passed in
registers. This is one of the things that makes today's compilers fast.
They do not compute the args, then move to the registers and call the
function - instead the computation is adapted such that the parameters
end up in the corresponding registers. Therefore it would als be next to
impossible if you had a call site for the DLL for analysis.

Your best bet as a human reverse engineer would be to go to the
beginning of the procedure and note down, which parameters are first
touched, i.e. copied, used etc. If there are parameters on the stack,
you will see access to [rsp+xx] or the frame-pointer thingy mov %rsp,
%rbp and access to [rbp+xx].

Christian

[Cholo Lennon]

If you can get it, you can use a proprietary tool: IDA (the Interactive
DisAssembler), by far the best dissasembler out there (it has a debugger
too). Not only it is capable of disassemble a wide number of executable
files, but it also has the ability to convert detected functions to C
code (among other useful features).

Regards

--
Cholo Lennon
Bs.As.
ARG

[Rick C. Hodgin]

It is not easily possible. That information is not contained within
the DLL in explicit form, so it must be derived. You must derive
the calling convention, the nuances of the caller/callee relationship.
You cannot know if the code was generated as custom assembly, or by
compiler output. There are hints and signs, but it's very difficult
to know in well-optimized code.

CAlive has addressed this by allowing compiler options for DLLs and
other forms of compiled binaries, including Manual, Limited, Extended,
and Full:

https://groups.google.com/d/msg/caliveprogramminglanguage/VE6omApXpUk/_evQOFQ2BAAJ

These will allow compile-time information to be conveyed through the
binary in a standard form that can be queried upon demand, sent through
standard parsing algorithms, which can yield information about what the
code contains.

Thank you,
Rick C. Hodgin

[Bonita Montero]

When I first saw your posting I thought I'll read a recommendation
on how to analyze the DLL-exports by the help of the lord. ^^

--
http://facebook.com/bonita.montero/

[Cholo Lennon]

On 23/03/2017 10:44, Rick C. Hodgin wrote:
> On Thursday, March 23, 2017 at 2:59:33 AM UTC-4, fir wrote:
>> if you got a dll it is easy to read its export and import names (i use total commander plugin to see it), (this means that reversing dll is easier than reversing exe)
>>
>> i wonder if it is realatively easy to read (probably by some disasemmbly) the number and size (and maybe partial type like if pointer or not) of arguments that those functions take
>>
>> could someone put some light on it?
>
> It is not easily possible. That information is not contained within
> the DLL in explicit form, so it must be derived. You must derive
> the calling convention, the nuances of the caller/callee relationship.
> You cannot know if the code was generated as custom assembly, or by
> compiler output. There are hints and signs, but it's very difficult
> to know in well-optimized code.

IDA is able to do that with very good precision (excellent precision
with 'standard' binaries). For unusual cases, it can be tuned it up in
order to help the disassembling process.

>
> CAlive has addressed this by allowing compiler options for DLLs and
> other forms of compiled binaries, including Manual, Limited, Extended,
> and Full:
>
> https://groups.google.com/d/msg/caliveprogramminglanguage/VE6omApXpUk/_evQOFQ2BAAJ
>
> These will allow compile-time information to be conveyed through the
> binary in a standard form that can be queried upon demand, sent through
> standard parsing algorithms, which can yield information about what the
> code contains.
>

[Rick C. Hodgin]

I like you, Bonita. :-)

In a way, that's exactly what did happen isn't it? Look at your hand,
for example. In order to do that one act, there are literally like 10
billion things which the Lord had to lay down to make it happen. If
even one of those things weren't there as they are, it would not happen.
Everything we possess comes from Him and His Creation, all the way down
to the operation of atoms and their even smaller components. We owe
the entirety of everything we are and can ever be to Him ... and that's
not just our guidance here in this life, the opportunities we've had,
and so forth ... it's everything even to the point of our existence,
and our place in His Kingdom (either in Heaven, or ... elsewhere).

[Rick C. Hodgin]

It's possible to do it. It's possible to do it reliably in many cases.
It's just not a given that it will always work because you are deriving
things which require assumptions. In most cases they'll be fine, but
not in all.

[fir]

i dont want tio write automatic analiser i want to
do it more by human eye..

if dlls convention is __cdecl and probably this is something callee-cleanning you will see the stack unvind
thus sizes (what exactly is this convention in dll? you are probably wrong speaking on fastcall and 32 bit but
im not sure, maybe system api like kernal32.dll uses this?)

ps assume 32 bit and assume c interface

harder could be tough reckognize type of the args,
though maybe also possible, at least the basic three
would be nice to reckognize (int, something*, float)

now im to tired to try disassebly and look but i wonder