i reversed a program i followed in a tutorial, but how do i make it run outside of a debugger?..

inside the debugger it works just fine like its supposed to, but outside it gives error on startup, i think this is due to the imports table but im not sure..

any help will be appreciated...

Hi,

I'm new here as well but I've been around long enough to know that the old saying 'ask a stupid question, get a stupid answer' doesn't apply here. It's more like ask a stupid question, get flamed, lectured, and/or ignored. I'd like to help you but your post gave me absolutely no understanding of what your problem is. Which debugger are you using? What's the error? Why do you think it's the import table? DETAILS.

well, im using ollydbg v1.10

i opened it in debugger and edited a start-up check so it allways checks back as registered. it runs fine with ollydbg and it works. but if i try to run it outside of olly (like a normal program) it just wont run and shows an error.

i dont really know why i think its in import table, but seeing it crashes on startup.

One possibility is that you, during the cracking of the program introduced a situation that triggers an exception. a SEH sort of structure. Inside the debugger, Olly itself may be swallowing the exception, but running the program outside olly the SEH crashes the program. Suggestions: in Olly make sure no exceptions are bypassed. (Debug tab) and/or, use another debugger to trace the cracked and un cracked program, then see when they diverge in behavior.

ok, ill try remove the exceptions ^^

edit: removed exceptions but it ran just fine. but it still doesnt run without debugger -.-

So, you're saying you changed something, and now it wont run on its own. Two questions: did it run on its own before you made the change, and will it run on its own if you change it back to its original state?

If it did not run on it's own originally, what kind of tutorial are you doing? Are you following the instructions properly in the tutorial? In other words, have you jumped over sections of the tute, or not started at the beginning, fully understanding what they are doing?

It sounds to me like the tutorial is faulty, or you're not understanding it correctly.

im doing exactly as in the tut and it works too, but the tut ends after doing the patching. so it doesnt show that it works outside of debugger. so i guess i something more is needed after the patching...

and y, it ran fine outside debugger before patching

Unless it specifically interests you, I would not get hung up on it then. As naides pointed out, there is likely an SEH problem and they can be difficult to isolate unless you really understand SEH. Rethinking the problem, if it's a tute, they are probably using a real app. It stands to reason that whoever wrote the protection counted on someone changing the code you changed and wrapped it with SEH.

I'm no expert with SEH and someone could help you better if you did a bit of work on it. SEH frames usually begin with a reference to FS:0 and the SEH code handler is referenced around there. You could look at the beginning of the code section you did the change in, and see if FS:0 is referenced.

The basic idea with SEH in protection is to set up a condition that flags an exception. Some code inserts an instruction that times how long it takes for the code to execute, and if you're single-stepping, it catches you. Others use a nonsense instruction in the code. In your case, I can't imagine what it would be, but they could be looping back to see if the code is the same or if it has been diverted with a jump.

Poke around the code near where you made the change and see if you can find instructions that don't make sense in that context.

Questions and ideas...

First lets make sure I get what you are saying: you followed some tut and made some changes to some file while debugging and saved the changes to disk. When running the newly saved file outside of a debugger it crashes or gives an error. Is the error coming from the program or from the operating system?
Additionally, when you say that "it" runs fine inside ollydbg, do you mean the newly saved file (i.e. newly saved file --> load and run olly--> success!) OR the original file (i.e. original file --> load and run in olly --> follow tut and patch --> patch works and running fine)?
My guess is that your newly saved file gives you the error inside or outside of a debugger. I suspect an integrity check is being performed on the file on disk so it fails when running the newly saved file. Let me know what you discover.

the error is coming from the program, not the OS.
Yeah, the patched file saved to disk -> open in Olly -> runs fine
run without olly -> error.

make copy of original EXE, then patch only in CODE-area of copied_EXE.

Ha, that's clever The scenario I am thinking of is: perform integrity check --> if tampered, check presence of debugger --> if debugger present, pretend everything is fine so that cracker pulls his/her hair out! Have you tried running it in one of the many modified ultra-hidden ollydbg versions out there (or with a hiding plugin)? It may give you the error then and you can hunt it down better.
Alternatively, you can go after the integrity check itself if that is what indeed is going on (remember, I'm just guessing here ) Good place to start is finding where the program looks for itself on disk (perhaps CreateFileA).
Another test I sometimes do is to open up the original file and change an arbitrary unused byte, save, and try running it. The integrity check is not necessarily done over the whole file, but if this change triggers your error you can be sure of what you are dealing with.

P.S. a quick search for CRC CreateFileA gave me http://www.woodmann.com/fravia/blackB_wincmd.html as a first hit, and it's a good place to start reading.

i think that might be it ^^
seeing how it runs like i wanted it to in debugger but not without debugger. ill check the integrity:P

thx for the help, ill report back if it works or not.

Edit: found 3 CreateFileA, maybe this could be it?

edit2: confirmed, i edited an unsued byte (u know, where we usually make code caves) and it stopped working , so i changed it back to normal to double check and it worked again. it has to be an integrity check right?

edit3: ty all for the help, that last post really did it,managed to patch it properly now.. maan u ppl rock

it was the integrity check but i had to edit CreateFileW and not CreateFileA :P , once again ty ^^

Now write a tutorial yourself and illuminate the rest of us on what you discovered. You could publish it in tuts4you or some site like that.

i might do that ^^

that's a no brainer. If they did set it up so the crc would be bypassed using a debugger, it should be easy to find where the decision point is located. I doubt if a smart protectionist would do that. What I want to know is why the tutorial did not tell you that. If it was a crackme, I could understand that, but not with a tutorial.

There's nothing wrong with using tutes to learn, but if you rely on them, you wont learn much, especially if they are incomplete and poorly written. You'll learn a few methods of attacking protected apps but you'll miss out on the overall technique.

If you want to learn what's going on here, trace from the beginning of the app, through winproc, and find where the crc check is being done. Learn about the different sections of an exe file and how to jump over sections to get to where you want to be. You'll learn a lot more about general reversing doing that than you will by doing tutes. If you just do tutes, you'll learn someone else's short cuts but you'll never learn how to reverse in general.