i have a packed exe file with a unknown packer, so i have to unpack it by hands. But when i open it using OllyDbg, it can't stop at the EP, OD has running status. Here, the exe has not a GUI, so i can see nothing. This exe file is attached to another program, when the other program(main program) start, this exe would be invoked. I want to use od to attach this sub-process, but i can't find it in the attach window of OD, although i can see both of the two process in task manager's process list. So, i want to know why? and how to resolve it?Thanks.

Regards,

Are you sure it doesn't appear in OllyDbg's process list? Hiding a process's presence is nontrivial and may indicate rootkit activity. What does PEiD have to say about the executable in question?

Anyway, you should be checking for calls from the parent process to to CreateProcessA and its kin. If it is launching a secondary process then it will need to use some API or other.

there are lots of ways to make it run without pausing
one that comes to mind atm is nicos sotm challenge exe that had some LoaderFlags modified to some value other than default which made ollydbg run without pausing

others like removing the temp bp set by ollydbg with tls on ep , Dllinit etc also are employed
to make it run without stopping

try breaking on system breakpoint try embedding a hardcoded int3 on peheader->addr of entrypoint etc

if it is a child process try breaking on CreateProcessApi of parent like suggested already

In fact, i had use HideOD plugin and HideToolz to hide my OllyDbg debugger and ignore all the exceptions of the debug options. I also made OllyDbg pause at the system break point. The packed exe has no tls. And i will try your advise right now, thanks

Yes, i really can't find it in OllyDbg's process list. PEiD says it normal as other packed exe files but with unkown packer. Since if i could find the call invoking this exe process, what could i do next?

Try and see if PE tools, Imprec, LordPE also fail to see this process in memory. If they see it, dump it, and analyze it with a disassembler.
It may be an Olly specific trick, perhaps?

I am sorry to forget to see (say?)that all the tools can't find the process, but only for windows' tasks manager. It is started by CreateProcessW function in its caller program. There i can see the command line, so i use this command line to start the exe file using CreateProcessW by myself, it will encounter a error message box as other wrong program "test.exe has encountered a problem and needs to close...."(test.exe is my test program) when the function is calling.

If i use OllyDbg to open it, i can do nothing, even to insert a breakpoint. So, I load it using Syser. Good, Syser can pause at the entrypoint, I can find the OEP successfully. When the control want to jump to the OEP, i modify the code to a endless loop. Then i return to Windows and want to dump it using PETools, but unfortunately, the process has exited. So, I can do nothing as normal.

So, after Syser load the program, I press F5 to return Windows, I can dump the program's memory using PETools. Then, I open ImportREC and input the OEP i have found, good, it afford to fix the dumped file successfully.

But the unpacked exe file can't replace the original one, if i did, the main program(the caller, which invoke the program) will be encounter a fatal error and have to closed. I can open my unpacked exe file using OllyDbg now, but when i press F9 to run the program, OllyDbg will pause one time after one time, it says "Debugged program was unable to process exceptions".

I want to know, what's wrong with it? How to dump such a program's memory when it goes to its OEP?
Thanks

it's kinda old thread, but this is a problem on how Olly list processes.
If the process is created as suspended, olly will just not list it in the list of process you can attach to.

hehe, this is not a olly specific problem, ida debugger for example will at least show suspended threads, but if you try to attach it fails.
Sounds resonable, because attaching a suspended thread can be difficult

should be. its really a difficult deal