Well actually there is a way of getting Kernel32 without linking but I think this can only be used by viruses so I don't think I'll mention it.
Why "can only be used by viruses"? :grin:

I didn't think that there were virii-only ways to call standard Win32 libraries.. you mean that if I use it in a 4KB intro will it infect the PC's? :eek:

Thanks for your help anyway, I'll save others a google search and put the files here that explain how to do it.

Note also that if one really wanted to write a virus, you probably haven't stopped him from doing *that*.

---

kungfoo :: advanced x86 win32 shellcode to retrieve the relative virtual addresses of the functions GetProcAddress and LoadLibraryA by scanning the kernel32 image in memory and retrieving them from the export address table. this code assumes no hard coded function calls therfore provides a dynamic way to retrieve the two most important addresses on the fly in a system independant way. yes, my kungfoo is the best ;-)

style :: x86 win32 shellcode snippet to provide a standard routine for loading librarys into your address space and retrieving API addresses from that library for use in your shellcode

getbase :: win32 app to retrieve kernel32's base address in memory.

getaddr :: win32 app to retrieve a functions address.

---

Greets,
Maverick
Posted on 2002-01-25 18:49:43 by Maverick
This is an interesting program. I think it still requires the target process to inport from kernel32 otherwise it would not be in the address space. When I said I was trying to not post things relating to viril I wasn't trying to stop people making viril I was trying to keep viril out of this board. Anway I think the purpose of that shellcode program it to run within another process wich is what a virus dose.
Posted on 2002-01-25 19:08:05 by Quantum
I'm pretty sure that KERNEL32 is running in your process even if you have zero imports. In fact a simple RET instruction (as opposed to a full ExitProcess) will anyway make us jump to a KERNEL32 routine that will do more or less what ExitProcess does (maybe it even points directly to ExitProcess).

Greets,
Maverick
Posted on 2002-01-25 19:40:27 by Maverick
I thought the only reason Kernel32 was in processes was because most processes will need ExitProcess but it turns out that its always there
Posted on 2002-01-25 19:45:20 by Quantum
There are a couple of things here, encrypting EXE files is usually a waste of time in that for the file to run, it must be decrypted somewhere, IE the time when you do a direct memory dump and get the code anyway. Lorian developed a smart way that fooled many for a while where he encrypted the import table but it was eventually broken.

The seemingly endless reference to cracking and viruses is not what this forum is about, the "crackme" scene is a leftover of the old cracking scene and while there is probably nothing illegal in security testing and design, the associations with illegal activity make it a NO NO here.

Same goes for VIRUS reference, posting information on techniques that can be used for this type of development is also a NO NO. Negative reference to virus development, (this could/could not be used to develop viruses) only proliferates the problem so please give it a rest.

The self modifying code posted by MOB is fine in that it is used for making program security more difficult to break, I have an simple example of SMC in MASM32 and it is also designed for that purpose.

Just be careful in that our new moderators are more efficient than the inquisition at sniffing out code and idea that should not be posted here so please keep this crap "outa here".

Regards,

hutch@movsd.com
Posted on 2002-01-25 20:14:35 by hutch--
If a simple ret in the startup proc will do the same that ExitProcess then why use it?

hutch


There are a couple of things here, encrypting EXE files is usually a waste of time in that for the file to run, it must be decrypted somewhere,


Most executable encription and CRC checking is for minimizing the probability of cracking or corruption. Of course that people will think of ways of circunventing its protection (after all they have more time than the developer), but at least it would be not that easy for everyone. Piracy is almost impossible to stop (unless your program is so crappy that nobody will care to crack it :) ). So the next best thing is minimizing it.
Posted on 2002-01-25 21:00:15 by dxantos
ExitProcess *should* clear up any resources you use. Well, "commmon"
resources anyway, including DLLs and whatnot. GDI object can be tricky,
but 99% of them should be cleaned up. Not that importing dynamically
will not avoid detection if your attacker has half a clue, a "bpx" in
softice will break nevertheless. Your apps will be a (little) slower,
be it load-time or runtime. And if you don't loadlib/getprocaddr, you
might end up with compatibility issues. Fine for 4k's, perhaps 64k's,
but not really acceptable for anything else.

