First public release

[SuperCRacker]

Hi,

Imports Fixer 1.5a beta is finally ready for a first public release. You can get it here

Fixes and updates since last version :

v1.5a beta PUBLIC VERSION (24.08.10)

- First public release.

v1.5a beta PRIVATE VERSION (16.08.10)

- Hex Editor loading data speed improved (whole hex editor recoded).

- Bug fixed while attempting to change a byte in the hex editor in a non writable memory page.

- Bug fixed while redirecting APIs to wsock32.dll.

- RtlSetLastWin32Error is now correctly forwarded.

- 4 ntdll APIs forwarded to user32.dll for VISTA & Windows 7.

- Bug fixed when cancel is chosen in the savedialog of update form. IF just used to ignore the user decision.

- Fixed small bug when IF updated version name is displayed in the savedialog form.

- Weird processes appearing as ??????? in the processes list or those having no path are removed from the list.

- A reminder messagebox pops up if the user tries to select an already terminated process (I noticed it was removed).

- Loading dlls is now done using mapping apis instead of LoadLibraryEx.

- Critical bug fixed while opening processes on x64 machines.

- Bug fixed when trying to set BaseOfCode of WinUpack packed targets.

- LoadConfig and COM are now fixed in the PE header.

- Dumper automatically displays data when pressing the arrows in order to improve speed.

- About section filled.

- IF update is redirected to IF official download site and no longer uses direct downloads.

- IF is no longer packed to avoid false virus alerts.

- IF Help updated and is now in pdf format.

- Using backspace in hex edit boxes now allowed.

- Original byte in Bytes Editor removed.

- IT & IAT Tab is henceforth disabled until a process is selected.

- Added the dates of new released versions in history.

If you want to know what has been done in previous versions, go to history directly in IF (Help -> History)

If you want additional information about functionalities, visit my blog here

For a more detailed help, see the documentation provided with the release (Help -> Documentation) (please don't consider fully all what is written in the help file as there are some functionalities that are not implemented yet or may never exist, a complete help file will be written within the final public build of IF)

A final word, this subforum is for you to report bugs, post new ideas you want to see in IF and to support IF development.

Thanks for your patience,

SC.

Edited August 25, 2010 by SuperCRacker

[Fungus]

Nice SuperCracker! I was beginning to wonder if it would ever be released. =]

I'll be sure to test it more for you and report any bugs.

Did you ever add the inject dll into process option I requested? =]

[SuperCRacker]

Hi Fungus,

Good to see you around again. What do you mean by injecting dll? Do you mean dlls rebuilding/fixing? If so it will be included in next version, otherwise can you give more information about the feature you want?

Ah, also you can take a look at the Next Update List in IF, I have implemented yesterady an optimistic update list hoping that all of the features listed would be included in next version.

SC.

[Fungus]

Hrm, I mean like for Armadillo (ArmAccess.dll) or MoleBox protected stuff.

So like, when your at OEP, and ready to rebuild imports, sometimes .dll is in memory and not on disk (virtual .dll). So, it would be cool if you could have button or feature "load dll into process space" so you can use another dll which IS dumped on disk to fix imports for these virtual .dll. That way you could do as normal, and click invalid thunk, select dll from drop down list as normal, and select the api you need.

Make sense? I hope so. =]

[quosego]

Yeah that's indeed a good idea. WL also has that sometimes.

Now I need to inject it manually. Btw does it also resolve kernel to ntdll imports??

Some earlier version did not and I do dpend on that in TM/wl apps,

Nice work,

q.

[Nacho_dj]

Fungus, I wonder if your loaded dll in memory has any PE header accessible, or instead just code & imports on its own. A proper PE header should be needed to be rebuilt properly...

Cheers

Nacho_dj

[0x2h]

yeah nice work

[SuperCRacker]

Hi Fungus,

Well, I see what you mean, it is adding manually a dll to the modules list to be able to add the imports from this dll later in the IT & IAT tab, you can see it in the update list, it is already there. I don't think though it is necessay to load it in the process image space as only the export table of this dll is necessary, correct me if I am wrong

I have also good news, I have brought big improvements to IAT management and integrated UIF features like Direct calls, Scattered imports, Shuffled imports, Imports Elimination ... All this will be detected by IF and you will not need anymore to apply any patch in memory, all imports will be rebuilt at once in disk.

P.S : Quosego, nice to see you interested in the tool again. Well yes, the imports redirection is supported from kernel32.dll to ntdll.dll . If you have issues with that let me know

Cheers,

SC.

Edited September 1, 2010 by SuperCRacker

[What]

imports redirection is supported from kernel32.dll to ntdll.dll.

it sounds like you hard coded the rtl functions in, you don't support other module redirections?

[SuperCRacker]

it sounds like you hard coded the rtl functions in, you don't support other module redirections?

Indeed it is hard coded. I find that it is better to use this method, fast and reliable. Other redirections are supported, from ws_32.dll to wsock.dll and 4 apis in vista and win7 under wow64. Indeed those last 4 apis cannot be redirected using a classic tracing method.

SC.

[What]

"classic tracing method"? Do you mean checking whether or not the address of function points within the export section? Anyway it would probably be best to at least try to build the forwards on non hard coded modules.

[SuperCRacker]

I will try to look deeper in this approach. Yet, do you have example of dlls that need forwarding apart from what has been mentioned?

SC.

[Nacho_dj]

SuperCRacker, I have found also this one in Win7/32:

secur32.dll forwards to sspicli.dll

