For the poster try this http://www.vwaskar.pwp.blueyonder.co.uk/fun/Owar.rar


Overwrite the file in the game folder, and also copy the file data6.owp into the same folder along with the crack.

I dont have the game to test it, but it seems to be the root folder of the game this data file goes to.

Or do a quick search of the games' sub folders for other .owp files, and place it there also.

nope,still no go.the last exe says something stupid about the game not being installed (it is,of course),and quits with "please insert install cd" message..all owp files are in the "disk2" folder (in the main game folder),the game is not accesing any data from cd,its just doing a cd check when it starts,thats all..

2 all with the hexedit advices: sorry guys,but I'm obviously too lame to crack it myself,thats why I'm asking for your help ;)

Give this a try:

http://rapidshare.de/files/22606113/...s-owl.rar.html

I changed mine a bit also, this time with registry checking etc. (seems its looking for a full.dll file also - if not in game folder/sub-folder you may need to get it from cd and copy into game folder)

www.vwaskar.pwp.blueyonder.co.uk/fun/Owarv2.rar

hmm all the pissing contests, you're doing it the wrong way...

Patch the proc, NOT the conditional...

.00457C2C is the proc i think (couldnt download exe, link expired, so i had to look at phils exe, nice tagging -> do the tags AFTER the crack works...)

looks like a simple true / false proc...

so a 33 C0 40 C3 should do the job... cant test, aint got all the files...

will do later, if someone wants to put the link up with the files needed to run
the exe until the msgbox appears or whatever...

-----

1. You replaced a 3 byte instruction with a 2 byte short jump, there is a byte left over, the coding will then continue making instructions from the 3rd byte you left behind unchecked and screw the rest of the program.

may/may not matter, depending on the code execution path, if the short jump is a forced jump, EB xx, then the extra byte should never be executed, unless theres a conditional above the part you patch that can branch past it..

-------

EBP is a Base Pointer and not the actual Stack itself which is ESP. If you check the GetDriveTypeA API you will see the stack itself is not changed in any way. So therefor the Stack is perfectly fine as it is.

-------

ebp is a FRAME and holds the stack pointer on entry of the proc...

typically looks like

push ebp
mov ebp,esp
blah blah blah

then can end with a...

mov ebp,esp
pop ebp
ret xx

or leave
ret xx

EBP is important especially within framed procs like this one, calling an api within the ebp frame doesnt matter, the cleanup at the end of the proc RELIES on the stack not being fucked, as it has to pop ebp, and set esp from ebp...

lessons... blind leading the blind more like...

Like I said, EBP is a Base Pointer for ESP yes, and like I said the GetDriveTypeA is not harming the stack. EDIT: Not everything uses stack frames, they can use local data too as in callbacks.



Thats correct on the 3 > 2byte, but on most occassions the byte left if it were a 74 then the coding will then take the next few bytes of the next op to make a je instruction which would then feck up the rest of the coding :) But as you know most nop the estranged byte/s to make sure.

Relies, it seems on 2 files and registry entry. data6.owp and full.dll and as I said the Software/Owar branch.

Hi,
@TippeX: If i had the game i would have testet it ;)

my comment was that you probably spent more time puting in your tags :), as for testing, thats the job of the guy who wanted the crack