Runtime Error R6002 - Floating point not loaded after unpacking
Hi,
I am basically having the same problem with two files protected with PeCompact as referenced in this thread: Quote:
For one of the programs in question, I could get from the peHeader the actual VirtualSize for the Code Section as 16D800 and for the Data Section as 167000. What I need to do is to edit the peHeader correctly to 3 sections (i.e. split the code section into code and data sections) when the program is at the OEP before dumping. I am however having problems modifying the peHeader in Olly correctly before the dump. Then both LordPe or OllyDump still see only the two sections .text and .rsrc. This is the peHeader of one of the programs: Code:
004000F8 50 45 00 00>ASCII "PE" ; PE signature (PE) Thanks TemPoMat PS: I know there are universal Unpackers in the wide like Nacho_dj's Unpacker_PeCompact which successfully unpack this particular file. The resulting size of the file is approx. 1MB larger than my manually unpacked one. This is however not the topic here. I am interested in manually unpacking and properly fixing the unpack file to get raid of the "R6002 floating point error", which according to many sources on the internet is related in this case to the wrong characteristics of the .rdata section, which is totally missing or better to say hidden in the code section. |
Check the __fp math initialization function logic and code like
if (IsSectionReadOnly(".rdata")) ... |
JFYI Nacho_dj's tool will attempt to rebuild the pe section headers with the sections rebuilt. If the file size is larger than your manual unpacked, you probably are not fully unpacked. Maybe you are only at fake oep where the resource section is repaired/remapped after fake oep. Try editing the resources on your manually unpacked file.
For the R6002 error, you have two options. Leave the sections as is and patch the check like Syoma is referring to or rebuild the section headers. If you manually rebuild the sections, plan on spending much time identifying where the sections are mapped and add/modify the section headers; rebuilding the PE map. Once the code and rdata can have separate permissions you can bypass this check without patching. more details here. http://forum.exetools.com/showpost.php?p=79880&postcount=16 There is a patcher by manhunter out there that will find and patch the code check if the section is writeable. Never tested it though. ..http://www.manhunter.ru/underground/65_runtime_error_r6002_floating_point_not_loaded.html btw if rebuilding the sections, might be easier to get the file dumped first then add/modify the sections to the dump. |
On tuts4you at Execryptor topic LCF-AT pointed how to quick bypass this issue.
Other solution. Compress the unpacked file with UPX and it will work. :) |
Later edit.
Here is the link: Quote:
Quote:
|
Quote:
Quote:
Quote:
If I set EAX=1 after the AND EAX,1 instruction at the first hit, the unpacked file runs without the error. All other hits will trigger the R6002 error and some other SEHs with EAX modified to 1. So patching here will have to be thoroughly thought of. Maybe trying to rebuild the peHeader first before dumping might be the most elegant way even though it could be the most time consuming option. |
Second file works with a patch
In the case of the second file, the check is made only once.
The file therefore runs fine with a patch like this without the R6002 error: original code=> Code:
005BDB17 . 8B40 24 MOV EAX,DWORD PTR DS:[EAX+24] Code:
005BDB17 . 8B40 24 MOV EAX,DWORD PTR DS:[EAX+24] |
Allright.
The idea was to do something like: XOR EAX, EAX MOV AL, 1 NOP NOP |
I remember running into a problem with bypassing this before but I don't remember the details. Since that procedure is used for other functions you could try following the return address and nop the jump instead.
Extra bytes 'overlay' might be another reason your file size is smaller than from Nacho_DJ unpacker tool. That tool will not leave a huge amount of extra bytes there and it appends the overlay back to the dump. If you think it's a bug, please PM me a link to the target if its not a problem. You will not see the PE header you modified in memory unless the dumper is set to use PE from memory instead of PE from disk. I always rebuild the PE sections once the file is dumped and dump using the pe from disk option. Since you are playing around with trying to modify the sections prior to dumping, maybe a dumper with more options might be of better use. Try OllyDumpEx. - jack |
Quote:
Packed File size=10.7 MB Manually unpacked size=18.0 MB Size after unpacking with Nacho dj's tool=33.3 MB I am not automatically thinking that it is a bug, as I have not tried to analyse the unpacked files (manual and with Nacho's tool) more closely to figure out if it is a bug or not. I just realize the version I tried (version 1.1) creates relatively larger files after dumping and fixing a packed file than when manually unpacked. I have sent you a PM with some links. Quote:
|
Please could I get a link to both targets via PM? Recently I fixed a bug related to size of dump but tool has not been released yet... Thanks!
Btw, very interesting topic and posts :) Nacho_dj |
@Nacho_dj Tested the new unpacker tool on the targets, all is good again. thx ;)
@TempoMat I followed up on that in PM. Let me know if you still have an issue. I'll try a manual rebuild of the sections later tonight. |
What I have found by using the new version of unpacker is a value in PE header that the tool is not checking, since it is not most used, it is Debug Directory RVA and Size, if you set them to zero in your dump the error won't appear any more... ;)
Another issue to be fixed in a future release :D |
Almost there...
Quote:
I managed to rebuild the PeHeader first before dumping with OllyDumpEx, which is able to read the modified PeHeader successful. I would have been 100% successful if it were not to be some awkward behaviour of ImpRec and Scylla during the fixing of the dumped file. For some unknown reasons both programs just decide to change the characteristics of the .rdata which I had set to 40000040 = INITIALIZED_DATA|READ before the dump to C0000040 = INITIALIZED_DATA|READ|WRITE A fixed PEHeader for the code from the initial post will now like this Code:
00400110 50 45 00 00>ASCII "PE" ; PE signature (PE) Continue... |
...continuation
At first I thought OllyDumpEx was the culprit but after opening all the dumps from OllyDumpEx without fixed IAT in Hiew, it was obvious that the dumps are exactly as wanted at this location (0x254). Any attempt to modify the PeHeader of any of the wrongly fixed files with PeEditors like LordPe or PeTools rendered the resulting files useless. However if I first load any of the fixed files in Olly and modify the characteristic of the second section ".rdata" to 40000040 before executing, the progis run without the R6002 errors. Otherwise not. All other unpacked and fixed files (at least 3 programs I packed with PeCompact v. 3.02.2) with the modification of the PEHeader before dumping run as long as they don't have the floating point checks on the second section. Cheers TempoMat. |
All times are GMT +8. The time now is 07:25. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX