Well thanx all for your help I did a search of the MB for commview and I finally got it unpacked and working, but still some probs!


The program runs just fine on its own, it doesn't "appear" to have any size checks or the like. It comes up and functions normal. But as soon as you try to patch ANY of its bytes on disk it crashes like a mother, spitting out delphi exceptions..I beleive this is written in delphi isn't it? DeDe won't decompile it at all.

It almost seems like there is another layer of protection or something. I can't even use a memory loader like I did for BPFTP Server. It still creates exceptions. What it almost looks like is that when it detects a change in its code, (or "critical" sections of code, like that jmp the fixes the half the packets bug ), that it then tries to call asprotect or something.

I kinda know when asprotect gets called because on my win98 machine it comes up as a 084:00000000 address where the crash happened. Yep obscure as hell. ANyway I've got to get some sleep tonite so gotta wait until tomm. to try fixing the bugs.

Thanks though for your knowledge all out there, I've never been able to dump this program before.

OH WELL OOPS and another thing, yep it crashes after a min or so with an error 212. I beleive that is a delphi memory access error. Looks like there are some good trix in this build. No wonder they don't need a size check. Time to find that damn timer....and possibly some weird crc check of some sort. Well at least it runs :P for like 40 seconds. lol.

-nt20

CommView uses the hash of its partial memory image to decrypt some resource data. There is a long hash-and-decrypt loop in its startup code. So if you press Ctrl+D before its main window appears, you may see this loop in SoftICE. It's a reasonable way to kick it away: After the decryption, copy & paste the decrypted data to dumped exe and skip the decrypt loop(+SplAj told me about this long time ago. we can also use Self-Modified Code to patch it). Now the question is: what's the begin and end of the decryption?

Hi People:

I've played around with CommView 3.3 (as you might've probably noticed) and was able to successfully unpack and patch the proggie.

Tesla: If you patch the file, you'll get into CRC/Hash check loops. Do this. Write a small loader. However, this loader is not trivial It seems if you CreateProcess suspended and patch the memory and then ResumeProcess, blah hash check again wtf?

So, we do this, CreateProcess normal, Sleep for like 10 secs. (this was on my machine) and then patch. Bingo!!! Works like clock-work. What is happening here is what Solomon said, there is a "lengthy" hash check loop. So, we'll have to wait for it to end.

Hey, folks btw, even after patching this, I don't think CV runs fine. I mean, it seems to be dropping packets on my machine and this happens only arbitrarily. If this is really a *trick*, it is a pretty tough one to crack, I think. You can imagine this: you can never predict what kind of packets are being dropped if the proggie detects if it is unpacked . So, now there is a question of reliability of the network monitor itself after unpacking.

Oops I think I'm saying too much. If CV guys hear this, they might incorporate this in the next version

Signed,
-- FoxThree

PS: If you guys need the code for the loader, PM me. It's nothing great, though !

hehe, brilliant ideaReGet's author can also destroy some random bytes of the downloaded files if it thinks it's cracked. But if he does so, ppl may never use it again

Thanx guys, I'll try some of those suggestions.

Still two questions rolling around in my head - number one, I tried to set a BPM on the code I changed, but I never seemed to land there, to access it - hmm wonder why. I thought I would land in the crap hash loop just like in Spl/\g's tutes. But no break. nothing. If MUST read it tho, or it wouldn't know it changed. Maybe I need another type of bpx (like bpr or something)

And also, why doesn't it work if I do an in memory patch with SI? ok, the first thing I am trying to kill of course is the "half the packets" bug. Am I killing this correct? Setting the je at 0060FADD to jmp always? It's the only reference I saw so far to the string, although of course there could be another that is encrypted. SO I open up SI, and edit the bytes right there in mem where I want, after CV has started. If a loader worx, how come I dont lol :>

It doesn't appear to change it. wth? Looks like I still need to learn a few things.


-nt20

