Help..Anyone know if this is encrypted??

[bunion]

Ive use caspr to unpack a file and it runs great but the code looks funny when disassembled in w32dasm.is it encrypted or mangled and if so any idea by what program....Thanks

funny looking winhex code

:0041ECA0 6E outsb
:0041ECA1 9E sahf
:0041ECA2 F1 BYTE 0f1h
:0041ECA3 81FF81E0FFC4 cmp edi, C4FFE081
:0041ECA9 46 inc esi
:0041ECAA 4B dec ebx
:0041ECAB 57 push edi
:0041ECAC B258 mov dl, 58
:0041ECAE E9896EED95 jmp 962F5B3C
:0041ECB3 45 inc ebp
:0041ECB4 C49E4014FD50 les ebx, dword ptr [esi+50FD1440]
:0041ECBA EE out dx, al
:0041ECBB 00B690BDFEC4 add byte ptr [esi+C4FEBD90], dh
:0041ECC1 EA9655CFFD9B6F jmp 6F9B:FDCF5596
:0041ECC8 C5EA lds ebp, edx
:0041ECCA 12BE7EEA9615 adc bh, byte ptr [esi+1596EA7E]
:0041ECD0 43 inc ebx
:0041ECD1 865500 xchg byte ptr [ebp+00], dl
:0041ECD4 BB691FFF39 mov ebx, 39FF1F69
:0041ECD9 6A3C push 0000003C
:0041ECDB 8DBEB5E3FFC4 lea edi, dword ptr [esi+C4FFE3B5]
:0041ECE1 FD std
:0041ECE2 E36E jcxz 0041ED52
:0041ECE4 C5EA lds ebp, edx
:0041ECE6 9E sahf
:0041ECE7 F8 clc
:0041ECE8 386A0C cmp byte ptr [edx+0C], ch
:0041ECEB 8B7EE1 mov edi, dword ptr [esi-1F]
:0041ECEE 9D popfd
:0041ECEF 380460 cmp byte ptr [eax], al
:0041ECF2 098B7EE19D78 or dword ptr [ebx+789DE17E], ecx
:0041ECF8 3A15680BB050 cmp dl, byte ptr [50B00B68]
:0041ECFE 118B7B0D9445 adc dword ptr [ebx+45940D7B], ecx
:0041ED04 DF BYTE 0dfh
:0041ED05 FE00 inc byte ptr [eax]

paul333

Try to compare this part with original code in original running exe. If you say that file runs great then what's the problem?

[bunion]

I have compared and its not the same.its encrypted with something and if anyone can tell me with what then thats cool...

Its winhex code and its one of my favourite apps...the code above is from a cracked version and id like to see how they did it for future reference

paul333

[JMI]

One of the "secrets of life" in the world of RCE is that encrypted code can't run. The whole purpose of encryption is to prevent people such as this group from looking at it and figuring out what it is all about. Fortunately for us, to run, the code had to be decrypted back into code the CPU can process. The trick is to find out when and where this happens. Does it decrypt only into memory, does it decrypt only a small chunk at a time, does it write to a temp file and operate from there.

One of the main things protectors attempt to do is prevent us from looking at the code while it is running or attempting to run, because if you can look at it while it runs, eventually you can figure out what the heck it is doing to make it difficult for us to understand what's happening.

So the first order of business is to make your debugger work so you can watch the program decrypt itself. If, and when you find out where this is happening, you had capture the "real" code and maybe even put it back together without the encryption. Of course, if the programmer is clever, you won't actually be able to decrypt all, or some important portion of the code without a valid license, but that is another whole field of cryptology.

Regards.

[bunion]

Thanks JMI for shedding some light on the problem with your wisdom...i didnt know it had to be decrypted first so nice one , now i have somewhere to start

paul333

It's probably W32Dasm simplicity fault. If You send me this prog I'll resend it to You with comments.


Greetings.

dxn@wp.pl

[bunion]

