Jump to content
Tuts 4 You

Weird problem with Scylla x86


Pancake

Recommended Posts

Hello. I've been using scylla for ages but today i encountered a very strange problem. The target is improting 3 APIs from "shlwapi.dll", and scylla shows one as "shlwapi.dll" correctly, and second with third as something like "api-ms-win-down..." and afetr dumping it says this dll does not exist. Well i checked the addresses myself and indeed all 3 functions are inside shlwapi.dll. Where is that problem coming from?


Greetz

Link to comment

Could you give me exact API and DLL names? I want to test. Also wondering why the priority for shlwapi.dll is set low. Are some DLLs forwarding to it or something?

Link to comment
16 hours ago, Pancake said:

Hello. I've been using scylla for ages but today i encountered a very strange problem. The target is improting 3 APIs from "shlwapi.dll", and scylla shows one as "shlwapi.dll" correctly, and second with third as something like "api-ms-win-down..." and afetr dumping it says this dll does not exist. Well i checked the addresses myself and indeed all 3 functions are inside shlwapi.dll. Where is that problem coming from?


Greetz

It will be a good idea to make a short video with Screen2SWF.

Link to comment

Here is the file I'm working with to reproduce: https://github.com/mrexodia/shlwapi-test. I cannot reproduce resolution to api-ms-win-downlevel-shlwapi-l1-1-0.dll (probably because the DLL is not loaded in the executable memory on Windows 8.1 x64), however, the forwarded exports in shlwapi.dll appear to be failing. There is only one resolved PathFileExistsA (in KernelBase.dll), however you can manually set it to shlwapi.dll. This means the bug is somewhere in the enumeration of the exports (there should be multiple resolutions for the address of PathFileExistsA).

vqQE6Fy.png

Hm, there appears to be no bug. There is no connection between api-ms-win-downlevel-shlwapi-l1-1-0:PathFileExistsA and shlwapi:PathFileExistsA apart from the API name. api-ms-win-downlevel-shlwapi-l1-1-0:PathFileExistsA forwards to kernelbase:PathFileExistsA. shlwapi:PathFileExistsA jumps to kernelbase:PathFileExistsA, but is not directly forwarded. Solutions for this problem involve either manually polling the api-ms-win-downlevel-shlwapi and adding virtual forwarders between shlwapi and kernelbase or something like name matching. Link APIs not just by forwarding, but also by name (this solution has my preference).

The whole priority algorithm needs a change. 'Normal' DLLs need a higher priority than name matches and kernelbase/API-* need a lower priority than name matching.

Edited by Mr. eXoDia
  • Like 1
Link to comment

So in the end, how can i tell scylla to use other dll name? Did not find such functionality (im using 0.9.1)

I downloaded the 0.9.8 and "version.dll" was properly found but the shlwapi is still messed :) Weird thing

 

So after tryin this and that, i made simple script which simply patches PE header. Writing 0 into export table address of everything which starts with "ms-api" makes scylla find these in shlwapi.dll.
"Polak potrafi" :)

Edited by Pancake
Link to comment
  • 4 weeks later...

Hi,

its funny that I can't find any download link to the latest Scylla tool in your section. So why don't you put the tool itself at the top of your section to find it quickly + DL link?

I have a just a small idea about a new option you can add in any of your next versions.Just add a option where the user can disable to check whether the APsI are forwarder APIs or not and then let fix it like it is with the module where the API RVA was found in AOF array.In that case you wouln't get the PathFileExistsA problem for example and it would fix to direct module of shlwapi.Of course you need to add / adjust another imports fixing method if mixed modules are used in same IAT blocks but its also possible and I think its a good alternativ to have a another option the user can choose if necessary.Or just add a under option about this where the user can choose the API xy from the list then right mouse click to a choose a option like "UnForward API" and the API gets re-checked and set to direct module where it was found.Maybe something like this would be fine too.

One thing,so you said the user can double click on the API to choose any other dll & API so thats right but the dll dosen't change and the new API get fixed to wrong dll module which was shown first also if its only one API in a block.Just a info and I don't use & test your latest version of Scylla (only version 0.8) and can't find the DL as I said first.

greetz

Link to comment

@LCF-AT I think the latest version was released a long time ago, but I don't manage the section. I was just trying to fix a bug but it appeared to be not possible. I don't have any plans of implementing anything new to Scylla right now. Maybe another time.

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