Well solomon, did like you said and sure enough huge ugly loop taking place. I wonder if this is why commview loads so damn slow? That slow loading really irritates the crap out of me. That's the annoying part about protections, like import table mucking. It slows the app to a damn crawl. You should see how much faster FlashMX is now after I unwrapped it from the crapware Vbox 4.6.

But anyway, I digress. Here is part of the code where this crap happens:

015F:0061DE9F 8BD7 MOV EDX,EDI
015F:0061DEA1 8D4314 LEA EAX,[EBX+14]
015F:0061DEA4 E8BF000000 CALL 0061DF68
015F:0061DEA9 83C740 ADD EDI,40
015F:0061DEAC 83EE40 SUB ESI,40
015F:0061DEAF 83FE40 CMP ESI,40
015F:0061DEB2 73EB JAE 0061DE9F

This little loop loops for a while it seems....

And here is what happens inside of that CALL 0061DF68 :

015F:0061DF68 53 PUSH EBX
015F:0061DF69 56 PUSH ESI
015F:0061DF6A 57 PUSH EDI
015F:0061DF6B 55 PUSH EBP
015F:0061DF6C 8BEA MOV EBP,EDX
015F:0061DF6E 50 PUSH EAX
015F:0061DF6F 8B500C MOV EDX,[EAX+0C]
015F:0061DF72 8B4808 MOV ECX,[EAX+08]
015F:0061DF75 8B5804 MOV EBX,[EAX+04]
015F:0061DF78 8B00 MOV EAX,[EAX]
015F:0061DF7A 034500 ADD EAX,[EBP+00]
015F:0061DF7D 0578A46AD7 ADD EAX,D76AA478
015F:0061DF82 8BF3 MOV ESI,EBX
015F:0061DF84 F7D6 NOT ESI
015F:0061DF86 23F2 AND ESI,EDX
015F:0061DF88 8BF9 MOV EDI,ECX
015F:0061DF8A 23FB AND EDI,EBX
015F:0061DF8C 0BF7 OR ESI,EDI
015F:0061DF8E 03C6 ADD EAX,ESI
015F:0061DF90 C1C007 ROL EAX,07
015F:0061DF93 03C3 ADD EAX,EBX
015F:0061DF95 035504 ADD EDX,[EBP+04]
015F:0061DF98 81C256B7C7E8 ADD EDX,E8C7B756
015F:0061DF9E 8BF0 MOV ESI,EAX
015F:0061DFA0 F7D6 NOT ESI

Just a bunch of bitwise operations just like mike describes for crypto You can see the constants there, this goes on for a while.

This little loop takes 40 byte chunks. But I haven't found where the data goes that is modified blah blah. Its 3 in the morn, I just got up for a small snack and figured I'd check in.

-nt20

Hi Tesla/crew:

This is getting to you right ? As +SplAj had once on his posting
"There is a very fine difference between a hobby and mental illness" he he I guess this applies a lot to reversing

And Solomon, don't say that out too loud, 'cos Reget's Author might implement such a thing if the proggie is unpacked...

Signed,
-- FoxThree

played a while with this baby. Here is what I got(v3.3 build 205):


61DE00 MD5Init
61DE30 MD5Update
61DF68 MD5Transform(0x40 bytes per block)
61DED0 MD5Final

Just setting a breakpoint at MD5Update(context, input, inputLen), I got the base address and length of input data. Base address is always 401000, and the max length is 21F800, so if we directly modify the data between RVA 01000~220800 before the above loop, it will crash. Have to use SMC to do this.

Also just to let you know this MD5 function is called even during runtime, for example, if you've done some mem patching, just try and open the packet log.

*BOOM*

Of course it won't crash the app, the exception handler catches it at least.

-nt20

It also puts file size into 62E570, but ddon't know whether it's checked. There are also some interesting names like "IsDebuggerpresent", "ZwSetInformationThread" etc.

Yeah that IsDebuggerPresent call is very popular...I even saw it in a screensaver once! And they always load it dynamically.

