Hello all,

I recently sniffed out a serial from a certain program. The idea is very straight forward; one call and the serial is in EAX. The serial is based on a hardware dependant code, rather than a name. Since nobody else is able to use my code, I decided to attempt a keygen.

I skipped through the registration proc, but it is extremely obfuse and extremely long (3098 lines, not mentioning a second sub proc which is called), so I don't really feel like trying to figure out what it does.

In the past, I once ripped a whole registration proc from a program and built another GUI around it. I figured that would be the best option in this case as well. Problem is; the program is written in VB and the regproc is full of calls to the MSVBVM60.dll. In order to make this work, I'll need to import MSVBVM60 in MASM...

Does anybody know how I can pull this off? Or maybe where I can find premade import headers? I searched the net, but couldn't find anything.

The best option would be to use inline ASM in VB, but since VB doesn't support that...

Thanks,
- Fahr

Your best bet it to use Smartcheck and try to build a VB keygen from its output, however if you are hard headed enough and determined enough, I would try looking here for some of your information.

http://vb-decompiler.com/ ("http://vb-decompiler.com/")

That's another problem I forgot to mention; this program was originally packed. After unpacking it, SmartCheck wont run it properly, says the code is still not very VB-ish, which can well be, since there's still loader crap and all.

SmartCheck is not really an options here. I'll check out that vb-decompiler though.

Thanks,
- Fahr

You said "the serial is in EAX", so why not use keymaker and so on, they can broken at the address where your serial be in EAX?

BTW: now we can use inline asm in vb6, just with help of some addin for vb,
you can search "tweakvb" ar google

I'm really not sure what you mean with this sentance... I know where in the program the serial is in EAX when you hit the 'register' button (with a wrong or right serial in the input box), so I can sniff it using OllyDBG.
Other people, however, don't know much or any reverse engineering. For those people I would like to build a keymaker, so they don't have to dig into OllyDBG etc.

TweakVB looks promising, I'll certainly look into it.

- Fahr

I think he means why don't you use inline keygening, or in other words patch the program to message box the correct serial number when you click register with your name and fake serial....etc....Essentially I think it would be less work, but then again, I have never attempted it I have only read about it

Oh, I've certainly considered that option. It would indeed be much less work, only a matter of minutes...

Point is that it would still require me to spread a patched exe, rather than a small keymaker. I can't build it in a byte patch either, because the original exe is packed...

Replacement exe @ 2MB VS Keymaker @20KB...

If a keymaker is possible, it would most certainly be the better option. It's also neater, I think. If I could pick between downloading a patched replacement exe or a keygen, I would definately go for the keygen...

- Fahr

Another thought! Would it be possible to write a loader which would grab the serial from mem at the moment of generation?

I never wrote a loader yet, so I wouldn't know if it can be done, especially seeing how the orig exe is packed...

- Fahr

Excuse my diatribe, don't take it personal, you can do what you want, but,

Bah, if all you're interested in this for is spreading cracks, keep this shit out of the Advanced Forum, this thread is moved...

Kayaker

I only used that as a point to illustrate. What I am really trying to do here is find a solution around that VB stuff...

But move it around as you wish, I guess you know what's the best place for this

- Fahr

inline ASM in VB:
www.tweakvb.com

Yes, someone already mentioned that. I'm looking into it.

- Fahr

Hmm... Inline Assembly in VB is not really an option, either... it doesn't recognize MSVBVM6.dll imports (I should've known, of course).

Is there really no way to import MSVBVM6.dll functions in MASM? In theory, it should be possible, no?

And otherwise that loader idea... any thoughts on that?

Thanks,
- Fahr

Oh, I think yes. We probaly can import and use export functions of MSVBVM60.dll in MASM32. But the document and prototype of them was not documented by Microsoft, so we must need some code reversing.
I use dumpbin /exports to create a export list file of MSVBVM60.dll, and change it to DEF file format, then use lib /machine:ix86 /def:def_file to create import library for msvbvm60.dll.
To create inc file, I use a tool call impapi, found on Win32ASM board.
The attached file contains: msvbvm60.def, msvbvm60.lib and msvbvm60.inc.
Good luck !

Thanks! That will be most helpful

Params etc. shouldn't really be a problem, since I have the IDA ASM output with the right calls in it... I should be able to copy it 1:1 with some minor changes here and there.

