I don't know what your idea of an "ordinary hacker" of today is, hutch.
But the general level has increased quite a bit. True, there's a hell of
a lot more clueless wannabes that'll never be able to do anything. But
there's a lot more "intermediates", and there's a lot more free knowledge
around these days... CRC check (or even better, hashing) is okay, but
unless you do something clever with it, it shouldn't take more than a
few minutes to detect & disable.


So the question is...
Now that the "bar" has been raised... what do we do?

I think this area is only briefly talked about and often of most use to *any* software programmer (and just because I write only freeware programs -- usually with source included) doesn't mean this information is less valuable to me...

The problem is that this thread has more turned into a philosopical arguement of whether "we" as software programmers can use tricks that people with destructive tendicies use?

Much like all good points this thread will fall to the way side and be buried under such thread of "help me convert this C to asm", "Seriously I need this converted" and "I'm a newbie can you help me convert this C to assembly"... All intresting topics but not useful to the community as a whole...

This, I believe, is something that is important...

Sliver

"Sliver" or "_Sliver_" on mirc

ps. If this does go away -- fodder I would appreciate any help you had to offer
Posted on 2002-01-27 14:05:48 by Sliver
f0dder,

Most who have written protection systems of one type or another have a pretty good idea of what it takes to break them but it is also well known that the real talent in protection systems have retired so ther majority of what is left over have little chance of breaking a reasonable system.

In particular, an EXE file compressed with UPX 0.84 or earlier has no automatic unpacker and just as a matter of fact, the compressor throws away a lot of information needed for the reconstruction back to an unpacked EXE file.

A memory dump and a set of fixups will get it to run again but nothing on the planet will recompress it again so it is very easy to write a length checked and CRC checked EXE file based on the compressed length after UPX has compressed it that will notv run if either is incorrect.

You appear to have confused the later UPX versions with the old ones that are constructed differently and many of the simpler ones that have automatic unpackers available to access them again.

To get a file to run on your own machine is a long way from being able to make a crack for it that will work on the original. You may in fact enjoy the internal structure of an EXE file packed with UPX 0.84, you get the original code to play with but the EXE file still runs from compressed code in another section so there is a lot more to do than just unpack it to reconstruct it back to original.

I know of a few guys who could have done the work but they are less than interested in hacking someones programs to get the functionality out of it. I used to follow the old UPX forum and while there were a number of people who postulated the view that if it runs it can be broken but with the format of UPX 0.84 and earlier, no-one ever produced a program that could do it, procdump and all so its a case of when the flag drops, the bullsh*t stops, all I ever heard was bullsh*t. :tongue:

The general drift is that something is better than nothing when it comes to protection systems as the general level of talent in the cracking scene is so poor these days that there is little risk of breaking anything stronger than a kiddies version anyway.

With an Elmer Fudd accent, "HAY man, I am a quacker, waddavyogottadotocrackthisfile, Quack Quack Quack."

Daffy Duck, "Well dude, you may have to do something like learn to program and how to read assembler."

Elmer, "Assembler, whats that ? I thought all you had to do was set a BPX on SetWindowText, twiddle it a little and you then become a l3et0 h1gH f3llut1n cr4Ck3r. I mean HAY man, I can count in HEX, 1h + 2h + 3h = 6h. R34lLy le3t hUh."

Daffy, "Well dude, it ain't that easy, you have to learn programming, how to read and write assembler, how to trace code in a debugger, understand operating system code, a range of different C runtime libraries, VB pcode construction, how to count on more than 10 fingers and all sorts of other complicated things."

Elmer, "No way, if I had to do all of that I would write the program myself."

Daffy, "Yeah, Right, Muhahahaha."

Regards,

hutch@movsd.com
Posted on 2002-01-27 18:38:47 by hutch--

In particular, an EXE file compressed with UPX 0.84 or earlier has
no automatic unpacker and just as a matter of fact, the compressor
throws away a lot of information needed for the reconstruction back
to an unpacked EXE file.


