Scylla Version Announcements

[Aguila]

New versions will be announced here.

 

 

https://forum.tuts4you.com/files/file/576-scylla-imports-reconstruction/

https://github.com/NtQuery/Scylla

 

 

Version 0.9.4 Final- direct import scanner (LEA, MOV, PUSH, CALL, JMP) + fixer with 2 fix methods
- create new iat in section
- fixed various bugs

 

I really recommend to update due to the bug fixes.

 

Direct import scanner fix methods:

- Normal: Patch memory with jmp/call only

- Universal: Works with everything, creates a jump table in the scylla section, watch for relocation information in the log file

 

 

I also found some weird thing in Windows 7 x64. I don't know yet why this happens:

 

 

### Windows 7 x64Sometimes the API kernel32.dll GetProcAddress cannot be resolved, because the IAT has an entry from apphelp.dll
Solution? I don't know

 

Maybe this is AV related.

[redblkjck]

That dll is for compatibility mode.  I just loaded a PEC target set to XP SP3 mode and many kernel32 imports are cross linked.  Way more than just the GetProcAddress import but maybe still linked or different mode.   Take a look to see if the app is set in a compatibility mode.  Below is a small sample from a PEC2 target on Win 7 64bit set to XP SP3 mode. 

Thanks for the update.  Cheers - jackapphelp.StubGetProcAddress would normally be GetProcAddress
AcGenral.63E5184D  should be DeleteFileW

005E1320                                  74D7D474  tÔ.t  kernel32.GetTempPathW005E1324                                  7431FFF6  ö.1t  apphelp.StubGetProcAddress005E1328                                  74D720F1  ñ .t  kernel32.SetProcessWorkingSetSize005E132C                                  74D7D565  eÕ.t  kernel32.lstrcmpiW005E1330                                  63E5184D  M.åc  AcGenral.63E5184D

edit  removed extra new line spacing

Edited February 5, 2014 by redblkjck

[Aguila]

I dont have compatibility mode enabled. The problem is that GetProcAddress has the address 0x6BDAFFF6 (base 6BDA0000) from apphelp.dll. And this address is not an exported function from apphelp.dll. The only solution is now, hardcode this function rva address.

[redblkjck]

ok I can replicate this with only one other API affected.   I found a post (nirsoft) where if the word 'launch' is part of the exe name, getprocaddess is hooked by the apphelp.dll.  This enforces the 'shim' to load even if compatibility mode is not set.  I did this to the target and sure enough getprocaddress is hooked by apphelp.dll and the import API is not resolved.  One other API is not resolved for kernel32, WinExec.  I hope that helps.  Below is the quoted info, links below that.   - jack

 

 

 

Update (November 28th):  Thanks for Dan about the writing the Shim comment. The problem is really the caused by Application Compatibility Engine. From some reason, when the .exe file contains the word 'launch', the Application Compatibility Engine consider the application as not compatible with Windows Vista/7, and thus the application is "shimmed", which means that apphelp.dll and AcLayers.DLL are loaded and replace some API calls of Windows in order to resolve compatibility issues.  In my case, this  Compatibility Engine doesn't solve compatibility problems... it actually creates the problem.

According to some Blog posts and documentations, embedding a Manifest inside the .exe that contains application compatibility information should disable the shimming and solve this problem, but... I tried it and unfortunately it doesn't work.  However, because I already know which component cause the problem, I'll eventually find a way to bypass it.

The problem was finally solved by making changes in the problematic utilities (NetPass,  LSASecretsView, and LSASecretsDump), so these utilities will work properly even when they are shimmed.  When these utilities detect that they are shimmed, LdrGetProcedureAddress (in ntdll.dll) function is used to get the real address of GetProcAddress function inside the Windows kernel, and in this way, my utilities  bypass the shim layer and get the real kernel addresses.

 

 

 

http://blog.nirsoft.net/2009/11/
http://blog.nirsoft.net/2009/11/27/very-weird-problem-on-windows-vista-and-windows-7/

[mrexodia]

Interesting stuff... Where/when do these apphelp 'exports' get written in the import table?

[redblkjck]

@Mr. eXoDia  It appears to be a function of the ntdll windows loader.   If you take a regular exe and incorporate the word 'launch' into the filename, the loader queries ShimEng.dll whose export's forward to apphelp.dll.  Soon as the file is loaded in Olly, the API for GetProcAddress is already mapped through apphelp.
0042D1B8 <&kernel32.GetProcAddress>       74B2FFF6  ö..t  apphelp.StubGetProcAddress
 

there is a write up about it here. part2 covers more details of the loader.

http://recxltd.blogspot.co.uk/2012/04/windows-appcompat-research-notes-part-1.html

http://recxltd.blogspot.com/2012/05/windows-appcompat-research-notes-part-2.html

 

Apparently every process that is created from an exe with launch in the name, the compatibility flag is passed on those processes also.  That's from the Nirsoft, posting.  Still reading more about it...

[mrexodia]

Hm, really strange stuff... Sounds like a real bug in windows to me (meaning the 'launch' part of course).

Edited February 5, 2014 by Mr. eXoDia

[redblkjck]

@Mr. eXoDia   Yeah it may not be the same thing Aquila referenced.  I was just looking how to replicate the issue and stumbled upon this.  Seems close to the result though.  Is an odd OS bug/feature though.  Wonder if any other objects can trigger the same effect.   Cheers 

[redblkjck]

Just a add on.  There is a database of file names that will cause different versions of compatibility mode to be enabled automatically.  Not really documented on the format of the database file.  But with a hex editor I found some others including 'launch' that are wildcarded. The word 'patch' in the file name is another one that causes the shim to be enabled.
In C:\Windows\AppPatch all the *.sdb files contain the info; sysmain.sdb is the main one.
This write up makes a few references to the sdb and a file named RecentFileCache.bcf.  http://journeyintoir.blogspot.com/2013/12/revealing-recentfilecachebcf-file.html 
There are also entries in the registry that can be set.  http://journeyintoir.blogspot.com/2013/12/revealing-program-compatibility.html 

This was long ago but I do remember having a exe stuck in compatibility mode, think it was when I copied it to another folder.  It was set in the registry mentioned in that article.  Anyway the blog has some interesting posting.  There is also one for Win 8. http://www.swiftforensics.com/2013/12/amcachehve-in-windows-8-goldmine-for.html

 

jack

 

[Aguila]

New Version

Version 0.9.5
- improved process lister

- improved module lister

- improved dump name

- improved IAT parser

[Aguila]

bugfix:

 

 

Version 0.9.5a- Fixed virtual device bug caused by QueryDosDeviceW bug

[Aguila]

 

Version 0.9.6

- improved iat search

- fixed bug in api resolve engine

- new option: parse APIs always from disk -> slower, useful against pe header modifications

[skylark]

@Aguila

hello sir, about the apphelp.dll, the latest scylla 0.9.8 version is somehow failing to resolve user32.CallNextHookEx API if it's called from apphelp.dll, could you please check that? I haven't found any more unresolved API yet, so can't give any list. But please check it, I was using windows 10 x86.

Also, in one program, after manually putting down the CallNextHookEx API and fixing dump with Scylla, program ran fine, but in another program which was packed by same packer, after putting the down the same API and fixing the dump, when I ran it, it gave me an error "Can't find the entry point......".