Page 1 of 1

cRO situation

Posted: 21 Mar 2013, 22:25
by DrKN
hello,

The cRO is relaunched last month and its currently in EP14.1 (The first EP of renewal)
However there is a big problem.
As they have a update every week and they reshuffle the packet headers every time it patched (now reshuffled 2 times)
I think the best way for supporting cRO is working on the client side
will it be possible to generate a signature list of every header assembly code?
so it can detect it and regenerate a redirect header code putting in cRO.pm

Re: cRO situation

Posted: 21 Mar 2013, 22:48
by kLabMouse
DrKN wrote:hello,

The cRO is relaunched last month and its currently in EP14.1 (The first EP of renewal)
However there is a big problem.
As they have a update every week and they reshuffle the packet headers every time it patched (now reshuffled 2 times)
I think the best way for supporting cRO is working on the client side
will it be possible to generate a signature list of every header assembly code?
so it can detect it and regenerate a redirect header code putting in cRO.pm
Why not like in bRO ?
There is "Detected" list of packets "normal" ID and "changed" ID that is generated out from client binary.

Re: cRO situation

Posted: 22 Mar 2013, 21:23
by DrKN
oh really?
is that the file generated by Ever Rox's tool?

Re: cRO situation

Posted: 23 Mar 2013, 22:53
by DrKN
The situation changed.
Now cRO is using theMida for exe protection
It is not letting OllyDBG attaching or opening the ragexe
If we need to support it we need to unpack this first but this is known as the hardest kernel exe shield

Re: cRO situation

Posted: 24 Mar 2013, 03:08
by kLabMouse
DrKN wrote:The situation changed.
Now cRO is using theMida for exe protection
It is not letting OllyDBG attaching or opening the ragexe
If we need to support it we need to unpack this first but this is known as the hardest kernel exe shield
Themida does not protect from memory dump. That's all that's needed. Unless they Virtualized some protection functions.