Kayaker...caught a reply from you on another site claiming ida2ice required mods to work on later versions of IDA.

My version seemed to work fine on later versions but on the app I am debugging it is having problems with certain types where the CC's used for alignment in the disassembly are mistaken for code. I can get i2s past them by tracking down the code references and undefining the code trying to refer to them. However, on the last couple of passes ida2ice exits on them without making an nms file, then finally choked with an access violation in i2s.plw @ addr 38 and 12F7A6f.

I am too tired to play with it right now, thought you might have a suggestion to save me re-inventing the wheel.

I did? Maybe in this thread

http://www.woodmann.com/forum/showthread.php?9593-IDA-2-Sice

Is there a specific error message from i2s? In the form msg( "I2S:

If so it would at least localize which function is giving the error.

Sorry for delay in response, and thanks for yours. I played with it for a bit but the initial error made no sense. It complained about an error in a byte at a specific address but I cross referenced it with Olly at the same address and both IDA and Olly showed a function there like GetParent. I don't have my notes in front of me but it complained about not being able to rename an address label because it was already in use. That made no sense at that particular address.

I tried an earlier version of IDA and it complained about the same error but gave me an nms file. It did not help much because I have yet to re-label IDA addresses for use in softice. It did help in some cases since IDA supplies handy references to windows procedures and labels sometimes.

For some reason, IDA is showing stack references on some functions that are really wild. It is showing ebp and esp offsets in the thousands range. I can correct them by undefining the entire function and having it re-analyze, but that's after a lot (and I mean a lot) of human interacting part that gives the I in IDA. It is getting hung up on the CC's used as alignment bytes, but only in some of the functions. In most of the disassembly it handles them fine. The earlier version seemed to handle them better but there was still a considerable amount of manual intervention required.

I suspect some of the problems stem from SEH functions where a handler address is pushed in a place where IDA may be expecting another stack frame instruction. I suspect that because in the later versions they are all marked as SEH functions on the call at the end of the function. Those are the funcs on which I mainly have to intervene. It seems reasonable to expect that ida2ice is choking on that stuff as well, although the earlier version handled it OK as far as producing an nms file once I had done my intervening.

I wonder if there is something wrong with me, all the same. I get a kick out of following through scads of IDA code, undefining it, or finding chunks of failed disassembly, finding the code after the CC's and marking them as code. I am much better at that than I am at reversing in general.

Not sure what's going on there. A couple of plugins that might help with the IDA cleanup though..

For fixing the align blocks and other undefined code:

Extra Pass

http://www.sirmabus.macromonkey.com/?p=375#more-375

And for defining the SEH stuff:

http://www.openrce.org/downloads/details/196

thanks, Kayaker...will give them a go.