Sure, there's no "Upx -d" for 0.84 and earlier. But it's still piece
of cake to get a dumped exe that can be both analyzed *and* run.
To verify this, I dug out an old backup CD, installed upx 0.84,
compressed a test file, and did a manual OEP-trace and dump. The
process of tracing and dumping took less than five minutes. I had to
set PEHdr.entry manually (big surprise since I did a manual dump),
and after that the executable ran just as it was supposed to. Sure,
it's not back in original state, and it has some UPX junk left, but
thing is, the exe runs fine.

And it's not like it's rocket science to unpack a file. Especially
not when there's NO tricks whatsoever. And even tricky stuff like
asprotect and telock and safedisc/securom gets unpacked...


To get a file to run on your own machine is a long way from being able
to make a crack for it that will work on the original.
You may in fact enjoy the internal structure of an EXE file packed with
UPX 0.84, you get the original code to play with but the EXE file still
runs from compressed code in another section so there is a lot more to
do than just unpack it to reconstruct it back to original.

Why would you need to get back the original? As for crack, people just
release the dumped/fixed exe. This is being done for asprotect, safedisc,
and whatever. No big deal really.


The general drift is that something is better than nothing when it
comes to protection systems as the general level of talent in the cracking
scene is so poor these days that there is little risk of breaking anything
stronger than a kiddies version anyway.

:rolleyes: . What rock are you sleeping under? :grin: . Yes, there's
a lot of talentless n00b's. People with no talent and no desire to learn.
A lot of the "old guys" have grown weary and have left the kiddie crackers.
Also, people seem to keep the best tools to themselves, because of all
the bullshit scene competition stuff. There *are* working generic safedisc2
unwrappers around, but the groups keeps them to themselves so they can
be the ones to release <whatever new thingamajig> before the rest, and
thus get more credits on the 13370 FTPz. Lame? Yes.

But I wouldn't say that there's not much talent in the "scene" these days.
Dongles are still popped. Wrapping schemes are still unwrapped. DAMN takes
care of the strong crypto. Some are in it for the fun, others for the leech
site access. Fact is, if you release a shareware app, it *will* get on a
groups supply list no matter how lame and pathetic the application is. And
almost no matter what you do to the application, it will be cr4xx0red.
The only thing you can really do is to make your program worth buying.
No "leet old UPX version" will do that for you.
Posted on 2002-01-27 20:53:45 by f0dder
Kool

Thank for letting us rookies hear how deep this stuff can really be. You Guys are the best...

Can we get a one shot deal here where with-in the next couple of week where the ones who are concern to present only 5 - 7 question each all at one time and wait until you guys find time to reply. Than be done with it...