Thanks a lot for your inc and lib! I'll post here how it went

- Fahr

It seems that the .inc file is not compatible with MASM

MASM wants inc definitions like this:

CreateSecurityPage PROTO : DWORD
EditSecurity PROTO : DWORD,: DWORD

with param definitions, prolly needed for the MASM specific .invoke statement...

Is there any way I can convert this .inc to a MASM compatible .inc? I don't think it's possible to generate definitions of the params from the DLL...

- Fahr

There is an l2inc utility with MASM32 which can generate .inc files for lib files, but this doesn't work with the .lib file generated with lib.exe

I tried your .def file and I rebuilt it myself, I do get the lib, but l2inc wont process it. It gives no errors, nothing, it just doesn't produce any output either...

- Fahr

Ok, disregard all that, I still got it working by changing all 'global's into 'extrn's... apparently MASM32 doesn't know global, but it does know extrn.

The program compiles ok, but there are some weird things... I hardcoded in the hardware dependant serial for now. At some point it puts it thru __vbaStrLen. The original program returns 12h (18), the actual size. My 'program' returns some bizarre number which is extremely high.

Eventually my program dies on a __vbaStrMove... I guess it just can't be done without the Visual basic stuff around it

I'll continue experimenting. If anyone has any input, it would be most welcome.

- Fahr

Hello Fahr
Below link might help you understand if its possible or not
hxxp://board.win32asmcommunity.net/showthread.php?threadid=7879&highlight=msvbvm60.dll

Regrads, Sope.

Sorry if I come late into this thread, and perhaps you are far into your project to consider a lateral solution but:

When you rip the code off the program you are taking the fish out of the water, and now you have to reconstruct the whole environnment in which it can work and survive.
Why don't you just leave it there, and modifiy the code so the whole, mostly untouch program IS your KeyGen?
In this case you would only need to inject some code that does the display of the Key once it is generated using already imported API, and modify the last few intructions of the Key generating routine to jump or call your code.
It would require quite less construction, but perhaps Construction is what you want to do, so by any means . . .

This is actually exactly what I did for now and it works fine, instead of the error (wrong key blah) it shows the key itself.
Point is, however, that this is not the nicest solution. I already realized that 'ripping' the keygen will be nearly impossible, if it's not the VB imports, it's because the whole environment is gone (as you said) and it will be hell to figure out and recreate. I am now basically at the point where I consider 2 remaining options:

1) Rebuild the keygen algorithm from looking at the code. Problem here is that the code is somewhere near 4000 lines long and more than extremely obfuscated.
2) Build some kind of loader which applies the 'crack' I already built on the fly (modify the prog in mem instead of on the HD). Problem here is that the original program is packed, plus I never wrote a loader yet and I wouldn't know where to start...

For now using the program itself as its own keygen works, but I would like to build that loader (building the keygen for this particular program was already deemed impossible on some other board, where someone attempted the same).

- Fahr

I read the topic and as far as I can say; everyone more or less agrees it's either extremely difficult or just impossible.

Thanks for the info, I completely discarded the code ripping idea and will focus on other possibilities

- Fahr

We have a simple loader on this forum as well here's the url hxxp://66.98.132.48/forum/showthread.php?t=5107 will help you begin with a loader coding for your program.

Thanks! That looks like what I want

I'll check it out!

- Fahr

Hmm... the whole loader idea doesn't seem to quite work out :S

I downloaded Zairon's loader and changed it to fit my needs (which are about the same as Zairon's, except for the addresses).
When I run it, it sticks in the while loop forever. I managed to fish out that it generates an access violation. I added this case:



in the exceptioncode switch. Now when I run it it gives me:

Access violation at 4911260!

only a million times, always at the same address...

When I check in Olly, it says 4911260 doesn't exist (even after I run the unpacker).
The loader never reaches the EXCEPTION_SINGLE_STEP, only the initial one, where I set the EP, then a few DLL loads and then endless access violations.

I have NO idea what I'm doing wrong. I didn't really change anything in Zairon's code except for the exe name and the addresses...

Any help?

Thanks,
- Fahr

Hmm... I just checked it out and it turns out I have exactly the same problem using Zairon's original source on the original crackme...

Is it just my comp? Or is there something buggy in his loader source?

- Fahr