Kernel32 will always be in your address space on 9x, but NOT on nt/2k.
In fact, if you don't import kernel32 (and none of your DLLs end up
importing it), win2ksp2 (and perhaps earlier) will fail to load your
executable. See why you must play by (some of the) rules?

Kernel32 base *can* be found on *all* current win32 versions (well,
haven't tested win32s, but 95 95sr 98 98se nt4 2k xp) by looking at
the dword at on program startup, but *only* generically if you
import kernel32 in the main app. And even this fact might change in
a future win32 version, so use with care.


If a simple ret in the startup proc will do the same that ExitProcess then why use it?

Because ExitProcess can be used anywhere and follows the win32 standard.
A "ret" only works when the stack points to the right return addr,
perhaps it has more requirements that need to be fulfilled, and it is
*undocumented*.
Posted on 2002-01-25 21:14:47 by f0dder
Hutch,
I don't believe the question I asked was irrelevant... and due to the fact that the code created in Crueme 1.0 took 8 months to crack (even with a straight dump) should show that this is just another wrench in the asm toolbelt...

I didn't want to discuss ... but I *did* want to know how to encrypt a file within itself... Just because use this technique doesn't make it wrong...

If I had asked:

Can someone help me with polymorphic code or opcode alteration I would have been told, "those are techniques -- you must be creating one".

but where else can I learn these techniques then if not from themselves... I don't want to create them, but for sercurity reasons I would like to understand them better...

Should "streams" be considered a NO NO topic because some guy wrote a program that used them to destructive ends?

Important part:
I do understand the need to keep that sortof material off this site... but I tried my best to rephrase the question the best I could... I really want to learn this information and I don't want to goto to get it...

I hope I haven't been disrespectful... All I want to do is learn some basic information of this technique...

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?

Sliver

:):):)
Posted on 2002-01-25 21:45:32 by Sliver
Sliver, you haven't said a wrong word at all :). Well, at least not as
my broken mind remembers ;).

Get on irc/icq/email with me, and we'll go through some stuff that'd
be hard to go through here (even if not directly bad). Might have to
wait until after the weekendl, as saturday's celebrating of my friend's
22nd year birthay might leave me "somewhat" hung over ;). But,
as I said, send me a mail and let's converse.
Posted on 2002-01-25 21:53:05 by f0dder
Kernel32 base *can* be found on *all* current win32 versions ... by looking at
the dword at on program startup


isn't this the return address and not the base?
Posted on 2002-01-25 21:54:39 by Quantum
Just finished checking it the single ret with OllyDebug on Win2K.

It ends up calling ExitThread.

MSDN says about ExitThread:

If the thread is the last thread in the process when this function is called, the thread's process is also terminated


So the only issue that I see here is when you have an aditional thread. (I think then the program will not exit). But basically you are right fOdder to be on the safe side is better to use ExitProcess.

I dont know if is possible or not to run a Windows executable without kernel32.lib. Both OllyDebug and VC++ debugger failed when trying to load an executable without having an ExitProcess call. To do my test I did the ret before the ExitProcess.

On entry (at least on Win2k) OllyDebug Shows that the DWORD on ESP points to a jump than in turn will push eax and then call ExitThread. So I wouldnt really recomend it for finding kernel32 functions. (Since the address of the jump could vary).
Posted on 2002-01-25 22:03:46 by dxantos
Yes quantum, it is a return address (and you can't even count on it,
as it is undocumented). But on all current win32 versions, the return
address lies inside kernel32, so you can backtrack and thus find the
kernel32 base.

Dxantos, as long as your programs "ends up" importing something
from kernel32, your process will load. So, even doing a single import
from gdi32 should be fine, as gdi32 (eventually) ends up importing
some stuff from kernel32. And on 9x (and perhaps some earlier NT),
the app will load even without kernel32 imports.

But if you want to be safe, import at least kernel32.ExitProcess.
And know that you cannot count on using a imported function
address to trace back to the base of the DLLs, as NT supports
export redirection.

Btw, a win32 application without imports and just a single "ret"
will seem to work if you run it, as it will fail silently. But it will fail
to load in any debugger :).
Posted on 2002-01-26 03:09:36 by f0dder
Sliver,

