{"id":8501,"date":"2023-05-12T21:35:49","date_gmt":"2023-05-12T21:35:49","guid":{"rendered":"https:\/\/www.hexacorn.com\/blog\/?p=8501"},"modified":"2023-05-12T21:36:06","modified_gmt":"2023-05-12T21:36:06","slug":"matlab-persistent-lolbin-2-years-too-late-but-always","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2023\/05\/12\/matlab-persistent-lolbin-2-years-too-late-but-always\/","title":{"rendered":"Matlab persistent lolbin – 2 years too late, but always…"},"content":{"rendered":"\n

I just realized I have never published a post about lolbinish\/persistencish Matlab feature that I referred to in this twit<\/a>. The Tl;dr; is that Matlab can load a DLL of our choice when we use its feature that is both Matlab-user friendly, and … unbelievable.<\/p>\n\n\n\n

Using the following command line invocation:<\/p>\n\n\n\n

MATLAB.exe -nosplash -nodesktop -r \"run('c:\\test\\test.m'); exit;\"<\/pre>\n\n\n\n
we can instruct matlab to load the matlab file named ‘test.m’ in a batch-like fashion.<\/p>\n\n\n\n
The ‘test.m’ in this example include a short piece of code shown below:<\/p>\n\n\n\n
x = foo();<\/pre>\n\n\n\n
When matlab loads the ‘test.m’, it tries to resolve the function ‘foo’ that it will eventually recognize as unknown; as a result, it will look for locally present Matlab executable files (*.mex32 on 32-, and *.mexw64 on 64-bit Windows), and will try to find that function there. In our case (on 64-bit version of OS\/matlab) it will look for a ‘foo.mexw64’ file, load it (it is a DLL), and then call a function mexFunctio<\/em>n acting as an interface between matlab and the matlab executable.<\/p>\n\n\n\n
The example session is shown in this animation:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
It’s obvious there are at least two scenarios where this ‘feature’ can be used for offensive purposes:<\/p>\n\n\n\n