View Full Version : Armadillo problem
Hero
May 14th, 2007, 01:11
Hi all
I tried on an armadillo project for my first one,and I thought that I were be able to successfully unpack it(a simple one without any special protection,only need patching magical jump for IAT).
But when I tried unpacked app,it starts normally on the begining,but after a little while,it makes an in code exception:
Unable to load floating point library.
and comes out of application.
what can cause this problem?remember that program starts normally and then it crashs,and this has a deferent meaning from crashing from start...
Regards
dELTA
May 14th, 2007, 01:57
Is it your own target, or someone else's? If it's not yours (i.e. you don't really know what's going on inside it), they might have added some custom delayed unpacking-detection code in it, causing this problem.
Hero
May 14th, 2007, 03:13
it is not mu own target and it has a 2 layer protection.
the first one is the layer that I unpacked,and the second one is
hackshield pro(ineteresting online protection -see details) :
http://www.hackshields.com/product.html
My main question is that is it possible that do this in arma itself?
or it is
surely from the second layer protection or an internal tamper detection?
Regards
Posted on another forum a while ago, sounds like the same problem.
Quote:
i had problems with it, first media player classic cant be packed with nspack or we get this error, only pecompact can pack it. now i try to unpack ######## pro new. dumped fixed iat, its debug blocker and nanos. arminline 0.93 can do them because it doesnt grey out repair button:P so we need to use 0.71
we run it and we get float not loaded
what the hell is that, do we live in 1990 and everybody have 386, because since 486 fpu is in cpu. so what is that crap. due that we cant run unpacked app. when we patch it every float to
string will give hash, and insted of 0.1 we will have 4 ascii chars. thats really ****ing me
off.
does someone knows how to fix it. why it executes fpu instructions but crashes on convert of float, maybe someone knows solutions for it
|
Quote:
thx to upx 2.0 src i find out it why it doesnt run.
if (use_dep_hack)
{
// This works around a "protection" introduced in MSVCRT80, which
// works like this:
// When the compiler detects that it would link in some code from its
// C runtime library which references some data in a read only
// section then it compiles in a runtime check whether that data is
// still in a read only section by looking at the pe header of the
// file. If this check fails the runtime does "interesting" things
// like not running the floating point initialization code - the result
// is an R6002 runtime error.
// These supposed to be read only addresses are covered by the sections
// UPX0 & UPX1 in the compressed files, so we have to patch the PE header
// in the memory. And the page on which the PE header is stored is read
// only so we must make it rw, fix the flags (i.e. clear
// PEFL_WRITE of osection[x].flags), and make it ro again.
simple way i just used cfe to change rdata from rw c0000040 to r only 40000040 and dump works,
|
dELTA
May 14th, 2007, 03:28
Most packers (including Arma I'm almost sure) offer ways for the developer to detect from within his own code if the packer has been removed, and in that case act in whatever way he likes (good for delayed mechanisms, just like this one).
The most common case is one or more functions like "IsPackerStillThere()" which will return a boolean and can be called from within the developer's source code itself.
So, the answer to your question is yes.
Hero
May 14th, 2007, 04:29
Quote:
[Originally Posted by Js;65667]Posted on another forum a while ago, sounds like the same problem. |
Hi Js
Thanks for this comment,I will try to check it.Perhaps it corrects my work.
Quote:
[Originally Posted by dELTA]Most packers (including Arma I'm almost sure) offer ways for the developer to detect from within his own code if the packer has been removed |
In armadillo help,It says the only way that application can intract with its armadillo shell is using ArmAccess.dll and they can't provide a way using linkable libraries.
Then if there is no ArmAccess.dll,there there is no checking.
Regards
naides
May 14th, 2007, 06:04
There is a long but sure way to figure this out.
Tracing. . .
Locate the code that generates the float library exception learn its behavior, particularly its call sequence:
One way to do it is to look a t the call stack when the exception is generated. place bp near the culprit instruction (Usually a call ) ad figure out in the call stack who called this call, and who call the caller. About 4 or 5 layers of call should suffice.
Now load and run the original, packed version of the proggy, placing bp on the calls that take you to the "sick" exception generating code.
Watch the change in code behavior and figure out why it happened
Hero
May 14th, 2007, 14:58
Quote:
[Originally Posted by Js;65667]Posted on another forum a while ago, sounds like the same problem. |
I checked it,and the problem was not from write permission.
I should check other things...
Regards
Hero
May 18th, 2007, 05:34
Hi all
Because I want to find this unpackings problem,I need to debug it...
First I had some problems with starting debugging it,because it is loading using a Loader and need some work to debug the main program from start.
But now that I am be able to start debugging it,I got new problem:
Program hangs in debugger...
It seems HackShield service in second layer detects my olly(a repaired olly + Hide debugger) and I can't continue debugging.
I want to know Is there any way for detecting olly,even it is a repaied one and using Hide debugger?
Is it possible that HackShield detects debugger because it is using a service for its engine?
Regards
naides
May 18th, 2007, 06:16
Without going into much detail I can assure you there is always another way to detect Olly, which is not contained in the Hide debugger anti-anti debugger detection.
Download fresh copies of Olly and apply different anti anti plug-ins until hopefully you find one that your app does not detect.
Also consider debugging it under SoftIce or Syser and see if you have better luck.
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.