i have this curiosity and a need lately to learn to tamper into non PE and NE files
bul let me better show you for one specific example

look in the file atached to this post (stellar.jpg)

im sure you can notice the grey nag screen in the middle of the capture
it just pops up whan you want to save and closes the saving operation when you press ok on it
so my guess is that just removing that one will leave the copying process live

but how ?.. windasm doesn't show not a single text string from the dissasembled executable anywhere

in softice i cant trap the spawning nag window because i dont know what bpx to set for it

it should be a 16 bit call like MessageBox ? i tried a lot of similars in softice but none worked
i am a little familliar with the win32 API calls but where to ge the ones for msdos .. are there any ..cos if there are i cant find them

the file is compiled by Borland C++ and im running out of debugger disasemblers to run it thru ....

i guess its time to learn IDA ... buy it too ...does it suport non PE files ?

anyone have experience with this type of executable reversing ?
could you spare some advices/instructions ?

Hello mancini !

W32DASM doesn't show any string references? So there are two possibilities. The first one is that the "W" stands for Windows and not for DOS, the second one that DOS you have no string references in DOS. Both are true.

In DOS you don't set a BPX on an API, since DOS has no APIs, just interrupts. So you must use BPINT. Of course you must also know on what INT with which value in AX to break.

DOS has no APIs, as said, and it has no window functions also. The program creates all screen output without the help of any interrupts. Maybe it uses a "write one char with given color at cursor position" interrupt call, but I doubt that.

Yes, IDA supports DOS files. DOS reversing is totally different from Win32 reversing. You have much to learn and there is little information available.

well at least i know now what i have to do next
unlike the deadend i reached on my own

and i allway have you guys to bother with endless questions

Here's something you might want to look at Mancini.


HOW TO CRACK, by +ORC, A TUTORIAL
Lesson 2: tools and tricks of the trade

When a protection scheme is marked by the issuance of a specific message on the screen, you could go into the program and locate the code that emits this message, and then determine what triggers it. A good way to start the location process is to see if a system call is used to display the string. Interrupt INT_21, INT_10 or INT_29 are usually used to display text messages to the console.

When the message's display is not a result of one of these system calls, direct video writing is probably being used. If you know the screen location used, and if that part of video memory is not used for anything else at the time (a big if), a memory write breakpoint could be set on the video buffer address
corresponding to the first character's position. If this won't work, use the step-over/step-around tracing technique while watching for the message to appear.
-------------------------------


Kayaker

Have you tried looking at it with a hex editor? windasm, when it works, is great, but it fails a lot, too. If you can see the string w/ a hex editor, then chances are the exe isn't packed and you can use softice's search memory command to locate the string. Then you put a bp on the range of bytes in the string.