Thanks Dynio.I had to use w32dasm POWER to disassemble it..thats the code u see above ..w32dasm VIRGiN (Original) and w32dasm CZ couldnd

I use 3 versions

Email sent

paul333

Ok.

I need this stuff e-mail'ed to me because I suppose You've missed something during dumping. I'll see it anyway.

[bunion]

Lol thats what i mean

What you need sent now??

ive sent the winhex.exe that i unpacked from ASProtect 1.1 brs using Caspr and the example Asprotect ini file found in the Caspr examples folder

i got Caspr from here at Exetools
http://www.exetools.com/files/unpackers/win/caspr1012.zip

Theres a GUI for it
http://www.exetools.com/files/unpackers/win/casprgui.zip

Thats what i used to unpack the cracked Winhex exe file by Eat

wINHEX 10.92 crack by EAT
_http://www.0daycn.net/0daycn.asp?id=vNNGwxwvxdHGoGHoGidcGv&key=scdown
_http://www.0daycn.net/0daycn.asp?id=vNNGwxwvxdHGoGHoGidcGv&key=ltdown
_http://www.0daycn.net/0daycn.asp?id=vNNGwxwvxdHGoGHoGidcGv&key=smdown

If you think ive missed something when unpacking then i used the default settings in the example asprotect ini file..if you know about these settings then maybe if you altered the ini in some small way then might work ..i think the crackr mamgled it before packing it though..thats why i posted the code above in the hope that someone would recognize it in some way..im hoping now that your on it that its just something to do with w32dasm in disassembling it so ill try using pe explorer ida etc see if its better with them

Thanks for helping

paul333

What I meant was only the file You're disassembling here. If it's winhex.exe and You've sent it to me -everything is fine. If I'll receive it I'll check it.

Greetings.

[riddler]

Hi,

Paul, after removing asprotect with caspr, run FileInfo 3.01 on it.

As you wil see it's protected with PEncrypt 4.0b by JunkCode!

regards,

rIDDLER!

Yeah, At offset 54401 You can see the following bytes: 60 E9 DC 05 00. So, You've correctly identified AsProtect (version 1.1 precisely). But... But after dumping the first protector we can see it's still "PeEncrypt'ed" (by JunkCode, ver 4.0 -the latest as I suppose). As You wrote, the exe runs fine but NOTICE IT'S NOT FULLY UNPROTECTED. Well, this is a freaky protection. With XP/NT/2000 You could easily run ANY debuger and the encryption is the simplest I've ever seen... bla bla.... Ok. hope that helped You at least a little bit.

Greetings.

I forgot to mention that this cracked realse of WinHex 10.92 is BAD. No to say fuc*ed. (Just try to run cracked executable on WinXP, and who's using two different protectors(!) for cracked executable??)

[bunion]

Thanks Riddler & Dynio

Ill need to get that File info then as PeID shows nothing after its unpacked with Caspr...at least we are getting there now, nice job!!..

"and who's using two different protectors(!) for cracked executable??)"

Exactly Dynio.not very friendly is it ?...i suppose he might be a wee bit justified in hiding it from Stefan though coz think about it, this is the FIRST time anyones SUCCESSFULLY CRACKED Winhex before!..im still learning but ive been thru Winhex's code zillions of times over the past 2 years i know its hard to find the ivalid user.txt checks..ive found the location no prob but changing things so it works is tricky and ive never succeeded so now u know why i want to "see" the crack

ps..ok he cracked it but as you said its faulty with XP..maybe thats the cracking thats caused that and not packer!

paul333

Paul3333:
Well, I haven't ever tried to crack WinHex, since I'm always getting full relases. If You say it's hard to crack then I'm disappointed...
According to this, author of above mentioned crack should have high knowledge about systems protections and assembler. So, I would pack it with an usual packer or modify it by hand. WHY HE DID IT TWICE?
All what I'm trying to say is: it COULD be a faked relase (stolen). But that's only my private opinion since I'm really disappointed.