I didn't know whether to post this in Tools, or here. I asked once before about general queries and was told this forum was where to post the simpler stuff. It involves softice but it's not a technical question about softice per se. I'd appreciate comment from anyone who cares to comment.

Please note: this is not a straight 'licence expired' problem. The app is fully functional with the exception that its database is old and can't be renewed. So, I'm not faced with a splash screen looking for a serial. Also, the people who wrote the app are no dummies. I'm sure the solution is quite complicated and that's what interests me. I want to learn something about protections.

1)something strange is happening with the tracing procedure. In one area of code in particular, a call to RegQueryExA brings up a splash screen and a message box indicating the licence has expired. I was trying to track down where the message box is triggered but there's a lot of code and dll loading between the splash screen and the message box.

I have jumped over a zillion RegQuery calls in the past and never triggered an event. As far as I knew, RegQuery was not re-entrant, so there was no way for it to call back into the app's code. I single-stepped it to be sure, and neither the splash screen nor the message box triggered with that approach. I then jumped over a RegClose call and it happened again.

This app is heavy with IPC procedures. There are two threads set up with long GUID-like names, and the app seems to have added a second process thread since it expired. I know that because I checked it many times in Windows Task Manager when it failed to respond in the past. There would be a second thread, and when I killed that thread, everything was OK. So, it only ever had one thread running when it was running well. Now it has two.

Is it possible for one thread to watch another, then trigger the splash screen and message box when another thread queries the registry for a specific event? I'm learning about IPC but I'm still pretty dumb about it. The app is using memory mapping, CreateEvent, Mutexes and Semaphores.

2)I traced the code back from the message box to a GetMessageA function. I am rusty on message loops, but I presume the GetMessage was called in response to a PostMessage call. Or, at least, the GetMessage func was idling till one was posted. At one time I was adept at getting myself out of message loops but now I'm scratching my head a bit.

Since the GetMessage func is in a single process, can I assume it will keep cycling till there are no more messages, at which time it should let me back into the main code? I am trying to trace past the message loop to the calling function but I'm having trouble visualizing the procedure.

Feel free to correct me if I'm wrong, but somewhere along the line, something was done to decide the licence was out of date. If the coder was smart, and I presume he was, that code will be nowhere near any PostMessage funcs. However, once it's decided the licence is out of date, a message 'could' be sent to initiate a message box. If so, is there a relationship between the PostMessage func and the GetMessage func that would allow me to trace back? Or will I have to trace into the GetMessage func looking for a re-entrant point?

Somewhere before the PostMessage func should be a good guy/bad guy point (or many ) and that's what I'm looking for. I realize it's not that simple...there could, and probably is, a long, convoluted math process. What's complicatig the issue this time is the IPC threads. I'm used to Windows apps that follow a straight Window registration procedure then call ShowWindow, or something.

a multi threaded app always behaves that way while in a debugger only one thread executes at one time
so when you jump over some apis the sytem might allot a timeslice for other thread to operate and it would look like the api is
triggering that event

im not conversant with sice much but you can observe thais behaviour in all r3 debuggers when dealing with multi threaded apps

if you can load this bird or beast into ollydbg you can try looking at call stack (right click and choose the threads in call stack window) by default call stack will list the main thread only




yes thats possible if i remember well there was a contest and some results in erstwhile contests section of anticrack.de
google might have a cache of it

getmessage() translatemessage() translateAccelerator() dispatch message() etc are run in an infinite loop looking for messages continously

i dont get your they giving back control to main app code it would be part of an infinite loop and they start and die with application and till they die they just keep spinning looking for messages

