Hello,
It's been a while since I've posted here, that's not to say I don't
visit every once in a while!

I have a couple of questions about an interesting program I would
like to reverse. I'm trying to learn as much as I can about how it works
before I attempt to make sense of any dead listings or debugging.

The app generates a unique hexadecimal ID based on some of the
computer hardware components, this is equivalent to a user name.
Passwords are validated based on this unique ID. Nothing new here
really.

I found that the exe has the magic constants P and Q as used in
RC5/6. So my initial thinking is that the computer ID and password
validation are based on one of these algos.

I reasoned that if I alter each constant by a digit this is likely to cause
the unique ID value to change or reject the validation of previously
valid passwords. No such effects were evident, the program just
performed as normal.

What I'd like to know is if my reasoning is correct and can is it safe to
assume that these algos are not used? It does seem odd that I
found a function header contain "RC5" in its name. Perhaps it has been
compiled into the code though not actually used?

The program in question acts as a client which on request loads a
second independent program (no network connectiom).

The second program in turn loads a DLL which acts on the the ID and
password in some way.
What I'd like to know here is how does the DLL knows where in the
memory space of the client will these variables will be stored.

Does it find the entry point of the client and use fixed offsets to
access the variables?
How would you implement this in C/C++ for example? This should aid
my understanding.

Thanks for reading my post.

Put a data breakpoint on the constants if you want to know where/if they are used. Also, any values in the main app memory space that are used by the dll are most likely communicated by parameters to some function in the dll, either directly (passing the value itself, or a direct pointer to it) or indirectly (passing a pointer that is in the beginning of some kind of pointer chain, which can ultimately be used to resolve the address of the value in the main app memory space).

Doing this would give me a definitive answer.


What you suggest is more logical, I got the direction of communcation the wrong way around. I've since noticed that the DLL does a check to see if the client is running. If I were to remove this check with a simple patch and
load the second app independently, this would confirm the direction of communication. Though I'm sure you are quite correct.
This does raise one question for me though, can the client pass values to the DLL even the the DLL is loaded by the second program. Is his quite a normal thing to do? Iwould have thought this is some sort of OS security breach?
Hmm, slightly confused by this.

Once again Delta you are the first to post a reply. Thanks for the insight, I'll see were this leads me. .
5Alive.

I'm not completely sure what you mean, but here are some facts:

1.
Several programs can load the same dll at the same time, yes.

2.
Several programs can load the same dll at the same time, and also operate on the same set of live data inside a shared data section of this dll, yes (such shared data sections are defined in the dll at compile/link time, and the operating system will then make these sections global to all processes that loads the dll).

3.
Other types of shared memory, created dynamically at runtime can also be used to share data between different processes loading the same dll, yes.

4.
Under "normal conditions" (i.e. when no shared data sections have been explicitly defined in the dll, and no dynamic shared memory code is being used in it), all loaded instances of the dll will operate on their own set of data though, i.e. if some data manipulating call is made to the dll from one process, all other instances of this dll loaded by other processes will stay completely unaffected.

Hi Delta,

I've just ran Process Explorer by Sys Internals, in DLL view it shows that the main app doesn't load the DLL in question, only when the main app loads the second program, the second program loads the DLL.

I was confused that one program could write data into the memory space of a second independent program, I understood this program memory space to be protected against other programs writing data to them. But then of course programs like trainers and loaders do exactly this. I guess this only applies to operating system files then?

So if one only one program loads the DLL, can a second program write to its data section? If I undestand correctly, I don't think any of the facts you listed conform to the way this program behaves.

The only way I can see this working is if the DLL has some shared data space, that the main app can write data to.

Judging from your description, my guess would be that the dll either reads the values from a file or registry key, or that you have misunderstood something about what the dll actually does, or the meaning of those values.

But sure, processes can manipulate the memory space of other processes by using several different API commands used for debugging and such (this is what loaders and trainers do). The user account under which the manipulating process is running must have certain privileges allowed from the operating system to do this though. Also, even harder restrictions apply when manipulating the memory of other processes that are not running under the same user account as the manipulating process itself.

But in this case I really don't see any reason why your application would use techniques like this, it seems quite unnecessary from what you have told us about the application anyway.