We be happy (PS: It would be nice if the Board had a special secssion one week every other month or so just to keep the members abreast. ....Just a thought
Posted on 2002-01-28 00:56:47 by cmax

BTW Mob,
Why can't use use the original offsets since in theory the rest of the code isn't going to be changed... meaning can't you just modify the open process based on the start offset and the end offset of the code you want to encrypt? How hard is it to modify the "inimport" program that you wrote in the masm32 example8 folder?


hm, you want to have a secure, encrypted, self-extracting
method... two ways are in my mind...

if you want it to be SFX you'll need something like a host
that automaticly generates executables... that means your
code + your encrypted data will be relocated

1st way: use use the regular pe-frame and just copy the
encrypted code into it... you have to use delta-fixed offsets
and you can't use api's the normal way, too... you have to get
the kernel base and loadup those api's for yourself... (yup
this example i gave in hutchs masm pack can be modified very
easy i think... i've got nevr and better versions if you want...)
even if that sounds pretty hard it's the easier way in my
opinion...

2nd way: you Have to Use a fixed pe-frame with import table.
determine The size of the encrypted data and change the pe
header section entries... i'm not sure but if you be carefull with
the offsets and api's you have to use, a "standart" way could
be possible but That should be very hard to implement...


Anyway, the reason why I'm writing is that from what you wrote it may seem that you know e.g. how to get LoadLibrary's address without importing it in your PE.. is it right? If so, how do you do it?


you can use api's without importing them, yes... in the normal
situation you could use loadlibrary & getprocadr to obtain your
goal... for code that will be relocated (v1riis, self-extracting,...)
there are other ways to do it...

you could scan the current executable's import-sec for the
presence of "GetModuleHandle", this api is imported in almost
every executable (maybe 95% i think...), if you have the adr
you Can use this api to get the base-adr of every dll you want,
say kernel32... now you can scan the export dir of kernel for
"GetProcAdress"... if you found This one you can now reach
every api you want...

but... you could also use this way (the better way i think):
EVERY win32 app is loaded by the kernel (CreateProcess)...
so if you doubleclick a executable windows will load up this
prog with "CreateProcess"... remeber if you CALL something
the current InstructionPointer will be pushed to the stack so
that the called function can retrurn properly (ret)... our goal
is to get the kernel-base... so just grab the first stack-entry
and you're inside the windows kernel... now you just scan
backwards until you find some of the known pe-marks (MZ,
PE/0/0)... there are a couple of checks to do but thats not
to hard... now you have the REAL kernel-base... you can
scan the pe-structures (export-dir) to get the api's you want...
i wrote a routine for this purpose... you just generate some
thing like a structure with the api's you want... later this
structure is filled with working pointers so you can use those
api's from now on...
Posted on 2002-01-28 03:24:18 by mob
mob, there's no guarantee that kernel32 CALLs your app.
It does on all current win32 versions, but nobody can tell
if it will remain doing so. As for GetModuleHandle, it will
probably only work for DLLs you are importing from (and DLLs
your imported DLLs import from.)

And remember that if you do manual importing, you must handle
NT-style redirected exports (which also means something you
think is in kernel32 is really in ntdll.dll, which means you
might even end up getting ntdll.dll base instead of kernel32.dll.)

The safest approach is probably to make (at least) one import
from each DLL you want. Then you can use GetModuleHandle to get
the DLL base (it's tempting to base-scan yourself, but if your
import has been redirected it will not work). Once you have the
base, it *should* be safe doing a manual GetProcAddress.
Posted on 2002-01-28 07:15:25 by f0dder
f0dder, i know that... but till now these techniques ARE win32
compatible... thats all i want... if microsoft changes this... bad
luck. btw i don't think they will... but even if they do... new
methods will developed. GMH?

scan for GetModuleHandle in the IMPORT dir of some executable
use this api to get the KERNEL32 base
scan KERNEL32 for GetProcAdress and maybe LoadLibrary
use those API'S to get other Dll's and Function's
stupid but it will work, WITHOUT GETTING KERNEL STACK ENTRY
result? FULL w32 compatiblity, even in future win versions...
oh and for "it will probably only work for DLLs you are importing
from (and DLLs your imported DLLs import from.)
" --- LoadLibrary

btw to sliver, cmax and all the other people that want to gain
knowledge about topics that differ from "standart" win32 coding:
yup, many v1riis use similar techniques but that doesn't have to
mean that this kind of stuff is evil, it can be widely used for very
usefull puposes like protection, security, whatever... there's no
doubt about it. i recommend reading tutes about the pe-format
at first... it's quite interesting and you'll learn what happens with
your code after it has been mapped... then you'll understand why
you can not just paste code or have to fix offsets or have to
struggle with the kernel to retrieve api-usage... stupidly you'll find
the most interesting stuff on v1rus-related sites but that should
not prevent you... i started learning this thing coz i was bored...
windows coding can be VERY boring sometimes... it's EVERYTIME
the same, CommonControl, DialogHandler, ToolHelp, bla bla bla...
everytime? ok, as i said, *sometimes* :)
Posted on 2002-01-28 07:21:28 by mob
f0dder,

If you are taking 5 minutes to unpack an EXE compressed with UPX 0.84, you are losing it but if you think that this is a reconstruction, you are abusing it. Getting it to run is kiddie level stuff, trying to modify it is another matter, if you bothered to look, it retains both the compressed and unpacked data and it still runs from the uncompressed data.

I have a particular program in mind here which I wrote before I had a HDD failure 2 years ago which I got to run in about 2 minutes. (Had to find the toys I wrote on my HDD :) ) Memory dumped it and did the fixups for the difference between disk and memory image offsets and voila, it runs. Problem is it still runs off the compressed data so simply patching it in a HEX editor is not going to help you here.

