Ok, guys
last night i try to disasmble my prog, which was created in Visual studio 6.0 . I simply created for experiment only. When I used PeiD for this (though i know which compiler i used i.e VSC++ 6.0) but PeId identified as VC++ 5.0 (debug) . I dont khow why. and when i try to disassmble in w32dasm 8.93+
,and to my confuse it did not display the string . i didn't use any packer/compressor. when i try in hexeditor, i can see thhe string.in IDA ()also give me the string (in PE), in Dos executable nothing.but in binary mode, i can see the string. and i dont know why w32dasm refuse to display the string.

any idea, and for newbie like me, do not use only one tools,try it with others.

and the is a good tool for newbie for starting assembly. once you have you will not be sorry
the protection is very funny ,and if you are luky like me, without using our tool (except brain) you can register it. but make sure it is version 4.02.
here's the kegen by Micro$oft, start->run->calc.exe before 72 mins . I bet you will be register. if you used the above keygen. I hate long serial like the author.

Have fun and try your luck ! i spent less than 30sec to register hee
when you got your registered used it wisely and got some funny protection.

remember no need long serial and i love/like this prog (if you have money please buy it.)

here's the link

You were doing fine until you decided for some reason, 20 minutes later, to edit your post and add a link to shareware and a method to crack it. Mark: F- (Large Wet Boots)

After battling through that, it's either a crack request or an actual crack. I'll leave that one for those with the large boots.

There are many reasons why WDASM won't show your string, and in fact there was a thread a couple of days ago covering this exact topic. I have no idea what "In DOS executable" and "binary" mode means, but I'd put money on it that you're seeing a unicode string that wdasm doesn't know anything about.

I've tried many other various dasms, and have come to the conclusion that

IDA is superior.

I simply report (for newbie) what i saw and the difference power of w32dasm and IDA and it's all about the importance of choosing our tools. don't worry, i will never ask for crack , but knowledge . That is why i decided to registered for this forum.

Ok I used IDA 5.0.0.879 for this.If you used it you'll see the above option
"In DOS executable" and "binary" may not be right but it's like that when you try to load prog.if you choose windows PE for the file type ,it's OK ,but if you choose the file type is dos executeable you will only see "This program cannot be run in Dos mode" string. for this prog. if you want to see for your self . i'll attach some picture/prog next monday.

BTW, thanks for showing me the right path for the above shareware link blah blah.. , It will not happen again .

lcx: No offense intended. You need to put your thoughts clearly, if you want your posts to be effective (readable). you, and somebody looking over your shoulder when you disassembly with IDA may stand a chance to guess what you are talking about, but me. . .

I can only remotely guess what you are taking for granted or known.

This is what I gather:

You disassembly your file with IDA with the PE option, you find your string, and every thing is rosy.

You try to disassembly with DOS executable or Binary mode and do not find it.

Right??

Ida is not a file viewer. If the program is a PE file, and you choose a DOS, MZ format, IDA will not process the file. The string is still there, IDA just do not show it, because it did not process the file. If you used a hex editor (with unicode search) you could always find your all important string.

So do not use pliers to hammer a nail, a screw driver to grab a wire or a hammer to screw,

disassembling a PE executable requires IDA to work in PE mode otherwise you come out empty handed.

This is a legacy hangover from the early Windows days, when the PE format was defined. There's an article about it on MSDN somewhere, it was needed because there was no guarantee the exe would be run in Windows rather than DOS, so it was used to display a nice warning message. The DOS stub is added by the compiler/linker (usually Visual Studio, but I bet other compilers do it too) but is not essential to the executable's operation. You can quite easily delete the stub code and edit the IMAGE_DOS_HEADER field in the PE header if you wanted - this is a common way size-limited demoscene intros save space.

All that IDA is doing is switching between the DOS stub and the win32 code as directed by the PE header, based on what you're choosing in the IDA options.

*edit* actually, the devil is in the details. The DOS stub actually preceedes everything else in the executable but is still referred to by the PE header, which comes immediately afterwards. So it's more accurate to say IDA doesn't use the PE data to find the DOS stub because the stub comes first (which is what naides already said). Damn, my post has degenerated into rubbish. I hate it when that happens.

Thanks, naides and silver for your post,

I am clear now.

Therefore I decide not attach that silly progs of mine. the point is all there in your post so no need to bother about it.

~Another little step~ ~