I don't know if I am up to resolving this encrypted crap yet. If I could just find where it stores the calculated hash value, I'd be home free, like in Spl/\j's tutorial for 3.1. But I have this feeling the author changed things a bit since then..but if not I could just redirect the created hash value to someplace else and then just hard code the correct value like in the tute. I like Spl/\j's way of thinking. You just feed the program what it wants. In fact I think that is better than heavily forcing the program, it's a cleaner patch that way. And you can never tell what other parts of the program might use that data.

Oh and I suppose you could see if the filesize is ever used by simply putting a BPM on it. It might be used, because after like 90 seconds I get an error message (error 212, this is a Delphi memory access error (invalid memory)). BTW have you ever used DeDe for delphi decompilation? It works very well on a dump. Keeps you in the HLL code so you don't get lost in Delphi library code that has nothing to do with the operation.

I am still working to get better at reading assembly in SI. I know asm, but reading thru an active routine requires a lot of concentration and sometimes my brain is just tired and I get distracted easy I guess . Maybe I should turn off the tv lol

I will say I have gotten a lot better even in the last few days even thanx to all you guys THANKS to Spl/\j, foxthree, binh81, and Solomon !


-nt20

yes I set a BPM but even after several minutes it's not triggered. Maybe it clears debug registers before check or maybe it checks file size at a certain time. I even search all references to this addr in the deadlist but no luck.

I have patched the CRC check and keyfile check, got a registered ver. There is no err msg box even after 15 minutes According to someone, the keyfile uses ECC.

Solomon, would you care to share with me how you worked around the hash valued crc check stuff? I really need some direction..

In other words, to get around the program checking its own code, which keeps me from changing anything.

-nt20

actually nothing new.

I just hard-coded the 512-byte MD5 hash into the unpacked exe to bypass the CRC check . Now each time it will fetch 16 bytes from this hash table, instead of calculating it out. This will also increase its launching speed

Er... excuse me Solomon, but 512-byte MD5 hash? I thought MD5 always produced 128-bit hash values (128bits == 16 bytes)? Is it a custom Hash Algorithm or MD5?

Signed,
-- FoxThree

Ok solomon, that is what I was going to do too, like in Spl/\j's tutorial, but what I am wondering is if you could tell me (ha ha lol I am lazy today) where did you find the hash value being stored? I tryed tracing thru the code but I got bored and kinda lost. *sigh*

So was it still using the same 16 byte trick as in the 3.1 tutorial?

Please excuse my slackness, my brain is kinda fried today, I did like 4 different programs over the last week lol.

Thank you

-nt20

Hi

FoxThree: sure u are correct. The loop counter is 0x20, so total = 16 * 0x20 = 512 bytes


Just set a "BPM X" exactly after MD5Final( ), you will see 4 MOVSD instructions. That's it.

BTW: I did not read +SplAj's tut about the old versions coz I can remember that it was full of unreadable characters to me when I opened it. Actually he already told me about it in private message(thx for this and much more )

Thanks solomon, I will try that.

Previously I had stepped through 3 different locations of movsd's. The problem was they all seemed to be called a lot, like if I put a bpx on it, it kept doing it as tho it was looping and not done yet. But Now I realize it could be that it was just calculating for each resource it was loading, so that might have been why. I DID try and watch the movsd's before, and I did write down where they went, but it never looked like it was actually done to me (cause it kept looping again).

Maybe I will look at this target again. (I already have a *working* version from somewhere else)

-nt20

Ok solomon I think I need more help please.

I do recognize now that yes the loop goes thru 20 times, hence the 512 bytes. But I still can't for the life of me see where these bytes go ! I mean, I put a bpx after md5 finalize, and ok, yes, there are 16 bytes getting transferred, but they are way up in the 01D*** range of mem. No where in the program that I could see yet (in the file). Of course there could be a pointer somewhere, I haven't looked for that yet, but I am thinking that the whole 512 bytes must be built into a table somewhere ? becaue the checking goes all the way up thru 00620800 if I calculated it correct, so this would include the code we are trying to step thru. Just stepping thru it corrupts it (because there is a bpx set).