What you are interested in doing is not a problem but where the topic brings in discussion of illegal activities, that discussion is a problem and it will be treated as a problem.

Protection systems have been developed for years so if you have a use for them, start working on PE file format to see what needs to be done to restructure a file in such a way that the code you require can be encrypted. PE compressors have to do much the same work so it definitely can be done.

They come in various flavours from simplistic to very sophisticated but they all have one characteristic in common, they can be broken because they can be run by the system loader.

A memory dump will get most of the information to break it, the smarter stuff I have seen "injects" a DLL into the PE file and accesses more or less whatever is wanted by the investigator.

I personally prefer dynamic protection systems that are written in the code as they are a lot harder to break and a lot harder to detect if they are broken or not which is part of the problem for the "would be" cracker.

Regards,

hutch@movsd.com
Posted on 2002-01-26 04:35:38 by hutch--
hutch:

I think that virii are very stupid things, since to destroy data or whatever else, when it took so many efforts to create it, is worth a psycho or an idiot.
I am *VERY* concerned about protection, and have always been, with my commercial games both to protect them from piracy and to hide my own code. Personally I've never mentioned virii, it was others that did it, I used that word only in reply to them. Virii are much less than my latest worry here, and neither that.



f0dder:

you're right, all summed up I prefer to import explicitly LoadLibraryA and GetProcAddress, and then do all the rest with these two. There's no advantage in looking for them in memory, only the disadvantage on NT based OS.
I'm concerned with API hooks now though.. so I think I'll load the 500KB image of the DLL and just use that. Not as RAM friendly as the shared DLL, but without possible API hooks.
This will be do-able if the OS allows another KERNEL32 image (mapped manually though) to work too.
As for SoftICE and every other debugger or debugging method, of course that sums to the list of anti-debugging arms to use.. together with many others, original, too.


Sliver:
If I had asked: Can someone help me with polymorphic code or opcode alteration I would have been told, "those are techniques -- you must be creating one".

