[keygenme]:sadistic-x #2

[Ufo-Pu55y]

Ufo-Pu55y:

i have no idea what is the problem with the keygen, it works fine on my XP SP2 machine. the self-keygen uses MessageBoxA (the function is imported) to display the correct serial. both solutions work fine here.

here's the source

edit: i think i've fixed the self-keygen

Yes, selfkeygen is working fine now !

The keygen should work for everybody, if you use a InitCommonControls at startup.

At least it worked for me this way

/EDIT: Ah, coz of ur used manifest !

I guess, you wouldn't need that InitCommonControls call, if you wouldn't use that

manifest. I don't know much about manifests. When they are needed at all.

But maybe your manifest isn't correctly defined. If I exclude it from the resources,

the keygen also works fine.

Edited February 9, 2008 by Ufo-Pu55y

[Ufo-Pu55y]

Ok, now I read that you HAVE to invoke InitCommonControls,

if you're using a manifest. Dunno, why it works for you w/o...

; how to enable XP-themed controls
include	ComCtl32.inc
includelib ComCtl32.libinvoke InitCommonControls; put this in the .rc file, updating YourApp with real executable name
XP 24 DISCARDABLE "YourApp.exe.manifest"; create this file: YourApp.exe.manifest using real executable name
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly 
	xmlns="urn:schemas-microsoft-com:asm.v1"
	manifestVersion="1.0">
	<assemblyIdentity
		version="1.0.0.0"
		processorArchitecture="X86"
		name="Company.Product.Application"
	   type="Win32"
	/>
<description>Your application description here.
	</description>
<dependency>
	<dependentAssembly>
		<assemblyIdentity
			type="win32"
			name="Microsoft.Windows.Common-Controls"
			version="6.0.0.0"
			processorArchitecture="X86"
			publicKeyToken="6595b64144ccf1df"
			language="*"
		/>
	</dependentAssembly>
</dependency>
</assembly>

More info at MSDN. For me it still works if I omit the resource file data, (and the executable shrinks by 1kb as the .manifest file is not included in the compiled code) but I don't think this has any influence on its operation. The project is attached.

Here's where things get funky: renaming the executable seems to invalidate the XP theme. Also renaming or deleting the .manifest file invalidates the XP theme. Furthermore, the v6.x.x.x Common Controls library is NOT redistributable, so this is an XP-only hack. Lastly, and most absurdly, only create a .manifest file for XP apps using an XP theme... the .manifest file just being present might mess up a non-XP-themed app! For example, if you create a .manifest file for an existing (non-XP theme) application which doesn't use ComCtl32 and InitCommonControls, the application may refuse to run! Try commenting out those lines of the sample included. The result simply exits.

Suddenly, .manifest files have become rather important. I remember the days when those came in shareware archives to outline the package contents, like a directory listing. Since they were rather redundant, I bet more than a few file-deletion utilities mark those as junk by default.

What a confusing bunch of hooey-gooey!

I haven't done a lot of messing with manifest files, but here are a couple of pointers for things i have experienced while putting together installs and bug fixing applications:

- having a correct manifest file but *no* call to InitCommonControls will usually cause your app to fail with a fairly random error message, the message you get will not give you a clue of what the real problem is. Delete the manifest file and the app will run perfectly.

- having a corrupt manifest file can cause your app to crash. To check if the file is ok and doesn't contain any non printable chars that corrupt it, just try and open it in IE, if IE complains or can't render it properly then the file needs to be fixed.

- it doesn't matter what you put in the data sections of your manifest file (i.e. your correct app name doesn't have to be in the name attribute of the assemblyIdentity node), as long as the file itself is named correctly it is still valid for your exe.

- if you *do* call InitCommonControls but have no manifest file, your app will still work, it just won't be XP themed. The manifest file simply specifies the minimum version of the common controls to load.

Another thing: I've found that manifest files should not have tab characters (ASCII 09), or Windows will refuse to load your app.

Edited February 9, 2008 by Ufo-Pu55y

[DrPepUr]

Ok I am about to pull my hair out could someone give me a push in the right direction?

[CyberLord]

@Ufo-Pu55y:

I think InitCommonControls is not required. I've seen apps with XP manifests that don't call InitCommonControls. Also I checked the source of RLPack and I didn't noticed call to InitCommonControls. Maybe my XP manifest isn't configured well, but the app runs without any problems on my machine.

Thanks for the information above

[CyberLord]

@dustyh1981:

there's a TLS callback and uses FindWindow to check for "OLLYDBG", "Lbr68", "Hacker's Disassembler", "TIdaWindow". Then it causes an exception which must be passed to the installed SEH handler, otherwise the app will exit. The SEH handler calculates key using the computer name, which is later used in serial number calculation.

[Killboy]

That's probably because any of the DLLs loaded by your app called it or referenced comctl32.dll

In fact, it's enough to call LoadLibraryA("comctl32.dll") as InitCommonControls effectively is an empty function (just a RETN).

Not sure if it HAS to be bound statically instead of loading it yourself with LoadLibrary.

Windows manifest stuff sucks dick, with VS 2005 they introduced dynamic runtime dll linking via manifests which practically eliminates portability.

Your app will require a SPECIFIC version of msvcr80.dll so if there's even a more recent one, it won't work :x

[DrPepUr]

I thought it had something to do with the computer name, and it was finding olly, I have tried working it with win32dasm and noticed it was calculating the byte and actually got it to break on GetComputerNameA but I cant follow the code.......Then I tried it with softice and got the same result..........after reading your post I went back to olly and set bp at the end of FindWindowA and GetComputerNameA it breaks on FindWindowA but not on GetComputerNameA, This is the first time I have messed with TLS callback so I am still kinda lost but thanks for your help.

[Killboy]

This keygenme seems to be somewhat advanced (apparently not the algo, havent looked at it though).

Dunno if you should be dealing with more or less advanced antidebug stuff considering your current skills (just from what I've read).

It would be better to read up on some of these tricks than randomly try to patch or set breakpoints.

[Angel-55]

* Off Topic *

the reason why manifests work without calling InitCommonControls function is that some machines doesn't have the latest hotfixes from M$ or even missed some before, due to hotfixes some core files has changed and it costed some problems for our releases while it worked on our machines and not on others and some crackers faced the same problem when their releases crashes immediatly after compiling the source....... the only solution was to call that API although it's not needed on some machines "it is recommended to use it just in case "

i hope none uses hotfixes like me rofl !!

Cheers guys

[DrPepUr]

I think I finially got it. Probbally just dumb luck but ....

Sadistic_X__2_KeyGen.rar

[CyberLord]

@dustyh1981:

working, good job