What the file needs is a full reconstruction just to get rid of the extra data and this will not reconstruct it, it will just make the file modifiable. Now I am sure that you are familiar with how simple length checking and CRC checking is in an EXE file, there are of course other ways to test if a file has been modified and this means just 1 byte difference, not a simplistic unpacking of an EXE file that has very large differences from the packed version so detection of change is kiddies stuff to do.

Now doing something this simple is enough to break most l3et0 w4nN4b3e cR4cK3rZ and it does not involve anything smart yet. The most common approach is to spread the tests across a complete application over a range of different categories so that the w0uLd b3 l3et0 has to do a lot of hard low level dirty work to even try and find what the checks are and there is no 5 minute effort that will do this.

As you would be aware, an EXE file is a big bag of binary with a multitude of critical numbers in it and it is trivial to fiddle any number of its bits to stop it from working. The most successful methods of preventing a file from being easily hacked use multiple techniques that are aimed at increasing the dirty work needed to be done by a massive amount and there is still nothing smart done here yet.

When the workload to break a protection system exceeds the time to write it, the protection system is working. I suggest that the days of easy cracks are over and this is enough to beat most attacks.

The next trick is to vary the system each release so the few who are smart enough to beat a tidy system have to do it all again. There comes a point where its not worth bothering and this is more or less how modern protection systems work.

It is easy to say that any file can be broken but what is not being said is the time frame to do it, having a crack ready for the release of Win3k is probably too late to bother the original program's owner.

What my advice to authors is in protection schemes is to start somewhere and this means start doing the simplest things first, compression is one of them that increases the workload on the freeloader while being easy to do. Depending on the requirement, there are many more things that can be done and being original just make the task harder for the attacker.

Regards,

hutch@movsd.com
Posted on 2002-01-28 12:33:51 by hutch--
Mob,

scan for GetModuleHandle in the IMPORT dir of some executable
use this api to get the KERNEL32 base
scan KERNEL32 for GetProcAdress and maybe LoadLibrary
use those API'S to get other Dll's and Function's

Who says GetModuleHandle will not be forwarded to, say, ntdll.dll
in some windows release? If you want to be 100% compatible, you
have to at least do LoadLibrary.

-----------------

Well, I'm sorry hutch, but my 5 minute dump (yes yes, I'm losing it)
includes making it run from the uncompressed data and fixing up the
imports to proper values instead of machine-dependant values.
I don't know if you're familiar with asprotect, it's anti-debugging
tricks, fake APIs, chunk encryption (etc). But "even" asprotect is
broken routinely... and no, we're not talking about weeks or days
of work.


so detection of change is kiddies stuff to do.

And kiddies stuff to remove. Ok, admitted, if you pepper them ALL
over the place, they can turn out to be annoying, especially if you're
smart enough to delay the checks, and delay the shutdown of the app
as well.


As you would be aware, an EXE file is a big bag of binary with a multitude
of critical numbers in it and it is trivial to fiddle any number of its bits
to stop it from working.

And trivial enough to change something so that it suddenly only works
on some windows versions. If you go fiddling with PE header values
runtime, you'd better know exactly what you're doing. Lots of people
who do this don't.


When the workload to break a protection system exceeds the time to write
it, the protection system is working. I suggest that the days of easy cracks
are over and this is enough to beat most attacks.

True. But most stuff today (because it relies on ready-made protection)
does *not* take very long time to break. IDA is one of the few apps that
have not been totally broken yet, and that's because their user group is
small enough that the main executable can be compiler per-user. It seems
like they got rid of all the watermarking and keychecks though...
Posted on 2002-01-28 13:07:07 by f0dder
Hutch--, these things should be built into the tools, IMO. Programatic convolution of code at non-time critical sections would be a nice feature to program into an assembler. Whoever tries to modify the program would have to write a special disassembler to handle the convolutions - not your average guy messing with your code. Even writing macros in IDA would take some talent to counter such methods.
Posted on 2002-01-28 13:07:35 by bitRAKE