Cheers

Nacho_dj

[SuperCRacker]

I see, but I am wondering if these forwardings are just to make the imports clean or the executable can't run if the forwardings aren't done.

SC.

[What]

Function forwardings are to preserve backwards compatibility mainly. An example of why I would prefer better support is for reversing reasons though. Say I want to make a fake user32.dll, hooking a couple of functions. The rest of the non hooked functions are forwarded out to the real user32.dll, renamed user34.dll (user34.MessageBox). If the forwarded functions are not implemented, the rebuilt file will ask for user34.dll to load.

edit: If I am not presenting my thoughts clearly here is a paper that may help.

http://www.packetstormsecurity.org/papers/win/intercept_apis_dll_redirection.pdf

Edited September 2, 2010 by What

[SuperCRacker]

I can understand now, thanks for clarifying the thing and for the paper. Hmm, As I am changing portions of code now it will be interesting to fix this now, but how do you prefer to see this feature implemented? Automatic forwarding, or maybe manual or both. Also should a list of known dlls that need forwarding should be hard coded?

SC.

[SuperCRacker]

I worked all this day and I automated the forwarding engine, it is no more hard coded. I was making a big mistake before, I was missing a lot of functions and the forwarding didn't support unsual dlls like the ones you are using for hooking.

Thanks What for reporting this,

SC

[BoB]

Cool, does it also handle forwarded ordinals now? EG "Kernel32.#27"

[SuperCRacker]

Cool, does it also handle forwarded ordinals now? EG "Kernel32.#27"

Yes

SC

[SuperCRacker]

I have optimized the forwarding engine, but I encountered a problem when I wanted to fix some apis in ntdll.dll : NtdllDefWindowProc_A and NtdllDefWindowProc_W and to forward them to user32.dll under DefWindowProcA and DefWindowProcW respectively.

What is weird is that under Vista x32 DefWindowProcA and DefWindowProcW are not forwarded to these above apis, however in TiGA's blog (thanks for revert for the link) he has his user32 apis pointing to ntdll apis under Vista x64. I will leave the forwarding engine as it is assuming that it will work on a user32.dll that is forwarding its apis to ntdll.dll, however I can't be sure until a beta is out for test.

SC

Edited September 3, 2010 by SuperCRacker

[SuperCRacker]

I have planned to do a lot of updates, but I spent a lot of time on the IAT and forwarding stuff and in fact it is worth it the results are very promising. I made massive code update to the code related to IAT management in order to support UIF features (and more), it is why I planned to release an intermediate version for testing all the core functionalities before moving to extra features (sorry the dlls rebuilding will be for later). I will release it first for private beta testers before releasing it to public. Please go here if you want to be part of them.

The private version will be out soon, the public one will follow ...

SC

Edited September 8, 2010 by SuperCRacker

[SnD]

This tool is better than imprec and virus free... very very useful thanks

[Jaymz]

Woohoo.. Finally a better replacement for ImpRec I hope.

Thanks a lot.

edit: I'm getting some errors with this when rebuilding armadillo 7 dumped files..

Edited September 16, 2010 by Jaymz

[SuperCRacker]

IF 1.6 is out.

v1.6 PUBLIC VERSION (06.10.10)

- Automated forwarding engine coded.

- Removed old hard-coded forwarded apis.

- IAT manager tool added.

- Smart IAT analyser&rebuilder: can detect and fix valid, invalid, partially

valid, shuffled, overlapped, scattered, disordered iat entries as well as

direct calls and import elimination.

- Added other direct calls schemes for APIs detection and rebuilding.

- Possibility of removing undesired IAT entries.

- Different colors used depending on IAT entry type.

- Statistics about each IAT entry (Blocks, DLLs, APIs, Invalid, %Invalid ...).

- Create new IAT option added.

- Possibility to select sections that contain code.

- Removed classic method of retreiving IAT by entering IAT RVA and IAT Size.

- Fast imports rebuilding, imports can be rebuilt even if invalid thunks still exist

in the imports tree.

- The display speed of data in ListViews, Imports tree list and HexEditor is

improved.

- Fixed a forwarding problem in shunimpl.dll under Windows 7.

- Imports Editor and Dumper Tool show instantly when called.

- IF auto refresh if the target is changed in memory (while getting and

loading imports).

- Plugins arguments changed and plugins help file updated.

- Arrange Thunks option added.

- Modern style.

- Unforwarding api names from crypt32.dll.

- "Write Imports" is replaced by "Fix dump" to avoid confusion.

- IAT section flags are set to C0000040.

- IAT section VOffset and ROffset corrected to respect Section and File

alignements.

- Terminating 00 is added on IAT section name while writing imports.

- Disable splash screen option added.

- Can now specify the location of new import table.

- Default state of checkbox "Notify me if a new version is out." is set to

unchecked.

- Intelli fix for direct call schemes (TM/WL).

- IAT thunks are written in original IAT even in the case of new created

IAT (TM/WL).

- Manually imports adding supported.

- Retreive APIs with/without direct calls option added.

- Major code update.

Sorry for being late, it is because there were a lots of tests and updates made on the PRIVATE beta version. I would like also to warmly thank LCF-AT, Fungus, Nacho_dj and metr0 for the bug reports and suggestions , they have made great efforts on testing this version.

Download page here.

SC

Edited October 6, 2010 by SuperCRacker

[Syntax]

Thank you SuperCracker for the release .

Btw : In about form , metr0 names as mert0 .

Greetz