Log in

View Full Version : IDA doesn't autoanalyse..


vesanico
September 19th, 2005, 11:32
... and I can'y understand how to do it. I just installed IDA 4.8, but it doesn't autoanalyse the file, nor does it apply the signatures like the 4.3 version did. So,
I'd really apreciate it if you could point me to a good howto and/or reference manual (the one that ships along is quite spartan...)

And by the way, this debugger that bundles with IDA, is it worth trying, or plain unusable?

Regards,

vesanico

quasar
September 19th, 2005, 16:07
Please search for patch on exetools forum.

vesanico
September 20th, 2005, 11:49
Thanks for the hint. I hadn't been to exetools yet. Unfortunately, membership is invite only, and the search function has been disabled. I found a reference to this patch, but I got a 403 forbidden on trying to access it. Would anyone with permissions care to post it somewhere I can reach it?

Regards,

vesanico

Int03h
October 10th, 2005, 22:13
vesanico, I don't know about ExeTool's patch because I do not gave access to their forums. As it was mentioned earlier it is invite only.

But here is something that might help you. I checked it out real fast and I come up with this. Open ida.wll in a hex editor and change the following:

0x0000A7E9: 7E
becomes
0x0000A7E9: EB

Tell me how this works for you. If anyone have access to the other patch from exetools, can you please upload it here ( maybe use rapidshare.de to upload it ) so we can compare?

Take care.

SiGiNT
October 10th, 2005, 23:03
My copy came with that incorporated, but, I still seem to have problems with iconsistant autoanalysis - I'll disassemble a file and even though it may be compiled with C+, it sometimes looks almost like a VB file - a lot of data tables - going back to 4.6 it looks fine - I've also been looking for "the patch" but I think there is supposed to be one from DataRescue that is needed - no luck searching.

SiGiNT

Int03h
October 10th, 2005, 23:12
Quote:
My copy came with that incorporated

What is your exact release name?

Int03h
October 10th, 2005, 23:27
What I think is applicable in your case sigint33 is that your time zone is set correctly, not that the release you got is "fixed".

SiGiNT
October 11th, 2005, 00:05
4.8.0.847 - It supposedly was a russian release, and I'm not there - interesting thought, about the time zone, I'll check it.

SiGiNT

nchanta
October 11th, 2005, 01:30
The russian release of IDA v4.8 is severly broken. Do not trust it for accurate, nor consistent results.

Either downgrade, or buy it!

(i still use ida v4.3 for most things )

nchanta
October 11th, 2005, 02:17
Oh and in regards to your query on the debugger, there are a few things to note:
- the debugger has been updated heavily in both v4.8 and v4.9 updates
- 4.9 also contains within its updates debugger scripting support (similar to olly scripts)
- 4.9 contains remote debugging features (handy for pocketpc/palm among other things)
- 4.9 ships with a "generic unpacking" script, not sure how useful it is but at the least it will demonstrate the script language

Knowing these things, the debugger is much better than it was, but still, i think, a cut below (yay) Softice and (yuck) Olly.

Int03h
October 11th, 2005, 03:05
OK, here is my explanation on why this happens with SSG repackaged 4.8 release: (ida.wll)
===================================================================
Code:

.text:1000B1D4 call __tzset ; set dword_100D3978 number of seconds in difference for timezone ( UTC - TZ )
; so if you are in a GMT-7 you will get 25200ms ( 25200 to catch GMT )
; likewise if you are GMT+7 you will get -2500ms ( your ahead of GMT )
.text:1000B1D9 mov eax, dword_100D3978 ; Load in register num in milliseconds of difference in TZ compared to GMT ( preparing for division )
.text:1000B1DE mov ecx, 0E10h ; store 3600 ( to do the devision ) to get the number of hours
.text:1000B1E3 cdq ; We need the cdq instruction before the idiv because the idiv actually divides the 64bits value held in EDX:EAX by the DWORD found in ECX
.text:1000B1E4 idiv ecx ; divide EDX:EAX by ECX ( number of ms to GMT / 3600 ) = Number of hours to GMT
.text:1000B1E6 cmp eax, 0FFFFFFFEh ; compare to -2 ( remember that -2 is GMT+2 because your catch up time with GMT is negative )
.text:1000B1E9 jle short loc_1000B201 ; accept only it it is equal or lower to -2 ( >= GMT+2 )


