In win98, I used the following code to get the Int 1 address:
sidt fword ptr pIDT ; Get IDT
mov eax, dword ptr ; eax -> IDT
add eax,8 ; eax -> int 1 "vector"
mov ebx, ; ebx == int 1 "vector"
However, when I execute this on Windows XP, it crashed with a c0000005 exception on the 'move ebx, ' instruction. Does anybody have the same problem and does anybody know a solution maybe ?

Posted on 2001-12-28 01:53:13 by _dante_
doh. XP is a little better protected then 98 ;) and why gain ring0 in such way? or is it for other uses?
Posted on 2001-12-28 09:24:43 by lifewire
I'd like to see which interrupts are hooked by other than system programs, for security purposes. In win98 for example, the int1 and int3 vector adresses start with $c000, if they are assigned to VMM procedures. I'd like to see in XP too, which vectors are hooked by VMM and which are hooked by 'third party' software. Do you know of another way to check the interrupt hooks ? Thanks for your time,
Posted on 2001-12-28 09:36:29 by _dante_
Realize that the NT kernel is very different from the 9x kernel.
Realize that you will have to code a KMD in order to do this cleanly.
Realize that messing with the interrupts are just about useless...
if you're doing this to implement some form of "protection", don't.
it will cause more annoyances then it will help you.
Posted on 2001-12-28 14:09:13 by f0dder
Hi f0dder,

Thanks for you reply, but why is it not good for a protector ? Why do you think it won't help me ? I think getting ring0 access is absolutely necessary for a good protector (otherwise you'll have to use these standard 'tricks', like backdoor interface, which are not too useful, considering the 1001 patches out there for winice (from Elicz etc)
Posted on 2001-12-29 08:17:36 by _dante_
Ring0 is messy, and requires 9x- and nt-specific versions. Lots of
NT users don't want to run as administrator just to be able to run
a silly application.

Sure, you can do more stuff in ring0, and if you know what you're
doing you can slow an attack down. But you risk adding an awful
lot of problems. I'm tired of dirty crap code that only runs on some
windows versions, or plays annoying tricks. And why shouldn't an
application run just because I have softice loaded? *sigh*.

If you want to protect... obfuscate and use clever algorithms. But
stay clean, stay ring3, play by the rules. And don't ever target any
specific applications (softice). It's annoying for legitimate users,
while most crackers will know how to avoid specific checks.
Posted on 2001-12-29 08:49:20 by f0dder
And why shouldn't an application run just because I have softice loaded? *sigh*.

That's really frustrating. I think Acrobat reader does this, as soon as I start softice, I can't view pdfs anymore. :rolleyes: What are they thinking? That I'm going to crack their free program? :)

Posted on 2001-12-29 09:06:54 by Thomas
I agree, it's most irritating when a program doesn't work, just because softice is loaded, but from the coder's point of view it's sometimes just necessary. I mean, it's so frustrating to find that a progam you've put so many months of hard work into, is cracked (in a few minutes) by some stupid newbie wannabe hacker (it are mostly those damn kids in cracking crew's that release cracks, the real advanced/skilled crackers mostly don't, I mean, how many cracks did you see by guys like Iczelion or Elicz or +Frogs ?). So, I think the goal of a protector should be to keep the beginners/medium hackers away (also because you simply CAN'T keep advanced crackers from cracking it, I mean, an ASM guru like you yourself, F0dder, could probably crack the most difficult schemes in a few hours). So, if Ring0 access is necessary to make it harder for the newbie/medium crackers (most of them can't even code a VxD), I think you should do it, even though it will be irritating for 'good guys' like you and me, that use softice for other purpose than cracking. And BTW, the specific program I'm protecting CAN only be run in administrator mode, so it's no problem that the protection also needs it (and I'll make sure that the code will run on different kernel version's, the Win 9x VxD I coded already does run on 95/98/ME kernel's without any problems.
Posted on 2001-12-29 11:21:55 by _dante_
Thomas, start adobe without softice loaded, and disable the "buy online"
(or whatever) module. They seem to be afraid of people discovering
their scheme... smells a bit of an insecure implementation ;).

dante, I am in no way an asm guru. I know some stuff, but I'm
hardly a guru. And cracking bores me, I can't be bothered to trace
through those "needle in a haystack" protections.

Why do people release cracks? Some for the fame, some for the
site access. And trust me, there are some pretty amazing sites
out there... seems to be in a bit of a "rebuild" phase right now because
of the recent cracker/warezgroup busts, but that's only a temporary

Well. You don't need to stop softice or play nasty tricks to get an
okay level of security. The most software that gets cracked are the
endless streams of shareware with crappy protection. You just need
something that is pretty obfuscated and annoying to trace - most
crackers will give up and choose another target from their supply list.

SEH can be used for a lot of fun stuff. I suggest you try handling
int3, and make your int3 SEH perform some crucial function (like
decrypting). Have multiple SEH handlers and switch between them.
This will make the code pretty annoying to trace. Note that 9x and NT
has some differences in how they handle int3 in SEH, so you'll need
a GetVersion check somewhere.

Encrypt parts of code that are only supposed to be run in the registered
version. Have the encryption key "somehow" in the registration data.
This can, if implemented effectively, make your app impossible to
crack without a leaked key. Hide user ID in the registration data
and you can keep track of who leaked your key.

Obfuscate API calls to make disassembly readings damn annoying.

Use VirtualAllocEx and position-independant code, decrypt,
decompress, and use that for some critical code code fragments.

These tricks are clean, in the sense that they will run on any win32
(if implemented correctly), don't target any specific tool, and do not
require administrator privileges. You can keep most crackers away
with this approach (the "I need site leech access" crackers), while
the good crackers *would* be able to defeat you. But the leech-crackers
are the only crackers you can ever hope to stop. If you use ring0
code, you risk attracting the attention of the better crackers.
Posted on 2001-12-29 13:51:14 by f0dder