Hello Timmy,
Sounds like your project for TalkPCR is dead at the moment. Even so I have looked at it and have some questions for you. I have traced through the keyfile rearangeing (breaks it up into 3 parts 0x100 each. Bits 1,4,7,ect in 1st part, bits 2,5,8,ect in second, bits 3,6,9,ect in 3rd part).
Then through the copying of these parts to a new location.
Then it decrypts the bytes by useing a part of 1 copied section as a mask for a different part of another.
Finaly it swaps a piece at the end of a section with a piece at the begining.
That done, it starts fishing for strings in these decrypted, rearanged sections (ie TalkPCR registration key, and _Master__) I also noticed it fishing around with my windows username adding underscores at front and back.
Finaly my problem. I have been trying to create a valid key file but can't seam to make any sence out of how to reverse the decryption part so I end up with a valid string in the end. What is the reverse of ORing something with 0x20 ect. I have experimented with some code in c but no luck. I looked over your code and could recreate it in c if I wanted but that wouldn't help me understand whats going on.
please send some help.

There are three main parts to the encryption.
1. You need to know the offsets in the unencrypted file where the data the program is looking for - this is failry easy as with a big enough data screen in sice you can see where the data should be.
2. The next part (most difficult) is basically very simple once you understand what is going on (it took me a while). Basically two bits from each byte are rotated through their corresponding counterpart in the other 100h byte blocks. ie. the original bits 1&6 of byte(n) go to bits 0&5 of byte(n+200h), while the original bits 0&5 of byte(n+200h) got to bits 3&7 of byte(n+100h), while the original bits 3&7 of byte(n+100h) go to bits 1&6 of byte(n).
3. The final part is just the interleaving of the three blocks of data back into one contigious file.

I hope this helps. ( I think I've got it right but it's 3:45 am here and I've had a wet )

Hello Timmy,

Thanks for the pointers. I have looked back at the decryption code and while everything I wrote down about it was correct; all thoes:

if byte x of middle section ANDed with 8h = 0 // meaning bit 3 = 0
then byte x of first section is ANDed with FDh // meaning bit 2 1st section set to 0
else byte x of first section is ORed with 2 // meaning bit 2 1st section set to 1

, I don't think I was any where near figureing out what it was doing (shifting the bits 1 & 6 from a byte in the first section to bits 0 & 5 in the last section ect. ect.) Once you explained it like that, createing a valid master keyfile was no problem. I doubt I would have ever figured out this bit shifting by myself. This was a pretty advanced project and I can see whay goatass didn't want to inflict it on newbies.

I do have some remaining question though. While I have created a valid keyfile and the nag screen is no longer shown ( doing the samething was a 1 byte patch as kayaker mentioned ) I still can't find where the program is reading in the serialnumber, date, ect. I have the type of keyfile "TalkPCR registration key" which is checked at 004ca7bc and the key type "_Master__" which is checked at 004ca844 but that is all it seams to need to bypass the nag screen.

The offsets you posted in your code are familiar:
registered owner = offset 294h in keyfile, ends up = begging of section 3;
serial number = offset 83h in keyfile, ends up = begging of section 1;

and the code from 004ca6e4 to 004ca763 swaps the sections around according to these offsets. I also noticed the calls to 00403c7c. Passed in is an empty mem location and a pointer to different places in the decrypted file (where it is looking for strings like our _Master__). When this function returns the empty mem location now contains a pointer to a copy of a null terminated string pointed at by the other paramater. Along with the strings length and a flag which is set to 1. The offsets it searches are the begging of each section and 80h (middle) of each section.

From this I can figure out where it is looking for the data but not what data it is looking for or where in the program it is reading this (which would deffinatly help figure out what goes where). As I said befor it only seams to check the places for the type of registration and the key type.

Can you help me put this to rest? I have lost enought sleep as it is. Maybe using IDA as you suggested would help but IDA still confuses the hell out of me. While I could have patched this program to run reged in about 5 min. I wouldn't have learned very much doing it. The hours I spent trying to create this keyfile have tought me a lot. Thanks
peace
()whore

Its a while since I looked at this but from memory I think the call to 00403c7c looks at the decrypted key file for a null terminated string. If it finds one it copies a pointer to the string somewhere and then eventually the program uses the string (via the pointer) for whatever. You should look where in the key file the c7c call accesses and enter some dummy data (a string) at this point and see what the help/about box shows, this tells you which place in the key file holds the relavent info for serial number / date etc. If you look at my source code in the other thread you will see where in the key file the relavent data goes (ie Buffer[X + n] where n is the offset in the file). BTW the date is a string that is a number of days from the start date 30/12/99.
Also I think there was a final c7c call but I didn't figure out what it was for. Regardless of what dummy data I entered the prog didn't do anything different.

Thanks again Timmy,

Mission accomplished. I now have a valid keyfile with proper name serial number and date. By placeing dummy strings in my keyfile at the known offsets I found what was being read into which field. For anyone else who has been keeping up with this. The offsets are:

begging section 1= serial number
begging section 2= keytype
begging section 3= registartion name
middle section 1= key file type
middle section 2= date
middle section 3= ???

as you said the date string was in number of days from a certain date. I tried putting in a dd/mm/yy date (trying to ignore what you said and find it out for myself) and found it was only reading the first number of this sequence. To get the date displayed right I needed to put the #349 in this spot.

good project. I hope to see another one soon. Things have been quit here lately, must be the comeing hollidays.
peace
()whore

Glad to be of help

BTW did you see the last c7c call ? I can't figure out what it is for ?

I entered string data and hex values but I did not see any change in the help/about box or anywhere else in the prog. I must admit I didn't trace what accesses the data pointed to by the last c7c call but I suppose it could be something left over from the progs developement stage. After all, the prog is only supposed to work on the comp it is installed on with a key derived from the comps registered owner name (I think - can't remember exactly) and the author did forget to remove his check for the master data in the key file.

Anyway, I'm glad to see that someone else got hooked with this one.