Hey all, I ran into an issue last night and would like a little feedback. I suspect it's because the EXE is packed, but I've had no experience in unpacking them. Anyway, lemme clear off the initial questions

1. What is the problem....Getting an Access Violation message when trying to run a program inside Ollydbg to learn it's behaviour.
2. What is the protection.....It calls on SecuROM 7.xx but that it's what I'm working on.
3. What tools are you using....Ollydbg 1.10
4. What tutorials have you read....I can't even remember the list - but I've read a fair few (though sadly none that dela with unpacking - just the low level n00b tuts)
5. Show your output listing WITH comments....says Access Violation (did this last night so I don't have the address - I can post it later tonight though)
6. NOW ask your question....

I'd like to know if this is an indicator that I need to unpack the EXE before being able to make any changes and follow it's flow through. It does also tell me when I load the EXE that it has an entry point outside the EXE - which is again, something I've not seen (or seen mention of in the tutorials I've read).

I appologise if this is something that you guys have seen a million times, or I'm not explaining it well enough - I hate to be the annoying n00b on the board. I DID do a search and I didn't see this particular issue listed though.

Thanks.

This is always a good indication that your exe is packed.
Maybe you should first try to unpack manually simpler things like UPX and so on, just to understand the steps of unpacking...
Also, you should take specific tutorials on older SecuROMs, so to have an idea of what you are facing, and what skill level/knowledge is required to deal with it successfully (and getting suggestion on the direction of your work too ).
Mmh... This remember me I still have to find a way to gently kick my favourite SafeDisc game to not force me to swap CDs all the time, since I listen music

Well done for following the FAQ. First-posters rarely do.

You never said what the consequences of the access violation are. Most non-programmers associate this term (if they've heard of it) with fatal crashes and blue-screens, but access violations happen all around us all the time. It's just that there's usually an exception handler or ten lying about to deal with them.
Many programs rely on access violation exceptions being raised in order to do what they do (it's poor practice, but it goes on). So unless you're debugging a program of your own or you expect no exceptions whatsoever, it's common to skip over any and every exception that is raised.
In OllyDbg's 'Debugging Options' there is a group of checkboxes that allow you to say which exceptions you want reported to you and which ones should be passed to the program (as they would be in normal execution). When I'm unpacking, I usually have all of these boxes checked (so that they are all handled automatically).
Once this is done, it's only a matter of using shift+F9 (instead of F9) to run and you'll never be hassled by an exception that doesn't concern you.

So I guess what I'm saying is that if you weren't already aware, this exception may be perfectly normal and routine, and that maybe it only wants to be handled by the program. However, if this exception is causing the target to terminate (by falling through to an unhandled exception or otherwise) then I'm afraid you have a long list of possibilities to investigate.

Regards
Admiral

Wow, thanks for all the info guys, I appreciate it.

I guess I've got some reading to do on unpacking and such and I'll have to get to that.

Just before I head off to do that though, are there any "universal" unpacking programs? (I know that's a bit of a dirty statement but it has to be asked I suppose).

I guess my main wondering is if unpakcing/packing tools are like debuggers - there's several main ones and all of them get the job done, it comes down to preference rather than exclusive functions.

Thanks again!

-V

There is NO easy answer for your question. There is one essential rule of thumb which guides the overall issue. Packed code will not run packed. At some point in time, and in some manner, the program HAS to unpack itself to actually run. It might do this all at once, it might do this parts at a time, and it might do it in such a way that it attempt to hide what it has done from prying eyes.

There are generally two "basic" approaches to unpacking. Try to identify the "packer" and use somebody's pre-made "unpacker" or use a debugger and watch the program attempt to unpack itself and try to catch it at the right moment when you can write the "unpacked" code back to disk, maybe do some other tasks with it and get to run it "unpacked" all the time.

Some packers are just that. Their only purpose is to make the exe smaller and when you get them unpacked they are ready for your viewing pleasure. Other programs both pack and attempt to protect their packing from your prying eyes and to make the unpacking process as difficult as possible for you to figure our and catch a "clean" full dump of the code. It's a constant game between the packer/protectors and the crackers on who's ahead in this game at the moment.

So you have alot of reading and exploring ahead of you from where you sit at the moment. We were ALL there at one time and we have all come only as far as the effort and time we have been able and willing to devote to the effort. If the goal is actual "learning" there is no particular shortcut other than going down the road through the dark codewoods and trying to stay on the proper trail.

Regards,

Thanks

I can say, to my small credit, that I have succeeded in the past at denagging a few fairly common apps out of boredom, but that was about a year ago and time prevented me form really getting into the swing of things.

I've got a lot of ground to recover and new ground to cover for the first time.

Noping the call to a nag is not very much related to the task of unpacking a packed and/or unpacked and protected file. Generally, you were able to "see" the code to find the nag because the program was "unpacked" already and visible in your debugger.

Regards,

Yeah - just wanted to put out that I'd actually managed something rather than stared wide eyed at the tutorials and drooled as my brain melted.

But anyway. Tutorials call.