if you want to trace then you would have to muck into gdi calls and win32k.sys SystemServices calls and thier wrappers
somewhere along the way from dispatch message (it takes a handle to the window thats going to be the reciepent along with the message it would endup in NtUserCallParam1,2,3,4 etc that would end up in int2b calls and the app code in question is called from r0 most of the time (see calc.exe , winmine.exe etc class procs thaey all will be located at high end of address viz 0xffff####

well if i remember well i think james of catch22.net had a createprocess example where one could use undocumented bits (reserved paramaeters to pass message from one app to another app etc and

If you haven't found it already you'll want to scope out what that 2nd thread is doing, monitoring an event from the first thread, creating the nag or whatever. One way to do that is to set a
BPX kernel32!BaseThreadStart
and step into the Call [ebp+08] to trace the thread from beginning to end.

You could patch in a simple RET at the start and just kill the whole thread, but that's probably not what you're trying to do.


If you want to get real funky with threads you can detect activation and deactivation of a thread from the scheduler with a trick from the Softice manual itself (replace 0xFF8B4020 with the KTEB/ETHREAD/KTHREAD pointer you get from the THREAD [processname] command).

Watch a thread being activated:
bpx ntoskrnl!SwapContext IF (edi==0xFF8B4020)

Watch a thread being deactivated:
bpx ntoskrnl!SwapContext IF (esi==0xFF8B4020)


This works because of the calling function @KiSwapContext where you can see how EDI and ESI are changed.



Not really that useful a trick but it will let you know when a thread switch occurs, and it also gives you dynamic access to the ETHREAD/EPROCESS/PEB structures if you want to play with them in situ.

Thanks for tip blabberer. I'll check that further.

I'll try that too. I have Olly loaded on my machine, and I started learning it about a month ago. Olly is a bit like Linux for me, however, in that the operator manuals are all over the place. I spent over an hour trying to find out how to set breakpoints in Olly. I was using softice as a comparison but it wasn't working well, so I spent hours getting it up again. I'll have to go back to Olly and suffer out the learning curve.


I was looking for tips like this...thanks.

yeah...I'm aware of that. In my experiences, when an app loads for the first time, the message loop hasn't been initiated. It isn't used till all the windows have been created, then it goes into a loop, in the message loop, waiting for thread-specific input.

What I'm dealing with is a situation where no windows have been created before the message loop is created. I've never seen anything like that before. There are threads being created with long GUID-like names from seeded numbers, like in an SHA1 encryption routine, but not as complicated. These threads get a different name on each boot, so it's virtually impossible to BPX on anything.

Once the main window is up, it's easier to relate it to the message loop. I have no idea at this point where the message loop is entered, so I don't know how to trace through it to find what called into it. Normally, an app will incorporate the message loop as part of winmain. On first boot, it will follow the code in winmain, setting up its windows, then come to the message loop and loop, waiting for an input to a window.

I'm not normally concerned with that situation because I can trace the app to see what it's doing, then I can play divide and conquer. Since this app is is using COM and IPC, as well as the msvcrt library, 'before' any windows are set up, it's hard to get a feeling for what it's doing, especially since I don't know a lot about COM or IPC. I am learning quickly.

All I know at this point is that a PostMessage func is calling to say the licence is expired, As I said, I have traced back from the message box to a GetMessage func, that does not seem to be in the main message loop. I just thought of that and I need to check it further. My question still stands as to how I can extricate myself from the GetMessage loop.

there has to be an interaction between the message loop and the main code. Modern languages like C++ and other OOP languages are urging people to think in abstracted objects. The code trail can actually still be thought of as in the old days: as a linear code with subroutines. If that was not the case, we would not be able to trace it with softice and Olly. There are processes going on in the background which are processor specific, but when I'm tracing with softice, as far as I know, the focused window thread is being executed one step at a time. My system clock even stops while I'm in softice.

That means to me that any message must either be inserted into the message loop by the app, or by an external interrupt like a mouse or keyboard. The app's message loop has no way to be running independently of the main code process. To get a message, GetMessage, in an app's code, has to be executed by the app's code. That means it has to be entered and exited. In other words, something has to call into the function and the function has to return to the calling function.

Meantime, Windows keeps a separate message loop in an infinite loop. It's job is to watch for mouse and keyboard input, for example, and to place messages in a message queue, which the apps message loop must check every so often. I'm not clear on this process.

I'm not asserting that anything I've said here is correct, but it's what I see as going on. Maybe I'm way off base. I have experienced going in one side of a message loop and out the other side, and back into the main code. I'll need to look at this more closely.

Hey Kayaker...I'm in the process of doing that, but it's a tough one for me. I have so far carefully dissected the entry code and a fair way through winmain. I have pages of notes on the code.

BTW...I tried this tool a guy had designed called Tracedump. He mentioned something about upgrading it to the XP level, but I guess he didn't have the time, or not enough interest was shown. I'm getting by using IceExt and referencing softice code to IDA.

As I said, the main problem for me right now is understanding the IPC process, and it's coming slowly. I am doing a crash course on critical sections, mutexes, events and threads in general. I was hoping someone with expertise in IPC could say something illuminating, or explain the process in reversing terms. Reading programmers talking about it gives me a headache.

I'm aware that mutexes et al are objects used to protect a thread by giving it exclusive access to data, so another thread can't interfere while it's doing that. I presume each thread taking part in an IPC event has specific code in the app. For example, the app knows the licence has expired, so it must have read the licence file. As I trace through the IPC code, called from the main app, I can't see where that code is accessed. That's because I don't yet understand the process well enough.

What is not made clear by texts on the subject is how these objects work under the hood. They talk about them as if they are objects like apples or oranges, which is a total abstraction. Mutexes, events, etc., are controls and checks to make sure code execution behaves.

In my app, functions are used like CreateFileMapping, MapViewofFile, CreatEvent, CreatMutex, etc.,, and I have a basic understanding of what they are doing. They are mapping files (code) into memory so they can act as servers or clients, or vice versa. All I've seen so far are server objects being created, but i can't see where the actual code is used.



funny enough, I was merrily tracing through ring 0 and noticed the call to SwapContext. I was tracing into WaitForSingleObject to see if it was re-entrant. Being new in the neighbourhood, it did not occur to me to drop into that function. I'll give it a closer look. There is a problem in that it's awfully easy to get lost down there.

I was in ring 0 and ran into this strange function I didn't recognize, WGMAN. I spent a long time trying to get out of it and gave up. It turned out to belong to the Sygate firewall. Another time, it was my NIC card driver. I have learned to shut down all unnecessary drivers while tracing through ring 0. There is so much garbage interfering with mainstream code down there it's a wonder Windows works at all. And that's not talking about the registry, a real dumping ground for everybody's data diarrhea.

I have been reading a lot on threads recently but it takes time to digest the finer points that you have described here. I will keep digging deeper. Thanks for the tips.

I did a bit of research and summarized it here:

After the UpdateWindow call, the window is fully visible on the video display. The program makes itself ready to read keyboard and mouse input from the user. Windows maintains a "message queue" for each Windows program currently running under Windows. When an input event occurs, Windows translates the event into a "message" that it places in the program's message queue. A program retrieves messages from the message queue by executing a block of code known as the "message loop":

while (GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}

The msg variable is a structure of type MSG, which is defined in the WINUSER.H header file.

The GetMessage call that begins the message loop retrieves a message from the message queue. TranslateMessage passes the msg structure back to Windows for some keyboard translation. The statement, DispatchMessage, again passes the msg structure back to Windows. Windows then sends the message to the appropriate window procedure for processing. What this means is that Windows calls the window procedure. After WndProc processes the message, it returns control to Windows, which is still servicing the DispatchMessage call. When Windows returns to the app following the DispatchMessage call, the message loop continues with the next GetMessage call.

I looked at several message loops and they were all part of the WinMain function. The rest of the WinMain function seemed to be about creating window classes, registering them, and creating them. Once all the windows were up and running, the code looped in the message loop waiting for a message.

Another important function in the simple windows code I looked at was the WinProc function:

LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)

This is apparently the Windows procedure called by Windows, although their can be more than one WinProc. The window procedure determines what the window displays in its client area and how the window responds to user input. Note the UINT message, which Windows fills in with the windows message.

I think that answers my question. It would seem I need to trace into the DispatchMessage func till I reach the point where Windows calls the appropriate function.

Unfortunately, the GetMessage function was probably called to get the message from me hitting the OK button on the message box, AFTER the app had decided the licence was out of date. I'm hoping the GetMessage function will now go to the DispatchMessage func and back to the calling procedure via Windows. I'll let you know.

Note that the situation in my app is not the same as here. None of the windows are up except for the splash screen. That indicates to me that the message loop I have encountered is temporary, or there it's the real message loop and the app has been temprarily diverted to use it.

Kayaker...sorry, I misread what you were saying. I thought it was about the BPX baseprocessstart we were discussing before.

OK, I followed your suggestion and ice broke almost immediately in repdrvfs.dll, which is a Windoze WMI file. That's annoying. I stripped WMI off my system once because it was following my files around. I rebuilt it but I may have to remove it again.

Anyway, I hit F5 and the app ran till just after the splash screen and broke again. This time it was the first process I mentioned that was on its own till the expired licence message box appeared. It's apparently the IPC server. I was doing well with the tracing but I forgot to disable my BP and it broke on a thread creation from Sygate...again!! I wish these firewall outfits would give you an option as to how intrusive they can be.

I'll reload and try again but it's late. There is another instance running as a process and I want to see what it's up to. I may take your advice to insert a ret in it, just to see what happens.

BTW...the function called was IPC_RECV. It appears to send a message to an address.

with ollydbg to set a break point on any arbitrary location (provided you are sure that the address points to start of command and not to middle ) there are various ways

assuming your application loaded at imagebase 400000 and the code section started at 401000 and olly has stopped on 401000

(initial bp set by ollydbg) and you want to set break point at 401034

1) hit ctrl+g and type 401034 hit enter and hit f2
you will see a red marker popup on that address that means your break point on that address has been set to remove it just hit f2 again you will see the red marker disappeared
hit f2 again it appears back (f2 is toggle for setting and removing the normal 0xcc replacement break point)

2) ollydbg comes with a default plugin commandline you can invoke it with shortcut key
alt+f1
type bp 401034 on there and hit enter you will see the by now familiar red marker again on the address