So as you see, to bypass the protection, just change the conditional jump at 1000B1E9 to a non conditional one.

This is easily verifiable by changing the TimeZone via the WindowsXP calendar ( Date and Time property ). Before patching the ida.wll try the following:

1)Set your timezone to anything below GMT+2 ( try GMT-7 for example )
2)Open IDA and try to disassemble something. It won't work

3)Set your timezone to anything above or equal to GMT+2 ( try GMT+2 for example )
4)Open IDA and try to disassemble something. It will work.


This is the only problem I am aware of with the SSG repacked release. So after this patch it is good to go.

Voila

SiGiNT
October 11th, 2005, 09:42
Well, I was planning on buying IDA, however my last consulting check was smaller than expected, (side job) - when I can afford it I will, (it is a fairly large amount of money), the release I have is the SSG, apparently with the patch, and I have noticed problems with the dissassembly - in comparison to 4.6 - just another quick qurstion - in a weak moment some time ago I unchecked the file dialog box that appears after the user splash - I now regret that, how can I get that dialog back instead of going straight into IDA? I've combed the .cfg files and the documentation and either missed it or it's not there - any hint would be appreciated.

SiGiNT
Edit:

I've found the patch for the SSG release - since I'm not sure if it would violate the rules, I'd rather share it in private - there is one more difference in ida.wll the byte at 2AB3Dh is changed from 75 to EB, this appears to bypass a lic. key limitation, - but the patch also contains another patch, (which matches mine), unless a moderator says differently then PM me an E-mail address and I'll get it to you.

SiGiNT

Sergey R.
October 12th, 2005, 01:52
Quote:
[Originally Posted by sigint33]... I unchecked the file dialog box that appears after the user splash - I now regret that, how can I get that dialog back instead of going straight into IDA? ...

Open the registery key
HKEY_CURRENT_USER\Software\Datarescue\IDA
search "DisplayWelcome" subkey and delete it or change its value to "1".

Int03h
October 12th, 2005, 16:06
sigint33, keep us updated on how things worked out for you.

visionx
October 22nd, 2005, 20:37
Thanks int03h! your patch work fine for me...
ida.wll @0x0000A7E9: 7E changed to EB

i had the patch from exetools but it didn't fix the problem coz it patch the ida.hlp to change the disassembly header char box, not the ida.wll LOL. Now i'll switch my IDA 4.3 to this new working one and waiting for v4.9

readdict
October 22nd, 2005, 23:24
An additional note in case any of you operate in a 64-bit environment.. There is a identical timezone check, the evil russian gmt one, in ida64.wll as well.

When you reverse ida.wll and apply your permanent patch solution, take note of the opcodes starting from the MOV ECX,0E10 instruction up until the conditional JLE instruction. The code in ida64.wll is identical as far as this part goes so you can use this set of opcodes to search & replace the check inside ida64.wll too.

If you for some reason would like to poke around at this code location and want to find it quickly I'd suggest you use ollydbg and load the wll as a dll file. A very useful option indeed, especially when you can't get the file to load during runtime due to lack of a 64-bit os. With the wll loaded in memory you could search for the unique set of opcodes in memory and find the codes address location.

Or you could use a more generic approach that would work when encountering similar checks, but each with their unique set of instructions, apart from i.e. the api used.

Analyze the file (or Ollydbg won't find all the "referenced to" of your target locations), then go fetch its Imports and find GetTimeZoneInformation. Select "Find references to import" and you'll find two references, of which one calls the api, follow this reference in the cpu (disassembler) window.

When you are located in the codeflow that calls GetTimeZoneInformation then "Go to previous procedure" (ctrl+minus) to get to the top of this branches codeflow. With the very first instructions selected, use "Find references to selected command" (ctrl+r) and you'll find two references here and only one of them is CALLing here, follow this ref.

And so you have arrived at the timezone check location.

What was ment to be a small notice about ida64.wll turned out to be a small chapter instead.

visionx
October 23rd, 2005, 01:18
Yup, that's true... Tested!
"ida64.wll" the byte is @0x0000B281 (7E -> EB), same codes as the 32bit version. thx