Hi all,
OK, let me explain a little further. :-) I'm not looking at a scenario
where I'm trying to avoid people hacking into a machine remotely.
Many apps out there require serial numbers. The compiled code of the app,
whether it be IL or i386 assembly, typically will boil down to a junction
We will publish (as open source) by he end of the week our
ThonaConsulting.Licensing.LicenseManager class, which should be a little
harder to hack :-)
Why? Well, we basically use signed XML configuration files - you can not
just replace a je/jne with a jmp, when the reach into the class picks up
Thanks Mike. Unfortunately, while I'm aware of the ability to break as soon
as the exception is thrown, it's not usually a good thing, which is why it's
off by default. The problem is that the program halts even on handled,
expected exceptions. Consider the following Paint code:
try {
---
I already sent this post to the DOTNET-CLR list, but didn't get a reply.
Maybe someone on this list can provide me some information.
---
I would like to write a server application which can handle http AND
socket connections, depending on the J2ME MIDP client capabilities.
If
I ask again. I'm trying emit this:
-
public class Test13_ConstLiteral
{
enum LiteralEnum : long
{
one, two
}
const Test13_ConstLiteral.LiteralEnum en =
Test13_ConstLiteral.LiteralEnum.two;
}
-
by using Refelction.Emit.
I wouldn't really refer to this scenario as hacking per se. More like
violating the terms of the licensing/stealing/etc.
In fact, what you are sketching is quite trivial. The CLR isn't going to
help at all.
You could, for instance, strongly-name your assemblies and load them
locally (i.e., not
Your test is quite artificial. I'm not sure that is really very
meaningful for an actual application. Given all the functionality of
remoting, I'm quite impressed with its performance for both protocols.
HTTP is built on top of TCP and has additional handshaking built into
it. I would expect it
I would modify that statement:
It
does not look like relying on the CLR to ensure assemblies have not
been
tampered is a viable solution.
This is only true *in the absence of a secured underlying platform*.
IOW, don't bother relying on the CLR if you don't secure the OS.
However, If you do
Hi all,
I'm back with another exception safety musing. Let me start by stating
that one of the goals of exception safety is to ensure the integrity of
the software in the face of exceptions. That being the case, consider the
following contrived C++ class.
class MyClass
{
public:
Yes, absolutely. Sorry I did not make that distinction before.
Thanks,
-Trey
I would modify that statement:
It
does not look like relying on the CLR to ensure assemblies have not
been
tampered is a viable solution.
This is only true *in the absence of a secured underlying platform*.
Hi there,
System.Enum.ToObject() is your friend -- here's a simple
example of (non-nested) use:
EnumBuilder enumBuilder =
moduleBuilder.DefineEnum(SomeEnum,
TypeAttributes.Public,
11 matches
Mail list logo
