Sitting on the Lolbins, 1

Posted on by

I recently mentioned that I am sitting on quite a few lolbins, and was asked to share, so here’s the first batch – at least 6 of them 🙂

c:\Program Files\HP\<model>\
\Bin\<model>.exe
\Bin\HPCustParticUI.exe
\Bin\hpqDTSS.exe
\Bin\InstanceFinderDlg.exe
\Bin\ScanToPCActivationApp.exe
\Bin\Toolbox.exe

where <model> means the actual HP printer model e.g. HP OfficeJet Pro 8710:

c:\Program Files\HP\HP OfficeJet Pro 8710\Bin\HP OfficeJet Pro 8710.exe

All of them take a nice command line argument -uiDll, e.g.:

Toolbox.exe -uiDll c:\Test\test.dll

This loads and executes your DLL of choice 🙂

Notably, there are a few more executables in the same directory that can be used for this purpose:

\Bin\DigitalWizards.exe
\Bin\FaxApplications.exe
\Bin\HPRewards.exe

but they require additional command line arguments that I have not figured out yet.

Beyond good ol’ Run key, Part 112

Posted on by

This is a pretty ancient persistence trick one can use on systems where IBM’s Java Control Panel is still present.

On these systems you will find Registry Key:

HKLM\SOFTWARE\IBM\Java2 Runtime Environment\
<version>\

and a Value Name underneath called:

JavaHome = <directory>

By changing this value, one can ensure that next time the Control Panel applet is called, the signed CPL file will launch a bin\javacpl.exe program from this path.

In other words, for the example old version 1.6.0 one could change the value name to this:

HKLM\SOFTWARE\IBM\Java2 Runtime Environment\
1.6.0\JavaHome=c:\test

and then drop a malicious c:\Test\bin\javacpl.exe file.

I have not tested it, but I am pretty sure that changing the value of that variable will definitely affect the way Java works, so things will be probably broken, unless proper links to files are established for all the content residing in the actual JavaHome directory.

Yes, it’s ancient, and probably dead by this time + not worth pursuing, but just documenting… because why not.