3)if you are bored to hit alt+f1 every time and after work remove it from view there is the same plugin modified by gigapede called commandbar on configuring it to show it just minimises
itself to status bar and sits open without hindering view now you can use bp and bc just by typing the arbitrary address in there

4) also there is a bpx syntax wherby you can type the callnames
like bpx GetModuleHandleA
which would effectively set breakpoints on all occurances within the module that is being examined

00401048 |. E8 25E00A00 CALL <JMP.&KERNEL32.GetModuleHandleA> ; \GetModuleHandleA

Breakpoints
Address Module Active Disassembly Comment
00401022 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
00401048 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004A213B OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004A2757 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004A4367 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004AC268 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004AD34E OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand
004AD403 OLLYDBG Always CALL <JMP.&KERNEL32.GetModuleHand



5) if you donot wish to set a breakpoint on the module that is being examined
but set it directly on the procedure in respective system dll

just use bp GetModuleHandleA (notice no x but just bp)
and olllydbg will set a int3 break point on dlls procedure entry point
like this on nt based sysem (w9x and me dont allow writing to shared memory)
though could be worked around with some helpers like ollyghost and made writable

Breakpoints, item 8
Address=7C80B529 kernel32.GetModuleHandleA
Module=kernel32
Active=Always
Disassembly=MOV EDI, EDI