in fact I too think that this discussion is perfectly relevant to this board.. encryption is not only algorithms but also practical and useful use that one does with it.. like protecting your own code (rather than simple data) from real hackers (honestly I've never liked the use of that word on Internet freaks that just run "ping" on a Unix shell.. blah).
Should "streams" be considered a NO NO topic because some guy wrote a program that used them to destructive ends?

Be afraid, those stupid things we can't name are often written in assembly. ;-)
Important part: I do understand the need to keep that sortof material off this site... but I tried my best to rephrase the question the best I could... I really want to learn this information and I don't want to goto to get it...

It's not your or my fault if virii were named..

Greets,
Maverick
Posted on 2002-01-26 06:30:03 by Maverick
Hi hutch:

I personally prefer dynamic protection systems that are written in the code as they are a lot harder to break and a lot harder to detect if they are broken or not which is part of the problem for the "would be" cracker.


I do too, those are the really powerful ones, but adding also "static" protection is not bad.

Greets,
Maverick
Posted on 2002-01-26 06:38:13 by Maverick
I have not gotten into code protection yet, because it seem that no body want you to know how....

Why can't this board have an section that pretain to this subject. I don't want to join the hacker union to get information about protection. Were not kids...Everybody don't want to be a dirty hacker. Were not learning ASM for our health...

This post is the best i read about code protection, and this is'nt much, but it's a dame good start....I did not know poop.

We just need a place to start and than we could set out on our own as it should be....But we got to at lease have SOME KIND of IDEA so we can protect our work.

We got to have somewhere to start...At lease i do...Why should i take all that i learned and worked for and let even someone dumb as i may be rip my work to streads....

But I know where Hutch is coming from....He know that People Get Carryed Away...And we all know there is a big crack down on even the most legal sights...And you know Govervement don't want you to know poop...They scare Toooo...They the real cracker... So I guest im back where i started...

But when someone get into this seriously, COUNT ME IN... by the end of this year i will know 1/3 of it ALL...
Posted on 2002-01-27 02:51:27 by cmax
Hello cmax,

You're right, it's a very "personal" thing.. so all the best ideas won't be disclosed and you've to find your own.. but most generic things can and will; and most of all, informations as inner working of the OS, etc.. can and will be disclosed to anyone.

For a start, check these pages:


Anti Cracking FAQ:
http://inner-smile.com/nocrack.phtml


HOW TO PROTECT BETTER:
http://fravia.kilrathi.pl/protec.htm


Another page:
http://www.soft4you.com/vitas/antihack.htm


Box Sk (more advanced stuff):

http://neworder.box.sk/box.php3?gfx=neworder&prj=neworder&key=cracking&txt=Code%20cracking

and:

http://neworder.box.sk/box.php3?gfx=neworder&prj=neworder&key=hack-crypt&txt=Cryptography

The latest two links are from an ambiguous place, so to speak.. but also the anti-cracking FAQ has got interviews to crackers.. so WTH?


Greets,
Maverick
Posted on 2002-01-27 06:24:51 by Maverick
PS: go get OllyDbg v1.05a2 and start experimenting with debuggers. Later you may want to buy SoftICE instead.

BTW: is there a simpler way to run SoftICE on Windows ME than downloading Windows ME's huge DDK?

Greets,
Maverick
Posted on 2002-01-27 06:26:48 by Maverick
cmax,

The idea of protecting code comes with knowing something about what it looks like in decompiled form and this of course means reading the code in assembler. I supply Clive Turvey's simple but effective DumpPE so that what you write you can immediately check what it looks like as an assembler dump.

The basics of attacks on your code is the capacity to simply modify parts of your code in HEX as the information on opcodes is available including the small utility in MASM32. This in the simplest form is changing a JE to a JNE or similar after a check on some registration system.

Contrary to popular myth, simply compressing an EXE file makes hacking it a lot harder and it gets rid of the capacity to make a simple binary patch for you EXE file that will remove the protection. Some people can restore the file with a lot of work in NTICE but some EXE compressors make a hell of a mess of the sections in a PE file. UPX 0.84 is a good example of a compressed EXE that is very difficult to restore to its original form.

Next trick is to both length check and CRC check the EXE file from within itself and if it is incorrect to what you originally built, shut the file down. There are many simple things you can do to make the job of attacking you file harder and slower. Experienced attackers can beat all of these methods but they will stop the ordinary hacker dead.

If you read around the internet in this area and perhaps some of the old cracking sites, you will find a lot of information on how the majority of protection systems work and this is a good reason to avoid them as they are easy to break by most attackers.

Once you understand the basics of how you file could be attacked, you will start to write code that avoids most of the common mistakes.

You are right in my view on what can be posted here, the idiot fringe will attack this forum if illegal things are posted here and this can also be well intended postings that are not well thought out. To help protect this forum, I have asked members to refrain from making reference to cracking or virus related issues as it only gives this idiot fringe a reason to try and destroy the forum.

Good luck with your investigations into protecting you software from attack.

Regards,

hutch@movsd.com
Posted on 2002-01-27 07:04:12 by hutch--

Contrary to popular myth, simply compressing an EXE file makes
hacking it a lot harder and it gets rid of the capacity to make
a simple binary patch for you EXE file that will remove the protection.

You can't make a binary patch, true. But it doesn't make a file
much harder to attack, unless you're using an advanced packer / protector.
Even if you can't dump the file correctly (ie, unpack it), you can
usually use a memory patcher.


Some people can restore the file with a lot of work in NTICE but some EXE
compressors make a hell of a mess of the sections in a PE file.
UPX 0.84 is a good example of a compressed EXE that is very difficult
to restore to its original form.

UPX difficult to restore? Heh :). UPX is a regular packer with no
anti-unpacking tricks whatsoever. Trace to original entrypoint and
dump, and you have a working executable. It might not end up in
"original form", but section names are pretty irrelevant as long as
the executable runs.

And this is not a very advanced topic. Even clueless crackers are
able to unpack simple stuff like UPX. With the tools available today,
annoying schemes likes asprotect can be unpacked by people who don't
even know exactly what's going on.


Next trick is to both length check and CRC check the EXE file from
within itself and if it is incorrect to what you originally built,
shut the file down. There are many simple things you can do to make
the job of attacking you file harder and slower. Experienced attackers
can beat all of these methods but they will stop the ordinary hacker dead.

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.
Posted on 2002-01-27 10:13:32 by f0dder