Discussion:
The patch and the no CD crack
(too old to reply)
IAIN SMITH
2004-10-17 16:05:38 UTC
Permalink
I have installed the patch without any problems so far and also put the no
CD patch (file name "nocd2k4patched.zip"). The fs9.exe version no seems
correct at 9.1.0.40901 but is now only 504kb instead of the 1.32Mb of the
file before cracking. Is this correct? Did the security use 816kb of the
file?

Iain
Fred
2004-10-17 16:24:35 UTC
Permalink
Post by IAIN SMITH
I have installed the patch without any problems so far and also put the no
CD patch (file name "nocd2k4patched.zip"). The fs9.exe version no seems
correct at 9.1.0.40901 but is now only 504kb instead of the 1.32Mb of the
file before cracking. Is this correct? Did the security use 816kb of the
file?
Iain
Iain, not sure what does what, but look at this early post from Bill
Post by IAIN SMITH
So it looks like the new NOCD hack is basically the old NOCD hack relinked
to 10 changes. So if you use the new NOCD exe you will most likely see
most of the changes that were coded into the new dll's, however you will
not gain any of the benefits coded into the new fs9.exe. And based on
Oskar's findings I suspect that those 10 relinks have to do with the two
3rd party .dlls and the entry tables to the new MS .dlls haven't changed.
Which makes sense in keeping with the COM contract that was supposed to
eliminate DLL hell.
There is a sure-fire test that will determine whether the "new no-CD
hack" is really 9.1xxxxx...

If Active Camera v2.0 w/ the 9.1 patch applied works, it's the real deal...

If AC v2.0 w/9.1 patch DOESN'T WORK, then it is a fraud.

The reason is simple: the offset addresses that are embedded in the
fs9.exe have changed between v9.0 and v9.1...

The same test will work if you have FSUIPC 3.40 installed. The newest
version of FSUIPC has been modified to access it's data from the new
memory offsets. If the "new no-CD crack" is legitimate, FSUIPC 3.40
won't complain.

AND NOW FOR THE TEST!

It is indeed a WINNER, as it passed both the above tests with flying colors.

Bill
*************

Fred
Henrik Dissing
2004-10-17 17:11:34 UTC
Permalink
Post by IAIN SMITH
I have installed the patch without any problems so far and also put the no
CD patch (file name "nocd2k4patched.zip"). The fs9.exe version no seems
correct at 9.1.0.40901 but is now only 504kb instead of the 1.32Mb of the
file before cracking. Is this correct?
Yes. It was the same with 9.0.
Post by IAIN SMITH
Did the security use 816kb of the file?
Apparently, yes.
--
Best regards,
Henrik Dissing

(e-mail: hendis AT post DOT tele DOT dk)
IAIN SMITH
2004-10-17 19:25:59 UTC
Permalink
Henrik,

Thank you for your reply. Did you look at my other post re anomalies along
the River Thames? Do you see the same or do I have some other problem? :->

Iain
Post by IAIN SMITH
Is this correct?
Yes. It was the same with 9.0.
Post by IAIN SMITH
Did the security use 816kb of the file?
Apparently, yes.
Tom|420
2004-10-19 00:41:51 UTC
Permalink
Post by IAIN SMITH
Henrik,
Thank you for your reply. Did you look at my other post re anomalies along
the River Thames? Do you see the same or do I have some other problem? :->
Iain
Post by IAIN SMITH
Is this correct?
Yes. It was the same with 9.0.
Post by IAIN SMITH
Did the security use 816kb of the file?
Apparently, yes.
I always wondered, as most No-CD exe's are much smaller than original.

At first we would be tempted to believe they actually removed the CD
protection code, but when you think of it it's doubtfull.

A binary EXE file is not just like a text file where you can just delete
a whole, not needed paragraph, and still have a correct, readable text.
An EXE is made of several internal sub-modules. Each of them calls each
other by address, or by an offset of their position relative to the
beginning of the file (incorrect but easier to understand). If you
remove one segment of the file, and moves everything that follows to
fill the gap, you also need to change the addresses everywhere so each
sub-module knows how to call the others at their new location. Feasible,
but a little over-head IMO considering you are saving only 816 KB of
disk space out of a games that uses like 2 GB of space.

What became my theory over the time looking at that issue is that they
might use some kind of EXE compression. This is not used much anymore
because diskspace is no more an issue today, we optimize for speed
rather than space, but some still use it as a protection. Once
compressed and encrypted, other crackers can't see the code and thus
cannot see how they cracked the stuff. After all they are in competition
with each other. Sure they don't make money, but they have a reputation
to maintain amongs them.

Just my 2¢

Tom :)
Carl Frisk
2004-10-19 01:31:30 UTC
Permalink
Actually the exe contains offset tables for the loader and it is a simple matter to relink those. Once the loader has
it in memory everything is relinked to actual memory locations and once the program is running the actual .exe is no
longer used. In common practice anyway.
WinPE files usually don't need the relocation header which they most likely removed, that would cut it down by at least
7% right off the top. They mostly likely compressed it from there.

This is pretty much what you said I'm just clarifying it a little.
--
...Carl Frisk
Anger is a brief madness.
- Horace, 20 B.C.
http://www.carlfrisk.net
Post by Tom|420
Post by IAIN SMITH
Henrik,
Thank you for your reply. Did you look at my other post re anomalies along the River Thames? Do you see the same or
do I have some other problem? :->
Iain
Post by IAIN SMITH
Is this correct?
Yes. It was the same with 9.0.
Post by IAIN SMITH
Did the security use 816kb of the file?
Apparently, yes.
I always wondered, as most No-CD exe's are much smaller than original.
At first we would be tempted to believe they actually removed the CD protection code, but when you think of it it's
doubtfull.
A binary EXE file is not just like a text file where you can just delete a whole, not needed paragraph, and still have
a correct, readable text. An EXE is made of several internal sub-modules. Each of them calls each other by address, or
by an offset of their position relative to the beginning of the file (incorrect but easier to understand). If you
remove one segment of the file, and moves everything that follows to fill the gap, you also need to change the
addresses everywhere so each sub-module knows how to call the others at their new location. Feasible, but a little
over-head IMO considering you are saving only 816 KB of disk space out of a games that uses like 2 GB of space.
What became my theory over the time looking at that issue is that they might use some kind of EXE compression. This is
not used much anymore because diskspace is no more an issue today, we optimize for speed rather than space, but some
still use it as a protection. Once compressed and encrypted, other crackers can't see the code and thus cannot see how
they cracked the stuff. After all they are in competition with each other. Sure they don't make money, but they have a
reputation to maintain amongs them.
Just my 2¢
Tom :)
Continue reading on narkive:
Loading...