6) also you can do all this with clickety clicks too
right click --> searchfor -> names in current module OR intermodular calls
start typing Getmodu and you will see the list auto scrolling and take you to the import if it existed
right click set break point on every referance
this has the added advantage of setting the break on jmp table too
so that obfuscated register calls could break too
like below calls

00401000 > 8D05 72F04A00 LEA EAX, DWORD PTR DS:[4AF072]
00401006 FFD0 CALL NEAR EAX ; <JMP.&KERNEL32.GetModuleHandleA>

the above all pertains to int 3 break points

apart from int3 break points
you can set conditional int3 break points (shift +f2)
conditional log breakpoints (shift +f4)

hardware breakpoint on read,write,execute on code as well as on read write on data (debug menu --> hard ware breakpoints) or right click on cpu pane--> hardware break point

you can set memory break points on access read and write

you can set page gaurd breaks too on memory

assume you are unpacking some target and you know it has decrypted the code section and it is going to hit code section
just view memory and set break on access on whole page
and ollydbg will break when that page is accessed on any arbitrary command

also you can set msg break points on certain messages like WM_LBUTTONCLICK or WM_CHAR

use windows window right click set msg breakpoint on classproc or window

if you are bore with 0xcc int 3 breaks you can use a polymorphic breakpointer plugin by mattwood that sets int 3 bp with cd 03 two byte bps or iirc you can select ebfe hook and rehook methods

hope i made the learning curve a bit flatter for you atleast for breakpoint releated things


anyway if the spalash screen is there then it means the window proc is there either by the coder or using comctrl premade
windowless windows or transparent windows or some such named windoze

and there is no stead fast rule that the winproc needs to handle or will get every message many are pre processed by DefWindowProc inside user32.dll or comctrl winprocs

if it is a button try breaking on BM_CLICK (button messageClick )

another beast called SubClassing and superclassing exists which again will divert the messages to another location of choice

try logging all the messages by intercepting Translatemessage() inisde system dll and filter out

also if the app in question is some kind of beast like bcbbuilder then you have to deal with WM_USER+ messages and deal with
arraytables case switches and such crap all subclassed and pita to decipher

all google hits on ipc_recv somehow point its usage ti ibm-tivoli tcp interprocess communication it seems
and this ipc_recv is a nix creation it seems

ipc_recv
Unix Prototype : int ipc_recv(int sock, char *buf)
Windows Prototype : int ipc_recv(SOCKET sock, char *buf) using winsock
Parameters :
Name : sock
Description: socket to receive from

Name : buf
Description: receive buffer

Returns : number of bytes read upon success, zero otherwise

this site seems to have some tcp library for ipc
http://www.future-lab.com/download/index.html

