Jump to content
Tuts 4 You

Scylla Version Announcements


Recommended Posts

New versions will be announced here.







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.

  • Like 1
Link to comment

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 by redblkjck
Link to comment

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.

Link to comment

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.





Link to comment

@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.




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...

Link to comment

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

Edited by Mr. eXoDia
Link to comment

@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 

Link to comment

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




Link to comment
  • 1 month later...

New Version

Version 0.9.5 - improved process lister
- improved module lister
- improved dump name
- improved IAT parser
  • Like 3
Link to comment


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

  • Like 1
Link to comment
  • 3 years later...


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......".

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...