So maybe if you could give me just a little more detail, like a super tiny mini walkthru..this is the toughest target I've ever done yet. I actually already downloaded Tamosoft's other program, the data protection one, and unpacked and patched it just fine. But it doesn't have this hella md5 check.

Im sure if I stare at the code long enuf I'll get it, but I think I may need a few more clues yet

Thanks for any help I really appreciate it.

-nt20

well this prog often uses __fastcall calling convention, please see the the following comments. At CS:0061EBA0 the value of ECX is always the same, so there is no consecutive 512-byte table, only 16-byte sequence. I suggest grabbing MD5 C source from google and comparing it with the corresponding ASM code.

Can anyone read the tut by +SplAj? URL is
h**p://www.woodmann.net/forum/attachment.php?s=&postid=10171

I'm using IE 6.0. It shows nothing when I open this html file, and full of unreadable chars when I select "view source" for this file.

That's because the source is JAVASCRIPT, the most powerful EVIL known to MANKIND.

Spl/\j, I was starting to like you, but now I don't know anymore...unless this got converted to script some other way

JAVASCRIPT IS EVIL

Here is the clean version.

In this version of CV is appears there is only one Hash calculated....unlike the 20 times loop in the new CV. Plus it puts it someplace easy to edit in the dump later..

-nt20

I'll look thru that C code , already looked thru some of it, it does look like what the prog is doing.

SO basically what i need to do then is get all 20 hash values, good ones, paste them in my dump somewhere, and then modify the md5 finalize routine to return these values one at a time instead of calc. it.

So I will need to modify the called routine at 61EBA8 to walk thru my table in 16 byte steps and just stick the value into the location the ecx got in with [esp-1C].

Sound about right?

The trouble then for me is getting good 16 byte hashes, I mean in you have a bpx set then the hash is screwed...

An alternate method would be to just write down the start and len each time and then use an external prog to calc the md5's (like hex workshop 3.1..) Or am I making this harder than it has to be ? (wouldn't be surprised )

-nt20

Just before the hash loop, we can set any BPX(coz CV clears debug registers).
But we just set "BPM X" during this loop, not "BPX"

Not terribly pertainent to the overall topic but I had no problem with the link to +Spl/\j's tut. With IE 5.5 it immediately opened a save box and downloaded without problem. I've been playing with my 98se system files, attempting to get ready to make a dual boot box with 98se and Win2K and when I attempted to open the zip file it told me that I needed to download vector graphic rendering (again) to properly view the tut. Solomon you might see if you have updated this subfeature with IE6, as that might be the problem.

Just to get further "off topic", don't believe them when they say you can "uninstall" IE 6. I installed it and it interferred with several of my programs and I had to go through the process of removing all of its elements and going back to IE 5.5. Managed to keep the one truely good "new" feature which is the new cookie control "privacy" tab in the internet options control panel which allows you to block all cookies of a specific site and save a listing of these excluded site. The old method, in IE 5+, required you to constantly keep pressing the "no" button when the "privacy alert" box appeared. With the correct dll's from IE6 you can now mark all cookies from a site or url as excluded once and forget having to deal with them again.

Regards,

well JMI, when I open the html in that zip file, IE 6.0 reports in its status line that there is error in that html file, so it displays nothing.

And what do you mean by "vector graphic rendering subfeature"? I never heard this before

Solomon -

If you go to the windows update page, listed under the "Tools" menu, and then click on product update, one of the choices should be "vector graphics rendering" which has something to do with graphics and movement on web pages afaik. When I rebuild my IE to 5.5 this element was missing and when I attempted to open the tut it advised me that I needed "vector graphics rendering" to properly view the tut. Just thought it might be your problem with it because my older copy had worked until I messed with the IE6 update and then removed most of it. Hope this helps. It could also be one of the security settings in IE6.

Regards.