Considering the APIs you mention above, I think you're thinking of the concept of "IPC" at a too high, complex or magic level. IPC implemented with those APIs is normally simply about two processes (or threads, even though technically that would be ITC ) sharing a memory buffer, waiting for the other one to write something to it and notifying the other part that this has been done (by incrementing a semaphore or releasing a mutex).

My suggestion would be to breakpoint MapViewofFile, and its return value will be the address of this communication buffer. Then set memory breakpoints in this buffer and you will be able to land smack in the middle of the IPC code of each process/thread. Then analyze it from there to be able to set even better breakpoints etc.

You sure have. Thanks for taking the time to write all this out. I have printed it for reference and even filed a copy under Olly in my Olly tute directory.

under normal circumstances I'd have no problem with that. The programmer has gone a different direction, however, and has introduced obstacles to tracing, either intentionally or to load his dlls and threads as required. I am tracing through lots of code that involves IPC calls and server code without understanding what I'm doing or where I'm going. I'm looking for landmarks.

The splash screen is irrelevant to me right now, providing only a visual marker to where I am in the code. For example, using Kayaker's suggestion for isolating threads, I can tell by whether the splash screen comes up or not, that I have reached my app's code. The threads are formed after the splash screen.

I understand basically how the winproc works and its association with DefWindowProc. However, if a WinProc has sent a PostMessage, it is most likely waiting for a reply from Windows.

I don't know if you're aware of the program Spyxx. It came originally with a Micro$oft programming package and it's dandy for interogating message boxes, etc. If you have a message box up, you can load Spyxx and it will list all processes currently running. All the hwnds are listed too. You can also find a window using a crosshair cursor. As you drag it over a window it will tell you lots of things about the object.

You can use that info to locate the window on the process list, highlight it, and right-click on it. You can pick 'messages', in which case another window comes up to record 'any' message that window processes. With a message box, you can click the OK button, and Spyxx will record every message that window outputs. That's how I found the secret messages this app uses.

there are several ways IPC can be used. One way is aimed at networks, and I imagine the reference you got was related to that, considering the tcp.

I got another reference to ipc_recv(message, to address, from address, options). I was too tired last night to follow through on that.

Hey Delta...thanks for input. I'm trying to visualize exactly how that would apply in my app. There are many dll's used by the app for various purposes and they seem to be called when selected from the app. The main thread seems to be the server and seems to access the dlls through memory mapping. If that's the case, I don't see the advantage of that over simply loaded the dlls as required. Do you think it might be protection scheme, or am I being paranoid?

good suggestion...I'll give it a go. I get hung up at times due to the enormous amount of bloated code used. I can't believe how many times long character strings are scanned and moved. There's so much redundancy.

Oh you just gotta pwn this app now, this ipc_recv is too intruiging

Is there an ipc_send? How did you find ipc_recv? Is it a dll function, maybe a wrapper for a more familiar mechanism? Can you breakpoint on it? Inquiring minds want to know..

It would be sweet if you could hook it and dump out the parameters and message block. Maybe it's used for a lot of communication other than just the nag/license check, and you may need to hook/dump/interpret the messages in order to fully understand it.

You might have a look at this to see what I'm getting at:

Fuzzing Win32 Interprocess Communication Mechanisms
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Burns.pdf

I found them in calls to an aptly named dll, a library in the app's directory. After loading the dll as an export in sice, the calls became more meaningful. There is definitely an IPC_SEND, with similar parameters to IPC_RECV. I don't want to say too much more for fear of revealing the app and getting the board in deep doo doo. PM me if you want to know more.

The calls to the dll don't show up in IDA. There's a call to a local address with a data reference, but that reference has ???'s in it. They must be inserted dynamically at load time. I found them in sice after loading the dll as an export.

I have interpreted several of the messages used elswhere in the app, maybe I should focus more on that.

yes sortof if not the ms spyxx i know of and do use a few like winspy++ and few others

anyway i thought a table of ipc mechanisms in windows should hold good for archival purposes



all these are used for ipc in windows world is the official word

http://support.microsoft.com/kb/95900

thanks for info, Blabberer. The app is definitely using Semaphores, MemMapped files, and maybe WM_COPYDATA. Also, Mutexes, Events and Critical Sections. It's not using pipes because none of the func names have 'pipe' in them and any funcs I've seen related to pipes do.

It's using so much code creating long strings for names on servers, mutexes, semaphores, etc., that I'm beginning to suspect the protection has something to do with that. The licence file also has long character strings. However, the idea of creating encrypted names from variables in the app, like Pid's, so the names are different each boot, is a good idea.