Author Topic: trying to use ndisasm  (Read 19502 times)

Offline michael weaser

  • Jr. Member
  • *
  • Posts: 9
trying to use ndisasm
« on: December 29, 2014, 01:24:30 AM »
i am trying to decompile edit.com the ms-dos text editor, i just want to know what the source is. i know how to decompile  which is ndisasm ?o100h edit.com  but How do you save the text from it as it is very long? is it possible to save the output to a text file? or how would i copy it to a text document as the code is not completely visible but only the bottom portion of the code that is view able in command text box. is there anything i can do about this? and also in the last parts of the code there is some data that isn't exactly code, ive tried  synchronization it but that isn't working at all. what would i do to be able to decompile this correctly and all of it code that is readable and also copy the whole code?

Offline alexfru

  • Jr. Member
  • *
  • Posts: 17
Re: trying to use ndisasm
« Reply #1 on: December 29, 2014, 08:41:44 AM »
Append >somefile.txt at the end of your ndisasm command. That will redirect the output to the somefile.txt file.

Offline michael weaser

  • Jr. Member
  • *
  • Posts: 9
Re: trying to use ndisasm
« Reply #2 on: December 29, 2014, 07:13:45 PM »
ok so it would be ndisasm -o100h edit.com Append >somefile.txt. so this will work under windows right? and what about fixing that syncronization doesnt work and still gives me some output that isnt exactly code at the end that is readable.

Offline alexfru

  • Jr. Member
  • *
  • Posts: 17
Re: trying to use ndisasm
« Reply #3 on: December 29, 2014, 11:00:42 PM »
ok so it would be ndisasm -o100h edit.com Append >somefile.txt. so this will work under windows right? and what about fixing that syncronization doesnt work and still gives me some output that isnt exactly code at the end that is readable.

It would be
ndisasm -o100h edit.com >somefile.txt
and this kind of output redirection works in DOS, Windows and Linux.

As for "synchronization", remember that programs contain both code and data. If the disassembly doesn't look like code, chances are it isn't, it's data. Since in regular DOS .COM and .EXE formats there's no clear-cut boundary between code and data (and they can even interleave each another: code, data, code, data, ...), you'll have to figure this one out yourself. I don't think you can find a reliable tool to help you here. Read the code.

Offline michael weaser

  • Jr. Member
  • *
  • Posts: 9
Re: trying to use ndisasm
« Reply #4 on: December 30, 2014, 12:34:26 AM »
Ok i was messing with synchronization with edit.com and i did the intelligent sync with ndisasm now i don't have any apparent data. can someone help me go thorough the code and help me understand it. i would expect to have data for the words in edit.com like file etc. and all of the menus stuff but there is nothing. . i want to know what parts of the code would go to what part in edit.com itself, i can't figure it out. i expect it wasn't programmed in assembly and probably in basic, c or c++ because if it was programmed in only assembly i would be able to figure it out but i cant. i have the source that i disassembled below in an attachment on whoever wants to help me.


 this is a text document with the source , i couldn't upload it on here since it is more than 1 mb.
https://drive.google.com/file/d/0BwNQdPOLgm2ZTGZqZE9pY0NycTQ/view?usp=sharing




Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: trying to use ndisasm
« Reply #5 on: December 30, 2014, 01:13:12 AM »
Don't do it, Michael! Microsoft's "edit.com" is a proprietary file and disassembling it would be illegal. The cops will come to your house and arrest you. They will arrest anyone who helps you. They will arrest the manufacturers of a tool that you use to accomplish such a nefarious act. Okay, maybe not, but that's why "reverse engineering" is off-topic here - Forum policy. Don't do it. We told him repeatedly not to do it, your honor!

Discussion of how to use ndisasm is fine, discussion of disassembling a proprietary file is not. Take it elsewhere. Sorry.

(having said that, ndisasm is not a particularly appropriate tool for the task anyway. Try IDAPro, or look for an old program called "sourcer".)

Best,
Frank


Offline michael weaser

  • Jr. Member
  • *
  • Posts: 9
Re: trying to use ndisasm
« Reply #6 on: December 30, 2014, 03:22:41 PM »
i don't want to get in trouble with Microsoft but i only wanted to analyze the code and see how it worked. i'm not sure even if i'm reverse engineering because i'm just interesting how the code works. i'm not going to sell the source code or anything. i don't even thinks microsoft even cares since dos really aint used anymore as long as i dont sell the code.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: trying to use ndisasm
« Reply #7 on: December 30, 2014, 08:01:59 PM »
I think you're right that "nobody cares" about antique code, but it's still against Forum policy. I personally don't care at all about breaking the law, and I don't care if you do, but we don't want to expose the Forum to any liability.

"Scotland Yard was trying hard,
they sent some dude with a calling card,
said do what you like but don't do it here."

'kay?

This is unfortunate, because there are some interesting questions - both about using ndisasm and decompiling code/data in general. Perhaps we could discuss using ndisasm on some arbitrary "myfile.com" that we do have the right to disassemble but don't have the source code for some reason...

One thing to keep in mind is that dos didn't care whether the name was .com or .exe, it distinguished entirely on the presence of an "MZ header" or not. If the first instructions ndisasm finds are "dec bp", "pop dx", you've got an .exe - even if it's named .com. This means that "-o 100h" won't be right, but there might be some useful information in the header. Ndisasm can't read this - or any - header. Doesn't even try... but you can...

I've never found that "automatic" or "intelligent" synchronization worked very well, but you can add manual synch points, as well as specifying areas to skip. This can result in a very long command line to ndisasm before you're done!

At one time there was a proposal to add an option to have ndisasm print (printable) ascii characters on the right. It was rejected, for reasons I don't remember. As I recall, it was just a fairly obvious "printf" statement in a fairly obvious spot, if you care to add it to your copy. This won't detect all data, of course, but it might keep you from struggling with the disassembly of "press any key"...

The overall question of separating code from data, I'm told, maps to the "halting problem" which has theoretically been proven insoluble. That doesn't mean you can't do it for some particular file, just that you can't do it for the "general case".

Agner Fog's "objconv" does a much nicer job disassembling files, but I don't think it works on 16-bit code...

If you've got questions about ndisasm, bring 'em on, and good luck with your "project".

Best,
Frank


Offline michael weaser

  • Jr. Member
  • *
  • Posts: 9
Re: trying to use ndisasm
« Reply #8 on: December 31, 2014, 12:57:53 AM »
ok so weird frank it is a mz .exe because i know if you open a mz .exe in notepad you will see mz and it is now i have to find out how to to decompile a mz .com that should be .exe.  . are any of the past things you said to me able to decompile a mz .exe like idapro or sourcer? what is the best way to decompile any mz .exe?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: trying to use ndisasm
« Reply #9 on: December 31, 2014, 05:29:58 AM »
Type "MZ executable" into a search engine and see what you find. We're not going to do it here.

Best,
Frank