These values are indeed stored in the registry, having run the registry monitor it is the main app can be seen to read these values,
this acts as a check to see that the unique ID hasn't changed for the current password(s). If the ID has changed, the registry is updated with a new ID and the now invalide passwords are removed.

I am now convinced that unique ID and passwords must be read by the DLL as you suggest, however, having said that, regmon only seem to display registry acesses via executables. Is this pehaps a limitation of regmon, what choices might I have to see the DLL read from the registry?

The other thing that confuses things a bit for me is that if I load the secondary program independently of the main app, the DLL will load as expected, but it will protest that it cannot be run without the main app running in memory. I patched this check in the hope that the DLL would read the registry values and run. It now protests that the secondary app must be launched via the main app. Perhaps if I patch this it'll fix it.


It looks like I've been overthinking things a little bit here maybe.
Thanks for the advice so far.
5aLIVE

DLLs are loaded by executables into the executable's process space, and then their code can be executed inside this process space. Hence, the registry access will be logged for the process that currently has the dll loaded and executes its code when it happens. It's not a limitation in Regmon, it logs processes, not the modules from which they originate (if any).

And if you are struggling with the regmon printout, you should check out this thread:
http://www.woodmann.com/forum/showthread.php?t=4162

were Kayaker provides a utility to remove duplicate entries, to make the study more "revealing." As Kayaker said: "It was actually JMI's woeful story of having to sift through 20,000+ Regmon log entries that finally spurred me to code this idea I'd had for quite a long time." We all owe him a debt of gratitude for that effort and the review of 20,000+ entries which may no longer be necessary.

Regards,

@dELTA, I've learned a great deal from the little excursion so far, and now understand that it is the calling process rather than the DLL which will be shown a reading from the registry.

So in this particular case, will the main app be shown as the process which reads the registry values of interest? When at a particular point in time, it is actually the loaded DLL from the secondary app. In other words the process at the top of the "process tree" is always shown to be the one accessing the registry. Have I got this right?

I'll aim to have a proper sift through the regmon logs to see what I can find. Thanks JMI/Kayaker for the little app. I'll try it out tomorrow, I need some sleep now.

Thanks guys.
5aLIVE

No, the relationship between processes (i.e., who started who) will not matter in Regmon, the process that loaded the dll will be the one showing. Note that dlls are not own processes, they are just incorporated into the process that loads them, so they are not "subprocesses" or something like that.

Okay that's clear, in that case the secondary app doesn't read the particular registry values im interested in. I've confirmed this by disassembling both the main app and the DLL and only found RegQueyValueEx API calls in the main app. I made use of Kayakers tool to help sift through things, very helpful indeed!

So the main app must pass these values to the DLL at some point. Therefor I think I need to find the RegQueyValueEx calls of interest and then where in memory these are stored.

If I then set BPs these memory locations being read, I should be able to see the communication beteween the main app passing these values to the the DLL? Is this a good approach?

I'm learning as I go so this will doubtless take some time. Sorry for all these questions, I am trying to do as much as I can though I do need a bit of guidance here and there.
Regards 5aLIVE.

Yeah, that should be pretty ok. Breakpoint the RegQueyValueEx API to find the right call faster. But exactly what location in the code is it that you are trying to pinpoint, and why? Why is the point of communication of the values to the dll important? Didn't you already know the point in the dll that performs calculations on the values?

I'll give it a shot.


See my answer below.


In a word, no. Presently what I do know is that these values are input to a message digest algo, there maybe a salt added I need to find too.
It is my aim to find out how these values are manipulated in the DLL before a digest is created.

Part of the digest is then used to create an interim key to use with a symmetric crypto algo.

It might be quite efficient to breakpoint all the exports of the dll, if you're lucky it will not make many more calls to it than the one you're looking for, with the hashing. This will also make it very easy to inspect all parameters that are passed to the dll (and the return values from the dll too).

Sounds like a good idea to me. I've since found paremter references in the data section to ID and password which should help me find what I'm looking for.

The more I look at this, I think I should be concentrating my efforts on the main app as this is where the unique ID is generated and where the password is checked. Now lets see what I can find today.

5aLIVE