HEy, seems a bit dead lately what do you say we start another project...Or since TalkPCR didnt seem to get anywhere, I think this may be because people are unsure how to proceed? Maybe some moderators/advanced crackers could give some detailed advice to newbies on how to proceed...I know this sounds like "ruining the puzzle", but lets just take this as an "introductory" sort of project into keyfile creating...(Decryption, etc.) Any thoughts would be cool

--ThRaX

Hello thrax,

I second the thought on a new project. How about something from visual basic or an introduction to useing IDA? These would be my suggestions.

about TalkPCR read through the 2 threads there is enough info there to get going on. If you run into any specific problems post them. I will try and help. I am sure Timmy would too, he has been getting me up too speed.

peace
()whore

I have just seen the post from SiR in the Newbies Forum regarding Logomanager. I have had a quick look and it looks like it's worth having a go at. First of all you have to figure out how to get the name/password entry box up (use regmon) and then sort out how your name and email address are manipulated.

The URL is ht*p://www.logomanager.co.uk

Hi Guys,

This one's packed with UPX. The project's not going to get too far without a down 'n dirty unpacking lesson ;-) We weren't supposed to do this, but for lack of a better project...

Get the latest version of Icedump and start it up (put your applicable version of icedump.exe in the SoftIce folder and double click it). SoftIce loader may not break at the start of the unpacking code if you don't.

Fire up LogoManager.exe in SI loader32.exe and you should break at the start of unpacking code at a PUSHAD. A few line below is a JMP. Trace through the JMP and you'll get into these loops you have to get over. You can just pay attention to where the farthest jump would be when you finally get out of the loop and set a breakpoint there, or just keep you finger on F10 and you'll eventually get out.

Easier though is to scroll down the code page a bit and notice a LOOP statement at 478164. The LOOP statement is characteristic with UPX. You can set a BP here to get past all the previous crap. Look further down the code and you notice a POPAD at 4781B7 and a JMP statement immediately after. Again this is characteristic of UPX.

The address pointed to by the JMP statement is the Original Entry Point or OEP of the program. At this point the unpacking is finished and the program is just about to start for real.

The classic Procdump method for dumping is as follows. Many of you already know how to do this, but in case not...

