Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workflow not precise #1

Open
3isenHeiM opened this issue Jul 7, 2020 · 5 comments
Open

Workflow not precise #1

3isenHeiM opened this issue Jul 7, 2020 · 5 comments

Comments

@3isenHeiM
Copy link

3isenHeiM commented Jul 7, 2020

Hi,
it's not an issue per say, more of a request for more information.

So far, I've :

  • Added my payload DLL (the one I need to run as SYSTEM) in the variable "SOURCE_FILE" in dllmain.cpp
  • Changed all the GUID and the bits and pieces since I'm targeting Symantec version 3335.1000
  • Compiled the RpcDll project
  • Put the generated DLL into the same folder as the copy of DevViewer.exe (renamed TextInputFramework.dll)
  • Executed DevViewer.exe. The GUI was opened.

However, I don't see the setup.dll in system32.

Any clues ? Am I doing it right ?

In TriDiag, do I need to change CLSID_CollectorService to the correct GUID ?

Many thanks :)

@3isenHeiM 3isenHeiM changed the title Worlkflow not precise Workflow not precise Jul 7, 2020
@hatRiot
Copy link
Contributor

hatRiot commented Jul 8, 2020

Hey @3isenHeiM

A few things:

  • When you changed all of the GUIDs, you also need to be sure you're including the correct IDL file and recompiling it. Once you change the GUID in the IDL, add it to your VS project, right click, and hit compile. This will produce a .c and .h file which needs to be added to your project prior to compiling
  • Please ensure the registry path at HKLM\\SOFTWARE\\WOW6432Node\\Symantec\\Symantec Endpoint Protection\\{C54D76E6-7423-47FD-84BA-DA73F3C0958F}\\Common Client\\ccIPC\\Channels exists
  • Ensure the ccSvcHst service is running
  • Confirm TextInputFramework.dll is being loaded by DevViewer.exe and your code is being executed
  • Is your complete version number 14.2.3335.1000?

If you have confirmed all of these things, I would be interested in knowing if there was an RPC error (see here). You can check this by adding a debug function that writes the error code to a file somewhere on your host.

@3isenHeiM
Copy link
Author

3isenHeiM commented Jul 8, 2020

Hi, thanks for the quick answer ! :)

  • Compiled the IDL but no .c nor .h files generated. However, I also updated the files 3335_1000_rpc_c.c, 3335_1000_rpc_s.c and 3335_1000_rpc_h.h.
  • Registry key exists (indide the correct GUID)
  • ccSvcHst.exe process is running (it's not a service though)
  • How can I check if the DLL is loaded while running DevViewer.exe ? ListDLL from sysinternal does this statically and ProcMon is blocked :/
  • Yes the complete version is 14.2.3335.1000

@hatRiot
Copy link
Contributor

hatRiot commented Jul 8, 2020

3335_1000_rpc_s.c and 3335_1000_rpc_s.h are not minor versions included in this repository, so the IDL must have compiled. Make sure you add both the .h and .c files to your Visual Studio project before compiling. My suspicion is the IDL/GUID isn't quite right here. Try deleting the .h/.c files, ensure the uuid(...) line in your IDL is correct, then add it to your project, right click, and compile. Then re-add the .h/.c files.

You can check using the Sysinternal's tool procmon. Just run it before you launch DevViewer and filter on the process name and event type.

@3isenHeiM
Copy link
Author

Thanks for the explanation :)

Re-compiled the RpcDll.dll, but restrictions on the machine prevent me to run ProcMon.
Since the GUI of DevViewer opens, I think the DLL is not loaded. And I don't see setup.dll in the system32 folder.

Besides that : in TrigDiag, where is mentioned the folder in which the FILE_NAME has to be executed ? Does it look by default in the SYSNATIVE folder for it ?

@hatRiot
Copy link
Contributor

hatRiot commented Jul 10, 2020

Using TrigDiag is only necessary once you've got setup.dll in your System32 folder, so we're not quite there yet.

You can confirm the DLL is being loaded by simply adding a system("calc.exe") or equivalent to your TextInputFramework.dll and checking if calc pops. If it does, please see my earlier comment about adding some debug output. Add a small function to write output to a text file somewhere (or attach to a console) and ensure you print the RPC error, if there is one. My guess is the problem is somewhere there, but I'd have to see the RPC error code to know for sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants