Hey there..newbie here..I wanted to know if there is any tutorial to get started to get pass softwrap...I did search the forums but the link on the exeforums.com wont let me register..so I cant see it

Thanks for the help.

-Spiffed

Did you actually READ THE FRIGGEN FAQ????

Try this search in your favorite search engine and use your brain to develope more criteria:

softwrap + cracking + tutorial

You may not be able to register at exetools, but google clearly shows that the softwrap materials came from: http://cracking.accessroot.com

but YOU did search DIDN'T YOU

Regards,

Thanks very much JMI...your my new hero.

No No No.......

He is not your hero, he's a prick .

Lets go back and check our options.
First thing, this is not exe forums. We are not
associated in any way other than by link's.
JMI is a moderator in both places, although
I dont see how that matters.

Next, you want "get pass Softwrap".
Get past softwrap ?? Get a password for softwrap ??

A search of this place using the most basic term of "softwrap"
reveals this :http://www.woodmann.com/forum/search.php?searchid=160866

A search of Google with the simple word "softwrap" reveals this :
http://www.google.com/search?hl=en&lr=&q=%22softwrap%22 ("http://www.google.com/search?hl=en&lr=&q=%22softwrap%22")

A search of Google with a "compound" phrase reveals this :
http://www.google.com/search?hl=en&lr=&q=%22softwrap+crack%22 ("http://www.google.com/search?hl=en&lr=&q=%22softwrap+crack%22")

http://www.google.com/search?hl=en&lr=&q=%22softwrap+serial%22 ("http://www.google.com/search?hl=en&lr=&q=%22softwrap+serial%22")

http://www.google.com/search?hl=en&lr=&q=%22softwrap+keygen%22 ("http://www.google.com/search?hl=en&lr=&q=%22softwrap+keygen%22")

Now, if we were to look for a tutorial, try this :
http://www.google.com/search?hl=en&lr=&q=%22softwrap+tutorial%22&btnG=Search ("http://www.google.com/search?hl=en&lr=&q=%22softwrap+tutorial%22&btnG=Search").
This last result will not yield much but, this is a start for you to
work from.

You could also try :http://www.woodmann.com/forum/search.php?searchid=160867
This also does not reveal much but, it should be enough to get you started.

I am not a hero, and your welcome

Woodmann

wow 2 heros in one day.

So Sayeth the OBC !

Regards,

sorry, I'm not very acquainted with human language...
what in the hell is an OBC?

An Old Bastard Clan?
An OnBoard Computer?
Someone Obscured By Clouds?

regards, bilbo

It's like an +ORC, but not Red ;-)

For some "unstated" reason, Woodmann started using the moniker on occasion, beginning in mid-2002.

In September 2002, in a Post in the Moderator's Forum, +Splaj labelled it as:

"OBC" is Old Bald Cracker.

No one has dared ask Woody if it's true. But I know for sure he is younger than I am.

Regards,

Hey I read the tutorial at http://cracking.accessroot.com and managed to get the loader working.

The question is the loader wont work on another machine since it will have a different virtual address..anyway to make it so it works on all machines?

Thanks

I take it you're using Diablo2oo2's Universal Patcher as described in the tutorial.
I've never used it before, but I'd guess it doesn't have support for relocations or differing imagebases (otherwise your problem is a no-brainer). But if I recall from a previous thread correctly, it has a memory search feature. Perhaps you could use that to, at load time, search for a (sufficiently long) unique sequence of bytes that can be found at the area needing attention. Of course, these will not be the opcodes you're ultimately looking to patch, as ExeShield unpacks its own code, but the packed code should be constant and invariant of the OS's choice of virtual addresses.
I'm not sure how powerful DUP is, but certainly if it has a scripting engine, you could easily use this byte search to your advantage.

Failing that, you could take on the challenge of coding your own loader. I found it to be a lot easier than I anticipated.

Perhaps someone here has more experience with DUP that I do.

The dll imagebase was one of the issues I faced when writing the tutorial. Sorry to say I haven't explored further with this protection outside of my tutorial. But if write your own loader to patch the dll irregardless of it's imagebase. You will have effectively made a generic softwrap loader. Since the dll is the same for all programs protected by v6.1.1
I have just started writing my own loaders, so I am not very versed in that area. But I think you can get the imagebase of the dll by using getmodulehandle. Then you just add the offsets to the imagebase and patch accordingly. I guess the trick would be to find out when to call getmodulehandle and then you just wait for the memory location+imagebase I used in the tutorial to change to 1. Then you can patch without fear of integrity checks.
sLayer from SND wrote up a tut using the loader method but instead of dup he used ABEL loader generator. I have never used it but you can try it out and see if it works.
EDIT: N/M I see you already tried that method and were unsuccessful.

EDIT2: Another option which I have not tried is to use admirals method of a search and replace loader. Then use the memcheck feature in dup. The dword you are checking will reside in the original exe which will remove the imagebase problems. However you will have to find a modified dword in the executable between the last integrity check and the loading of the nag. Again, I have not tested this and fear that it will not work. I do not think that the dll returns to the program until after the nag. But it is worth a shot.

Up to XP (XP SP2?) this has been true. But from then on (and even more for the x64 versions and later Windows versions), DLLs can have different imagebases in different processes, although there is only one actual image - it can get mapped to different addresses in each process using it.

So whereas it was a common fact that LoadLibrary() [for DLLs not loaded yet] resp. GetModuleHandle() [only if the DLL is already loaded] returned a module handle that equaled the current image base in memory, it has become safer to inject code to the target process and let it fetch the imagebase belonging to that process with GetModuleHandle() and access "their" image of the DLL with ReadProcessMemory and WriteProcessMemory.
I encountered this some months ago for the first time and spent quite some time with odd behaviour and crashes before i found out.

@Laola: far as I know, this is general Windows NT behaviour. Windows NT uses the "copy-on-write" page flag for dlls, meaning that whenever a process modifies a dlls address space, that dll is immediately copied into the process space of the modifier. Hence, for any NT-based system, you can't modify a dll loaded by another process by loading the dll yourself (or getting it's imagebase by other means) and then modifying it.

Fake

Well, up to XP SP2 it has been a pretty sure bet that when you LoadLib an already loaded dll, you get the same Handle back that the other processes got. (thus same imagebase and addresses for use with Read-/WriteProcessMemory)
At least I tried many times on a "plain" XP and W2K but always got the same imagebase for all processes once a DLL has been loaded.
Obviously, something has changed inside the memory manager because the "can have a different image base" has turned into "will most definitely have a different image base".

Yeah, I suppose that might be true.

It seemed like you suggested that on NT systems prior to XP SP2 you could modify the memory of a dll systemwide, just by patching it in your own process - which you can't. Hence, on NT systems, there normally never would be any reason to fetch the imagebase of a dll outside of the process space of the process you want to fumble with - you wouldn't be able to do anything fun anyway.

Fake

Hehe, sorry for being so unclear I just meant that determining the location of the DLL was the same for all processes loading it, so it was easy to find the proper addresses for using ReadProcessMemory and WriteProcessMemory because a simple LoadLibrary() inside my own process would return the same value as it did when the target process loaded the DLL. But now I have to inject code into the target process to retrieve the proper value.

At least that seems to be the easiest way for Ring3 In Ring0 there are other ways to obtain the DLL address.

I hope the idea is a bit more clear now