Scylla x64/x86 Imports Reconstruction

[deepzero]

i think scylla is always interested in crash reports, no matter why they happened.

[Syoma]

Some feedback
1. It does not remember the last folder used to store dump/fix, but always start from the module home folder.
2. It keeps separate adjacent chunks of functions related to the same module.
3. For dump naming would be better to follow ImpRec behavior: default dump name is module name + suffix.

Feature request
+ Add import manually. Now it can be done using XML editing, but need to recalc offsets, ordinals, etc.
+ Single -Dump & Fix- button

[Computer_Angel]

Originally Posted by Carbon

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

We could using plugin for apphelp.dll to solve the api. This is my small plugin for Imprec & Scylla.

About scylla crash, I had found that the function ApiReader:arseExportTable is parsing export not correct in some case, the way of calculating functionName = (char*)(addressOfNamesArray[i] + deltaAddress) is not right if the address of names in the differ memory than the exportbuffer cover.

[Carbon]

Originally Posted by Computer_Angel

1.Scylla should have option to use PE Header of module on disk just like imprec .
right now, scylla read the pe header from memory and in some case the export directory is destroy make scylla crash.
You could try some target using cryengine sdk such as Warface to get this case/.

In the options you can choose between reading pe header from disk or from memory. It should work.

the way of calculating functionName = (char*)(addressOfNamesArray[i] + deltaAddress) is not right if the address of names in the differ memory than the exportbuffer cover.

Thanks I will fix that.

We could using plugin for apphelp.dll to solve the api. This is my small plugin for Imprec & Scylla.

I am more interested in how your plugin works. How do you resolve the functions?
GetProcAddress points to function rva FFF6 from apphelp.dll and this function address is NOT exported by apphelp.dll. This is my problem.

@Syoma
Thanks for the suggestions, I will fix that.

[Computer_Angel]

Originally Posted by Carbon

I am more interested in how your plugin works. How do you resolve the functions?
GetProcAddress points to function rva FFF6 from apphelp.dll and this function address is NOT exported by apphelp.dll. This is my problem.

There're many way.
1.trace into the apphelp.dll function code then you'll get the correct api function by watching some special call,jmp such as call eax, call [eax+const], call [ecx+const], jmp eax.

2. Using debuging symbol of apphelp then we'll get the simillar correct name of api.

I got the same problem with aclayers.dll, but seem it's hard to make a tracer for that. Seem the best way is to hard-code the address value for these dll.

[ahmadmansoor]

I know this is not a good Idea or stupid Idea ,but for unpacker when he work on unpack he can do this :

when load apphelp.dll
search for
8B 4D 10 89 08 C7 45 E4 01 00 00 00 C7 45 FC FE FF FF FF 8B 45 E4
search for
75C63011 . 8B4D 10 mov ecx, dword ptr [ebp+0x10]
75C63014 8908 mov dword ptr [eax], ecx >>>> nop this
75C63016 . C745 E4 01000000 mov dword ptr [ebp-0x1C], 0x1
75C6301D > C745 FC FEFFFFFF mov dword ptr [ebp-0x4], -0x2
75C63024 . 8B45 E4 mov eax, dword ptr [ebp-0x1C]

and done . so no need to fix this .

[Carbon]

New version

Version 0.9.5

- improved process lister
- improved module lister
- improved dump name
- improved IAT parser

@Computer_Angel
I cannot reproduce the crash, tested with crysis and far cry.

[Computer_Angel]

Originally Posted by Carbon

New version


@Computer_Angel
I cannot reproduce the crash, tested with crysis and far cry.

1.Just test the new version, seem the module lister not list all the module in process.I'll check it more in next day.
2.I'll try to give you the examples about the crash.

[Carbon]

There was a bug with virtual devices...

[Computer_Angel]

Originally Posted by Carbon

There was a bug with virtual devices...

More buggy with lastest release. My binary is on Virtual devices and scylla could not define a correct pathname for it (it show unknow for path). When try to select the process with unknow path ---> crash happen

[Carbon]

Windows doesn't handle virtual devices like it should

This should work now, but the solution is bad...

[Computer_Angel]

Here's the samples for scylla crash bug. Use Ollydbg2 load the scylla_.exe, then you'll stop at EP. Now using scylla to process the scylla_.exe module and scylla will crash. Hope this will help you

[ahmadmansoor]

Hi Carbon :
about Computer_Angel target don't care about it, scylla is the best and it Does not need any fix for handle virtual devices.
this sample is an tricky Target it write false size for IMAGE_EXPORT_DIRECTORY which make it very very big so can't handle it with
bufferExportTable = new BYTE[readSize];
so Computer_Angel it is as an anti scylla (or other IAT re builder ) technique .

10001036 |. 50 push eax ; /pOldProtect
10001037 |. 6A 40 push 0x40 ; |NewProtect = PAGE_EXECUTE_READWRITE
10001039 |. 8B3E mov edi, dword ptr [esi] ; |
1000103B |. 6A 04 push 0x4 ; |Size = 0x4
1000103D |. 56 push esi ; |Address
1000103E |. FF15 0>call near dword ptr [<&KERNEL32.VirtualP>; \VirtualProtect
10001044 |. E8 AE0>call scyllacr.100010F7
10001049 |. 0FB6C0 movzx eax, al
1000104C |. 69C0 0>imul eax, eax, 0x1010101
10001052 |. 8906 mov dword ptr [esi], eax
10001054 |. 8946 0>mov dword ptr [esi+0x4], eax <<<<<< very bad

Computer_Angel just one thing ,pls where u get like this targets ,every time u surprise us with this kind of targets ,I work with a lot of targets never get my hand on targets like which u bring it to us .....
Computer_Angel

[Computer_Angel]

Ahmadmansoor , i get this problem when unpack warface game.

[Carbon]

Thanks for the file Computer_Angel and thanks for the help ahmadmansoor.

I added an option to read the export table always from disk. This is slower than reading it from the target process. I guess this is a rare case, so people should only enable it if needed.

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