• Welcome to Valhalla Legends Archive.
 
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Darawk

#1
Advanced Programming / Re: "Smart disassemblers"
March 31, 2006, 04:52 PM
Hmm...maybe some kind of signature library of some of the more obscure compiler optimizations/features.  Especially those that involve doing conditional branching based on floating point comparisons...I *always* have to take like 20 minutes to figure out what is actually going on there.  So, it would just basically try to identify these code sequences, and auto-comment them or something.

Better handling of "this" pointers.  I've yet to see any disassemblers that can really properly handle OOP.  There's still lots of relatively tedious work that could be alleviated in this area.

STL signatures.

I'll add more if I think of anything else...
#2
Advanced Programming / Re: Detecting Qemu
March 22, 2006, 07:03 PM
http://www.offensivecomputing.net/?q=node/172  <-- Generic VM detection method
http://www.invisiblethings.org/papers/redpill.html <-- Works on some VM's...but has some faults, as described in the above paper
http://www.trapkit.de/research/vmm/vmm.htm  <-- A nice collection of more general research on the topic of "defeating"(detecting and/or breaking out of) VMM's.
#3
If I were you, I would exclusively use the new/delete (and new[] / delete []) operators in your code, because you can overload them to use whatever underlying allocation methods you like with ease.

So, if you decide later on that you actually want to use HeapAlloc/HeapFree...then all you have to do is overload those operators and leave the rest of your code unchanged.  This will make your code much more flexible, and probably a lot cleaner too.
#4
To quote from the PECOFF specification(found here: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx )

The characteristics field has the following 2 flags:

Quote
IMAGE_FILE_16BIT_MACHINE   0x0040   Use of this flag is reserved for future use.   
IMAGE_FILE_32BIT_MACHINE   0x0100   Machine based on 32-bit-word architecture.   

So, the reason that IDA still dis-assembled your binary as 32-bit, is because even though you unset the 32-bit flag you didn't set the 16 bit one...and I would guess that IDA, in the absence of explicit specification, defaults to 32-bit disassembly.