Comments on: Download and LoadLibrary shellcode released http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/ The blog for absolutely nothing! Fri, 25 Jun 2010 07:02:27 +0000 hourly 1 http://wordpress.org/?v=3.0 By: SkyLined http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/comment-page-1/#comment-654 SkyLined Sun, 17 Jan 2010 21:06:29 +0000 http://skypher.com/?p=366#comment-654 Fair enough, I had a look to see how small a shellcode I could make using WinExec when I remembered another reason why LoadLibrary shellcode is so much smaller: it only requires calls to two distinct functions; LoadLibrary & URLDownloadToCacheFileA. The code stores the two 16-bit hashes in the EDI register and it uses all other registers in the hash calculating code. So, there is no place where I can store a third hash for WinExec. I would need to rewrite the code to use the stack as additional storage, which would mean the code would become (a lot) larger. Switching to smaller hashes, so I can store all three in EDI is very likely to be impossible because URLDownloadToCacheFileA is found in urlmon.dll, which is not one of the first loaded modules. This means that collisions with other functions in modules loaded before urlmon are very likely and will cause the code to fail. Fair enough, I had a look to see how small a shellcode I could make using WinExec when I remembered another reason why LoadLibrary shellcode is so much smaller: it only requires calls to two distinct functions; LoadLibrary & URLDownloadToCacheFileA. The code stores the two 16-bit hashes in the EDI register and it uses all other registers in the hash calculating code. So, there is no place where I can store a third hash for WinExec. I would need to rewrite the code to use the stack as additional storage, which would mean the code would become (a lot) larger. Switching to smaller hashes, so I can store all three in EDI is very likely to be impossible because URLDownloadToCacheFileA is found in urlmon.dll, which is not one of the first loaded modules. This means that collisions with other functions in modules loaded before urlmon are very likely and will cause the code to fail.

]]> By: ForteanMultiply http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/comment-page-1/#comment-652 ForteanMultiply Mon, 11 Jan 2010 22:09:53 +0000 http://skypher.com/?p=366#comment-652 WinExec doesn't require it either, it is only ShellExecute which relies on the extension, just because that is how it works out what to do with the file. WinExec doesn’t require it either, it is only ShellExecute which relies on the extension, just because that is how it works out what to do with the file.

]]> By: SkyLined http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/comment-page-1/#comment-651 SkyLined Mon, 11 Jan 2010 19:46:15 +0000 http://skypher.com/?p=366#comment-651 Maybe I should have mentioned that I was assuming one would use <a href="http://msdn.microsoft.com/en-us/library/ms687393(VS.85).aspx" rel="nofollow">WinExec</a> because <a href="http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx" rel="nofollow">CreateProcess</a> requires more complex arguments to be set-up, which costs even more then 4 bytes. While CreateProcess may allow you to create a process from a file without an .exe extention, I do not believe WinExec does. LoadLibrary does indeed pose a larger risk of failing in the face of mayor corruption of the stack and/or heap. So, one should only use this shellcode if one is able to limit the damage to the stack and/or heap to areas that do not affect LoadLibrary or do a bit of clean-up when needed. It makes sense to automatically test your exploit works a large number of times to make sure you haven't missed anything (but that goes for any exploit). Mind you that this is not intended to be a complete replacement for download & execute shellcode but an alternative that may be better suited in some situations. Maybe I should have mentioned that I was assuming one would use WinExec because CreateProcess requires more complex arguments to be set-up, which costs even more then 4 bytes. While CreateProcess may allow you to create a process from a file without an .exe extention, I do not believe WinExec does.

LoadLibrary does indeed pose a larger risk of failing in the face of mayor corruption of the stack and/or heap. So, one should only use this shellcode if one is able to limit the damage to the stack and/or heap to areas that do not affect LoadLibrary or do a bit of clean-up when needed. It makes sense to automatically test your exploit works a large number of times to make sure you haven’t missed anything (but that goes for any exploit).

Mind you that this is not intended to be a complete replacement for download & execute shellcode but an alternative that may be better suited in some situations.

]]> By: ForteanMultiply http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/comment-page-1/#comment-650 ForteanMultiply Mon, 11 Jan 2010 17:59:09 +0000 http://skypher.com/?p=366#comment-650 Just worth pointing out CreateProcess does not require an .exe extension in order to run, it will run what ever file you give it, and there is a chance that if you have twatted the process through exploitation then your LoadLibrary might just cause the process to blow up more. Just worth pointing out CreateProcess does not require an .exe extension in order to run, it will run what ever file you give it, and there is a chance that if you have twatted the process through exploitation then your LoadLibrary might just cause the process to blow up more.

]]>