While you are ON the JMP statement, take note of the address and write it down. Type 'a eip' in Softice (Assemble at the address you're on) and enter 'jmp eip'. Now hit enter twice to exit the 'a' command.

You are now in a permanent loop jumping nowhere but to itself. Exit SoftIce at this point with F5. Your cursor will probably be a little sandtimer because of the infinite loop you just created. Open Procdump and in the main Task window right click on the Logomanager process and select Dump(full). Save the dump, then right click on the process again and Kill it.

Now all you need to do is fix the OEP. Open the file you just dumped with Procdumps PE Editor and change the Entry Point to the one in the JMP statement that you wrote down. Note that you must subtract the Image Base of 400000 from this, i.e. the Entry Point for 401234 would be 1234.

That's it. You should now be able to disassemble the file with Wdasm yadda, yadda, yadda.

Hope this helps,

Kayaker

Hi,
I have an easy method to unpack this application
-Run Procdump ->Select unpack button
-select UPX
-chose *exe
-let procdump wait
-push procdump OK button when Logomanager has been started
ready!
happy cracking

meRlin

OK, this isn't a Newbie target

It seems to use something called D-Square Cipher v2.5 (saw a ref. to it) to decrypt your name and s/n (concatenated as a string, no capitals) from the RegistrationKey registry value at location 20h. Minimum length of RegistrationKey is 30h. This is the value MOVed to cl. It then compares each character with your name/sn string as hex, XORed with 55 at 4205B0.

If this passes, then it compares it with your name/sn string as it has been encrypted in WindowData. This is a simple XOR AA encryption. NOTing it will recreate it as the XOR 55 value.

i.e. "k" in hex is 6B. 6B XOR AA = C1. This is stored in WindowData.

6B XOR 55 = 3E. NOT C1 = 3E


:004205A4 mov cl, byte ptr [eax] ; DEcrypted name/sn from RegistrationKey, still partially encrypted
:004205A6 mov dl, byte ptr [eax+edx-000024C8] ; your name/sn as hex. i.e. "k" = 6B
:004205AD xor dl, 55 ; 6B XOR 55 = 3E
:004205B0 cmp dl, cl ; are they equal?
:004205B2 jne 004205C4
:004205B4 test esi, esi ; counter
:004205B6 je 004205C4
:004205B8 mov dl, byte ptr [eax+FFFFDB38] ; name/sn from WindowData. i.e. "k" = C1
:004205BE not dl ; NOT C1 = 3E
:004205C0 cmp dl, cl
:004205C2 je 004205CE

This is repeated verbatim at 3 locations in the program. The easiest solution is to patch all the jumps.

Now there's a problem with this solution. As long as you have the details fairly correct in the Registry key "RegistrationKey" (this found from Regmon), i.e. 30h bytes or more, then you will always be registered as whatever you enter as name and s/n. BUT, the reg box comes up every time.

Maybe a couple of reasonable Tasks for this is to find the 3 comparison routines and patch them (1st one is above), and then try to get rid of the reg box that comes up each time. Maybe figure out how to show your registered name in the About box.

When you create this RegistrationKey value out of thin air, how do you know whether it's supposed to be a String, Binary or DWORD value? Sometimes you can just make a good guess, but if not, the 3rd parameter of RegQueryValueExA will tell you.

LONG RegQueryValueEx(

HKEY hKey, // handle of key to query
LPTSTR lpValueName, // address of name of value to query
LPDWORD lpReserved, // reserved
LPDWORD lpType, // address of buffer for value type
LPBYTE lpData, // address of data buffer
LPDWORD lpcbData // address of data buffer size

i.e.

Public Const REG_SZ = 1 ' Unicode nul terminated string
Public Const REG_EXPAND_SZ = 2 ' Unicode nul terminated string
Public Const REG_BINARY = 3 ' Free form binary
Public Const REG_DWORD_LITTLE_ENDIAN = 4 ' 32-bit number (same as REG_DWORD)


Anybody had any other luck with the encryption process?

Kayaker

Hello,

I am working on this project but have some questions. First I tried to unpack this program manualy like kayaker was explaining. I have done this befor and had no problem stepping through the unpacking code and dumping the decoded file with procdump. I changed the peheader to reflect the new oep. Now this program runs fine but windsm and ida both barf trying to decode it ?!? I tried redoing this a couple of time with no luck. I finaly got a decent disasembly letting procdumb unpack it thought even with this the import table is screwed.

next and more importantly both kayaker and timmy mentioned the RegistrationKey that our program was looking for. I found this but where/how did you find that this key needed to be 30h? I finaly got the dialog box for name and serial number after makeing this key the proper size. Reading the posts it sounds like regmon was reporting this 30h size but I found nothing like that in mine.

finaly to actualy be of some help. The program checks the keycode at three places
004223f3
004225cf
00422758
or roughly there abouts.

As for which type of data to make the RegistrationKey (string,binary,dword) I tried string first and the program didn't like that. Next I tried binary and that made the gods very happy.

I haven't had a lot of time with this one yet but c:0041fefe is the call that reads your dummy registration key. Later there are three compares, cs:0041ff28, cs:0041ff35 and cs:0041ff3e, the last of which is cmp,ecx,30. I have seen the reference to Square Cipher v2.5 but it looks a bit base 64 ish (I could quite easily be wrong).
Look at 6af354 > 01 23 45 67 89 ab cd ef-fe dc ba 98 76 54 32 10 00 00 00 00(and what generates it)
and (I can't remeber where but) the area where 8954jkh89fdhjnh4 etc. are stored (and the next bit of string data). Look up Latin Cipher and Block Cipher then Base 64. THERE ARE URL'S THAT EXPLAIN THIS. I know this is VERY DEEP but usually the author of a program usually is a specialist in what he has written the program for - not cryptography so he is most likely to have used a pre-built cripto routine for his protection. (Unless we are VERY UNLUCKY).
This project definately needs a bit of lateral thinking - don't dive in too deep stepping through hundreds of lines of code at first. See what each register points to before a call and what happens to the data after a call. I have found with this sort of protection that you have to run it many (many, many, many) times before you begin to get a feel for it.
I agree with Kayaker that this is an advanced project but even if it takes a while to sort it (assuming that we do), from what I have seen so far this is going to be a very good learning exercise.
BTW cs:00422618 kills you, so we are interested in whats before this. Also, not every program is keygenable but all should be patchable. I have a feeling that at least this one is registerable with tha data we input as test data (as a keygen could be too involved). Maybe we need to work on the RegistratioKey data and backstep to string values for Username and Email address.
(BTW in the main decryption routine there is a cmp with 3f, is this the maximum RegistrationKey length? - It might not throw up an error in the programs execution but with the RegistrationKey and the references to 8954jkh89fdhjnh4 etc. and the next bit of string data it makes me wonder. I will have another look in my data on Base 64 and see if I can find again the URL to info that led me (blindly) to my conclusions).

Start URL = http://www.io.com/~ritter/GLOSSARY.HTM

This page has some interesting stuff. It is serious and heavy going I know but amongst the interesting lines there is :

"A public code for converting between 6-bit values 0..63 (or 00..3f hex) and text symbols accepted by most computers: "

Also look at the reference to Base64

Sorry - error at the bottom of my last post

It should read - take a look at Mixing Cipher.

Hello Kayaker and Timmy,

I must have been smokeing crack befor. I missed some of the reg checks; and from the looks of it Kayaker did too. If you patch ALL the jumps the program runs like a dream. You get no nag, no repeated dialog box for name, and your name and data appear in the about box. the checks are located at:

00408dab
00408eab
004205ad
004223f3
004225c7
0042275f

remember there are 2 checks at each location. I found all of them by doing a string search in wdasm for "xor dl, 55". I was also thinking of patching [450000] as it seams to be a flag to the program weather it is reged or not.

Now if we want to get into decrypting this algo, I am up for it. But would we learn much in the process?

cheers,
()whore

You're right ()whore, I guess I must've been smoking something missing the rest of those calls. Heh, heh. Yeah, that pretty much takes care of all the checks. You've probably also seen the 6 corresponding calls leading to the decryption key:


* Referenced by a CALL at Addresses:
|:00408D87 , :00408E86 , :00420533 , :00422384 , :0042255C
|:004226FA
|
:004221D0 81ECC0000000 sub esp, 000000C0
:004221D6 8D442478 lea eax, dword ptr [esp+78]
:004221DA 56 push esi
:004221DB 57 push edi
:004221DC 50 push eax
:004221DD E85E630000 call 00428540
:004221E2 6A34 push 00000034
:004221E4 8D8C2488000000 lea ecx, dword ptr [esp+00000088]

* Possible StringData Ref from Data Obj ->"8954jkh89fdhjnh43tkjdsg9lij32qr09ai;r'ar098at4"
->"takjg8"
|
:004221EB 68E0574300 push 004357E0
etc.



The ref in the file is "Square cipher v.2.5 (compiled on Dec 13 2000 23:41:31)..Using assembler core functions". I think I found the latest implementation of it (v 2.7) which uses this exact phrasing at
http://www.esat.kuleuven.ac.be/~rijmen/downloadable/square/Square27.zip

Can one of you C gurus compile this and see what it generates? There was a new Hashing scheme implemented between v2.5 and v2.7, but it would be interesting to see what it does.

Regards,

Kayaker

Good work there boys. I think my brain needs testing though - for some reason I've been trying to work out how the cipher works. The nibbles of the first 20h bytes are interlaced with the nibbles of the second 20h bytes (I think, it looks like the RegistrationKey length should be 3fh bytes long). It is standard block cipher (if you can call it standard). Then this is played with .......... I spent 4 hours figuring the first bit out and now I can't see anymore. There is info in the regkey as to the number of chars in username and password plus god knows what else.
()whore is bang on the mark - the only thing I can see that could be gained from totally reversing the decryption process is that patching is sometimes far better than keygenning (apart from the personal satisfaction).
I have a weak understanding of what is going on but to be honest, I've had enough of this one. It just shows you that you can have a brilliant encryption scheme but in the end a few appropriately placed jmp's can defeat it.

Hello again guys,

Kayaker. I compiled that c program you linked above. Acctualy its 2 different .exe. One just runs some timeing tests on it encryptions techniques and the other out puts some crypto bable to a file. If you want them I will gladly send them on but nothing I would wan't to tangle with.

Lets get another project up. It has been fun working on these as a group. We can help each other out. But first. PLEASE someone tell me how or why you arrived at 30h for the size of the RegistrationKey. Were you getting that by BPXing on RegQuereyValueExa? I just don't see where it was comeing from.

If you want a sugestion for a new project, how about mp3 navigator from http://www.vertexlab.com/mp3nav/
but be warned this is packed (ASpack I believe) and it kills filemon and regmon when it starts up. Oh and it also has a crc check. I have poked around with this one with out getting very far.
peace
()whore

The check (checks - there are a couple) for the size of the regkey are just after cs:41fefe (this call reads the key) - I think it is at cs:41ff3e.

how do you get logomanager to break, ive only been at this for a week, any help please

Hi John,

This may not be the best target to start with, but if I remember correctly you needed to fake a "RegistrationKey" value (minimum length 30h) in the Registry which would then automatically call up a registration box. Definitely an unusual trick. This is (sort of) discussed in the above posts

Kayaker