Log in

View Full Version : KeyGen Output


roottt
March 30th, 2006, 05:12
hi all members

thnx god i found a great minded forum like this

thnx to all came up with this forum

i have a noob Q

i have a cdkey genrator for a game, and want to export it's result to a txt file

like 100 cdkey to a txt file when i press genrate button ,

I know this is worth less,but if anyone has any suggestions, hints, ideas, anything, I would greatly appreciate it.

Thanx for the help,

P.S the keygen in the attachements

Kayaker
March 30th, 2006, 11:59
Sorry, no attaching or linking to keygens, cracks, serials etc. here. I deleted the keygen but your question is valid and can be answered without it.

I suspect you need some application of WriteFile. I also suspect you didn't write this keygen since you probably wouldn't be asking the question in the first place.

So why don't you rethink and restate the problem as you see it. Is what you are really saying is - you want to patch another process so that it outputs its result to a text file instead of just to an editbox?

Kayaker

Admiral
March 30th, 2006, 12:18
Hi roottt.

Your task looks fairly easy, but is more tedious than it should be.
At first glance, I thought the best way to do this would be the obvious one:
By means of breaking on SetWindowTextA (and its equivalents), locate the function responsible for filling a buffer with a randomly generated key. Once this is found, inject a block of code to create a text file using CreateFileA, and write a loop to fill it with keys. This all sounds fine, but it's a real pain to implement.

So a better, albeit hackier method (assuming you only want to do this once) is to bypass the file-handling business and work directly in the process's memory:
Break on this generating function and run to return. Now find an innocent piece of .data memory (or allocate your own) that's out of the way and big enough to accomodate 100 keys, and fill it with some character that won't appear in any keys (let's assume it's an exclamation mark). Now all you have to do is mindlessly patch around this generating-function call (making abundant use of 'Fill with NOP') constructing a loop to run however many times, that will tell the generating function to write a new key (into this cleared memory block) directly after the last key (leaving one '!' character to separate the keys). Using a breakpoint to catch the loop termination, let the loop run through. If you picked a good spot of memory, handled your cursor correctly and maintained the stack properly, your memory block will be full of keys, delimited by '!'. All that's left is to binary-copy this out and paste it into any old text editor. The rest is cosmetic (you'll probably want to Find & Replace the '!' with carriage-return/line-feeds).

If you choose your memory block carefully, you won't even need to maintain a loop counter, but instead run an infinite loop and rely on an access violation error to terminate the loop.

Regards
Admiral

roottt
March 30th, 2006, 17:37
thnx Kayaker & Admiral for your help and support

Quote:
[Originally Posted by Kayaker]
you want to patch another process so that it outputs its result to a text file instead of just to an editbox?


you simply stated my problem

Quote:
[Originally Posted by Admiral]I thought the best way to do this would be the obvious one:
By means of breaking on SetWindowTextA (and its equivalents), locate the function responsible for filling a buffer with a randomly generated key. Once this is found, inject a block of code to create a text file using CreateFileA, and write a loop to fill it with keys. This all sounds fine, but it's a real pain to implement.


that will be easy for me if i have the code for the keygen

Quote:
[Originally Posted by Admiral]
So a better, albeit hackier method (assuming you only want to do this once) is to bypass the file-handling business and work directly in the process's memory:
Break on this generating function and run to return. Now find an innocent piece of .data memory (or allocate your own) that's out of the way and big enough to accomodate 100 keys, and fill it with some character that won't appear in any keys (let's assume it's an exclamation mark). Now all you have to do is mindlessly patch around this generating-function call (making abundant use of 'Fill with NOP') constructing a loop to run however many times, that will tell the generating function to write a new key (into this cleared memory block) directly after the last key (leaving one '!' character to separate the keys). Using a breakpoint to catch the loop termination, let the loop run through. If you picked a good spot of memory, handled your cursor correctly and maintained the stack properly, your memory block will be full of keys, delimited by '!'. All that's left is to binary-copy this out and paste it into any old text editor. The rest is cosmetic (you'll probably want to Find & Replace the '!' with carriage-return/line-feeds).

If you choose your memory block carefully, you won't even need to maintain a loop counter, but instead run an infinite loop and rely on an access violation error to terminate the loop.


sorry, didn't get anything




mmm, may i diassemple the keygen and get the instructions for making the cdkey and make my own keygen but export it's result..

i really don't know, need your help please

Kayaker
March 30th, 2006, 18:55
Quote:
[Originally Posted by Admiral]By means of breaking on SetWindowTextA (and its equivalents), locate the function responsible..


That seems the most reasonable. Or what about a remote thread-specific WH_CALLWNDPROC hook using SetWindowsHookEx. WH_CALLWNDPROC is used when SendMessage is called, which SetWindowText calls down to anyway. I've never implemented one but all you really need to access is the lParam value of WM_SETEXT when the appropriate SendMessage call is made to the remote edit control, then simply write the string buffer out from your own app. Check out Iczelion's tutorial example for an introduction.

Kayaker

LLXX
March 30th, 2006, 22:29
Quote:
[Originally Posted by roott]that will be easy for me if i have the code for the keygen
Quote:
[Originally Posted by roott]mmm, may i diassemple the keygen and get the instructions for making the cdkey and make my own keygen but export it's result..
You are aware that this is a reverse engineering site? Keygens can be reversed too... just disassemble, edit the code, and reassemble. For only 100 keys no elaborate scheme is needed; just get it to fill a block of memory with its output, then write the entire block to an output file.

A good exercise in Asm nonetheless

roottt
March 31st, 2006, 18:06
searching for Iczelion's tutorial ............

Admiral
April 1st, 2006, 07:01
If you want to do this the RCE way, it seems like you have a little reading to do. Learn some of the basics on debugging & finding crucial spots in memory (functions and variables, using breakpoints) then take another look at my last post. You asked if you should disassemble the keygen. Well yes you should (using a debugger), but if you only need to do this once then you shouldn't need to use anything but a debugger.

However, if you're a programmer first and a reverser second (or not at all), then Kayaker's suggestion is a much better idea: You could achieve your goal without touching a reversing tool. If you are familiar with Windows Hooks and manipulating the Windows message pump (in a remote process) then you can easilyish throw together another app in the language of your choice to probe the data out of an active instance of the keygen (WM_COMMAND:BN_CLICKED may come in handy). If you aren't familiar with these structures then throw a few of the API function names Kayaker gave into Google. Once this is done, assuming you're using a HLL, dumping the output to a text file is trivial.

Regards
Admiral

LLXX
April 1st, 2006, 20:26
I'd recommend IDA for disassembling the keygen. Trying to disassemble it in a debugger is more difficult, since no debugger I've ever used has the analysis power and convenience of IDA. You can also get IDA to emit assemblable source code, which no debugger can do. Once you've gotten the source, edit and reassemble and you're done. (Of course, you should use the debugger to test what you've made.)

roottt
April 2nd, 2006, 04:27
http://win32assembly.online.fr/tut24.html