HI all,

I'm working on a proggy called VirtuaGirl....yup, it's what it sounds like LOL....

Anyway, the critical compare took about 1.1 seconds to find, but as the code is used for online downloads, a patch here is worthless.

A number generated by some math on my serial (I haven't found all of this yet, just see the results), this result is then compared with the value at an address. When I bpm this addy, it breaks on WriteFile several times. The file being accessed is vg.prf.

The number generated from my serial is multiplied by 15D70h and then compared to the number at the address, which ends up being 28h......this is an impossible test isn't it? (meaning a certain serial pattern may change the number at the address too?)

I'm not done digging through this yet, but if someone has any pointers/ideas, I'd be grateful.

It can be found at www.virtuagirl.com

Hi ?ferret,

Heh heh, it's good to see there's still some quality xxhareware programs around. I like your tastes ^_^

I'm wondering if the s/n is not used for the actual online downloads, but rather it just allows you to view the d/l's with the proggy once you've got them, or maybe it just gets rid of the nag. If you go to the site you still have to access the members section with a valid name and p/w, the usual dealy which would require site hacking (which I know diddly about).

Re the program, the value derived from your s/n that is multiplied by 15D70 is your s/n in hex (why I always use 998899 - converts to an easily recognizable 0F3DF3)

0040AAC6 call ds:GetDlgItemTextA ;get s/n (name not used)
0040AACC push esi
0040AACD call sub_40D484 ;convert to hex
0040AAD2 pop ecx
0040AAD3 mov esi, eax
0040AAD5 call sub_403008 ;something to do with WriteFile vg.prf
0040AADA imul esi, 15D70h
0040AAE0 mov eax, dword_41EAC8
0040AAE5 push ebx
0040AAE6 cmp esi, [eax+14h]
0040AAEE push esi
0040AAEF jnz short loc_40AAF5 ;good/bad cracker message

For me, the value in [eax+14h] varied: 50h, 64h, 3Ch. The address itself also varied, but seemed to be a reference in the file anim.prf. If I changed the value in memory so it matched what ESI was (s/n in hex * 15D70), then it was written into anim.prf, but later got overwritten.

It's all kind of weird, these .prf files are being continually updated and are PICS Rules files for the Content Advisor feature of IE. Do you think a s/n would be stored in one of these?

My suggestion is hack the site and get some full d/l's

Cheers,

Kayaker

I get different addresses for [eax+14] also, but it's always the same place in the file ;-)

hmm....for me, the value there is ALWAYS 28h....but even with the values you're getting it's an impossible compare to satisfy, right? ???

btw....what's up w/ the disassembly (I haven't tried w/ IDA) ....no code at all & if it's packed, I can't figure out what with....

Re the disassembly, this seems to be the problem again with W32Dasm getting confused with proggys that have Resources that are Named instead of being identified with an ID, in this case the bitmaps. If you delete the .rsrc section completely, or otherwise render it unrecognizable by editing its header section, W32Dasm has no problems disassembling the .text section.

It might be an interesting reversing exercise to find out WHY W32Dasm seems limited this way. (Are you listening Harlequin? ^_^) I don't remember the name of the other program this happened with a few months ago.

You're right, that 0040AAE6 cmp esi, [eax+14h] makes no sense when its only 1 byte being compared. And yet I don't see how it could be anything else when that address is from a file that's constantly being overwritten anyway.