Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sphr]

Wow... it's quite a hefty investment if I were to buy it personally..  and since I'm using AMD64, I may have to get the advanced version which costs almost twice as much.  Hesitating now coz I could have gotten a new machine to add to my home network for that price, but I may try out the evaluation copy first.

[0x517A5D]

It is indeed pricey.  That's because it's for a small vertical market.  They probably sell only one or two thousand a year.

Unless you are targetting a AMD64 program, you don't need the AMD64-capable version; the standard one will run fine in the 32-bit emulation mode.

I will also add that they really don't like to sell to individuals.  Pirates try to scam them like you wouldn't believe, so they're very cautious.

An alternative: a couple of years ago they released an obsolete but non-crippled version for free.  URL=http://www.datarescue.com/idabase/idadown.htm  Version 4.9 doesn't have the latest bells & whistles (such as the very useful integrated debugger) but is still a very capable disassembler.

Getting started can be rough -- there is a very steep initial learning curve.  But you mastered Dwarf Fortress, you can handle it.  I would suggest not trying to work with a 5 MB program like DF at first; find a 5 or 10 KB utility and see what you can understand about it.

[bartavelle]

IDA is totally great, and if you don't have the integrated debugger you might want to test OllyDbg (or immunity dbg, including python scripting and horrendous colors). There is, along with the 4.9 version, an evaluation version for 5.1, but it won't let you save your work. It might however be enough for a quick test.

Dwarf fortress is quite a pain to reverse indeed, because it is large, and in C++.  Programs like hex rays (quite expensive!) are also totally great when tackling large C++ functions ... i'm however not aware of any free tools, even moderately useful, that would have the same usage.

[0x517A5D]

Back on topic, I've been thinking about this for a couple of days, and I see no downside to using the PE header .TimeDateStamp field.

It's at a fixed file location (offset 0xF8), a fixed memory location (address 0x4000F8), has been unique for every build, and is almost guaranteed to continue to be.

I've updated my wiki address lists with the stamps for each released version, and will continue to do so.

out 0x517A5D, 0xF8

[sphr]

Thanks for all the info for IDA.  Basically, I'm not running into code disassembly at this stage.  But rather, just exploring the data part.  The interface for the memory maps seems ideal for this for now.  Right now, ANYTHING beats a calculator + raw memory viewer  

As for the pe timestamp, if it is sufficient, then I'll say we go for it.  As an added check, we can try to list optional data like file size as well.  Ideal case is that for each binary, we have a bunch of verification data that the end user (util coder in this case) can choose.  We can also list down common "combo" that should be relatively safe (timestamp for a quick check or maybe timestamp + filesize for a double check.  Paranoid people can go for more robust solutions like checksums). I think it will certainly be a great improvement over the "blank nothing" on version detection in the wiki before this, and would help save time in the future (for people like me who had to experiment here and there and bug the general audience in the forums with threads like this before I can reach a few working methods   )

Would help Jifodus's library too, if he includes it in future mapping data files.

come to think of it.... isn't "size-32" (glorified name for filesize) a possible solution as well?  as long as it is the real file size and not the allocated file size. LOL

[ December 15, 2007: Message edited by: sphr ]