![]() |
Unpack mpress 1.2xx
Hi !
someone have info/tool/tutorial/other to unpack/reverse an executable protect with matcode mpress product ? Bye |
mpress doesn't use any tricks to make unpacking hard.
Hence any tutorial about manual unpacking upx also applies to mpress (just use the ESP trick). |
as zementmischer said it is like upx
check this tut on tuts4you PHP Code:
|
4 Attachment(s)
Check this out.
From SunBeam Quote:
|
Hi !
Many thanks to everyone reply me.. I'm a absolute beginner in exewarez , tracing and patching.. My target is this (the Development version..) http://www.gearotic.com/downloads.html Any help is greatly appreciated, and I can learn something .. |
1 Attachment(s)
Here is the OEP.
Just watch the video. |
And here's the unpacked exe:
hxxp://www.mediafire.com/download.php?g30hjuz8jdgkzlc unpacking was a lil' bit harder than expected due to a darn R6002 exception :mad: |
Hi !
WOW !! not one, but 2, SUPER RAPID solutions !! I would give the award ex-aequo to both.. giv and zementmischer many thanks again.. now i can try to "cure" him !! Can I get help if I need it? Bye Axel |
Wow, choosing a target that depends on a digitally signed license is probably the most sophisticated way to start rce'ing ;)
I guess the best way to break its protection would be to generate your own public/private key pair using MS' CSP and replace the public key BLOB inside the exe (resource id 163) with your own one. Use the private key to code a simple keygen (you'll also need it to RE the license file format - but from what I saw the format isn't too complicated) The main advantage of this approach is that you can crack future versions by just replacing its BLOB resource with your own one. You'll quickly find the license handler if you look for references to CryptAcquireContextW, CryptImportKey and CryptDecrypt. |
Quote:
..http://forum.tuts4you.com/topic/29562-i-have-a-rogue-program-i-cant-figure-out-what-it-is/ Your dumps will not run without some tweaking because all the code sections are located in .mpress1 unpacked. This causes an r6002 error msg for your dumps. You must patch the header check for .rdata or remap/rebuild the pe header mpress sections back .text .rdata .data. If you can't get access to the post let me know. - jack |
1 Attachment(s)
@axl936: Here's a link to an already patched version (proof-of-concept).
I did create my own RSA key pair, replaced the private key of the target with my own one and used my public key to make a valid license. Btw. my first guess regarding DSA was a lil' bit wrong - the target actually uses an RSA cipher with 1024bit. @RedBlkJck: I opted for the first method - splitting sections and rebuilding the PE image is a far more time consuming task than setting a hwbp at the section flags inside the PE header :D |
@zementmischer I hear ya. I spent a little time looking to rebuild it. The packer code start point has been the end of the text section in my testing with other mpress files. IE betwen the 2 JMPs routines, packer code. I was looking for some patterns to identify it easier. Sometimes there is a pointer of the amount of bytes to the next section from the .text section. mpress2 is all packer code can be removed. You can easily see where the resource mapping was moved from the original code. But it isn't as convenient as UPX including a copy of the original PE section. Anyway here is my mapping of my dump for this target if you are interested.
Name VirtSize VirtAddr SizeRaw PtrRaw Flags Pointing Directories ------------------------------------------------------------------------------------------- .text 001E3000h 00401000h 001E2200h 00000200h E00000E0h .rdata 00063000h 005E4000h 00062000h 001E2400h 40000040h Delay Import Descriptor .data 00009000h 00647000h 00009000h 00244400h C0000040h .rsrc 005A0000h 00650000h 0059F200h 0024D400h C0000040h Resource Table .ImpFix 00005000h 00BF0000h 00004400h 007EC600h C0000040h Import Table |
Quote:
effectively i can't access to the post.. @zementmischer Thanks for the work done, but I'd like to understand how you did it .. Can you explain me ? |
I thought to make a loader....but your sollution was excelent.
|
If the application is written on .NET, you can use de4dot version 1.9.0 to deobfuscate.
|
1 Attachment(s)
@axl936
AFAIK registration at tuts4you is open. Unpacking different targets are well covered there. The post was a little long with having to solve a problem with olly setup, etc. Here is a shortened version of what I posted with some selective editing. mpress is easy to unpack as there is very little to prevent unpacking. There is a generic pattern that can be used RET JMP, step, POPAD JMP = OEP There are olly scripts that will do this. Load the packed file in Olly. Scroll down in Olly until the code goes to all null bytes, scroll back up and you will see RET followed by JMP C3E9. Break on JMP and run. Step in after break. Scroll down in Olly again looking for the POPAD followed by JMP 61E9. Break on JMP and run. The JMP destination is your OEP. Step once and you are at OEP. Dump and rebuild your taget. It should run but this app is compiled with MS VC++ and uses floating point literal constants. Your dump will have a R6002 error msg. The problem of R6002 error can be seen across other packers also. If UPX was used to pack the same file and you dumped it, the same error would occur in your dump. Just like Mpress your dump would have all the sections placed into the first section .UPX0 If you used UPX -d flag or a program like PE Explorer the unpacked UPX file would not have the error. This is because a copy of the original PE would be used to rebuild it back to the origial sections. Mpress doesn't include this so you would have to rebuild the original sections manualy. This blog posting covers the problem of MSVC++ floating point that packers will have to deal with. It has an example not packed to demostrate the problem and how to track it. Read this to get an understanding of the R6002. http://nezumi-lab.org/blog/?p=73 Ghandi posted some more indepth details on the tuts4you thread with other code list examples. I'm only quoting a small portion of ghandi's post. Quote Ghandi But it is sufficient to say that the following check is performed and if the call to IsNonWiteableInCurrentImage returns FALSE, it will throw that error. The fix is simple when the sections haven't been mangled, just change the permissions of '.rdata' to read only and if the sections have been mangled you can always patch the code itself to bypass this check. PHP Code:
Mpress takes all the sections and places them into one, the resource mappings are kept in their own section but the raw resources are placed into mpress1 section. .mpress2 section is packer code. If you change permissions to read only on .mpress1 of your dump, you are changing it for all the original sections and the app will crash with different error. The packer is dealing with the same problem of the rdata section, this is why the app doesn't crash while packed. Basically a section of the file PE header will be read and checked for what permission attributes it has. It does not verify the permissions of the section as it is actually loaded in memory, just the PE. If the attributes of the section is read only then EAX = 00000001 on the RET to the call. When TEST EAX, EAX is performed, the next conditional jump JE SHORT will not jump. If EAX = 00000000 JE SHORT will JMP causing the R6002 msg. You can see this in the same code above from Ghandi @013E30D6. In testing with other examples of this, the result is the same. So how you patch it is up to you. Just so the call causing the error msg is not the next instruction at JE SHORT. Using the packed demo and the break point method from the blog, I added some observation notes. Follow the same method with your Gearotic target and you will come to the same solution. PHP Code:
Credits to Ghandi (ARTeam) and KPNC blog post explaining the R6002 error. |
@axl936: And once you have managed to unpack it you should take a look at my 'quick and dirty' patcher/keyfilemaker implementation. I've successfully tested the patcher with both versions (stable and development). The following steps are performed:
The main advantage of this procedure is that it should also work with future versions and different keys (as long as 1024bit RSA keys are used and the blob is stored as "BIN" resource). But you can easily modify the sources by redefining KEYLENGTH and BLOBRSRC - just in case they change the key size or the resource location. Code:
#include <windows.h> |
Thanks for the wonderful explanation, very complete and accurate!
Now I will try to repeat the steps as indicated from scratch and I want to see if I can do it! I have effectively chosen a bone too hard for me to start learn unpacking/patching ! Luckily for me you know a lot about this subject, and you've done all the work in a very short time! A good lesson in rce'ing !! Thanks.. |
Quote:
Quote:
|
| All times are GMT +8. The time now is 20:58. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2026, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX